Re: [PATCH] D9924: Ignore report when the argument to malloc is assigned known value

[Aditya Kumar via cfe-commits]

hiraditya updated this revision to Diff 32381.
hiraditya added a comment.

Refactored the code and check whether denominator > 0.


http://reviews.llvm.org/D9924

Files:
  lib/StaticAnalyzer/Checkers/MallocOverflowSecurityChecker.cpp
  test/Analysis/malloc-overflow.c
  test/Analysis/malloc-overflow2.c

Index: test/Analysis/malloc-overflow2.c
===
--- /dev/null
+++ test/Analysis/malloc-overflow2.c
@@ -0,0 +1,36 @@
+// RUN: %clang_cc1 -analyze -analyzer-checker=alpha.security.MallocOverflow,unix -verify %s
+
+typedef __typeof__(sizeof(int)) size_t;
+extern void * malloc(size_t);
+extern void free(void *ptr);
+
+void *malloc(unsigned long s);
+
+struct table {
+  int nentry;
+  unsigned *table;
+  unsigned offset_max;
+};
+
+static int table_build(struct table *t) {
+
+  struct offset *offset;
+  unsigned i, m;
+
+  t->nentry = ((t->offset_max >> 2) + 31) / 32;
+  t->table = (unsigned *)malloc(sizeof(unsigned) * t->nentry); // no-warning
+
+
+  int n;
+  n = 1;
+  int *p = malloc(sizeof(int) * n); // no-warning
+
+  free (p);
+return 0;
+}
+
+void * f(int n)
+{
+  return malloc(n * 0 * sizeof(int));  // expected-warning {{Call to 'malloc' has an allocation size of 0 bytes}}
+}
+
Index: test/Analysis/malloc-overflow.c
===
--- test/Analysis/malloc-overflow.c
+++ test/Analysis/malloc-overflow.c
@@ -102,7 +102,7 @@
 {
   if (s->n > 10)
 return NULL;
-  return malloc(s->n * sizeof(int));  // no warning
+  return malloc(s->n * sizeof(int));  // no-warning
 }
 
 void * f14(int n)
Index: lib/StaticAnalyzer/Checkers/MallocOverflowSecurityChecker.cpp
===
--- lib/StaticAnalyzer/Checkers/MallocOverflowSecurityChecker.cpp
+++ lib/StaticAnalyzer/Checkers/MallocOverflowSecurityChecker.cpp
@@ -23,18 +23,22 @@
 #include "clang/StaticAnalyzer/Core/BugReporter/BugReporter.h"
 #include "clang/StaticAnalyzer/Core/Checker.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/AnalysisManager.h"
+#include "llvm/ADT/APSInt.h"
 #include "llvm/ADT/SmallVector.h"
 
 using namespace clang;
 using namespace ento;
+using llvm::APInt;
+using llvm::APSInt;
 
 namespace {
 struct MallocOverflowCheck {
   const BinaryOperator *mulop;
   const Expr *variable;
+  APSInt maxVal;
 
-  MallocOverflowCheck (const BinaryOperator *m, const Expr *v) 
-: mulop(m), variable (v)
+  MallocOverflowCheck (const BinaryOperator *m, const Expr *v, APSInt val)
+: mulop(m), variable (v), maxVal(val)
   {}
 };
 
@@ -54,6 +58,11 @@
 };
 } // end anonymous namespace
 
+// Return true for computations which evaluate to zero: e.g., mult by 0.
+static inline bool EvaluatesToZero(APSInt &Val, BinaryOperatorKind op) {
+  return (op == BO_Mul) && (Val == 0);
+}
+
 void MallocOverflowSecurityChecker::CheckMallocArgument(
   SmallVectorImpl &PossibleMallocOverflows,
   const Expr *TheArgument,
@@ -64,13 +73,14 @@
Reject anything that applies to the variable: an explicit cast,
conditional expression, an operation that could reduce the range
of the result, or anything too complicated :-).  */
-  const Expr * e = TheArgument;
+  const Expr *e = TheArgument;
   const BinaryOperator * mulop = nullptr;
+  APSInt maxVal;
 
   for (;;) {
+maxVal = 0;
 e = e->IgnoreParenImpCasts();
-if (isa(e)) {
-  const BinaryOperator * binop = dyn_cast(e);
+if (const BinaryOperator *binop = dyn_cast(e)) {
   BinaryOperatorKind opc = binop->getOpcode();
   // TODO: ignore multiplications by 1, reject if multiplied by 0.
   if (mulop == nullptr && opc == BO_Mul)
@@ -80,11 +90,19 @@
 
   const Expr *lhs = binop->getLHS();
   const Expr *rhs = binop->getRHS();
-  if (rhs->isEvaluatable(Context))
+  if (rhs->isEvaluatable(Context)) {
 e = lhs;
+maxVal = rhs->EvaluateKnownConstInt(Context);
+if (EvaluatesToZero(maxVal, opc))
+  return;
+  }
   else if ((opc == BO_Add || opc == BO_Mul)
-   && lhs->isEvaluatable(Context))
+   && lhs->isEvaluatable(Context)) {
+maxVal = lhs->EvaluateKnownConstInt(Context);
+if (EvaluatesToZero(maxVal, opc))
+  return;
 e = rhs;
+  }
   else
 return;
 }
@@ -103,7 +121,7 @@
 
   // TODO: Could push this into the innermost scope where 'e' is
   // defined, rather than the whole function.
-  PossibleMallocOverflows.push_back(MallocOverflowCheck(mulop, e));
+  PossibleMallocOverflows.push_back(MallocOverflowCheck(mulop, e, maxVal));
 }
 
 namespace {
@@ -126,33 +144,77 @@
   return false;
 }
 
-void CheckExpr(const Expr *E_p) {
-  const Expr *E = E_p->IgnoreParenImpCasts();
+const Decl *getDecl (const DeclRefExpr *DR) {
+  return DR->getDecl();
+}
+
+const Decl *getDecl (const MemberExpr *ME) {
+  return ME->getMemberDecl();
+}
 
+template 
+void Erase (

RE: [PATCH] D12052: [X86][SSE] Add _mm_undefined_* intrinsics

[Kuperstein, Michael M via cfe-commits]

I’m not sure how much people actually use these, but the AVX-512 versions of 
these, at least, can be very useful internally to implement AVX-512 intrinsics.
For AVX-512, we use the same GCC builtin for all 3 versions of the intrinsic 
(pass-through masked, set to zero masked, and unmasked). This is the same 
implementation that’s used in GCC, and is fairly clean, since the only 
difference is in the desired pass-through values (actual value, zero, or undef).

However, since we don’t actually have the undef intrinsics right now, we put a 
zero in the unmasked version as well, which is definitely a pessimization.
The plan is to change them to use undef once the undef intrinsics are 
implemented.


From: Eric Christopher [mailto:echri...@gmail.com]
Sent: Monday, August 17, 2015 21:33
To: reviews+d12052+public+a6057f04f570e...@reviews.llvm.org; 
llvm-...@redking.me.uk; craig.top...@gmail.com; Kuperstein, Michael M
Cc: david.majne...@gmail.com; Badouh, Asaf; cfe-commits@lists.llvm.org; Richard 
Smith
Subject: Re: [PATCH] D12052: [X86][SSE] Add _mm_undefined_* intrinsics


On Sun, Aug 16, 2015 at 3:05 AM Simon Pilgrim 
mailto:llvm-...@redking.me.uk>> wrote:
RKSimon added a comment.

Yes using that uninitialized value has worried me as well. I originally set it 
to zero (and considered using __ LINE __ or __ COUNTER __) but both introduce 
defined behaviour that I could see causing all sorts of problems further down 
the line in debug vs release builds. How undefined do we want our undefined to 
be? ;-)

Yeah, this is why I hadn't implemented them yet either.

I can create __builtin_ia32_undef64mmx / __builtin_ia32_undef128 / 
__builtin_ia32_undef256 / __builtin_ia32_undef512 if nobody can think of a 
better alternative?

This seems fairly heavyweight, but I don't have any better ideas. I'll assume 
we don't want to try to expose undef as a value in C (making it as something we 
could just add), if not then this seems to make the most sense. It's pretty 
painful/ugly though.

Are people using these or did they just notice for completeness? We probably 
_could_ define them to zero and leave it at that. It's not pleasant and slower 
than it needs to be but not crazy.

-eric


Repository:
  rL LLVM

http://reviews.llvm.org/D12052


-
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r245271 - [TreeTransform] Simplify code. No functionality change.

[Benjamin Kramer via cfe-commits]

Author: d0k
Date: Tue Aug 18 03:10:39 2015
New Revision: 245271

URL: http://llvm.org/viewvc/llvm-project?rev=245271&view=rev
Log:
[TreeTransform] Simplify code. No functionality change.

Modified:
cfe/trunk/lib/Sema/TreeTransform.h

Modified: cfe/trunk/lib/Sema/TreeTransform.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/TreeTransform.h?rev=245271&r1=245270&r2=245271&view=diff
==
--- cfe/trunk/lib/Sema/TreeTransform.h (original)
+++ cfe/trunk/lib/Sema/TreeTransform.h Tue Aug 18 03:10:39 2015
@@ -4719,9 +4719,7 @@ QualType TreeTransform::Transfo
 
   QualType Result = TL.getType();
   if (getDerived().AlwaysRebuild() || ResultType != T->getReturnType() ||
-  T->getNumParams() != ParamTypes.size() ||
-  !std::equal(T->param_type_begin(), T->param_type_end(),
-  ParamTypes.begin()) || EPIChanged) {
+  T->getParamTypes() != llvm::makeArrayRef(ParamTypes) || EPIChanged) {
 Result = getDerived().RebuildFunctionProtoType(ResultType, ParamTypes, 
EPI);
 if (Result.isNull())
   return QualType();


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

Re: [PATCH] D11797: [libclang] Expose the ElaboratedType

[Sergey Kalinichev via cfe-commits]

skalinichev added a comment.

Ping? Can someone commit it?


http://reviews.llvm.org/D11797



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

RE: [PATCH] RE: [cfe-dev] missing return statement for non-void functions in C++

[Sjoerd Meijer via cfe-commits]

Please see updated patch file attached, which now includes a fixed/added 
regression test.

Sjoerd.

 

From: Sjoerd Meijer 
Sent: 17 August 2015 13:34
To: 'Gabriel Dos Reis'; Richard Smith
Cc: Marshall Clow; cfe-commits
Subject: RE: [PATCH] RE: [cfe-dev] missing return statement for non-void 
functions in C++

 

Agreed, let’s get that right first.

The attached patch causes the program to trap for all optimizations levels, 
except when optimizing for size.

 

Sjoerd.

 

From: dosr...@gmail.com [mailto:dosr...@gmail.com] On Behalf Of Gabriel Dos Reis
Sent: 13 August 2015 21:51
To: Richard Smith
Cc: Sjoerd Meijer; Marshall Clow; cfe-commits
Subject: Re: [PATCH] RE: [cfe-dev] missing return statement for non-void 
functions in C++

 

Please make such programs crash early and often.  They are a nightmare to 
maintain.  Make them blow in the face of the original authors; not after they 
are gone.

 

-- Gaby

 



0001-Always-trap-for-missing-return-statements-except-whe.patch
Description: Binary data
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

RE: [PATCH] RE: [cfe-dev] missing return statement for non-void functions in C++

[scott douglass via cfe-commits]

> Please see updated patch file attached, which now includes a fixed/added
> regression test.

I think it's a good idea; two minor remarks:

+if (!CGM.getCodeGenOpts().OptimizeSize) {
Should this be 'else if'?  I imagine there's no use emitting a trap after the 
sanitizer has emitted a missing_return check.

In the regression test, the CHECK-OPT case is now essentially the same as the 
CHECK case, so remove ' --check-prefix=CHECK-OPT' (but leave the RUN:) and 
these lines
  // CHECK-OPT: call void @llvm.trap
  // CHECK-OPT: unreachable



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

Re: [PATCH] D12036: We shouldn't need to pass -fno-strict-aliasing when building clang with clang.

[Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL245304: We shouldn't need to pass -fno-strict-aliasing when 
building clang with clang. (authored by cbieneman).

Changed prior to commit:
  http://reviews.llvm.org/D12036?vs=32349&id=32420#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D12036

Files:
  cfe/trunk/CMakeLists.txt
  cfe/trunk/Makefile

Index: cfe/trunk/Makefile
===
--- cfe/trunk/Makefile
+++ cfe/trunk/Makefile
@@ -67,8 +67,11 @@
 #   http://gcc.gnu.org/PR41874
 #   http://gcc.gnu.org/PR41838
 #
-# We can revisit this when LLVM/Clang support it.
+# We don't need to do this if the host compiler is clang.
+ifeq ($(CXX_COMPILER), "clang")
 CXX.Flags += -fno-strict-aliasing
+endif
+
 
 # Set up Clang's tblgen.
 ifndef CLANG_TBLGEN
Index: cfe/trunk/CMakeLists.txt
===
--- cfe/trunk/CMakeLists.txt
+++ cfe/trunk/CMakeLists.txt
@@ -253,7 +253,10 @@
 
 # Add appropriate flags for GCC
 if (LLVM_COMPILER_IS_GCC_COMPATIBLE)
-  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-common -Woverloaded-virtual 
-fno-strict-aliasing")
+  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-common -Woverloaded-virtual")
+  if (NOT "${CMAKE_CXX_COMPILER_ID}" MATCHES "Clang")
+set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-strict-aliasing")
+  endif ()
 
   # Enable -pedantic for Clang even if it's not enabled for LLVM.
   if (NOT LLVM_ENABLE_PEDANTIC)


Index: cfe/trunk/Makefile
===
--- cfe/trunk/Makefile
+++ cfe/trunk/Makefile
@@ -67,8 +67,11 @@
 #   http://gcc.gnu.org/PR41874
 #   http://gcc.gnu.org/PR41838
 #
-# We can revisit this when LLVM/Clang support it.
+# We don't need to do this if the host compiler is clang.
+ifeq ($(CXX_COMPILER), "clang")
 CXX.Flags += -fno-strict-aliasing
+endif
+
 
 # Set up Clang's tblgen.
 ifndef CLANG_TBLGEN
Index: cfe/trunk/CMakeLists.txt
===
--- cfe/trunk/CMakeLists.txt
+++ cfe/trunk/CMakeLists.txt
@@ -253,7 +253,10 @@
 
 # Add appropriate flags for GCC
 if (LLVM_COMPILER_IS_GCC_COMPATIBLE)
-  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-common -Woverloaded-virtual -fno-strict-aliasing")
+  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-common -Woverloaded-virtual")
+  if (NOT "${CMAKE_CXX_COMPILER_ID}" MATCHES "Clang")
+set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-strict-aliasing")
+  endif ()
 
   # Enable -pedantic for Clang even if it's not enabled for LLVM.
   if (NOT LLVM_ENABLE_PEDANTIC)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r245304 - We shouldn't need to pass -fno-strict-aliasing when building clang with clang.

[Chris Bieneman via cfe-commits]

Author: cbieneman
Date: Tue Aug 18 11:15:44 2015
New Revision: 245304

URL: http://llvm.org/viewvc/llvm-project?rev=245304&view=rev
Log:
We shouldn't need to pass -fno-strict-aliasing when building clang with clang.

Summary: The code comments in the Makefile indicate this was put in place to 
support issues when building clang with GCC. Today clang's strict aliasing 
works, so we shouldn't pass -fno-strict-aliasing when building with clang.

Reviewers: bogner, echristo

Subscribers: cfe-commits

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

Modified:
cfe/trunk/CMakeLists.txt
cfe/trunk/Makefile

Modified: cfe/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/CMakeLists.txt?rev=245304&r1=245303&r2=245304&view=diff
==
--- cfe/trunk/CMakeLists.txt (original)
+++ cfe/trunk/CMakeLists.txt Tue Aug 18 11:15:44 2015
@@ -253,7 +253,10 @@ configure_file(
 
 # Add appropriate flags for GCC
 if (LLVM_COMPILER_IS_GCC_COMPATIBLE)
-  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-common -Woverloaded-virtual 
-fno-strict-aliasing")
+  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-common -Woverloaded-virtual")
+  if (NOT "${CMAKE_CXX_COMPILER_ID}" MATCHES "Clang")
+set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-strict-aliasing")
+  endif ()
 
   # Enable -pedantic for Clang even if it's not enabled for LLVM.
   if (NOT LLVM_ENABLE_PEDANTIC)

Modified: cfe/trunk/Makefile
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/Makefile?rev=245304&r1=245303&r2=245304&view=diff
==
--- cfe/trunk/Makefile (original)
+++ cfe/trunk/Makefile Tue Aug 18 11:15:44 2015
@@ -67,8 +67,11 @@ endif
 #   http://gcc.gnu.org/PR41874
 #   http://gcc.gnu.org/PR41838
 #
-# We can revisit this when LLVM/Clang support it.
+# We don't need to do this if the host compiler is clang.
+ifeq ($(CXX_COMPILER), "clang")
 CXX.Flags += -fno-strict-aliasing
+endif
+
 
 # Set up Clang's tblgen.
 ifndef CLANG_TBLGEN


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

Re: [PATCH] D12076: Add loop-convert check to clang-tidy.

[Alexander Kornienko via cfe-commits]

alexfh added a comment.

In http://reviews.llvm.org/D12076#226476, @angelgarcia wrote:

> Split the tests in several files.


Thank you! Seems better like this.

A few more comments.



Comment at: clang-tidy/modernize/LoopConvertCheck.cpp:293
@@ +292,3 @@
+return nullptr;
+  const std::string Name = Member->getMemberDecl()->getName();
+  const std::string TargetName = IsBegin ? "begin" : "end";

s/const std::string/StringRef/


Comment at: clang-tidy/modernize/LoopConvertCheck.cpp:294
@@ +293,3 @@
+  const std::string Name = Member->getMemberDecl()->getName();
+  const std::string TargetName = IsBegin ? "begin" : "end";
+  if (Name != TargetName)

ditto


Comment at: clang-tidy/modernize/LoopConvertCheck.cpp:448
@@ +447,3 @@
+
+  std::string MaybeDereference = ContainerNeedsDereference ? "*" : "";
+  std::string TypeString = AutoRefType.getAsString();

s/std::string/StringRef/


Comment at: test/clang-tidy/modernize-loop-convert-basic.cpp:4
@@ +3,3 @@
+
+#include "Inputs/modernize-loop-convert-structures.h"
+

Relative paths to included files may not work in all test setups.

Please move the header to a subdirectory (modernize-loop-convert) inside Inputs 
(you can also rename it to just structures.h) and specify the directory in the 
RUN: line using `-I %S/Inputs/modernize-loop-convert`. That will ensure an 
absolute path to the directory is used. The #include directive should then 
refer the file without path.


http://reviews.llvm.org/D12076



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

[clang-tools-extra] r245310 - [clang-tidy] Fixed typos and formatting in a comment. NFC

[Alexander Kornienko via cfe-commits]

Author: alexfh
Date: Tue Aug 18 11:43:07 2015
New Revision: 245310

URL: http://llvm.org/viewvc/llvm-project?rev=245310&view=rev
Log:
[clang-tidy] Fixed typos and formatting in a comment. NFC

Modified:
clang-tools-extra/trunk/clang-tidy/misc/AssertSideEffectCheck.h

Modified: clang-tools-extra/trunk/clang-tidy/misc/AssertSideEffectCheck.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/AssertSideEffectCheck.h?rev=245310&r1=245309&r2=245310&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/misc/AssertSideEffectCheck.h (original)
+++ clang-tools-extra/trunk/clang-tidy/misc/AssertSideEffectCheck.h Tue Aug 18 
11:43:07 2015
@@ -21,15 +21,15 @@ namespace tidy {
 /// \brief Finds \c assert() with side effect.
 ///
 /// The condition of \c assert() is evaluated only in debug builds so a
-/// condition with side effect can cause different behaviour in debug / 
relesase
+/// condition with side effect can cause different behavior in debug / release
 /// builds.
 ///
 /// There are two options:
-/// - AssertMacros: AssertMacros: A comma-separated list of the names of assert
-///   macros to be checked.
+/// - AssertMacros: A comma-separated list of the names of assert macros to be
+///   checked.
 /// - CheckFunctionCalls: Whether to treat non-const member and non-member
-///   functions as they produce side effects. Disabled by default
-///   because it can increase the number of false positive warnings.
+///   functions as they produce side effects. Disabled by default because it 
can
+///   increase the number of false positive warnings.
 
 class AssertSideEffectCheck : public ClangTidyCheck {
 public:


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

Re: [PATCH] D11194: Instantiate function declarations in instantiated functions.

[Serge Pavlov via cfe-commits]

sepavloff added inline comments.


Comment at: lib/AST/DeclBase.cpp:273
@@ +272,3 @@
+return true;
+  if (const CXXRecordDecl *ClassD = dyn_cast(LDC))
+return ClassD->isLocalClass() && !ClassD->isLambda();;

rsmith wrote:
> It's not necessary for this change, but to match its documentation this 
> function should handle other kinds of `TagDecl` too (enums, C structs). 
> Something like:
> 
>   do {
> if (LDC->isFunctionOrMethod())
>   return true;
> if (!isa(LDC))
>   return false;
> LDC = LDC->getLexicalParent();
>   } while (LDC);
>   return false;
> 
> ... maybe?
The proposed code recognizes lambda as lexically contained within a function. 
As a result, the following test starts to fail (obtained from 
CXX\expr\expr.prim\expr.prim.lambda\default-arguments.cpp):
```
struct NoDefaultCtor {
  NoDefaultCtor(const NoDefaultCtor&); // expected-note{{candidate constructor}}
  ~NoDefaultCtor();
};

template
void defargs_in_template_unused(T t) {
  auto l1 = [](const T& value = T()) { };
  l1(t);
}

template void defargs_in_template_unused(NoDefaultCtor);
```
because default value for lambda argument cannot be instantiated. It is not 
clear whether instantiation of the lambda default argument must always occur 
similar to DR1484. I couldn't find appropriate place in the standard. According 
to spirit it shouldn't as lambda is not a separate declaration but a part of 
instantiated content. If so  14.6.4.1p2 is more likely to be applied and the 
above test must pass.

Maybe we need to rename `isLexicallyWithinFunctionOrMethod` to 
`shouldBeAlwaysInstantiated` or something like that to avoid misunderstanding?



http://reviews.llvm.org/D11194



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

Re: [PATCH] Have clang list the imported modules in the debug info

[Adrian Prantl via cfe-commits]

(ping.)

> On Aug 10, 2015, at 5:03 PM, Adrian Prantl  wrote:
> 
> [resending because I accidentally sent this to the old mailing list].
> 
>> On Jul 24, 2015, at 12:33 PM, David Blaikie > > wrote:
>> 
>> *reads back through the thread*
> 
> appreciated, it’s long :-)
> 
>> So what I originally had in mind about a year ago when we discussed this, 
>> was that the module data could have an extra table from type hash to 
>> whatever useful internal representation to find the type in the PCM.
> 
> It turned out that the most useful internal type representation to find a 
> type in a PCM is the type’s DeclContext+Name; this is how (surprise!) clang 
> looks up types in a PCM and the format is supposed to be fast for these kind 
> of lookups.
> 
>> Everything else would just be DWARF with type units and fission (with the 
>> slight wrinkle of type units that aren't resolvable within a single object 
>> file - they could reference cross-object/dwo file) - emitting a fission CU 
>> for each referenced module.
>> 
>> Needing modules to disambiguate/avoid collisions/support non-odr languages 
>> wasn't something I understood/had considered back then. That explains the 
>> need to add module references to the CU, so the debugger can know which 
>> modules to search for the types in (& doesn't just go loading all of them, 
>> etc).
>> 
>> I would still picture this as "normal type units + a table in the module to 
>> resolve types", but if you guys particularly like using the mangled string 
>> name (or other identifier) in the DWARF that may avoid the need for an 
>> intermediate table (but it doesn't sound like you are avoiding an 
>> intermediate table - you said something about having an 
>> accelerator-table-like thing to aid in the DWARF->AST mapping? So could that 
>> be key'd of the type hash/signature we're using, thus keeping the DWARF more 
>> plain/vanilla DWARF5 (type units + fission)?)
> 
> I originally disliked type signatures and favored using mangled names because 
> the mangled names contained the DeclContext necessary to find types in the 
> PCM. But if we can squeeze the DeclContext somewhere else, that’s fine.
> 
> From the discussion we had on FlagExternalTypeRef I got the impression that 
> long-form forward declarations are starting to look more attractive: If every 
> external type reference is a reference to a forward declaration that has a 
> complete decl context, with a DW_TAG_module at the root of the decl context 
> chain, and a DW_AT_name+DW_AT_signature at the other end, we would have all 
> the information we need without introducing any further LLVM-specific DWARF 
> extensions. To look up an external type from the PCM, the consumer imports 
> the DW_TAG_module and deserializes the type found by declcontext+name. To 
> load the type from DWARF, the consumer grabs the signature from the forward 
> declaration and magically (1) finds the PCM and looks up the type by 
> signature (2).
> 
> (1) My suggestion is to extend LLVM so it can put the DW_TAG_module with the 
> forward declaration inside the skeleton compile unit (which has the path to 
> the PCM and its DWOid).
> (2) On ELF with type units this works out of the box, on MachO without type 
> units we need some kind of index mapping signature -> DIE (bag of DWARF 
> style?).
> 
> Assuming that many external types will share a similar DeclContext prefix I 
> am not very worried by the space needed to store the long forward references. 
> Compared to storing the mangled name for every type it will often actually 
> take up less space. Also, on Darwin at least, llvm-dsymutil can strip them 
> out of the way after resolving the external type references.
> 
> -- adrian

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

Re: [PATCH] D11958: Add a -gmodules option to the clang driver.

[Adrian Prantl via cfe-commits]

aprantl added a comment.

Ping.


Repository:
  rL LLVM

http://reviews.llvm.org/D11958



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

Re: r245304 - We shouldn't need to pass -fno-strict-aliasing when building clang with clang.

[Nico Weber via cfe-commits]

On Tue, Aug 18, 2015 at 9:15 AM, Chris Bieneman via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: cbieneman
> Date: Tue Aug 18 11:15:44 2015
> New Revision: 245304
>
> URL: http://llvm.org/viewvc/llvm-project?rev=245304&view=rev
> Log:
> We shouldn't need to pass -fno-strict-aliasing when building clang with
> clang.
>
> Summary: The code comments in the Makefile indicate this was put in place
> to support issues when building clang with GCC. Today clang's strict
> aliasing works, so we shouldn't pass -fno-strict-aliasing when building
> with clang.
>
> Reviewers: bogner, echristo
>
> Subscribers: cfe-commits
>
> Differential Revision: http://reviews.llvm.org/D12036
>
> Modified:
> cfe/trunk/CMakeLists.txt
> cfe/trunk/Makefile
>
> Modified: cfe/trunk/CMakeLists.txt
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/CMakeLists.txt?rev=245304&r1=245303&r2=245304&view=diff
>
> ==
> --- cfe/trunk/CMakeLists.txt (original)
> +++ cfe/trunk/CMakeLists.txt Tue Aug 18 11:15:44 2015
> @@ -253,7 +253,10 @@ configure_file(
>
>  # Add appropriate flags for GCC
>  if (LLVM_COMPILER_IS_GCC_COMPATIBLE)
> -  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-common
> -Woverloaded-virtual -fno-strict-aliasing")
> +  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-common
> -Woverloaded-virtual")
> +  if (NOT "${CMAKE_CXX_COMPILER_ID}" MATCHES "Clang")
> +set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-strict-aliasing")
> +  endif ()
>
># Enable -pedantic for Clang even if it's not enabled for LLVM.
>if (NOT LLVM_ENABLE_PEDANTIC)
>
> Modified: cfe/trunk/Makefile
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/Makefile?rev=245304&r1=245303&r2=245304&view=diff
>
> ==
> --- cfe/trunk/Makefile (original)
> +++ cfe/trunk/Makefile Tue Aug 18 11:15:44 2015
> @@ -67,8 +67,11 @@ endif
>  #   http://gcc.gnu.org/PR41874
>  #   http://gcc.gnu.org/PR41838


These two bugs are marked fixed. Do we still need to pass this for gcc, or
can we just not pass it anywhere?


>
>  #
> -# We can revisit this when LLVM/Clang support it.
> +# We don't need to do this if the host compiler is clang.
> +ifeq ($(CXX_COMPILER), "clang")
>  CXX.Flags += -fno-strict-aliasing
> +endif
> +
>
>  # Set up Clang's tblgen.
>  ifndef CLANG_TBLGEN
>
>
> ___
> 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: r239883 - Update the intel intrinsic headers to use the target attribute support.

[Dimitry Andric via cfe-commits]

The problems from my earlier mail still stand, even with trunk r245199.

1) Various configure scripts (e.g. lame and others) try to check for intrinsics 
using fragments similar to the following:

#include 

then running that through "clang -E".  If preprocessing succeeds, the 
intrinsics are assumed to be available, otherwise they are not.

The changes in r239883 break this assumption.  In my opinion, intrinsics 
headers should always cause a compilation error, when the specific intrinsics 
asked for are not available.  Of course configure scripts can always be hacked 
up to cope, but this is really the wrong way around.

2) When those configure scripts erroneously assume specific intrinsics are 
available, while they really are not, and the program attempts to use them, 
clang dies with a fatal backend error, for example:

SplitVectorResult #0: 0x2bbd2f3c: v4f32 = llvm.x86.sse.sqrt.ps 0x2bbd53a8, 
0x2bbd2ea0 [ORD=11] [ID=0]

fatal error: error in backend: Do not know how to split the result of this 
operator!

This problem is reported in https://llvm.org/bugs/show_bug.cgi?id=24335 .

-Dimitry

> On 18 Aug 2015, at 00:08, Eric Christopher  wrote:
> 
> There is nothing broken about not having the include guards there, it's just 
> not helpful. I'm working on the infrastructure for an error if you call a 
> function from within an incompatible routine at the moment (without 
> duplicating a lot of code it's actually a bit annoying), but there's nothing 
> actually wrong with the code. It's just the same as basically saying 
> asm("invalid_instruction") in a random function.
> 
> Any configure script that was depending on error conditions from this is 
> already broken by gcc as well, and likely icc.
> 
> -eric
> 
> On Mon, Aug 17, 2015 at 3:04 PM Dimitry Andric  > wrote:
> [Re-sending, used the old cfe-commits address by accident]
> 
> Where is the other thread?  This problem still exists, for both trunk and the 
> upcoming 3.7.0 RC3.  I'll try to submit a patch tomorrow to partially restore 
> the include guards, so we won't have a broken release.
> 
> -Dimitry
> 
>> On 03 Aug 2015, at 18:48, Eric Christopher > > wrote:
>> 
> 
>> 
>> 
>> Where are the negative test cases? Diagnosing uses of these functions
>> when they aren't valid is really important - it's a pretty serious
>> regression if we don't.
>> 
>> Two threads, I'm going to take this in the other thread. :)
>> 
>> -eric
>> 
>> 
> 
>> ___
>> cfe-commits mailing list
>> cfe-comm...@cs.uiuc.edu 
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits 
>> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r239883 - Update the intel intrinsic headers to use the target attribute support.

[Eric Christopher via cfe-commits]

On Tue, Aug 18, 2015 at 10:51 AM Dimitry Andric  wrote:

> The problems from my earlier mail still stand, even with trunk r245199.
>
> 1) Various configure scripts (e.g. lame and others) try to check for
> intrinsics using fragments similar to the following:
>
> #include 
>
> then running that through "clang -E".  If preprocessing succeeds, the
> intrinsics are assumed to be available, otherwise they are not.
>
> The changes in r239883 break this assumption.  In my opinion, intrinsics
> headers should always cause a compilation error, when the specific
> intrinsics asked for are not available.  Of course configure scripts can
> always be hacked up to cope, but this is really the wrong way around.
>
>
I fundamentally disagree with you. As does everyone else that ships these
headers these days.


> 2) When those configure scripts erroneously assume specific intrinsics are
> available, while they really are not, and the program attempts to use them,
> clang dies with a fatal backend error, for example:
>
> SplitVectorResult #0: 0x2bbd2f3c: v4f32 = llvm.x86.sse.sqrt.ps
> 0x2bbd53a8, 0x2bbd2ea0 [ORD=11] [ID=0]
>
> fatal error: error in backend: Do not know how to split the result of this
> operator!
>
> This problem is reported in https://llvm.org/bugs/show_bug.cgi?id=24335 .
>
>
This will be a better error soon (next day or so) and come out of the front
end.

-eric


> -Dimitry
>
> On 18 Aug 2015, at 00:08, Eric Christopher  wrote:
>
> There is nothing broken about not having the include guards there, it's
> just not helpful. I'm working on the infrastructure for an error if you
> call a function from within an incompatible routine at the moment (without
> duplicating a lot of code it's actually a bit annoying), but there's
> nothing actually wrong with the code. It's just the same as basically
> saying asm("invalid_instruction") in a random function.
>
> Any configure script that was depending on error conditions from this is
> already broken by gcc as well, and likely icc.
>
> -eric
>
> On Mon, Aug 17, 2015 at 3:04 PM Dimitry Andric  wrote:
>
>> [Re-sending, used the old cfe-commits address by accident]
>>
>> Where is the other thread?  This problem still exists, for both trunk and
>> the upcoming 3.7.0 RC3.  I'll try to submit a patch tomorrow to partially
>> restore the include guards, so we won't have a broken release.
>>
>> -Dimitry
>>
>> On 03 Aug 2015, at 18:48, Eric Christopher  wrote:
>>
>>
>>>
>>> Where are the negative test cases? Diagnosing uses of these functions
>>> when they aren't valid is really important - it's a pretty serious
>>> regression if we don't.
>>>
>>
>> Two threads, I'm going to take this in the other thread. :)
>>
>> -eric
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-comm...@cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r239883 - Update the intel intrinsic headers to use the target attribute support.

[Dimitry Andric via cfe-commits]

No, it does not occur in the 3.7 branch, thanks for reverting those changes. :)

-Dimitry

> On 18 Aug 2015, at 01:09, Hans Wennborg  wrote:
> 
> The 3.7 branch does have the include guards; they were re-added in
> http://llvm.org/viewvc/llvm-project?rev=243925&view=rev. That happened
> after rc2, but it will be in rc3.
> 
> Can you double check if you're still running into problems on the 3.7 branch?
> 
> - Hans
> 
> 
> On Mon, Aug 17, 2015 at 3:04 PM, Dimitry Andric  wrote:
>> [Re-sending, used the old cfe-commits address by accident]
>> 
>> Where is the other thread?  This problem still exists, for both trunk and
>> the upcoming 3.7.0 RC3.  I'll try to submit a patch tomorrow to partially
>> restore the include guards, so we won't have a broken release.
>> 
>> -Dimitry
>> 
>> On 03 Aug 2015, at 18:48, Eric Christopher  wrote:
>> 
>>> 
>>> 
>>> Where are the negative test cases? Diagnosing uses of these functions
>>> when they aren't valid is really important - it's a pretty serious
>>> regression if we don't.
>> 
>> 
>> Two threads, I'm going to take this in the other thread. :)
>> 
>> -eric
>> 
>> 
>> ___
>> cfe-commits mailing list
>> cfe-comm...@cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>> 
>> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r245320 - Update to reflect the library set in LLVM changing.

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Tue Aug 18 12:59:33 2015
New Revision: 245320

URL: http://llvm.org/viewvc/llvm-project?rev=245320&view=rev
Log:
Update to reflect the library set in LLVM changing.

Modified:
cfe/trunk/tools/driver/CMakeLists.txt

Modified: cfe/trunk/tools/driver/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/driver/CMakeLists.txt?rev=245320&r1=245319&r2=245320&view=diff
==
--- cfe/trunk/tools/driver/CMakeLists.txt (original)
+++ cfe/trunk/tools/driver/CMakeLists.txt Tue Aug 18 12:59:33 2015
@@ -3,7 +3,6 @@ set( LLVM_LINK_COMPONENTS
   Analysis
   CodeGen
   Core
-  IPA
   IPO
   InstCombine
   Instrumentation


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

Re: r239883 - Update the intel intrinsic headers to use the target attribute support.

[Dimitry Andric via cfe-commits]

> On 18 Aug 2015, at 19:52, Eric Christopher  wrote:
> 
> 
> 
> On Tue, Aug 18, 2015 at 10:51 AM Dimitry Andric  wrote:
> The problems from my earlier mail still stand, even with trunk r245199.
> 
> 1) Various configure scripts (e.g. lame and others) try to check for 
> intrinsics using fragments similar to the following:
> 
> #include 
> 
> then running that through "clang -E".  If preprocessing succeeds, the 
> intrinsics are assumed to be available, otherwise they are not.
> 
> The changes in r239883 break this assumption.  In my opinion, intrinsics 
> headers should always cause a compilation error, when the specific intrinsics 
> asked for are not available.  Of course configure scripts can always be 
> hacked up to cope, but this is really the wrong way around.
> 
> 
> I fundamentally disagree with you. As does everyone else that ships these 
> headers these days.

Aha, I see now what you mean:

$ cat simple-detect.c
#include 

$ gcc47 -c simple-detect.c
In file included from simple-detect.c:1:0:
/usr/local/lib/gcc47/gcc/i386-portbld-freebsd11.0/4.7.4/include/xmmintrin.h:32:3:
 error: #error "SSE instruction set not enabled"

$ gcc48 -c simple-detect.c
In file included from simple-detect.c:1:0:
/usr/local/lib/gcc48/gcc/i386-portbld-freebsd11.0/4.8.5/include/xmmintrin.h:31:3:
 error: #error "SSE instruction set not enabled"
 # error "SSE instruction set not enabled"
   ^

$ gcc49 -c simple-detect.c


E.g., somewhere between gcc 4.8 and 4.9, they also removed the include guards 
from their intrinsics headers.  (It seems to be this commit: 
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=200349 )

So since this old method of just attempting to include certain intrinsics 
headers is not working anymore, what would be the correct new method of 
detecting whether certain classes of intrinsic are available with the current 
compilation flags?  For example, actually trying to call such an intrinsic?  Or 
maybe even attempt to link the program, and see if linking fails?


>  2) When those configure scripts erroneously assume specific intrinsics are 
> available, while they really are not, and the program attempts to use them, 
> clang dies with a fatal backend error, for example:
> 
> SplitVectorResult #0: 0x2bbd2f3c: v4f32 = llvm.x86.sse.sqrt.ps 0x2bbd53a8, 
> 0x2bbd2ea0 [ORD=11] [ID=0]
> 
> fatal error: error in backend: Do not know how to split the result of this 
> operator!
> 
> This problem is reported in https://llvm.org/bugs/show_bug.cgi?id=24335 .
> 
> 
> This will be a better error soon (next day or so) and come out of the front 
> end.

Thank you.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D9285: Add a KeepVirtual option to misc-use-override

[Alexander Kornienko via cfe-commits]

alexfh added a comment.

In http://reviews.llvm.org/D9285#224690, @ehsan wrote:

> Sorry, I kind of dropped the ball here!
>
> At Mozilla we ended up deciding on allowing only a maximum of one of virtual, 
> final or override per function declaration, similar to the Google coding 
> style, so we won't need the KeepVirtual option.  Should I still add it 
> nevertheless?


No, I don't think the option (and the rule it backs up) makes sense. I'm glad 
you got rid of the relevant style rule ;)


http://reviews.llvm.org/D9285



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

Re: [PATCH] D9286: Insert override at the same line as the end of the function declaration

[Alexander Kornienko via cfe-commits]

alexfh added a comment.

In http://reviews.llvm.org/D9286#224691, @ehsan wrote:

> I should land this, but let's wait to see if we want 
> http://reviews.llvm.org/D9285 or not, since this patch is built on top of it. 
>  If not, I can rebase it on top of master as well.


We don't want http://reviews.llvm.org/D9285, so this patch should be rebased on 
top of master. Please also address the inline comments.


http://reviews.llvm.org/D9286



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

Re: r239883 - Update the intel intrinsic headers to use the target attribute support.

[Eric Christopher via cfe-commits]

On Tue, Aug 18, 2015 at 11:05 AM Dimitry Andric  wrote:

> > On 18 Aug 2015, at 19:52, Eric Christopher  wrote:
> >
> >
> >
> > On Tue, Aug 18, 2015 at 10:51 AM Dimitry Andric 
> wrote:
> > The problems from my earlier mail still stand, even with trunk r245199.
> >
> > 1) Various configure scripts (e.g. lame and others) try to check for
> intrinsics using fragments similar to the following:
> >
> > #include 
> >
> > then running that through "clang -E".  If preprocessing succeeds, the
> intrinsics are assumed to be available, otherwise they are not.
> >
> > The changes in r239883 break this assumption.  In my opinion, intrinsics
> headers should always cause a compilation error, when the specific
> intrinsics asked for are not available.  Of course configure scripts can
> always be hacked up to cope, but this is really the wrong way around.
> >
> >
> > I fundamentally disagree with you. As does everyone else that ships
> these headers these days.
>
> Aha, I see now what you mean:
>
> $ cat simple-detect.c
> #include 
>
> $ gcc47 -c simple-detect.c
> In file included from simple-detect.c:1:0:
> /usr/local/lib/gcc47/gcc/i386-portbld-freebsd11.0/4.7.4/include/xmmintrin.h:32:3:
> error: #error "SSE instruction set not enabled"
>
> $ gcc48 -c simple-detect.c
> In file included from simple-detect.c:1:0:
> /usr/local/lib/gcc48/gcc/i386-portbld-freebsd11.0/4.8.5/include/xmmintrin.h:31:3:
> error: #error "SSE instruction set not enabled"
>  # error "SSE instruction set not enabled"
>^
>
> $ gcc49 -c simple-detect.c
> 
>
> E.g., somewhere between gcc 4.8 and 4.9, they also removed the include
> guards from their intrinsics headers.  (It seems to be this commit:
> https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=200349 )
>
> So since this old method of just attempting to include certain intrinsics
> headers is not working anymore, what would be the correct new method of
> detecting whether certain classes of intrinsic are available with the
> current compilation flags?  For example, actually trying to call such an
> intrinsic?  Or maybe even attempt to link the program, and see if linking
> fails?
>
>
I think the best bet is going to be a compile test. Though I really worry
about a configure time check for this kind of feature in that it's not
particularly portable. :\

That ship has probably sailed though.


>
> >  2) When those configure scripts erroneously assume specific intrinsics
> are available, while they really are not, and the program attempts to use
> them, clang dies with a fatal backend error, for example:
> >
> > SplitVectorResult #0: 0x2bbd2f3c: v4f32 = llvm.x86.sse.sqrt.ps
> 0x2bbd53a8, 0x2bbd2ea0 [ORD=11] [ID=0]
> >
> > fatal error: error in backend: Do not know how to split the result of
> this operator!
> >
> > This problem is reported in https://llvm.org/bugs/show_bug.cgi?id=24335
> .
> >
> >
> > This will be a better error soon (next day or so) and come out of the
> front end.
>
> Thank you.
>

Yep. Thanks for being patient :)

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

r245323 - Make __builtin_object_size always answer correctly

[George Burgess IV via cfe-commits]

Author: gbiv
Date: Tue Aug 18 13:18:27 2015
New Revision: 245323

URL: http://llvm.org/viewvc/llvm-project?rev=245323&view=rev
Log:
Make __builtin_object_size always answer correctly

__builtin_object_size would return incorrect answers for many uses where
type=3. This fixes the inaccuracy by making us emit 0 instead of LLVM's
objectsize intrinsic.

Additionally, there are many cases where we would emit suboptimal (but
correct) answers, such as when arrays are involved. This patch fixes
some of these cases (please see new tests in test/CodeGen/object-size.c
for specifics on which cases are improved)

Patch mostly by Richard Smith.
Differential Revision: http://reviews.llvm.org/D12000
This fixes PR15212.


Modified:
cfe/trunk/lib/AST/ExprConstant.cpp
cfe/trunk/test/CodeGen/object-size.c
cfe/trunk/test/Sema/const-eval.c

Modified: cfe/trunk/lib/AST/ExprConstant.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ExprConstant.cpp?rev=245323&r1=245322&r2=245323&view=diff
==
--- cfe/trunk/lib/AST/ExprConstant.cpp (original)
+++ cfe/trunk/lib/AST/ExprConstant.cpp Tue Aug 18 13:18:27 2015
@@ -967,10 +967,6 @@ namespace {
 // Check this LValue refers to an object. If not, set the designator to be
 // invalid and emit a diagnostic.
 bool checkSubobject(EvalInfo &Info, const Expr *E, CheckSubobjectKind CSK) 
{
-  // Outside C++11, do not build a designator referring to a subobject of
-  // any object: we won't use such a designator for anything.
-  if (!Info.getLangOpts().CPlusPlus11)
-Designator.setInvalid();
   return (CSK == CSK_ArrayToPointer || checkNullPointer(Info, E, CSK)) &&
  Designator.checkSubobject(Info, E, CSK);
 }
@@ -2713,8 +2709,7 @@ static bool handleLValueToRValueConversi
 
   // Check for special cases where there is no existing APValue to look at.
   const Expr *Base = LVal.Base.dyn_cast();
-  if (!LVal.Designator.Invalid && Base && !LVal.CallIndex &&
-  !Type.isVolatileQualified()) {
+  if (Base && !LVal.CallIndex && !Type.isVolatileQualified()) {
 if (const CompoundLiteralExpr *CLE = dyn_cast(Base)) {
   // In C99, a CompoundLiteralExpr is an lvalue, and we defer evaluating 
the
   // initializer until now for such expressions. Such an expression can't 
be
@@ -5998,8 +5993,7 @@ public:
   bool VisitSizeOfPackExpr(const SizeOfPackExpr *E);
 
 private:
-  static QualType GetObjectType(APValue::LValueBase B);
-  bool TryEvaluateBuiltinObjectSize(const CallExpr *E);
+  bool TryEvaluateBuiltinObjectSize(const CallExpr *E, unsigned Type);
   // FIXME: Missing: array subscript of vector, member of vector
 };
 } // end anonymous namespace
@@ -6171,7 +6165,7 @@ static bool EvaluateBuiltinConstantP(AST
 
 /// Retrieves the "underlying object type" of the given expression,
 /// as used by __builtin_object_size.
-QualType IntExprEvaluator::GetObjectType(APValue::LValueBase B) {
+static QualType getObjectType(APValue::LValueBase B) {
   if (const ValueDecl *D = B.dyn_cast()) {
 if (const VarDecl *VD = dyn_cast(D))
   return VD->getType();
@@ -6183,49 +6177,87 @@ QualType IntExprEvaluator::GetObjectType
   return QualType();
 }
 
-bool IntExprEvaluator::TryEvaluateBuiltinObjectSize(const CallExpr *E) {
+bool IntExprEvaluator::TryEvaluateBuiltinObjectSize(const CallExpr *E,
+unsigned Type) {
+  // Determine the denoted object.
   LValue Base;
-
   {
 // The operand of __builtin_object_size is never evaluated for 
side-effects.
 // If there are any, but we can determine the pointed-to object anyway, 
then
 // ignore the side-effects.
 SpeculativeEvaluationRAII SpeculativeEval(Info);
+FoldConstant Fold(Info, true);
 if (!EvaluatePointer(E->getArg(0), Base, Info))
   return false;
   }
 
-  if (!Base.getLValueBase()) {
-// It is not possible to determine which objects ptr points to at compile 
time,
-// __builtin_object_size should return (size_t) -1 for type 0 or 1
-// and (size_t) 0 for type 2 or 3.
-llvm::APSInt TypeIntVaue;
-const Expr *ExprType = E->getArg(1);
-if (!ExprType->EvaluateAsInt(TypeIntVaue, Info.Ctx))
-  return false;
-if (TypeIntVaue == 0 || TypeIntVaue == 1)
-  return Success(-1, E);
-if (TypeIntVaue == 2 || TypeIntVaue == 3)
-  return Success(0, E);
-return Error(E);
+  CharUnits BaseOffset = Base.getLValueOffset();
+
+  // If we point to before the start of the object, there are no
+  // accessible bytes.
+  if (BaseOffset < CharUnits::Zero())
+return Success(0, E);
+
+  // If Type & 1 is 0, the object in question is the complete object; reset to
+  // a complete object designator in that case.
+  //
+  // If Type is 1 and we've lost track of the subobject, just find the complete
+  // object instead. (If Type is 3, that's not correct behavior and we should
+  // return 0 instead.)
+  LVa

[PATCH] D12109: [WinEH] Update to new EH pad/ret signatures (with tokens required)

[Joseph Tremoulet via cfe-commits]

JosephTremoulet created this revision.
JosephTremoulet added reviewers: majnemer, rnk.
JosephTremoulet added a subscriber: cfe-commits.

The signatures of the methods in LLVM for creating EH pads/rets are changing
to require token arguments on rets and assume token return type on pads.
Update creation code accordingly.

http://reviews.llvm.org/D12109

Files:
  lib/CodeGen/CGCleanup.cpp
  lib/CodeGen/CGException.cpp
  lib/CodeGen/MicrosoftCXXABI.cpp

Index: lib/CodeGen/MicrosoftCXXABI.cpp
===
--- lib/CodeGen/MicrosoftCXXABI.cpp
+++ lib/CodeGen/MicrosoftCXXABI.cpp
@@ -859,7 +859,7 @@
   void Emit(CodeGenFunction &CGF, Flags flags) override {
 if (CGF.CGM.getCodeGenOpts().NewMSEH) {
   llvm::BasicBlock *BB = CGF.createBasicBlock("catchret.dest");
-  CGF.Builder.CreateCatchRet(BB, CPI);
+  CGF.Builder.CreateCatchRet(CPI, BB);
   CGF.EmitBlock(BB);
 } else {
   CGF.EmitNounwindRuntimeCall(
Index: lib/CodeGen/CGException.cpp
===
--- lib/CodeGen/CGException.cpp
+++ lib/CodeGen/CGException.cpp
@@ -887,11 +887,10 @@
 
 if (EHPersonality::get(CGF).isMSVCXXPersonality()) {
   CGF.Builder.CreateCatchPad(
-  llvm::Type::getTokenTy(CGF.getLLVMContext()), Handler.Block,
-  NextBlock, {TypeValue, llvm::Constant::getNullValue(CGF.VoidPtrTy)});
+  Handler.Block, NextBlock,
+  {TypeValue, llvm::Constant::getNullValue(CGF.VoidPtrTy)});
 } else {
-  CGF.Builder.CreateCatchPad(llvm::Type::getTokenTy(CGF.getLLVMContext()),
- Handler.Block, NextBlock, {TypeValue});
+  CGF.Builder.CreateCatchPad(Handler.Block, NextBlock, {TypeValue});
 }
 
 // Otherwise we need to emit and continue at that block.
Index: lib/CodeGen/CGCleanup.cpp
===
--- lib/CodeGen/CGCleanup.cpp
+++ lib/CodeGen/CGCleanup.cpp
@@ -904,8 +904,7 @@
 llvm::BasicBlock *NextAction = getEHDispatchBlock(EHParent);
 if (CGM.getCodeGenOpts().NewMSEH &&
 EHPersonality::get(*this).isMSVCPersonality())
-  CPI = Builder.CreateCleanupPad(llvm::Type::getTokenTy(getLLVMContext()),
- {});
+  CPI = Builder.CreateCleanupPad({});
 
 // We only actually emit the cleanup code if the cleanup is either
 // active or was used before it was deactivated.
@@ -916,7 +915,7 @@
 }
 
 if (CPI)
-  Builder.CreateCleanupRet(NextAction, CPI);
+  Builder.CreateCleanupRet(CPI, NextAction);
 else
   Builder.CreateBr(NextAction);
 


Index: lib/CodeGen/MicrosoftCXXABI.cpp
===
--- lib/CodeGen/MicrosoftCXXABI.cpp
+++ lib/CodeGen/MicrosoftCXXABI.cpp
@@ -859,7 +859,7 @@
   void Emit(CodeGenFunction &CGF, Flags flags) override {
 if (CGF.CGM.getCodeGenOpts().NewMSEH) {
   llvm::BasicBlock *BB = CGF.createBasicBlock("catchret.dest");
-  CGF.Builder.CreateCatchRet(BB, CPI);
+  CGF.Builder.CreateCatchRet(CPI, BB);
   CGF.EmitBlock(BB);
 } else {
   CGF.EmitNounwindRuntimeCall(
Index: lib/CodeGen/CGException.cpp
===
--- lib/CodeGen/CGException.cpp
+++ lib/CodeGen/CGException.cpp
@@ -887,11 +887,10 @@
 
 if (EHPersonality::get(CGF).isMSVCXXPersonality()) {
   CGF.Builder.CreateCatchPad(
-  llvm::Type::getTokenTy(CGF.getLLVMContext()), Handler.Block,
-  NextBlock, {TypeValue, llvm::Constant::getNullValue(CGF.VoidPtrTy)});
+  Handler.Block, NextBlock,
+  {TypeValue, llvm::Constant::getNullValue(CGF.VoidPtrTy)});
 } else {
-  CGF.Builder.CreateCatchPad(llvm::Type::getTokenTy(CGF.getLLVMContext()),
- Handler.Block, NextBlock, {TypeValue});
+  CGF.Builder.CreateCatchPad(Handler.Block, NextBlock, {TypeValue});
 }
 
 // Otherwise we need to emit and continue at that block.
Index: lib/CodeGen/CGCleanup.cpp
===
--- lib/CodeGen/CGCleanup.cpp
+++ lib/CodeGen/CGCleanup.cpp
@@ -904,8 +904,7 @@
 llvm::BasicBlock *NextAction = getEHDispatchBlock(EHParent);
 if (CGM.getCodeGenOpts().NewMSEH &&
 EHPersonality::get(*this).isMSVCPersonality())
-  CPI = Builder.CreateCleanupPad(llvm::Type::getTokenTy(getLLVMContext()),
- {});
+  CPI = Builder.CreateCleanupPad({});
 
 // We only actually emit the cleanup code if the cleanup is either
 // active or was used before it was deactivated.
@@ -916,7 +915,7 @@
 }
 
 if (CPI)
-  Builder.CreateCleanupRet(NextAction, CPI);
+  Builder.CreateCleanupRet(CPI, NextAction);
 else
   Builder.CreateBr(NextAction);
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.o

Re: [PATCH] D12000: Bugfix - Clang handles __builtin_object_size in wrong way

[George Burgess IV via cfe-commits]

george.burgess.iv closed this revision.
george.burgess.iv added a comment.

r245323


http://reviews.llvm.org/D12000



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

[PATCH] Fix out-of-bounds array access when setting arm float registers

[Leandro Graciá Gil via cfe-commits]

Hi,

Please find attached a patch fixing an out-of-bounds array access present
in the current libunwind top of tree code.

The problem is caused by subtracting the wrong base register in
Registers_arm::SetFloatRegister and should become obvious after taking a
quick look to the code.

Could someone please commit this to trunk and merge it to the release 37
branch?

Thanks,
Leandro


0001-Fix-out-of-bounds-array-access-when-setting-arm-floa.patch
Description: Binary data
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r245304 - We shouldn't need to pass -fno-strict-aliasing when building clang with clang.

[Chris Bieneman via cfe-commits]

> On Aug 18, 2015, at 10:48 AM, Nico Weber  wrote:
> 
> On Tue, Aug 18, 2015 at 9:15 AM, Chris Bieneman via cfe-commits 
> mailto:cfe-commits@lists.llvm.org>> wrote:
> Author: cbieneman
> Date: Tue Aug 18 11:15:44 2015
> New Revision: 245304
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=245304&view=rev 
> 
> Log:
> We shouldn't need to pass -fno-strict-aliasing when building clang with clang.
> 
> Summary: The code comments in the Makefile indicate this was put in place to 
> support issues when building clang with GCC. Today clang's strict aliasing 
> works, so we shouldn't pass -fno-strict-aliasing when building with clang.
> 
> Reviewers: bogner, echristo
> 
> Subscribers: cfe-commits
> 
> Differential Revision: http://reviews.llvm.org/D12036 
> 
> 
> Modified:
> cfe/trunk/CMakeLists.txt
> cfe/trunk/Makefile
> 
> Modified: cfe/trunk/CMakeLists.txt
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/CMakeLists.txt?rev=245304&r1=245303&r2=245304&view=diff
>  
> 
> ==
> --- cfe/trunk/CMakeLists.txt (original)
> +++ cfe/trunk/CMakeLists.txt Tue Aug 18 11:15:44 2015
> @@ -253,7 +253,10 @@ configure_file(
> 
>  # Add appropriate flags for GCC
>  if (LLVM_COMPILER_IS_GCC_COMPATIBLE)
> -  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-common -Woverloaded-virtual 
> -fno-strict-aliasing")
> +  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-common -Woverloaded-virtual")
> +  if (NOT "${CMAKE_CXX_COMPILER_ID}" MATCHES "Clang")
> +set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-strict-aliasing")
> +  endif ()
> 
># Enable -pedantic for Clang even if it's not enabled for LLVM.
>if (NOT LLVM_ENABLE_PEDANTIC)
> 
> Modified: cfe/trunk/Makefile
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/Makefile?rev=245304&r1=245303&r2=245304&view=diff
>  
> 
> ==
> --- cfe/trunk/Makefile (original)
> +++ cfe/trunk/Makefile Tue Aug 18 11:15:44 2015
> @@ -67,8 +67,11 @@ endif
>  #   http://gcc.gnu.org/PR41874 
> 
>  #   http://gcc.gnu.org/PR41838 
> 
> 
> These two bugs are marked fixed. Do we still need to pass this for gcc, or 
> can we just not pass it anywhere?

I don’t have access to gcc to test removing the flag there. I see no reason not 
to remove it for gcc, but I haven’t and can’t test it. Someone else will need 
to test it before committing.

-Chris

>  
> 
>  #
> -# We can revisit this when LLVM/Clang support it.
> +# We don't need to do this if the host compiler is clang.
> +ifeq ($(CXX_COMPILER), "clang")
>  CXX.Flags += -fno-strict-aliasing
> +endif
> +
> 
>  # Set up Clang's tblgen.
>  ifndef CLANG_TBLGEN
> 
> 
> ___
> 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

[libcxxabi] r245325 - Revert r243752, it broke running tests on OS X (PR24491).

[Nico Weber via cfe-commits]

Author: nico
Date: Tue Aug 18 13:29:33 2015
New Revision: 245325

URL: http://llvm.org/viewvc/llvm-project?rev=245325&view=rev
Log:
Revert r243752, it broke running tests on OS X (PR24491).

Modified:
libcxxabi/trunk/test/lit.cfg

Modified: libcxxabi/trunk/test/lit.cfg
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/test/lit.cfg?rev=245325&r1=245324&r2=245325&view=diff
==
--- libcxxabi/trunk/test/lit.cfg (original)
+++ libcxxabi/trunk/test/lit.cfg Tue Aug 18 13:29:33 2015
@@ -53,11 +53,6 @@ if obj_root is None:
 
 config.test_exec_root = os.path.join(obj_root, 'test')
 
-# Check if we have produced a Clang with this build (in-tree)
-this_clang = os.path.join(obj_root, '../../bin/clang++')
-if os.path.exists(this_clang):
-config.cxx_under_test = this_clang
-
 cfg_variant = getattr(config, 'configuration_variant', 'libcxxabi')
 if cfg_variant:
 print 'Using configuration variant: %s' % cfg_variant


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

Re: [PATCH] D11932: [OPENMP] Link libomp.lib on Windows

[Reid Kleckner via cfe-commits]

rnk accepted this revision.
rnk added a comment.

lgtm


http://reviews.llvm.org/D11932



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

Re: r245304 - We shouldn't need to pass -fno-strict-aliasing when building clang with clang.

[Reid Kleckner via cfe-commits]

On Tue, Aug 18, 2015 at 11:26 AM, Chris Bieneman via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
> I don’t have access to gcc to test removing the flag there. I see no
> reason not to remove it for gcc, but I haven’t and can’t test it. Someone
> else will need to test it before committing.
>

I tested it. There's tons of warnings.

It actually fires on this construct, where we go out of our way to cast via
an omnipotent char*:
APValue.h:309:45: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
  return ((const AddrLabelDiffData*)(const char*)Data.buffer)->LHSExpr;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxx] r245330 - implement more of N4258 - Cleaning up noexcept in the standard library. Specifically add new noexcept stuff to vector and string's move-assignment operations

[Marshall Clow via cfe-commits]

Author: marshall
Date: Tue Aug 18 13:57:00 2015
New Revision: 245330

URL: http://llvm.org/viewvc/llvm-project?rev=245330&view=rev
Log:
implement more of N4258 - Cleaning up noexcept in the standard library. 
Specifically add new noexcept stuff to vector and string's move-assignment 
operations

Modified:
libcxx/trunk/include/memory
libcxx/trunk/include/string
libcxx/trunk/include/vector

libcxx/trunk/test/std/containers/sequences/vector.bool/move_assign_noexcept.pass.cpp

libcxx/trunk/test/std/containers/sequences/vector/vector.cons/move_assign_noexcept.pass.cpp

libcxx/trunk/test/std/strings/basic.string/string.cons/move_assign_noexcept.pass.cpp

Modified: libcxx/trunk/include/memory
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/memory?rev=245330&r1=245329&r2=245330&view=diff
==
--- libcxx/trunk/include/memory (original)
+++ libcxx/trunk/include/memory Tue Aug 18 13:57:00 2015
@@ -5574,6 +5574,15 @@ template 
 _LIBCPP_INLINE_VISIBILITY
 void __swap_allocator(_Alloc &, _Alloc &, false_type) _NOEXCEPT {}
 
+template >
+struct __noexcept_move_assign_container : public integral_constant 14
+|| _Traits::is_always_equal::value
+#else
+&& is_nothrow_move_assignable<_Alloc>::value
+#endif
+> {};
 
 _LIBCPP_END_NAMESPACE_STD
 

Modified: libcxx/trunk/include/string
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/string?rev=245330&r1=245329&r2=245330&view=diff
==
--- libcxx/trunk/include/string (original)
+++ libcxx/trunk/include/string Tue Aug 18 13:57:00 2015
@@ -115,8 +115,8 @@ public:
 basic_string& operator=(const basic_string& str);
 basic_string& operator=(basic_string&& str)
 noexcept(
- allocator_type::propagate_on_container_move_assignment::value &&
- is_nothrow_move_assignable::value);
+ allocator_type::propagate_on_container_move_assignment::value ||
+ allocator_type::is_always_equal::value ); // C++17
 basic_string& operator=(const value_type* s);
 basic_string& operator=(value_type c);
 basic_string& operator=(initializer_list);
@@ -1377,8 +1377,7 @@ public:
 #ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
 _LIBCPP_INLINE_VISIBILITY
 basic_string& operator=(basic_string&& __str)
-
_NOEXCEPT_(__alloc_traits::propagate_on_container_move_assignment::value &&
-   is_nothrow_move_assignable::value);
+_NOEXCEPT_((__noexcept_move_assign_container<_Allocator, 
__alloc_traits>::value));
 #endif
 _LIBCPP_INLINE_VISIBILITY basic_string& operator=(const value_type* __s) 
{return assign(__s);}
 basic_string& operator=(value_type __c);
@@ -1845,11 +1844,16 @@ private:
 
 #ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
 _LIBCPP_INLINE_VISIBILITY
-void __move_assign(basic_string& __str, false_type);
+void __move_assign(basic_string& __str, false_type)
+_NOEXCEPT_(__alloc_traits::is_always_equal::value);
 _LIBCPP_INLINE_VISIBILITY
 void __move_assign(basic_string& __str, true_type)
+#if _LIBCPP_STD_VER > 14
+_NOEXCEPT;
+#else
 _NOEXCEPT_(is_nothrow_move_assignable::value);
 #endif
+#endif
 
 _LIBCPP_INLINE_VISIBILITY
 void
@@ -2430,6 +2434,7 @@ template ::__move_assign(basic_string& __str, 
false_type)
+_NOEXCEPT_(__alloc_traits::is_always_equal::value)
 {
 if (__alloc() != __str.__alloc())
 assign(__str);
@@ -2441,7 +2446,11 @@ template ::__move_assign(basic_string& __str, 
true_type)
+#if _LIBCPP_STD_VER > 14
+_NOEXCEPT
+#else
 _NOEXCEPT_(is_nothrow_move_assignable::value)
+#endif
 {
 clear();
 shrink_to_fit();
@@ -2454,8 +2463,7 @@ template &
 basic_string<_CharT, _Traits, _Allocator>::operator=(basic_string&& __str)
-_NOEXCEPT_(__alloc_traits::propagate_on_container_move_assignment::value &&
-   is_nothrow_move_assignable::value)
+_NOEXCEPT_((__noexcept_move_assign_container<_Allocator, 
__alloc_traits>::value))
 {
 __move_assign(__str, integral_constant());

Modified: libcxx/trunk/include/vector
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/vector?rev=245330&r1=245329&r2=245330&view=diff
==
--- libcxx/trunk/include/vector (original)
+++ libcxx/trunk/include/vector Tue Aug 18 13:57:00 2015
@@ -51,8 +51,8 @@ public:
 vector& operator=(const vector& x);
 vector& operator=(vector&& x)
 noexcept(
- allocator_type::propagate_on_container_move_assignment::value &&
- is_nothrow_move_assignable::value);
+ allocator_type::propagate_on_container_move_assignment::value ||
+ allocator_type::is_always_equal::value); // C++17
 vector& operator=(initializer_list il);
 template 
 void assign(InputIterator first, InputIter

r245332 - Removing useless whitespace; NFC.

[Aaron Ballman via cfe-commits]

Author: aaronballman
Date: Tue Aug 18 14:11:07 2015
New Revision: 245332

URL: http://llvm.org/viewvc/llvm-project?rev=245332&view=rev
Log:
Removing useless whitespace; NFC.

Modified:
cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h

Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h?rev=245332&r1=245331&r2=245332&view=diff
==
--- cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h (original)
+++ cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h Tue Aug 18 14:11:07 2015
@@ -4209,7 +4209,6 @@ AST_POLYMORPHIC_MATCHER(isExplicit,
 AST_POLYMORPHIC_SUPPORTED_TYPES(CXXConstructorDecl,
 CXXConversionDecl)) {
   return Node.isExplicit();
-
 }
 
 /// \brief If the given case statement does not use the GNU case range


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

[PATCH] D12110: [SemaExpr] Re-enable missing assertion

[Davide Italiano via cfe-commits]

davide created this revision.
davide added a reviewer: rsmith.
davide added a subscriber: cfe-commits.

This has been disabled for a long time, but:
1) Initializers work (and apparently they're re reason why this was disabled).
2) various tests happen to hit this code path and the invariant seems to be 
always verified.

I propose to add this back, it may be useful to catch mistakes.

http://reviews.llvm.org/D12110

Files:
  lib/Sema/SemaExpr.cpp

Index: lib/Sema/SemaExpr.cpp
===
--- lib/Sema/SemaExpr.cpp
+++ lib/Sema/SemaExpr.cpp
@@ -5085,8 +5085,7 @@
 Sema::ActOnCompoundLiteral(SourceLocation LParenLoc, ParsedType Ty,
SourceLocation RParenLoc, Expr *InitExpr) {
   assert(Ty && "ActOnCompoundLiteral(): missing type");
-  // FIXME: put back this assert when initializers are worked out.
-  //assert((InitExpr != 0) && "ActOnCompoundLiteral(): missing expression");
+  assert((InitExpr != 0) && "ActOnCompoundLiteral(): missing expression");
 
   TypeSourceInfo *TInfo;
   QualType literalType = GetTypeFromParser(Ty, &TInfo);


Index: lib/Sema/SemaExpr.cpp
===
--- lib/Sema/SemaExpr.cpp
+++ lib/Sema/SemaExpr.cpp
@@ -5085,8 +5085,7 @@
 Sema::ActOnCompoundLiteral(SourceLocation LParenLoc, ParsedType Ty,
SourceLocation RParenLoc, Expr *InitExpr) {
   assert(Ty && "ActOnCompoundLiteral(): missing type");
-  // FIXME: put back this assert when initializers are worked out.
-  //assert((InitExpr != 0) && "ActOnCompoundLiteral(): missing expression");
+  assert((InitExpr != 0) && "ActOnCompoundLiteral(): missing expression");
 
   TypeSourceInfo *TInfo;
   QualType literalType = GetTypeFromParser(Ty, &TInfo);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

RE: Second Lit tests C++11 compatibility patch: using preprocessor to filter expected-error

[Li, Charles via cfe-commits]

Hi Justin and Richard,

>> +// RUN: %clang_cc1 -E -C -P -triple x86_64-apple-darwin10 %s > %t1.c 
>> +// RUN: %clang_cc1 -fsyntax-only -verify -triple 
>> +x86_64-apple-darwin10 %t1.c

> I think you forgot to switch this one to stop preprocessing first.

Thank you for catching this. I have removed it for this patch.


> +#if (!defined(__cplusplus)) || (__cplusplus <= 199711L) // C or C++03 or 
> earlier modes
> You can simplify that to:
> #if __cplusplus <= 199711L
> Otherwise, this LGTM.

Thank you, I have made the simplifications


> __cplusplus will expand to 0 inside a #if in C (as will any un#defined 
> identifier).

As an aside, I did a "-E -dM" and __cplusplus is not in the macro dump.
Likewise, having __cplusplus stand alone inside a t.c file will not cause 
preprocessor to replace it with 0.
It appears the macro replacement of __cplusplus is context sensitive.


Cheers,
Charles

-Original Message-
From: Justin Bogner [mailto:jus...@justinbogner.com] On Behalf Of Justin Bogner
Sent: Monday, August 17, 2015 9:28 PM
To: Li, Charles
Cc: Richard Smith; cfe-commits@lists.llvm.org
Subject: Re: Second Lit tests C++11 compatibility patch: using preprocessor to 
filter expected-error

"Li, Charles"  writes:
> Hi Richard,
>
> I have modified the “expected-“ lines as you requested.
>
> Cheers,
>
> Charles
>
> From: meta...@gmail.com [mailto:meta...@gmail.com] On Behalf Of 
> Richard Smith
> Sent: Monday, August 17, 2015 5:41 PM
> To: Li, Charles
> Cc: Justin Bogner; cfe-commits@lists.llvm.org
> Subject: Re: Second Lit tests C++11 compatibility patch: using 
> preprocessor to filter expected-error
>
> On Mon, Aug 17, 2015 at 5:15 PM, Li, Charles via cfe-commits < 
> cfe-commits@lists.llvm.org> wrote:
>
> Hi Richard and Justin,
>
>> What's the upside to this approach? AFAICT it makes the test harder 
>> to read
> and errors less informative due to pointing at the wrong lines, but 
> (at least in switch-1.c) it doesn't actually reduce any code 
> duplication or anything like that. What is this gaining us apart from 
> not having to create one more file?
>
> Thank you Justin.
>
> Our original intention was to get the Lit tests to run at any default 
> C++ dialect.
>
> We first discovered that FileCheck does not respect #ifdef since it 
> does not know about pre-defined macros.
>
> So we figured if we preprocess the source first, the preprocessor will 
> filter the #ifdef sections and the output will feed nicely into FileCheck.
>
> The upside is the test can run at the default dialect in addition to 
> explicitly specified dialect.
>
> The downside is, as you mentioned, the errors diagnostics would point 
> to the wrong lines.
>
>> The only thing novel about this approach is using the preprocessor to
> achieve it. -verify *does* respect #ifdef, and we have a lot of tests 
> that rely on that.
>
> Thank you Richard.
>
> We erroneously assumed that “// CHECK:” and “// expected-error” work 
> the same way.
>
> But now we realized that assumption was wrong.
>
> In light this discussion, I have removed the preprocessing to 
> temporary step for all tests.
>
> The attached patch (Lit_24.patch) revised 2 test fixes relative to the 
> previous patch (Lit_22.patch)
>
>   test/Analysis/temp-obj-dtors-cfg-output.cpp
>
> This test uses FileCheck to check for CFG dump.
>
> Instead of using #ifdef for the dialect specific “// CHECK:” 
> lines,
>
> I have created 2 check-prefixes “CXX11” and “CXX98”.
>
> The pre-process step have been removed.
>
>   test/Sema/switch-1.c
>
> This test uses –verify to check for integer overflows diagnostics.
>
> The pre-process step have been removed.
>
> The #ifdef is kept since it works with -verify.
>
> Instead of duplicating the code, you can do this:
>
> case blah:
>
> #if __cplusplus >= 201103L
>
> // expected-error@-2 {{error 2 lines above}}
>
> #else
>
> // expected-error@-4 {{error 4 lines above}}
>
> #endif
>
> Please let me know how you feel about this patch.
>
> Sincerely,
>
> Charles
>
> From: meta...@gmail.com [mailto:meta...@gmail.com] On Behalf Of Richard
> Smith
> Sent: Monday, August 17, 2015 1:07 PM
> To: Li, Charles
> Cc: cfe-commits@lists.llvm.org
> Subject: Re: Second Lit tests C++11 compatibility patch: using
> preprocessor to filter expected-error
>
> On Mon, Aug 17, 2015 at 9:56 AM, Li, Charles via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> Hi Clang developers,
>
> We here at Sony are continuing to update the Lit tests for C++ dialects
> compatibility.
>
> Attached is the second patch. (As a reference, here is the link to the
> discussion on the previous Lit patch. http://lists.cs.uiuc.edu/pipermail/
> cfe-commits/Week-of-Mon-20150727/134667.html)
>
> In this second patch, there is 1 complicated change and 3 simple changes.
>
> Here is the complicated change first.
>
> test/Sema/switch-1.c
>
>   This test verifies the d

[libcxx] r245333 - [libcxx] Disable -Wnon-virtual-dtor warning in

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Tue Aug 18 14:39:35 2015
New Revision: 245333

URL: http://llvm.org/viewvc/llvm-project?rev=245333&view=rev
Log:
[libcxx] Disable -Wnon-virtual-dtor warning in 

Summary:
Normally people won't see warnings in libc++ headers, but if they compile with 
"-Wsystem-headers -Wnon-virtual-dtor" they will likely see issues in .

In the libc++ implementation `time_get' has a private base class, 
`__time_get_c_storage`, with virtual methods but a non-virtual destructor. 
`time_get` itself can safely be used as a polymorphic base class because it 
inherits a virtual destructor from `locale::facet`. To placate the compiler we 
change `__time_get_c_storage`'s destructor from public to protected, ensuring 
that it will never be deleted polymorphically.

Reviewers: mclow.lists

Subscribers: cfe-commits

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

Modified:
libcxx/trunk/include/locale

Modified: libcxx/trunk/include/locale
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/locale?rev=245333&r1=245332&r2=245333&view=diff
==
--- libcxx/trunk/include/locale (original)
+++ libcxx/trunk/include/locale Tue Aug 18 14:39:35 2015
@@ -1888,6 +1888,9 @@ protected:
 virtual const string_type& __r() const;
 virtual const string_type& __x() const;
 virtual const string_type& __X() const;
+
+_LIBCPP_ALWAYS_INLINE
+~__time_get_c_storage() {}
 };
 
 template  >


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

[libcxx] r245334 - [libc++] Fix PR22606 - Leak pthread_key with static storage duration to ensure all of thread-local destructors are called.

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Tue Aug 18 14:40:38 2015
New Revision: 245334

URL: http://llvm.org/viewvc/llvm-project?rev=245334&view=rev
Log:
[libc++] Fix PR22606 - Leak pthread_key with static storage duration to ensure 
all of thread-local destructors are called.

Summary:
See https://llvm.org/bugs/show_bug.cgi?id=22606 for more discussion.

Most of the changes in this patch are file reorganization to help ensure 
assumptions about how __thread_specific_pointer is used hold. The assumptions 
are:

* `__thread_specific_ptr` is only created with a `__thread_struct` pointer.
* `__thread_specific_ptr` can only be constructed inside the 
`__thread_local_data()` function.

I'll remove the comments before committing. They are there for clarity during 
review.

Reviewers: earthdok, mclow.lists

Subscribers: cfe-commits

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

Modified:
libcxx/trunk/include/thread

Modified: libcxx/trunk/include/thread
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/thread?rev=245334&r1=245333&r2=245334&view=diff
==
--- libcxx/trunk/include/thread (original)
+++ libcxx/trunk/include/thread Tue Aug 18 14:40:38 2015
@@ -113,11 +113,38 @@ void sleep_for(const chrono::duration class __thread_specific_ptr;
+class _LIBCPP_TYPE_VIS __thread_struct;
+class _LIBCPP_HIDDEN __thread_struct_imp;
+class __assoc_sub_state;
+
+_LIBCPP_FUNC_VIS __thread_specific_ptr<__thread_struct>& __thread_local_data();
+
+class _LIBCPP_TYPE_VIS __thread_struct
+{
+__thread_struct_imp* __p_;
+
+__thread_struct(const __thread_struct&);
+__thread_struct& operator=(const __thread_struct&);
+public:
+__thread_struct();
+~__thread_struct();
+
+void notify_all_at_thread_exit(condition_variable*, mutex*);
+void __make_ready_at_thread_exit(__assoc_sub_state*);
+};
+
 template 
 class __thread_specific_ptr
 {
 pthread_key_t __key_;
 
+ // Only __thread_local_data() may construct a __thread_specific_ptr
+ // and only with _Tp == __thread_struct.
+static_assert(is_same<_Tp, __thread_struct>::value, "");
+__thread_specific_ptr();
+friend _LIBCPP_FUNC_VIS __thread_specific_ptr<__thread_struct>& 
__thread_local_data();
+
 __thread_specific_ptr(const __thread_specific_ptr&);
 __thread_specific_ptr& operator=(const __thread_specific_ptr&);
 
@@ -125,7 +152,6 @@ class __thread_specific_ptr
 public:
 typedef _Tp* pointer;
 
-__thread_specific_ptr();
 ~__thread_specific_ptr();
 
 _LIBCPP_INLINE_VISIBILITY
@@ -159,7 +185,10 @@ __thread_specific_ptr<_Tp>::__thread_spe
 template 
 __thread_specific_ptr<_Tp>::~__thread_specific_ptr()
 {
-pthread_key_delete(__key_);
+// __thread_specific_ptr is only created with a static storage duration
+// so this destructor is only invoked during program termination. Invoking
+// pthread_key_delete(__key_) may prevent other threads from deleting their
+// thread local data. For this reason we leak the key.
 }
 
 template 
@@ -307,26 +336,6 @@ public:
 static unsigned hardware_concurrency() _NOEXCEPT;
 };
 
-class __assoc_sub_state;
-
-class _LIBCPP_HIDDEN __thread_struct_imp;
-
-class _LIBCPP_TYPE_VIS __thread_struct
-{
-__thread_struct_imp* __p_;
-
-__thread_struct(const __thread_struct&);
-__thread_struct& operator=(const __thread_struct&);
-public:
-__thread_struct();
-~__thread_struct();
-
-void notify_all_at_thread_exit(condition_variable*, mutex*);
-void __make_ready_at_thread_exit(__assoc_sub_state*);
-};
-
-_LIBCPP_FUNC_VIS __thread_specific_ptr<__thread_struct>& __thread_local_data();
-
 #ifndef _LIBCPP_HAS_NO_VARIADICS
 
 template 


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

[libcxx] r245335 - [libcxx] Fix PR23589: std::function doesn't recognize null pointer to varargs function.

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Tue Aug 18 14:41:51 2015
New Revision: 245335

URL: http://llvm.org/viewvc/llvm-project?rev=245335&view=rev
Log:
[libcxx] Fix PR23589: std::function doesn't recognize null pointer to varargs 
function.

Summary:
This patch fixes __not_null's detection of nullptr by breaking it down into 4 
cases.

1. `__not_null(Tp const&)`: Default case. Tp is not null.
2. `__not_null(Tp* __ptr);` Case for pointers to functions.
3. `__not_null(_Ret _Class::* __ptr);` Case for pointers to members.
4. `__not_null(function const&);`: Cases for other std::functions.

Reviewers: mclow.lists

Subscribers: cfe-commits

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

Added:

libcxx/trunk/test/std/utilities/function.objects/func.wrap/func.wrap.func/func.wrap.func.con/F_nullptr.pass.cpp
Modified:
libcxx/trunk/include/__functional_03
libcxx/trunk/include/functional

Modified: libcxx/trunk/include/__functional_03
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__functional_03?rev=245335&r1=245334&r2=245335&view=diff
==
--- libcxx/trunk/include/__functional_03 (original)
+++ libcxx/trunk/include/__functional_03 Tue Aug 18 14:41:51 2015
@@ -451,15 +451,6 @@ class _LIBCPP_TYPE_VIS_ONLY function<_Rp
 aligned_storage<3*sizeof(void*)>::type __buf_;
 __base* __f_;
 
-template 
-_LIBCPP_INLINE_VISIBILITY
-static bool __not_null(const _Fp&) {return true;}
-template 
-_LIBCPP_INLINE_VISIBILITY
-static bool __not_null(_R2 (*__p)()) {return __p;}
-template 
-_LIBCPP_INLINE_VISIBILITY
-static bool __not_null(const function<_R2()>& __p) {return __p;}
 public:
 typedef _Rp result_type;
 
@@ -558,7 +549,7 @@ function<_Rp()>::function(_Fp __f,
  typename 
enable_if::value>::type*)
 : __f_(0)
 {
-if (__not_null(__f))
+if (__function::__not_null(__f))
 {
 typedef __function::__func<_Fp, allocator<_Fp>, _Rp()> _FF;
 if (sizeof(_FF) <= sizeof(__buf_))
@@ -585,7 +576,7 @@ function<_Rp()>::function(allocator_arg_
 : __f_(0)
 {
 typedef allocator_traits<_Alloc> __alloc_traits;
-if (__not_null(__f))
+if (__function::__not_null(__f))
 {
 typedef __function::__func<_Fp, _Alloc, _Rp()> _FF;
 if (sizeof(_FF) <= sizeof(__buf_))
@@ -736,27 +727,6 @@ class _LIBCPP_TYPE_VIS_ONLY function<_Rp
 aligned_storage<3*sizeof(void*)>::type __buf_;
 __base* __f_;
 
-template 
-_LIBCPP_INLINE_VISIBILITY
-static bool __not_null(const _Fp&) {return true;}
-template 
-_LIBCPP_INLINE_VISIBILITY
-static bool __not_null(_R2 (*__p)(_B0)) {return __p;}
-template 
-_LIBCPP_INLINE_VISIBILITY
-static bool __not_null(_R2 (_Cp::*__p)()) {return __p;}
-template 
-_LIBCPP_INLINE_VISIBILITY
-static bool __not_null(_R2 (_Cp::*__p)() const) {return __p;}
-template 
-_LIBCPP_INLINE_VISIBILITY
-static bool __not_null(_R2 (_Cp::*__p)() volatile) {return __p;}
-template 
-_LIBCPP_INLINE_VISIBILITY
-static bool __not_null(_R2 (_Cp::*__p)() const volatile) {return __p;}
-template 
-_LIBCPP_INLINE_VISIBILITY
-static bool __not_null(const function<_R2(_B0)>& __p) {return __p;}
 public:
 typedef _Rp result_type;
 
@@ -855,7 +825,7 @@ function<_Rp(_A0)>::function(_Fp __f,
  typename 
enable_if::value>::type*)
 : __f_(0)
 {
-if (__not_null(__f))
+if (__function::__not_null(__f))
 {
 typedef __function::__func<_Fp, allocator<_Fp>, _Rp(_A0)> _FF;
 if (sizeof(_FF) <= sizeof(__buf_))
@@ -882,7 +852,7 @@ function<_Rp(_A0)>::function(allocator_a
 : __f_(0)
 {
 typedef allocator_traits<_Alloc> __alloc_traits;
-if (__not_null(__f))
+if (__function::__not_null(__f))
 {
 typedef __function::__func<_Fp, _Alloc, _Rp(_A0)> _FF;
 if (sizeof(_FF) <= sizeof(__buf_))
@@ -1033,27 +1003,6 @@ class _LIBCPP_TYPE_VIS_ONLY function<_Rp
 aligned_storage<3*sizeof(void*)>::type __buf_;
 __base* __f_;
 
-template 
-_LIBCPP_INLINE_VISIBILITY
-static bool __not_null(const _Fp&) {return true;}
-template 
-_LIBCPP_INLINE_VISIBILITY
-static bool __not_null(_R2 (*__p)(_B0, _B1)) {return __p;}
-template 
-_LIBCPP_INLINE_VISIBILITY
-static bool __not_null(_R2 (_Cp::*__p)(_B1)) {return __p;}
-template 
-_LIBCPP_INLINE_VISIBILITY
-static bool __not_null(_R2 (_Cp::*__p)(_B1) const) {return __p;}
-template 
-_LIBCPP_INLINE_VISIBILITY
-static bool __not_null(_R2 (_Cp::*__p)(_B1) volatile) {return __p;}
-template 
-_LIBCPP_INLINE_VISIBILITY
-static bool __not_null(_R2 (_Cp::*__p)(_B1) const volatile) {return 
__p;}
-template 
-_LIBCPP_INLINE_VISIBILITY
-  

[libcxx] r245336 - Broke C++03 compatibility in 245330. Fix that.

[Marshall Clow via cfe-commits]

Author: marshall
Date: Tue Aug 18 14:51:37 2015
New Revision: 245336

URL: http://llvm.org/viewvc/llvm-project?rev=245336&view=rev
Log:
Broke C++03 compatibility in 245330. Fix that.

Modified:
libcxx/trunk/include/memory

Modified: libcxx/trunk/include/memory
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/memory?rev=245336&r1=245335&r2=245336&view=diff
==
--- libcxx/trunk/include/memory (original)
+++ libcxx/trunk/include/memory Tue Aug 18 14:51:37 2015
@@ -5574,7 +5574,7 @@ template 
 _LIBCPP_INLINE_VISIBILITY
 void __swap_allocator(_Alloc &, _Alloc &, false_type) _NOEXCEPT {}
 
-template >
+template  >
 struct __noexcept_move_assign_container : public integral_constant 14


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

Re: [PATCH] D12110: [SemaExpr] Re-enable missing assertion

[Davide Italiano via cfe-commits]

While at it, maybe the assertion can be modernized removing the != 0 part.

On Tue, Aug 18, 2015 at 3:09 PM, Davide Italiano  wrote:
> davide created this revision.
> davide added a reviewer: rsmith.
> davide added a subscriber: cfe-commits.
>
> This has been disabled for a long time, but:
> 1) Initializers work (and apparently they're re reason why this was disabled).
> 2) various tests happen to hit this code path and the invariant seems to be 
> always verified.
>
> I propose to add this back, it may be useful to catch mistakes.
>
> http://reviews.llvm.org/D12110
>
> Files:
>   lib/Sema/SemaExpr.cpp
>
> Index: lib/Sema/SemaExpr.cpp
> ===
> --- lib/Sema/SemaExpr.cpp
> +++ lib/Sema/SemaExpr.cpp
> @@ -5085,8 +5085,7 @@
>  Sema::ActOnCompoundLiteral(SourceLocation LParenLoc, ParsedType Ty,
> SourceLocation RParenLoc, Expr *InitExpr) {
>assert(Ty && "ActOnCompoundLiteral(): missing type");
> -  // FIXME: put back this assert when initializers are worked out.
> -  //assert((InitExpr != 0) && "ActOnCompoundLiteral(): missing expression");
> +  assert((InitExpr != 0) && "ActOnCompoundLiteral(): missing expression");
>
>TypeSourceInfo *TInfo;
>QualType literalType = GetTypeFromParser(Ty, &TInfo);
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r244416 - [modules] PR22534: Load files specified by -fmodule-file= eagerly. In particular, this avoids the need to re-parse module map files when using such a module.

[Gábor Horváth via cfe-commits]

Sorry, I sent the original message to the wrong list.

-- Forwarded message --
From: Gábor Horváth 
Date: 18 August 2015 at 12:59
Subject: Re: r244416 - [modules] PR22534: Load files specified by
-fmodule-file= eagerly. In particular, this avoids the need to re-parse
module map files when using such a module.
To: Richard Smith 
Cc: "cfe-comm...@cs.uiuc.edu" 


Hi!

In r244416 you made createModuleManager to call the Initialize method of
the ASTConsumer.
Because of this change the ASTConsumer::Initialize might be called twice in
some scenarios.

This change makes the Static Analyzer crash (use after free) in those
scenarios. I think most of the ASTConsumers was not written with that in
mind Initialize might be called twice for the object. This fact is also not
covered by the documentation.

In my opinion we should either guarantee that the Initialize method will be
called only once during the lifetime of an ASTConsumer, or document the
fact that, it might be called multiple times and notify the authors of the
different consumers to update their classes accordingly (announcement on
the mailing list?).

What do you think?

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

r245339 - Simplify Diagnostic's ctors a bit by using in-class initializers for its members

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Tue Aug 18 15:24:06 2015
New Revision: 245339

URL: http://llvm.org/viewvc/llvm-project?rev=245339&view=rev
Log:
Simplify Diagnostic's ctors a bit by using in-class initializers for its members

Modified:
cfe/trunk/include/clang/Basic/Diagnostic.h

Modified: cfe/trunk/include/clang/Basic/Diagnostic.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Diagnostic.h?rev=245339&r1=245338&r2=245339&view=diff
==
--- cfe/trunk/include/clang/Basic/Diagnostic.h (original)
+++ cfe/trunk/include/clang/Basic/Diagnostic.h Tue Aug 18 15:24:06 2015
@@ -864,28 +864,27 @@ public:
 /// the common fields to registers, eliminating increments of the NumArgs 
field,
 /// for example.
 class DiagnosticBuilder {
-  mutable DiagnosticsEngine *DiagObj;
-  mutable unsigned NumArgs;
+  mutable DiagnosticsEngine *DiagObj = nullptr;
+  mutable unsigned NumArgs = 0;
 
   /// \brief Status variable indicating if this diagnostic is still active.
   ///
   // NOTE: This field is redundant with DiagObj (IsActive iff (DiagObj == 0)),
   // but LLVM is not currently smart enough to eliminate the null check that
   // Emit() would end up with if we used that as our status variable.
-  mutable bool IsActive;
+  mutable bool IsActive = false;
 
   /// \brief Flag indicating that this diagnostic is being emitted via a
   /// call to ForceEmit.
-  mutable bool IsForceEmit;
+  mutable bool IsForceEmit = false;
 
   void operator=(const DiagnosticBuilder &) = delete;
   friend class DiagnosticsEngine;
 
-  DiagnosticBuilder()
-  : DiagObj(nullptr), NumArgs(0), IsActive(false), IsForceEmit(false) {}
+  DiagnosticBuilder() = default;
 
   explicit DiagnosticBuilder(DiagnosticsEngine *diagObj)
-  : DiagObj(diagObj), NumArgs(0), IsActive(true), IsForceEmit(false) {
+  : DiagObj(diagObj), IsActive(true) {
 assert(diagObj && "DiagnosticBuilder requires a valid DiagnosticsEngine!");
 diagObj->DiagRanges.clear();
 diagObj->DiagFixItHints.clear();


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

[clang-tools-extra] r245340 - We no longer need a custom matcher for this; use the builtin AST matcher instead. NFC, and existing tests should cover this change.

[Aaron Ballman via cfe-commits]

Author: aaronballman
Date: Tue Aug 18 15:27:44 2015
New Revision: 245340

URL: http://llvm.org/viewvc/llvm-project?rev=245340&view=rev
Log:
We no longer need a custom matcher for this; use the builtin AST matcher 
instead. NFC, and existing tests should cover this change.

Modified:
clang-tools-extra/trunk/clang-tidy/google/UnnamedNamespaceInHeaderCheck.cpp

Modified: 
clang-tools-extra/trunk/clang-tidy/google/UnnamedNamespaceInHeaderCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/google/UnnamedNamespaceInHeaderCheck.cpp?rev=245340&r1=245339&r2=245340&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/google/UnnamedNamespaceInHeaderCheck.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/google/UnnamedNamespaceInHeaderCheck.cpp 
Tue Aug 18 15:27:44 2015
@@ -15,20 +15,14 @@
 using namespace clang::ast_matchers;
 
 namespace clang {
-namespace {
-AST_MATCHER(NamespaceDecl, isAnonymousNamespace) {
-  return Node.isAnonymousNamespace();
-}
-} // namespace
-
 namespace tidy {
 namespace google {
 namespace build {
 
 void UnnamedNamespaceInHeaderCheck::registerMatchers(
 ast_matchers::MatchFinder *Finder) {
-  Finder->addMatcher(
-  namespaceDecl(isAnonymousNamespace()).bind("anonymousNamespace"), this);
+  Finder->addMatcher(namespaceDecl(isAnonymous()).bind("anonymousNamespace"),
+ this);
 }
 
 void


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

r245342 - Revert r245323, it caused PR24493.

[Nico Weber via cfe-commits]

Author: nico
Date: Tue Aug 18 15:32:55 2015
New Revision: 245342

URL: http://llvm.org/viewvc/llvm-project?rev=245342&view=rev
Log:
Revert r245323, it caused PR24493.

Modified:
cfe/trunk/lib/AST/ExprConstant.cpp
cfe/trunk/test/CodeGen/object-size.c
cfe/trunk/test/Sema/const-eval.c

Modified: cfe/trunk/lib/AST/ExprConstant.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ExprConstant.cpp?rev=245342&r1=245341&r2=245342&view=diff
==
--- cfe/trunk/lib/AST/ExprConstant.cpp (original)
+++ cfe/trunk/lib/AST/ExprConstant.cpp Tue Aug 18 15:32:55 2015
@@ -967,6 +967,10 @@ namespace {
 // Check this LValue refers to an object. If not, set the designator to be
 // invalid and emit a diagnostic.
 bool checkSubobject(EvalInfo &Info, const Expr *E, CheckSubobjectKind CSK) 
{
+  // Outside C++11, do not build a designator referring to a subobject of
+  // any object: we won't use such a designator for anything.
+  if (!Info.getLangOpts().CPlusPlus11)
+Designator.setInvalid();
   return (CSK == CSK_ArrayToPointer || checkNullPointer(Info, E, CSK)) &&
  Designator.checkSubobject(Info, E, CSK);
 }
@@ -2709,7 +2713,8 @@ static bool handleLValueToRValueConversi
 
   // Check for special cases where there is no existing APValue to look at.
   const Expr *Base = LVal.Base.dyn_cast();
-  if (Base && !LVal.CallIndex && !Type.isVolatileQualified()) {
+  if (!LVal.Designator.Invalid && Base && !LVal.CallIndex &&
+  !Type.isVolatileQualified()) {
 if (const CompoundLiteralExpr *CLE = dyn_cast(Base)) {
   // In C99, a CompoundLiteralExpr is an lvalue, and we defer evaluating 
the
   // initializer until now for such expressions. Such an expression can't 
be
@@ -5993,7 +5998,8 @@ public:
   bool VisitSizeOfPackExpr(const SizeOfPackExpr *E);
 
 private:
-  bool TryEvaluateBuiltinObjectSize(const CallExpr *E, unsigned Type);
+  static QualType GetObjectType(APValue::LValueBase B);
+  bool TryEvaluateBuiltinObjectSize(const CallExpr *E);
   // FIXME: Missing: array subscript of vector, member of vector
 };
 } // end anonymous namespace
@@ -6165,7 +6171,7 @@ static bool EvaluateBuiltinConstantP(AST
 
 /// Retrieves the "underlying object type" of the given expression,
 /// as used by __builtin_object_size.
-static QualType getObjectType(APValue::LValueBase B) {
+QualType IntExprEvaluator::GetObjectType(APValue::LValueBase B) {
   if (const ValueDecl *D = B.dyn_cast()) {
 if (const VarDecl *VD = dyn_cast(D))
   return VD->getType();
@@ -6177,87 +6183,49 @@ static QualType getObjectType(APValue::L
   return QualType();
 }
 
-bool IntExprEvaluator::TryEvaluateBuiltinObjectSize(const CallExpr *E,
-unsigned Type) {
-  // Determine the denoted object.
+bool IntExprEvaluator::TryEvaluateBuiltinObjectSize(const CallExpr *E) {
   LValue Base;
+
   {
 // The operand of __builtin_object_size is never evaluated for 
side-effects.
 // If there are any, but we can determine the pointed-to object anyway, 
then
 // ignore the side-effects.
 SpeculativeEvaluationRAII SpeculativeEval(Info);
-FoldConstant Fold(Info, true);
 if (!EvaluatePointer(E->getArg(0), Base, Info))
   return false;
   }
 
-  CharUnits BaseOffset = Base.getLValueOffset();
-
-  // If we point to before the start of the object, there are no
-  // accessible bytes.
-  if (BaseOffset < CharUnits::Zero())
-return Success(0, E);
-
-  // If Type & 1 is 0, the object in question is the complete object; reset to
-  // a complete object designator in that case.
-  //
-  // If Type is 1 and we've lost track of the subobject, just find the complete
-  // object instead. (If Type is 3, that's not correct behavior and we should
-  // return 0 instead.)
-  LValue End = Base;
-  if (((Type & 1) == 0) || (End.Designator.Invalid && Type == 1)) {
-QualType T = getObjectType(End.getLValueBase());
-if (T.isNull())
-  End.Designator.setInvalid();
-else {
-  End.Designator = SubobjectDesignator(T);
-  End.Offset = CharUnits::Zero();
-}
-  }
-
-  // FIXME: We should produce a valid object size for an unknown object with a
-  // known designator, if Type & 1 is 1. For instance:
-  //
-  //   extern struct X { char buff[32]; int a, b, c; } *p;
-  //   int a = __builtin_object_size(p->buff + 4, 3); // returns 28
-  //   int b = __builtin_object_size(p->buff + 4, 2); // returns 0, not 40
-  //
-  // This is GCC's behavior. We currently don't do this, but (hopefully) will 
in
-  // the near future.
-
-  // If it is not possible to determine which objects ptr points to at compile
-  // time, __builtin_object_size should return (size_t) -1 for type 0 or 1
-  // and (size_t) 0 for type 2 or 3.
-  if (End.Designator.Invalid)
-return false;
-
-  // According to the GCC documentation, we want the size of the subobject
-  // denote

[libcxx] r245343 - GC empty directory.

[Joerg Sonnenberger via cfe-commits]

Author: joerg
Date: Tue Aug 18 15:34:33 2015
New Revision: 245343

URL: http://llvm.org/viewvc/llvm-project?rev=245343&view=rev
Log:
GC empty directory.

Removed:
libcxx/trunk/src/support/newlib/

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

r245344 - [sanitizer] Add -lutil to static runtime link flags.

[Evgeniy Stepanov via cfe-commits]

Author: eugenis
Date: Tue Aug 18 15:36:11 2015
New Revision: 245344

URL: http://llvm.org/viewvc/llvm-project?rev=245344&view=rev
Log:
[sanitizer] Add -lutil to static runtime link flags.

This is needed to prevent breakage of -Wl,-as-needed link when
interceptors for functions in libutil are added. See PR15823.

Modified:
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/test/Driver/sanitizer-ld.c

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=245344&r1=245343&r2=245344&view=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Tue Aug 18 15:36:11 2015
@@ -2498,6 +2498,7 @@ static void linkSanitizerRuntimeDeps(con
   CmdArgs.push_back("--no-as-needed");
   CmdArgs.push_back("-lpthread");
   CmdArgs.push_back("-lrt");
+  CmdArgs.push_back("-lutil");
   CmdArgs.push_back("-lm");
   // There's no libdl on FreeBSD.
   if (TC.getTriple().getOS() != llvm::Triple::FreeBSD)

Modified: cfe/trunk/test/Driver/sanitizer-ld.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/sanitizer-ld.c?rev=245344&r1=245343&r2=245344&view=diff
==
--- cfe/trunk/test/Driver/sanitizer-ld.c (original)
+++ cfe/trunk/test/Driver/sanitizer-ld.c Tue Aug 18 15:36:11 2015
@@ -14,6 +14,7 @@
 // CHECK-ASAN-LINUX-NOT: "-export-dynamic"
 // CHECK-ASAN-LINUX: "-lpthread"
 // CHECK-ASAN-LINUX: "-lrt"
+// CHECK-ASAN-LINUX: "-lutil"
 // CHECK-ASAN-LINUX: "-ldl"
 
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
@@ -29,6 +30,7 @@
 // CHECK-SHARED-ASAN-LINUX: "-whole-archive" 
"{{.*}}libclang_rt.asan-preinit-i386.a" "-no-whole-archive"
 // CHECK-SHARED-ASAN-LINUX-NOT: "-lpthread"
 // CHECK-SHARED-ASAN-LINUX-NOT: "-lrt"
+// CHECK-SHARED-ASAN-LINUX-NOT: "-lutil"
 // CHECK-SHARED-ASAN-LINUX-NOT: "-ldl"
 // CHECK-SHARED-ASAN-LINUX-NOT: "-export-dynamic"
 // CHECK-SHARED-ASAN-LINUX-NOT: "--dynamic-list"
@@ -46,6 +48,7 @@
 // CHECK-DSO-SHARED-ASAN-LINUX: libclang_rt.asan-i386.so"
 // CHECK-DSO-SHARED-ASAN-LINUX-NOT: "-lpthread"
 // CHECK-DSO-SHARED-ASAN-LINUX-NOT: "-lrt"
+// CHECK-DSO-SHARED-ASAN-LINUX-NOT: "-lutil"
 // CHECK-DSO-SHARED-ASAN-LINUX-NOT: "-ldl"
 // CHECK-DSO-SHARED-ASAN-LINUX-NOT: "-export-dynamic"
 // CHECK-DSO-SHARED-ASAN-LINUX-NOT: "--dynamic-list"
@@ -65,6 +68,7 @@
 // CHECK-ASAN-FREEBSD: "-export-dynamic"
 // CHECK-ASAN-FREEBSD: "-lpthread"
 // CHECK-ASAN-FREEBSD: "-lrt"
+// CHECK-ASAN-FREEBSD: "-lutil"
 
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: -target i386-unknown-freebsd -fsanitize=address \
@@ -90,6 +94,7 @@
 // CHECK-ASAN-LINUX-CXX: stdc++
 // CHECK-ASAN-LINUX-CXX: "-lpthread"
 // CHECK-ASAN-LINUX-CXX: "-lrt"
+// CHECK-ASAN-LINUX-CXX: "-lutil"
 // CHECK-ASAN-LINUX-CXX: "-ldl"
 
 // RUN: %clang -no-canonical-prefixes %s -### -o /dev/null -fsanitize=address \
@@ -167,6 +172,7 @@
 // CHECK-TSAN-LINUX-CXX: stdc++
 // CHECK-TSAN-LINUX-CXX: "-lpthread"
 // CHECK-TSAN-LINUX-CXX: "-lrt"
+// CHECK-TSAN-LINUX-CXX: "-lutil"
 // CHECK-TSAN-LINUX-CXX: "-ldl"
 
 // RUN: %clangxx -no-canonical-prefixes %s -### -o %t.o 2>&1 \
@@ -185,6 +191,7 @@
 // CHECK-MSAN-LINUX-CXX: stdc++
 // CHECK-MSAN-LINUX-CXX: "-lpthread"
 // CHECK-MSAN-LINUX-CXX: "-lrt"
+// CHECK-MSAN-LINUX-CXX: "-lutil"
 // CHECK-MSAN-LINUX-CXX: "-ldl"
 
 // RUN: %clang -fsanitize=undefined %s -### -o %t.o 2>&1 \


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

r245346 - Initialize the AST consumer as soon as we have both an ASTConsumer and an

[Richard Smith via cfe-commits]

Author: rsmith
Date: Tue Aug 18 15:39:29 2015
New Revision: 245346

URL: http://llvm.org/viewvc/llvm-project?rev=245346&view=rev
Log:
Initialize the AST consumer as soon as we have both an ASTConsumer and an
ASTContext. Fixes some cases where we could previously initialize the AST
consumer more than once.

Modified:
cfe/trunk/lib/CodeGen/CodeGenAction.cpp
cfe/trunk/lib/CodeGen/ObjectFilePCHContainerOperations.cpp
cfe/trunk/lib/Frontend/ASTMerge.cpp
cfe/trunk/lib/Frontend/CompilerInstance.cpp
cfe/trunk/lib/Sema/Sema.cpp
cfe/trunk/test/Index/index-pch-with-module.m
cfe/trunk/test/Index/skip-parsed-bodies/compile_commands.json

Modified: cfe/trunk/lib/CodeGen/CodeGenAction.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenAction.cpp?rev=245346&r1=245345&r2=245346&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenAction.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenAction.cpp Tue Aug 18 15:39:29 2015
@@ -82,11 +82,8 @@ namespace clang {
 }
 
 void Initialize(ASTContext &Ctx) override {
-  if (Context) {
-assert(Context == &Ctx);
-return;
-  }
-
+  assert(!Context && "initialized multiple times");
+
   Context = &Ctx;
 
   if (llvm::TimePassesIsEnabled)

Modified: cfe/trunk/lib/CodeGen/ObjectFilePCHContainerOperations.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/ObjectFilePCHContainerOperations.cpp?rev=245346&r1=245345&r2=245346&view=diff
==
--- cfe/trunk/lib/CodeGen/ObjectFilePCHContainerOperations.cpp (original)
+++ cfe/trunk/lib/CodeGen/ObjectFilePCHContainerOperations.cpp Tue Aug 18 
15:39:29 2015
@@ -71,10 +71,7 @@ public:
   virtual ~PCHContainerGenerator() {}
 
   void Initialize(ASTContext &Context) override {
-if (Ctx) {
-  assert(Ctx == &Context);
-  return;
-}
+assert(!Ctx && "initialized multiple times");
 
 Ctx = &Context;
 VMContext.reset(new llvm::LLVMContext());

Modified: cfe/trunk/lib/Frontend/ASTMerge.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/ASTMerge.cpp?rev=245346&r1=245345&r2=245346&view=diff
==
--- cfe/trunk/lib/Frontend/ASTMerge.cpp (original)
+++ cfe/trunk/lib/Frontend/ASTMerge.cpp Tue Aug 18 15:39:29 2015
@@ -59,7 +59,6 @@ void ASTMergeAction::ExecuteAction() {
  /*MinimalImport=*/false);
 
 TranslationUnitDecl *TU = Unit->getASTContext().getTranslationUnitDecl();
-CI.getASTConsumer().Initialize(CI.getASTContext());
 for (auto *D : TU->decls()) {
   // Don't re-import __va_list_tag, __builtin_va_list.
   if (const auto *ND = dyn_cast(D))

Modified: cfe/trunk/lib/Frontend/CompilerInstance.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/CompilerInstance.cpp?rev=245346&r1=245345&r2=245346&view=diff
==
--- cfe/trunk/lib/Frontend/CompilerInstance.cpp (original)
+++ cfe/trunk/lib/Frontend/CompilerInstance.cpp Tue Aug 18 15:39:29 2015
@@ -96,7 +96,12 @@ void CompilerInstance::setSourceManager(
 
 void CompilerInstance::setPreprocessor(Preprocessor *Value) { PP = Value; }
 
-void CompilerInstance::setASTContext(ASTContext *Value) { Context = Value; }
+void CompilerInstance::setASTContext(ASTContext *Value) {
+  Context = Value;
+
+  if (Context && Consumer)
+getASTConsumer().Initialize(getASTContext());
+}
 
 void CompilerInstance::setSema(Sema *S) {
   TheSema.reset(S);
@@ -104,6 +109,9 @@ void CompilerInstance::setSema(Sema *S)
 
 void CompilerInstance::setASTConsumer(std::unique_ptr Value) {
   Consumer = std::move(Value);
+
+  if (Context && Consumer)
+getASTConsumer().Initialize(getASTContext());
 }
 
 void CompilerInstance::setCodeCompletionConsumer(CodeCompleteConsumer *Value) {
@@ -385,10 +393,11 @@ std::string CompilerInstance::getSpecifi
 
 void CompilerInstance::createASTContext() {
   Preprocessor &PP = getPreprocessor();
-  Context = new ASTContext(getLangOpts(), PP.getSourceManager(),
-   PP.getIdentifierTable(), PP.getSelectorTable(),
-   PP.getBuiltinInfo());
+  auto *Context = new ASTContext(getLangOpts(), PP.getSourceManager(),
+ PP.getIdentifierTable(), 
PP.getSelectorTable(),
+ PP.getBuiltinInfo());
   Context->InitBuiltinTypes(getTarget());
+  setASTContext(Context);
 }
 
 // ExternalASTSource
@@ -1249,7 +1258,7 @@ void CompilerInstance::createModuleManag
   ReadTimer = llvm::make_unique("Reading modules",
  *FrontendTimerGroup);
 ModuleManager = new ASTReader(
-getPreprocessor(), *Context, getPCHContainerReader(),
+getPreprocessor(), getASTCont

r245352 - Workaround -Wdeprecated on SemDiagnosticConsumer's tricksy copy ctor.

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Tue Aug 18 15:54:26 2015
New Revision: 245352

URL: http://llvm.org/viewvc/llvm-project?rev=245352&view=rev
Log:
Workaround -Wdeprecated on SemDiagnosticConsumer's tricksy copy ctor.

Modified:
cfe/trunk/include/clang/Sema/Sema.h

Modified: cfe/trunk/include/clang/Sema/Sema.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=245352&r1=245351&r2=245352&view=diff
==
--- cfe/trunk/include/clang/Sema/Sema.h (original)
+++ cfe/trunk/include/clang/Sema/Sema.h Tue Aug 18 15:54:26 2015
@@ -1054,6 +1054,14 @@ public:
 SemaDiagnosticBuilder(DiagnosticBuilder &DB, Sema &SemaRef, unsigned 
DiagID)
   : DiagnosticBuilder(DB), SemaRef(SemaRef), DiagID(DiagID) { }
 
+// This is a cunning lie. DiagnosticBuilder actually performs move
+// construction in its copy constructor (but due to varied uses, it's not
+// possible to conveniently express this as actual move construction). So
+// the default copy ctor here is fine, because the base class disables the
+// source anyway, so the user-defined ~SemaDiagnosticBuilder is a safe 
no-op
+// in that case anwyay.
+SemaDiagnosticBuilder(const SemaDiagnosticBuilder&) = default;
+
 ~SemaDiagnosticBuilder() {
   // If we aren't active, there is nothing to do.
   if (!isActive()) return;


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

Re: r245352 - Workaround -Wdeprecated on SemDiagnosticConsumer's tricksy copy ctor.

[David Blaikie via cfe-commits]

Richard, do you think there's anything we could do better here?

It seems difficult to support proper move semantic behavior for
[Sema]DiagnosticBuilder across the two common use cases:

  DiagnosticBuilder D;
  D << x;
  D << y;
  return D;

and

  return DiagnosticBuilder() << x << y;

The only thing I can imagine is if every one of those op<< were function
templates using universal references (I forget, is that the right name for
them?) and matching their return value (so in the first case, passed a
non-const lvalue ref, they return by non-const lvalue ref, and in the
second case, passed an rvalue, they return the same). But that seems
painful.


On Tue, Aug 18, 2015 at 1:54 PM, David Blaikie via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: dblaikie
> Date: Tue Aug 18 15:54:26 2015
> New Revision: 245352
>
> URL: http://llvm.org/viewvc/llvm-project?rev=245352&view=rev
> Log:
> Workaround -Wdeprecated on SemDiagnosticConsumer's tricksy copy ctor.
>
> Modified:
> cfe/trunk/include/clang/Sema/Sema.h
>
> Modified: cfe/trunk/include/clang/Sema/Sema.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=245352&r1=245351&r2=245352&view=diff
>
> ==
> --- cfe/trunk/include/clang/Sema/Sema.h (original)
> +++ cfe/trunk/include/clang/Sema/Sema.h Tue Aug 18 15:54:26 2015
> @@ -1054,6 +1054,14 @@ public:
>  SemaDiagnosticBuilder(DiagnosticBuilder &DB, Sema &SemaRef, unsigned
> DiagID)
>: DiagnosticBuilder(DB), SemaRef(SemaRef), DiagID(DiagID) { }
>
> +// This is a cunning lie. DiagnosticBuilder actually performs move
> +// construction in its copy constructor (but due to varied uses, it's
> not
> +// possible to conveniently express this as actual move
> construction). So
> +// the default copy ctor here is fine, because the base class
> disables the
> +// source anyway, so the user-defined ~SemaDiagnosticBuilder is a
> safe no-op
> +// in that case anwyay.
> +SemaDiagnosticBuilder(const SemaDiagnosticBuilder&) = default;
> +
>  ~SemaDiagnosticBuilder() {
>// If we aren't active, there is nothing to do.
>if (!isActive()) return;
>
>
> ___
> 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

[libcxx] r245354 - Move atomic_support.h and config_elast.h into src/include

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Tue Aug 18 16:08:54 2015
New Revision: 245354

URL: http://llvm.org/viewvc/llvm-project?rev=245354&view=rev
Log:
Move atomic_support.h and config_elast.h into src/include

Added:
libcxx/trunk/src/include/
libcxx/trunk/src/include/atomic_support.h
libcxx/trunk/src/include/config_elast.h
Removed:
libcxx/trunk/src/config_elast.h
libcxx/trunk/src/support/atomic_support.h
Modified:
libcxx/trunk/src/ios.cpp
libcxx/trunk/src/memory.cpp
libcxx/trunk/src/mutex.cpp
libcxx/trunk/src/system_error.cpp

Removed: libcxx/trunk/src/config_elast.h
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/src/config_elast.h?rev=245353&view=auto
==
--- libcxx/trunk/src/config_elast.h (original)
+++ libcxx/trunk/src/config_elast.h (removed)
@@ -1,36 +0,0 @@
-//===--- config_elast.h 
---===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is dual licensed under the MIT and the University of Illinois Open
-// Source Licenses. See LICENSE.TXT for details.
-//
-//===--===//
-
-#ifndef _LIBCPP_CONFIG_ELAST
-#define _LIBCPP_CONFIG_ELAST
-
-#if defined(_WIN32)
-#include 
-#else
-#include 
-#endif
-
-#if defined(ELAST)
-#define _LIBCPP_ELAST ELAST
-#elif defined(_NEWLIB_VERSION)
-#define _LIBCPP_ELAST __ELASTERROR
-#elif defined(__linux__)
-#define _LIBCPP_ELAST 4095
-#elif defined(__APPLE__)
-// No _LIBCPP_ELAST needed on Apple
-#elif defined(__sun__)
-#define _LIBCPP_ELAST ESTALE
-#elif defined(_WIN32)
-#define _LIBCPP_ELAST _sys_nerr
-#else
-// Warn here so that the person doing the libcxx port has an easier time:
-#warning ELAST for this platform not yet implemented
-#endif
-
-#endif // _LIBCPP_CONFIG_ELAST

Added: libcxx/trunk/src/include/atomic_support.h
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/src/include/atomic_support.h?rev=245354&view=auto
==
--- libcxx/trunk/src/include/atomic_support.h (added)
+++ libcxx/trunk/src/include/atomic_support.h Tue Aug 18 16:08:54 2015
@@ -0,0 +1,142 @@
+#ifndef ATOMIC_SUPPORT_H
+#define ATOMIC_SUPPORT_H
+
+#include "__config"
+#include "memory" // for __libcpp_relaxed_load
+
+#if defined(__clang__) && __has_builtin(__atomic_load_n) \
+   && __has_builtin(__atomic_store_n)\
+   && __has_builtin(__atomic_add_fetch)  \
+   && __has_builtin(__atomic_compare_exchange_n) \
+   && defined(__ATOMIC_RELAXED)  \
+   && defined(__ATOMIC_CONSUME)  \
+   && defined(__ATOMIC_ACQUIRE)  \
+   && defined(__ATOMIC_RELEASE)  \
+   && defined(__ATOMIC_ACQ_REL)  \
+   && defined(__ATOMIC_SEQ_CST)
+#   define _LIBCPP_HAS_ATOMIC_BUILTINS
+#elif !defined(__clang__) && defined(_GNUC_VER) && _GNUC_VER >= 407
+#   define _LIBCPP_HAS_ATOMIC_BUILTINS
+#endif
+
+#if !defined(_LIBCPP_HAS_ATOMIC_BUILTINS) && !defined(_LIBCPP_HAS_NO_THREADS)
+# if defined(_MSC_VER) && !defined(__clang__)
+_LIBCPP_WARNING("Building libc++ without __atomic builtins is unsupported")
+# else
+#   warning Building libc++ without __atomic builtins is unsupported
+# endif
+#endif
+
+_LIBCPP_BEGIN_NAMESPACE_STD
+
+namespace {
+
+#if defined(_LIBCPP_HAS_ATOMIC_BUILTINS) && !defined(_LIBCPP_HAS_NO_THREADS)
+
+enum __libcpp_atomic_order {
+_AO_Relaxed = __ATOMIC_RELAXED,
+_AO_Consume = __ATOMIC_CONSUME,
+_AO_Aquire  = __ATOMIC_ACQUIRE,
+_AO_Release = __ATOMIC_RELEASE,
+_AO_Acq_Rel = __ATOMIC_ACQ_REL,
+_AO_Seq = __ATOMIC_SEQ_CST
+};
+
+template 
+inline _LIBCPP_INLINE_VISIBILITY
+void __libcpp_atomic_store(_ValueType* __dest, _FromType __val,
+   int __order = _AO_Seq)
+{
+__atomic_store_n(__dest, __val, __order);
+}
+
+template 
+inline _LIBCPP_INLINE_VISIBILITY
+void __libcpp_relaxed_store(_ValueType* __dest, _FromType __val)
+{
+__atomic_store_n(__dest, __val, _AO_Relaxed);
+}
+
+template 
+inline _LIBCPP_INLINE_VISIBILITY
+_ValueType __libcpp_atomic_load(_ValueType const* __val,
+int __order = _AO_Seq)
+{
+return __atomic_load_n(__val, __order);
+}
+
+template 
+inline _LIBCPP_INLINE_VISIBILITY
+_ValueType __libcpp_atomic_add(_ValueType* __val, _AddType __a,
+   int __order = _AO_Seq)
+{
+return __atomic_add_fetch(__val, __a, __order);
+}
+
+template 
+inline _LIBCPP_INLINE_VISIBILITY
+bool __libcpp_atomic_compare_exchange(_ValueType* __val,
+_ValueType* __expected, _ValueType __after,
+int __success_order = _AO_Seq,
+int __fail_order = _AO_Seq)
+{
+return __

Re: r245304 - We shouldn't need to pass -fno-strict-aliasing when building clang with clang.

[Hal Finkel via cfe-commits]

- Original Message -
> From: "Chris Bieneman via cfe-commits" 
> To: cfe-commits@lists.llvm.org
> Sent: Tuesday, August 18, 2015 11:15:44 AM
> Subject: r245304 - We shouldn't need to pass -fno-strict-aliasing when 
> building clang with clang.
> 
> Author: cbieneman
> Date: Tue Aug 18 11:15:44 2015
> New Revision: 245304
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=245304&view=rev
> Log:
> We shouldn't need to pass -fno-strict-aliasing when building clang
> with clang.
> 
> Summary: The code comments in the Makefile indicate this was put in
> place to support issues when building clang with GCC. Today clang's
> strict aliasing works, so we shouldn't pass -fno-strict-aliasing
> when building with clang.
> 
> Reviewers: bogner, echristo
> 
> Subscribers: cfe-commits
> 
> Differential Revision: http://reviews.llvm.org/D12036
> 
> Modified:
> cfe/trunk/CMakeLists.txt
> cfe/trunk/Makefile
> 
> Modified: cfe/trunk/CMakeLists.txt
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/CMakeLists.txt?rev=245304&r1=245303&r2=245304&view=diff
> ==
> --- cfe/trunk/CMakeLists.txt (original)
> +++ cfe/trunk/CMakeLists.txt Tue Aug 18 11:15:44 2015
> @@ -253,7 +253,10 @@ configure_file(
>  
>  # Add appropriate flags for GCC
>  if (LLVM_COMPILER_IS_GCC_COMPATIBLE)
> -  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-common
> -Woverloaded-virtual -fno-strict-aliasing")
> +  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-common
> -Woverloaded-virtual")
> +  if (NOT "${CMAKE_CXX_COMPILER_ID}" MATCHES "Clang")
> +set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-strict-aliasing")
> +  endif ()
>  
># Enable -pedantic for Clang even if it's not enabled for LLVM.
>if (NOT LLVM_ENABLE_PEDANTIC)
> 
> Modified: cfe/trunk/Makefile
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/Makefile?rev=245304&r1=245303&r2=245304&view=diff
> ==
> --- cfe/trunk/Makefile (original)
> +++ cfe/trunk/Makefile Tue Aug 18 11:15:44 2015
> @@ -67,8 +67,11 @@ endif
>  #   http://gcc.gnu.org/PR41874
>  #   http://gcc.gnu.org/PR41838
>  #
> -# We can revisit this when LLVM/Clang support it.
> +# We don't need to do this if the host compiler is clang.
> +ifeq ($(CXX_COMPILER), "clang")
>  CXX.Flags += -fno-strict-aliasing
> +endif

This logic is backwards, it disables strict aliasing when the compiler is 
clang, and leaves it enabled otherwise. Perhaps you want to ifeq -> ifneq?

 -Hal

> +
>  
>  # Set up Clang's tblgen.
>  ifndef CLANG_TBLGEN
> 
> 
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r245359 - [autoconf] Fixing reversed logic introduced r245304.

[Chris Bieneman via cfe-commits]

Author: cbieneman
Date: Tue Aug 18 16:23:44 2015
New Revision: 245359

URL: http://llvm.org/viewvc/llvm-project?rev=245359&view=rev
Log:
[autoconf] Fixing reversed logic introduced r245304.

Thanks for the catch Hal!

Modified:
cfe/trunk/Makefile

Modified: cfe/trunk/Makefile
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/Makefile?rev=245359&r1=245358&r2=245359&view=diff
==
--- cfe/trunk/Makefile (original)
+++ cfe/trunk/Makefile Tue Aug 18 16:23:44 2015
@@ -68,7 +68,7 @@ endif
 #   http://gcc.gnu.org/PR41838
 #
 # We don't need to do this if the host compiler is clang.
-ifeq ($(CXX_COMPILER), "clang")
+ifneq ($(CXX_COMPILER), "clang")
 CXX.Flags += -fno-strict-aliasing
 endif
 


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

Re: r245304 - We shouldn't need to pass -fno-strict-aliasing when building clang with clang.

[Chris Bieneman via cfe-commits]

Wow! Thank you for catching that!

Fixed in r245359.

-Chris

> On Aug 18, 2015, at 2:15 PM, Hal Finkel  wrote:
> 
> - Original Message -
>> From: "Chris Bieneman via cfe-commits" 
>> To: cfe-commits@lists.llvm.org
>> Sent: Tuesday, August 18, 2015 11:15:44 AM
>> Subject: r245304 - We shouldn't need to pass -fno-strict-aliasing when 
>> building clang with clang.
>> 
>> Author: cbieneman
>> Date: Tue Aug 18 11:15:44 2015
>> New Revision: 245304
>> 
>> URL: 
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D245304-26view-3Drev&d=BQICaQ&c=eEvniauFctOgLOKGJOplqw&r=Hfcbhu5JC70tzQtVGDgDJg&m=LZ6mOKBg2jvfMXj1e1AeP3UD23LAMeWnUDGoS7OAfRo&s=OwUS_r30_fyatqpHGo8Mfbpay2m_WXuAZbUe6yr-m5A&e=
>>  
>> Log:
>> We shouldn't need to pass -fno-strict-aliasing when building clang
>> with clang.
>> 
>> Summary: The code comments in the Makefile indicate this was put in
>> place to support issues when building clang with GCC. Today clang's
>> strict aliasing works, so we shouldn't pass -fno-strict-aliasing
>> when building with clang.
>> 
>> Reviewers: bogner, echristo
>> 
>> Subscribers: cfe-commits
>> 
>> Differential Revision: 
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D12036&d=BQICaQ&c=eEvniauFctOgLOKGJOplqw&r=Hfcbhu5JC70tzQtVGDgDJg&m=LZ6mOKBg2jvfMXj1e1AeP3UD23LAMeWnUDGoS7OAfRo&s=61uO56iUYJqbrrPmpu3s3IC4BqPskB4xQ1IhffBJM5g&e=
>>  
>> 
>> Modified:
>>cfe/trunk/CMakeLists.txt
>>cfe/trunk/Makefile
>> 
>> Modified: cfe/trunk/CMakeLists.txt
>> URL:
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_CMakeLists.txt-3Frev-3D245304-26r1-3D245303-26r2-3D245304-26view-3Ddiff&d=BQICaQ&c=eEvniauFctOgLOKGJOplqw&r=Hfcbhu5JC70tzQtVGDgDJg&m=LZ6mOKBg2jvfMXj1e1AeP3UD23LAMeWnUDGoS7OAfRo&s=kMBsIYcu-mqcpUPKstn6a3qKi1tZ8ZipfNj7-n5zJTE&e=
>>  
>> ==
>> --- cfe/trunk/CMakeLists.txt (original)
>> +++ cfe/trunk/CMakeLists.txt Tue Aug 18 11:15:44 2015
>> @@ -253,7 +253,10 @@ configure_file(
>> 
>> # Add appropriate flags for GCC
>> if (LLVM_COMPILER_IS_GCC_COMPATIBLE)
>> -  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-common
>> -Woverloaded-virtual -fno-strict-aliasing")
>> +  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-common
>> -Woverloaded-virtual")
>> +  if (NOT "${CMAKE_CXX_COMPILER_ID}" MATCHES "Clang")
>> +set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-strict-aliasing")
>> +  endif ()
>> 
>>   # Enable -pedantic for Clang even if it's not enabled for LLVM.
>>   if (NOT LLVM_ENABLE_PEDANTIC)
>> 
>> Modified: cfe/trunk/Makefile
>> URL:
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_Makefile-3Frev-3D245304-26r1-3D245303-26r2-3D245304-26view-3Ddiff&d=BQICaQ&c=eEvniauFctOgLOKGJOplqw&r=Hfcbhu5JC70tzQtVGDgDJg&m=LZ6mOKBg2jvfMXj1e1AeP3UD23LAMeWnUDGoS7OAfRo&s=oVWnGjjONssWGC7tIuD3ftvoidZBhow7jIBK3jGNPzY&e=
>>  
>> ==
>> --- cfe/trunk/Makefile (original)
>> +++ cfe/trunk/Makefile Tue Aug 18 11:15:44 2015
>> @@ -67,8 +67,11 @@ endif
>> #   
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__gcc.gnu.org_PR41874&d=BQICaQ&c=eEvniauFctOgLOKGJOplqw&r=Hfcbhu5JC70tzQtVGDgDJg&m=LZ6mOKBg2jvfMXj1e1AeP3UD23LAMeWnUDGoS7OAfRo&s=LjF6Tc2RbfHB6IGj5VcgnpQp0V7Ag_ptcayUefS3k0k&e=
>>  
>> #   
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__gcc.gnu.org_PR41838&d=BQICaQ&c=eEvniauFctOgLOKGJOplqw&r=Hfcbhu5JC70tzQtVGDgDJg&m=LZ6mOKBg2jvfMXj1e1AeP3UD23LAMeWnUDGoS7OAfRo&s=Wg9_cRbtgqczt08wykO8rWLJYEmUWSxVMeZmPVOxo_Y&e=
>>  
>> #
>> -# We can revisit this when LLVM/Clang support it.
>> +# We don't need to do this if the host compiler is clang.
>> +ifeq ($(CXX_COMPILER), "clang")
>> CXX.Flags += -fno-strict-aliasing
>> +endif
> 
> This logic is backwards, it disables strict aliasing when the compiler is 
> clang, and leaves it enabled otherwise. Perhaps you want to ifeq -> ifneq?
> 
> -Hal
> 
>> +
>> 
>> # Set up Clang's tblgen.
>> ifndef CLANG_TBLGEN
>> 
>> 
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Dcommits&d=BQICaQ&c=eEvniauFctOgLOKGJOplqw&r=Hfcbhu5JC70tzQtVGDgDJg&m=LZ6mOKBg2jvfMXj1e1AeP3UD23LAMeWnUDGoS7OAfRo&s=WPkNdzCUCk9mc2t5-AjiEWBOb63rfTn7cniall2Powc&e=
>>  
>> 
> 
> -- 
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory

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

Re: [PATCH] D11046: [libcxx] Add Atomic test helper and fix TSAN failures.

[Eric Fiselier via cfe-commits]

EricWF updated this revision to Diff 32454.
EricWF added a comment.

Add more explanation to the wait tests.


http://reviews.llvm.org/D11046

Files:
  test/std/thread/thread.condition/notify_all_at_thread_exit.pass.cpp
  
test/std/thread/thread.condition/thread.condition.condvarany/wait.exception.pass.cpp
  
test/std/thread/thread.condition/thread.condition.condvarany/wait_for.exception.pass.cpp
  
test/std/thread/thread.condition/thread.condition.condvarany/wait_terminates.sh.cpp
  test/support/test_atomic.h

Index: test/support/test_atomic.h
===
--- /dev/null
+++ test/support/test_atomic.h
@@ -0,0 +1,109 @@
+#ifndef SUPPORT_TEST_ATOMIC_H
+#define SUPPORT_TEST_ATOMIC_H
+
+// If the atomic memory order macros are defined then assume
+// the compiler supports the required atomic builtins.
+#if !defined(__ATOMIC_SEQ_CST)
+#define TEST_HAS_NO_ATOMICS
+#endif
+
+template 
+class Atomic {
+   ValType value;
+   Atomic(Atomic const&);
+   Atomic& operator=(Atomic const&);
+   Atomic& operator=(Atomic const&) volatile;
+private:
+  enum {
+#if !defined(TEST_HAS_NO_ATOMICS)
+AO_Relaxed = __ATOMIC_RELAXED,
+AO_Seq = __ATOMIC_SEQ_CST
+#else
+AO_Relaxed,
+AO_Seq
+#endif
+  };
+  template 
+  static inline void atomic_store_imp(Tp* dest, FromType from, int order = AO_Seq) {
+#if !defined(TEST_HAS_NO_ATOMICS)
+  __atomic_store_n(dest, from, order);
+#else
+*dest = from;
+#endif
+  }
+
+  template 
+  static inline Tp atomic_load_imp(Tp* from, int order = AO_Seq) {
+#if !defined(TEST_HAS_NO_ATOMICS)
+return __atomic_load_n(from, order);
+#else
+return *from;
+#endif
+  }
+
+  template 
+  static inline Tp atomic_add_imp(Tp* val, AddType add, int order = AO_Seq) {
+#if !defined(TEST_HAS_NO_ATOMICS)
+  return __atomic_add_fetch(val, add, order);
+#else
+return *val += add;
+#endif
+  }
+
+  template 
+  static inline Tp atomic_exchange_imp(Tp* val, Tp other, int order = AO_Seq) {
+#if !defined(TEST_HAS_NO_ATOMICS)
+  return __atomic_exchange_n(val, other, order);
+#else
+  Tp old = *val;
+  *val = other;
+  return old;
+#endif
+  }
+public:
+Atomic() : value(0) {}
+Atomic(ValType x) : value(x) {}
+
+ValType operator=(ValType val) {
+   atomic_store_imp(&value, val);
+   return val;
+}
+
+ValType operator=(ValType val) volatile {
+atomic_store_imp(&value, val);
+return val;
+}
+
+ValType load() const volatile { return atomic_load_imp(&value); }
+voidstore(ValType val) volatile { atomic_store_imp(&value, val); }
+
+ValType relaxedLoad() const volatile { return atomic_load_imp(&value, AO_Relaxed); }
+voidrelaxedStore(ValType val) volatile { atomic_store_imp(&value, val, AO_Relaxed); }
+
+ValType exchange(ValType other) volatile { return atomic_exchange_imp(&value, other); }
+booltestAndSet() volatile { return atomic_exchange_imp(&value, 1); }
+voidclear() volatile { atomic_store_imp(&value, 0); }
+
+operator ValType() const { return atomic_load_imp(&value); }
+operator ValType() const volatile { return atomic_load_imp(&value); }
+
+ValType operator+=(ValType val)  { return atomic_add_imp(&value, val); }
+ValType operator-=(ValType val)  { return atomic_add_imp(&value, -val); }
+ValType operator+=(ValType val) volatile { return atomic_add_imp(&value, val); }
+ValType operator-=(ValType val) volatile { return atomic_add_imp(&value, -val); }
+
+ValType operator++()  { return *this += 1; }
+ValType operator++(int) { return (*this += 1) - 1;  }
+ValType operator++() volatile { return *this += 1; }
+ValType operator++(int) volatile { return (*this += 1) - 1;  }
+
+ValType operator--() { return *this -= 1; }
+ValType operator--(int) { return (*this -= 1) + 1; }
+ValType operator--() volatile { return *this -= 1; }
+ValType operator--(int) volatile { return (*this -= 1) + 1; }
+};
+
+typedef Atomic AtomicInt;
+typedef Atomic AtomicBool;
+
+#endif // SUPPORT_TEST_ATOMIC_H
Index: test/std/thread/thread.condition/thread.condition.condvarany/wait_terminates.sh.cpp
===
--- /dev/null
+++ test/std/thread/thread.condition/thread.condition.condvarany/wait_terminates.sh.cpp
@@ -0,0 +1,132 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+// UNSUPPORTED: libcpp-has-no-threads
+
+// 
+
+// class condition_variable_any;
+
+// RUN: %build
+// RUN: %run 1
+// RUN: %run 2
+// RUN: %run 3
+// RUN: %run 4
+// RUN: %run 5
+// RUN: %run 6
+
+// 

[PATCH] D12117: Replace __asan_set_error_exit_code() with __sanitizer_set_death_callback()

[Alexey Samsonov via cfe-commits]

samsonov created this revision.
samsonov added a reviewer: EricWF.
samsonov added a subscriber: cfe-commits.

We are going to remove the former soon.

http://reviews.llvm.org/D12117

Files:
  test/libcxx/containers/sequences/vector/asan.pass.cpp

Index: test/libcxx/containers/sequences/vector/asan.pass.cpp
===
--- test/libcxx/containers/sequences/vector/asan.pass.cpp
+++ test/libcxx/containers/sequences/vector/asan.pass.cpp
@@ -21,8 +21,11 @@
 #include "test_macros.h"
 
 #ifndef _LIBCPP_HAS_NO_ASAN
-extern "C" void __asan_set_error_exit_code(int);
+extern "C" void __sanitizer_set_death_callback(void (*callback)(void));
 
+void do_exit() {
+  exit(0);
+}
 
 int main()
 {
@@ -48,7 +51,7 @@
 assert(is_contiguous_container_asan_correct(v));
 }
 
-__asan_set_error_exit_code(0);
+__sanitizer_set_death_callback(do_exit);
 {
 typedef int T;
 typedef std::vector C;


Index: test/libcxx/containers/sequences/vector/asan.pass.cpp
===
--- test/libcxx/containers/sequences/vector/asan.pass.cpp
+++ test/libcxx/containers/sequences/vector/asan.pass.cpp
@@ -21,8 +21,11 @@
 #include "test_macros.h"
 
 #ifndef _LIBCPP_HAS_NO_ASAN
-extern "C" void __asan_set_error_exit_code(int);
+extern "C" void __sanitizer_set_death_callback(void (*callback)(void));
 
+void do_exit() {
+  exit(0);
+}
 
 int main()
 {
@@ -48,7 +51,7 @@
 assert(is_contiguous_container_asan_correct(v));
 }
 
-__asan_set_error_exit_code(0);
+__sanitizer_set_death_callback(do_exit);
 {
 typedef int T;
 typedef std::vector C;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r244416 - [modules] PR22534: Load files specified by -fmodule-file= eagerly. In particular, this avoids the need to re-parse module map files when using such a module.

[Richard Smith via cfe-commits]

On Tue, Aug 18, 2015 at 1:52 PM, Gábor Horváth  wrote:

> On 18 August 2015 at 13:41, Richard Smith  wrote:
>
>> On Tue, Aug 18, 2015 at 12:59 PM, Gábor Horváth 
>> wrote:
>>
>>> Hi!
>>>
>>> In r244416 you made createModuleManager to call the Initialize method
>>> of the ASTConsumer.
>>> Because of this change the ASTConsumer::Initialize might be called twice
>>> in some scenarios.
>>>
>>> This change makes the Static Analyzer crash (use after free) in those
>>> scenarios. I think most of the ASTConsumers was not written with that in
>>> mind Initialize might be called twice for the object. This fact is also not
>>> covered by the documentation.
>>>
>>> In my opinion we should either guarantee that the Initialize method will
>>> be called only once during the lifetime of an ASTConsumer, or document the
>>> fact that, it might be called multiple times and notify the authors of the
>>> different consumers to update their classes accordingly (announcement on
>>> the mailing list?).
>>>
>>> What do you think?
>>>
>>
>> Fixed in r245346.
>>
>> It seems like an indicator of poor design that we have the initialize
>> function at all. I don't think there is any situation where we need or want
>> to create an ASTConsumer before we have enough information to create the
>> ASTContext, so perhaps we can just get rid of this function.
>>
>
> Thank you for fixing this!
>
> I agree that it would be awesome to get rid of that function.
>

CCing the right list again :)

Are you interested in looking into this? (If not, it's going to near the
bottom of a long list of TODO items for me...)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r245361 - Range-based-for-convert some loops in ASTWriter. No functionality change intended.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Tue Aug 18 16:53:42 2015
New Revision: 245361

URL: http://llvm.org/viewvc/llvm-project?rev=245361&view=rev
Log:
Range-based-for-convert some loops in ASTWriter. No functionality change 
intended.

Modified:
cfe/trunk/include/clang/Basic/Module.h
cfe/trunk/lib/Serialization/ASTWriter.cpp

Modified: cfe/trunk/include/clang/Basic/Module.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Module.h?rev=245361&r1=245360&r2=245361&view=diff
==
--- cfe/trunk/include/clang/Basic/Module.h (original)
+++ cfe/trunk/include/clang/Basic/Module.h Tue Aug 18 16:53:42 2015
@@ -475,6 +475,13 @@ public:
   submodule_iterator submodule_end()   { return SubModules.end(); }
   submodule_const_iterator submodule_end() const { return SubModules.end(); }
 
+  llvm::iterator_range submodules() {
+return llvm::make_range(submodule_begin(), submodule_end());
+  }
+  llvm::iterator_range submodules() const {
+return llvm::make_range(submodule_begin(), submodule_end());
+  }
+
   /// \brief Appends this module's list of exported modules to \p Exported.
   ///
   /// This provides a subset of immediately imported modules (the ones that are

Modified: cfe/trunk/lib/Serialization/ASTWriter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTWriter.cpp?rev=245361&r1=245360&r2=245361&view=diff
==
--- cfe/trunk/lib/Serialization/ASTWriter.cpp (original)
+++ cfe/trunk/lib/Serialization/ASTWriter.cpp Tue Aug 18 16:53:42 2015
@@ -2284,6 +2284,9 @@ void ASTWriter::WritePreprocessorDetail(
 }
 
 unsigned ASTWriter::getSubmoduleID(Module *Mod) {
+  if (!Mod)
+return 0;
+
   llvm::DenseMap::iterator Known = SubmoduleIDs.find(Mod);
   if (Known != SubmoduleIDs.end())
 return Known->second;
@@ -2434,12 +2437,11 @@ void ASTWriter::WriteSubmodules(Module *
 Stream.EmitRecordWithBlob(DefinitionAbbrev, Record, Mod->Name);
 
 // Emit the requirements.
-for (unsigned I = 0, N = Mod->Requirements.size(); I != N; ++I) {
+for (const auto &R : Mod->Requirements) {
   Record.clear();
   Record.push_back(SUBMODULE_REQUIRES);
-  Record.push_back(Mod->Requirements[I].second);
-  Stream.EmitRecordWithBlob(RequiresAbbrev, Record,
-Mod->Requirements[I].first);
+  Record.push_back(R.second);
+  Stream.EmitRecordWithBlob(RequiresAbbrev, Record, R.first);
 }
 
 // Emit the umbrella header, if there is one.
@@ -2487,26 +2489,19 @@ void ASTWriter::WriteSubmodules(Module *
 // Emit the imports. 
 if (!Mod->Imports.empty()) {
   Record.clear();
-  for (unsigned I = 0, N = Mod->Imports.size(); I != N; ++I) {
-unsigned ImportedID = getSubmoduleID(Mod->Imports[I]);
-assert(ImportedID && "Unknown submodule!");
-Record.push_back(ImportedID);
-  }
+  for (auto *I : Mod->Imports)
+Record.push_back(getSubmoduleID(I));
   Stream.EmitRecord(SUBMODULE_IMPORTS, Record);
 }
 
 // Emit the exports. 
 if (!Mod->Exports.empty()) {
   Record.clear();
-  for (unsigned I = 0, N = Mod->Exports.size(); I != N; ++I) {
-if (Module *Exported = Mod->Exports[I].getPointer()) {
-  unsigned ExportedID = getSubmoduleID(Exported);
-  Record.push_back(ExportedID);
-} else {
-  Record.push_back(0);
-}
-
-Record.push_back(Mod->Exports[I].getInt());
+  for (const auto &E : Mod->Exports) {
+// FIXME: This may fail; we don't require that all exported modules
+// are local or imported.
+Record.push_back(getSubmoduleID(E.getPointer()));
+Record.push_back(E.getInt());
   }
   Stream.EmitRecord(SUBMODULE_EXPORTS, Record);
 }
@@ -2516,38 +2511,33 @@ void ASTWriter::WriteSubmodules(Module *
 // module itself.
 
 // Emit the link libraries.
-for (unsigned I = 0, N = Mod->LinkLibraries.size(); I != N; ++I) {
+for (const auto &LL : Mod->LinkLibraries) {
   Record.clear();
   Record.push_back(SUBMODULE_LINK_LIBRARY);
-  Record.push_back(Mod->LinkLibraries[I].IsFramework);
-  Stream.EmitRecordWithBlob(LinkLibraryAbbrev, Record,
-Mod->LinkLibraries[I].Library);
+  Record.push_back(LL.IsFramework);
+  Stream.EmitRecordWithBlob(LinkLibraryAbbrev, Record, LL.Library);
 }
 
 // Emit the conflicts.
-for (unsigned I = 0, N = Mod->Conflicts.size(); I != N; ++I) {
+for (const auto &C : Mod->Conflicts) {
   Record.clear();
   Record.push_back(SUBMODULE_CONFLICT);
-  unsigned OtherID = getSubmoduleID(Mod->Conflicts[I].Other);
-  assert(OtherID && "Unknown submodule!");
-  Record.push_back(OtherID);
-  Stream.EmitRecordWithBlob(ConflictAbbrev, Record,
-Mod->Conflicts[I].Message);

Re: r244488 - [dllimport] A non-imported class with an imported key can't have a key

[Hans Wennborg via cfe-commits]

On Tue, Aug 11, 2015 at 9:40 AM, Hans Wennborg  wrote:
> On Mon, Aug 10, 2015 at 12:39 PM, Reid Kleckner via cfe-commits
>  wrote:
>> Author: rnk
>> Date: Mon Aug 10 14:39:01 2015
>> New Revision: 244488
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=244488&view=rev
>> Log:
>> [dllimport] A non-imported class with an imported key can't have a key
>>
>> Summary:
>> The vtable takes its DLL storage class from the class, not the key
>> function. When they disagree, the vtable won't be exported by the DLL
>> that defines the key function. The easiest way to ensure that importers
>> of the class emit their own vtable is to say that the class has no key
>> function.
>>
>> Reviewers: hans, majnemer
>>
>> Subscribers: cfe-commits
>>
>> Differential Revision: http://reviews.llvm.org/D11913
>
> Should we merge this and r244266 to 3.7?

As pointed out on the r244266 thread, these patches are still not
merged as the tests don't pass on 3.7. I was hoping someone more
familiar with the patches could take a look.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r244902 - Driver: Fix include directories when not using libgcc under mingw

[Hans Wennborg via cfe-commits]

Richard, I tried to ping you on the review thread but I'm not sure it
got through. Martell requested this be merged to 3.7. What do you
think?

On Thu, Aug 13, 2015 at 8:41 AM, Martell Malone via cfe-commits
 wrote:
> Author: martell
> Date: Thu Aug 13 10:41:04 2015
> New Revision: 244902
>
> URL: http://llvm.org/viewvc/llvm-project?rev=244902&view=rev
> Log:
> Driver: Fix include directories when not using libgcc under mingw
>
> Summary:
> When we want to use mingw-w64 and clang with compiler-rt we should not
> need to have libgcc installed. This fixes finding includes when libgcc
> is not installed
>
> Reviewers: yaron.keren
>
> Subscribers: cfe-commits
>
> Differential Revision: http://reviews.llvm.org/D11808
>
> Added:
> cfe/trunk/test/Driver/Inputs/mingw_clang_tree/
> cfe/trunk/test/Driver/Inputs/mingw_clang_tree/mingw32/
> cfe/trunk/test/Driver/Inputs/mingw_clang_tree/mingw32/i686-w64-mingw32/
> 
> cfe/trunk/test/Driver/Inputs/mingw_clang_tree/mingw32/i686-w64-mingw32/include/
> 
> cfe/trunk/test/Driver/Inputs/mingw_clang_tree/mingw32/i686-w64-mingw32/include/.keep
> cfe/trunk/test/Driver/Inputs/mingw_clang_tree/mingw32/include/
> cfe/trunk/test/Driver/Inputs/mingw_clang_tree/mingw32/include/.keep
> Modified:
> cfe/trunk/lib/Driver/MinGWToolChain.cpp
> cfe/trunk/test/Driver/mingw.cpp
>
> Modified: cfe/trunk/lib/Driver/MinGWToolChain.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/MinGWToolChain.cpp?rev=244902&r1=244901&r2=244902&view=diff
> ==
> --- cfe/trunk/lib/Driver/MinGWToolChain.cpp (original)
> +++ cfe/trunk/lib/Driver/MinGWToolChain.cpp Thu Aug 13 10:41:04 2015
> @@ -47,7 +47,7 @@ void MinGW::findGccLibDir() {
>Archs.emplace_back(getTriple().getArchName());
>Archs[0] += "-w64-mingw32";
>Archs.emplace_back("mingw32");
> -  Arch = "unknown";
> +  Arch = Archs[0].str();
>// lib: Arch Linux, Ubuntu, Windows
>// lib64: openSUSE Linux
>for (StringRef CandidateLib : {"lib", "lib64"}) {
>
> Added: 
> cfe/trunk/test/Driver/Inputs/mingw_clang_tree/mingw32/i686-w64-mingw32/include/.keep
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/Inputs/mingw_clang_tree/mingw32/i686-w64-mingw32/include/.keep?rev=244902&view=auto
> ==
> (empty)
>
> Added: cfe/trunk/test/Driver/Inputs/mingw_clang_tree/mingw32/include/.keep
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/Inputs/mingw_clang_tree/mingw32/include/.keep?rev=244902&view=auto
> ==
> (empty)
>
> Modified: cfe/trunk/test/Driver/mingw.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/mingw.cpp?rev=244902&r1=244901&r2=244902&view=diff
> ==
> --- cfe/trunk/test/Driver/mingw.cpp (original)
> +++ cfe/trunk/test/Driver/mingw.cpp Thu Aug 13 10:41:04 2015
> @@ -1,3 +1,8 @@
> +// RUN: %clang -target i686-windows-gnu -c -### 
> --sysroot=%S/Inputs/mingw_clang_tree/mingw32 %s 2>&1 | FileCheck 
> -check-prefix=CHECK_MINGW_CLANG_TREE %s
> +// CHECK_MINGW_CLANG_TREE: 
> "{{.*}}/Inputs/mingw_clang_tree/mingw32{{/|}}i686-w64-mingw32{{/|}}include"
> +// CHECK_MINGW_CLANG_TREE: 
> "{{.*}}/Inputs/mingw_clang_tree/mingw32{{/|}}include"
> +
> +
>  // RUN: %clang -target i686-pc-windows-gnu -stdlib=libstdc++ -c -### 
> --sysroot=%S/Inputs/mingw_mingw_org_tree/mingw %s 2>&1 | FileCheck 
> -check-prefix=CHECK_MINGW_ORG_TREE %s
>  // CHECK_MINGW_ORG_TREE: 
> "{{.*}}/Inputs/mingw_mingw_org_tree/mingw{{/|}}lib{{/|}}gcc{{/|}}mingw32{{/|}}4.8.1{{/|}}include{{/|}}c++"
>  // CHECK_MINGW_ORG_TREE: 
> "{{.*}}/Inputs/mingw_mingw_org_tree/mingw{{/|}}lib{{/|}}gcc{{/|}}mingw32{{/|}}4.8.1{{/|}}include{{/|}}c++{{/|}}mingw32"
>
>
> ___
> 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: r244266 - [ItaniumCXXABI] Don't import RTTI data for classes with key functions

[Richard Smith via cfe-commits]

On Fri, Aug 14, 2015 at 11:27 AM, Hans Wennborg via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Tue, Aug 11, 2015 at 1:41 PM, Hans Wennborg  wrote:
> > On Thu, Aug 6, 2015 at 1:56 PM, David Majnemer via cfe-commits
> >  wrote:
> >> Author: majnemer
> >> Date: Thu Aug  6 15:56:55 2015
> >> New Revision: 244266
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=244266&view=rev
> >> Log:
> >> [ItaniumCXXABI] Don't import RTTI data for classes with key functions
> >>
> >> MinGW has some pretty strange behvaior around RTTI and
> >> dllimport/dllexport:
> >> - RTTI data is never imported
> >> - RTTI data is only exported if the class has no key function.
> >>
> >> Modified:
> >> cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
> >> cfe/trunk/test/CodeGenCXX/dllimport-rtti.cpp
> >
> > I tried to merge this to 3.7 (as discussed on the commit thread for
> > r244488), but the test doesn't pass:
> >
> > --
> >
> /usr/local/google/work/llvm-3.7/cfe.src/test/CodeGenCXX/dllimport-rtti.cpp:22:13:
> > error: expected string not found in input
> > // GNU-DAG: @_ZTV1V = available_externally dllimport
> > ^
> > :1:1: note: scanning from here
> > ; ModuleID =
> '/usr/local/google/work/llvm-3.7/cfe.src/test/CodeGenCXX/dllimport-rtti.cpp'
> > ^
> > :15:1: note: possible intended match here
> > @_ZTV1S = available_externally dllimport unnamed_addr constant [3 x
> > i8*] [i8* null, i8* bitcast (i8** @_ZTI1S to i8*), i8* bitcast (void
> > (%struct.S*)* @_ZN1S1fEv to i8*)], align 4
> > ^
> > --
> >
> > I assume there's some other commit this depends on, but I haven't been
> > able to figure out which. Can you take a look?
>
> Ping?
>

Looks like the test depends on r243090, which shouldn't go to the branch.
I'd guess we could fix the test by changing that check line to "// GNU-DAG:
@_ZTV1V = external" or similar. David?
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D12119: Analyzer: Fix a crasher in UbigraphViz

[Ismail Pazarbasi via cfe-commits]

ismailp created this revision.
ismailp added reviewers: zaks.anna, krememek.
ismailp added a subscriber: cfe-commits.

Name `Out` refers to the parameter. It is moved into the member `Out`
in ctor-init. Dereferencing null pointer will crash clang, if user
passes '-analyzer-viz-egraph-ubigraph' argument.

http://reviews.llvm.org/D12119

Files:
  lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp

Index: lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
===
--- lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
+++ lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
@@ -781,8 +781,8 @@
 UbigraphViz::UbigraphViz(std::unique_ptr Out, StringRef Filename)
 : Out(std::move(Out)), Filename(Filename), Cntr(0) {
 
-  *Out << "('vertex_style_attribute', 0, ('shape', 'icosahedron'))\n";
-  *Out << "('vertex_style', 1, 0, ('shape', 'sphere'), ('color', '#ffcc66'),"
+  *this->Out << "('vertex_style_attribute', 0, ('shape', 'icosahedron'))\n";
+  *this->Out << "('vertex_style', 1, 0, ('shape', 'sphere'), ('color', 
'#ffcc66'),"
   " ('size', '1.5'))\n";
 }
 


Index: lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
===
--- lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
+++ lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
@@ -781,8 +781,8 @@
 UbigraphViz::UbigraphViz(std::unique_ptr Out, StringRef Filename)
 : Out(std::move(Out)), Filename(Filename), Cntr(0) {
 
-  *Out << "('vertex_style_attribute', 0, ('shape', 'icosahedron'))\n";
-  *Out << "('vertex_style', 1, 0, ('shape', 'sphere'), ('color', '#ffcc66'),"
+  *this->Out << "('vertex_style_attribute', 0, ('shape', 'icosahedron'))\n";
+  *this->Out << "('vertex_style', 1, 0, ('shape', 'sphere'), ('color', '#ffcc66'),"
   " ('size', '1.5'))\n";
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r245084 - WindowsX86: long double is x87DoubleExtended on mingw

[Hans Wennborg via cfe-commits]

Richard, I tried to ping you on the review thread but I'm not sure it
got through. Martell requested this be merged to 3.7. What do you
think?

On Fri, Aug 14, 2015 at 12:05 PM, Martell Malone via cfe-commits
 wrote:
> Author: martell
> Date: Fri Aug 14 14:05:56 2015
> New Revision: 245084
>
> URL: http://llvm.org/viewvc/llvm-project?rev=245084&view=rev
> Log:
> WindowsX86: long double is x87DoubleExtended on mingw
>
> Summary:
> long double on x86 mingw is 80bits and is aligned to 16bytes
>
> Fixes:
> https://llvm.org/bugs/show_bug.cgi?id=24398
>
> Reviewers: rnk
>
> Subscribers: cfe-commits
>
> Differential Revision: http://reviews.llvm.org/D12037
>
> Modified:
> cfe/trunk/lib/Basic/Targets.cpp
>
> Modified: cfe/trunk/lib/Basic/Targets.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=245084&r1=245083&r2=245084&view=diff
> ==
> --- cfe/trunk/lib/Basic/Targets.cpp (original)
> +++ cfe/trunk/lib/Basic/Targets.cpp Fri Aug 14 14:05:56 2015
> @@ -3784,7 +3784,10 @@ namespace {
>  class MinGWX86_32TargetInfo : public WindowsX86_32TargetInfo {
>  public:
>MinGWX86_32TargetInfo(const llvm::Triple &Triple)
> -  : WindowsX86_32TargetInfo(Triple) {}
> +  : WindowsX86_32TargetInfo(Triple) {
> +LongDoubleWidth = LongDoubleAlign = 128;
> +LongDoubleFormat = &llvm::APFloat::x87DoubleExtended;
> +  }
>void getTargetDefines(const LangOptions &Opts,
>  MacroBuilder &Builder) const override {
>  WindowsX86_32TargetInfo::getTargetDefines(Opts, Builder);
> @@ -4014,7 +4017,10 @@ public:
>  class MinGWX86_64TargetInfo : public WindowsX86_64TargetInfo {
>  public:
>MinGWX86_64TargetInfo(const llvm::Triple &Triple)
> -  : WindowsX86_64TargetInfo(Triple) {}
> +  : WindowsX86_64TargetInfo(Triple) {
> +LongDoubleWidth = LongDoubleAlign = 128;
> +LongDoubleFormat = &llvm::APFloat::x87DoubleExtended;
> +  }
>void getTargetDefines(const LangOptions &Opts,
>  MacroBuilder &Builder) const override {
>  WindowsX86_64TargetInfo::getTargetDefines(Opts, Builder);
>
>
> ___
> 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] D12119: Analyzer: Fix a crasher in UbigraphViz

[Ismail Pazarbasi via cfe-commits]

ismailp added inline comments.


Comment at: lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp:749
@@ -748,3 +748,3 @@
 
   assert (Src != Dst && "Self-edges are not allowed.");
 

Is Ubigraph generator actively maintained? If I run tests with 
'-analyzer-viz-egraph-ubigraph', this assertion gets triggered. According to 
static analyzer documentation, cycles are allowed in ExplodedGraph. I am unsure 
whether self-cycles are allowed, however.


http://reviews.llvm.org/D12119



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

Re: r244416 - [modules] PR22534: Load files specified by -fmodule-file= eagerly. In particular, this avoids the need to re-parse module map files when using such a module.

[Gábor Horváth via cfe-commits]

On 18 August 2015 at 14:46, Richard Smith  wrote:

> On Tue, Aug 18, 2015 at 1:52 PM, Gábor Horváth 
> wrote:
>
>> On 18 August 2015 at 13:41, Richard Smith  wrote:
>>
>>> On Tue, Aug 18, 2015 at 12:59 PM, Gábor Horváth 
>>> wrote:
>>>
 Hi!

 In r244416 you made createModuleManager to call the Initialize method
 of the ASTConsumer.
 Because of this change the ASTConsumer::Initialize might be called
 twice in some scenarios.

 This change makes the Static Analyzer crash (use after free) in those
 scenarios. I think most of the ASTConsumers was not written with that in
 mind Initialize might be called twice for the object. This fact is also not
 covered by the documentation.

 In my opinion we should either guarantee that the Initialize method
 will be called only once during the lifetime of an ASTConsumer, or document
 the fact that, it might be called multiple times and notify the authors of
 the different consumers to update their classes accordingly (announcement
 on the mailing list?).

 What do you think?

>>>
>>> Fixed in r245346.
>>>
>>> It seems like an indicator of poor design that we have the initialize
>>> function at all. I don't think there is any situation where we need or want
>>> to create an ASTConsumer before we have enough information to create the
>>> ASTContext, so perhaps we can just get rid of this function.
>>>
>>
>> Thank you for fixing this!
>>
>> I agree that it would be awesome to get rid of that function.
>>
>
> CCing the right list again :)
>
> Are you interested in looking into this? (If not, it's going to near the
> bottom of a long list of TODO items for me...)
>

Hope to CC the right list this time :)

Well, it would end up on the bottom of my TODO list as well, so maybe we
should both add it, and the one who gets there earlier should do this.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r245367 - Wdeprecated: Support movability of EHScopeStack::Cleanup objects as they are move constructed in ConditionalCleanup::restore

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Tue Aug 18 17:09:28 2015
New Revision: 245367

URL: http://llvm.org/viewvc/llvm-project?rev=245367&view=rev
Log:
Wdeprecated: Support movability of EHScopeStack::Cleanup objects as they are 
move constructed in ConditionalCleanup::restore

Modified:
cfe/trunk/lib/CodeGen/EHScopeStack.h

Modified: cfe/trunk/lib/CodeGen/EHScopeStack.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/EHScopeStack.h?rev=245367&r1=245366&r2=245367&view=diff
==
--- cfe/trunk/lib/CodeGen/EHScopeStack.h (original)
+++ cfe/trunk/lib/CodeGen/EHScopeStack.h Tue Aug 18 17:09:28 2015
@@ -144,7 +144,12 @@ public:
   class Cleanup {
 // Anchor the construction vtable.
 virtual void anchor();
+
   public:
+Cleanup(const Cleanup &) = default;
+Cleanup(Cleanup &&) = default;
+Cleanup() = default;
+
 /// Generation flags.
 class Flags {
   enum {


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

r245368 - Fix for MSVC

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Tue Aug 18 17:10:49 2015
New Revision: 245368

URL: http://llvm.org/viewvc/llvm-project?rev=245368&view=rev
Log:
Fix for MSVC

Modified:
cfe/trunk/lib/CodeGen/EHScopeStack.h

Modified: cfe/trunk/lib/CodeGen/EHScopeStack.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/EHScopeStack.h?rev=245368&r1=245367&r2=245368&view=diff
==
--- cfe/trunk/lib/CodeGen/EHScopeStack.h (original)
+++ cfe/trunk/lib/CodeGen/EHScopeStack.h Tue Aug 18 17:10:49 2015
@@ -147,7 +147,7 @@ public:
 
   public:
 Cleanup(const Cleanup &) = default;
-Cleanup(Cleanup &&) = default;
+Cleanup(Cleanup &&) {}
 Cleanup() = default;
 
 /// Generation flags.


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

Re: [PATCH] D12119: Analyzer: Fix a crasher in UbigraphViz

[Ted Kremenek via cfe-commits]

krememek added inline comments.


Comment at: lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp:784
@@ -783,3 +783,3 @@
 
-  *Out << "('vertex_style_attribute', 0, ('shape', 'icosahedron'))\n";
-  *Out << "('vertex_style', 1, 0, ('shape', 'sphere'), ('color', '#ffcc66'),"
+  *this->Out << "('vertex_style_attribute', 0, ('shape', 'icosahedron'))\n";
+  *this->Out << "('vertex_style', 1, 0, ('shape', 'sphere'), ('color', 
'#ffcc66'),"

This seems really brittle.

Can we just rename the parameter 'Out' to something else, and then just use 
'Out'?  Seems more reasonable to rename the parameter than to change every 
single functional line of code that uses 'Out'.


http://reviews.llvm.org/D12119



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

Re: [PATCH] D12119: Analyzer: Fix a crasher in UbigraphViz

[Ted Kremenek via cfe-commits]

krememek added inline comments.


Comment at: lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp:749
@@ -748,3 +748,3 @@
 
   assert (Src != Dst && "Self-edges are not allowed.");
 

ismailp wrote:
> Is Ubigraph generator actively maintained? If I run tests with 
> '-analyzer-viz-egraph-ubigraph', this assertion gets triggered. According to 
> static analyzer documentation, cycles are allowed in ExplodedGraph. I am 
> unsure whether self-cycles are allowed, however.
There was a time where a self-cycle indicated a bug in the analyzer.  Much has 
changed since destructor support was added, but the Ubigraph support hasn't 
bitrotted.  It could be the case that this assertion needs to be removed 
because an invariant in the analyzer has changed, but I would be willing to 
also say it is possible that the tests are failing because an invariant is 
getting violated.


http://reviews.llvm.org/D12119



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

[PATCH] D12122: [CUDA] Add appropriate host/device attribute to target-specific builtins.

[Artem Belevich via cfe-commits]

tra created this revision.
tra added reviewers: eliben, echristo.
tra added a subscriber: cfe-commits.

The patch adds appropriate __host__ or __device__ attributes to target-specific 
builtins 
so we can properly check whether they may or may not be called from particular 
context.


http://reviews.llvm.org/D12122

Files:
  include/clang/Basic/Builtins.h
  lib/Sema/SemaDecl.cpp
  test/SemaCUDA/builtins.cu
  test/SemaCUDA/implicit-intrinsic.cu

Index: test/SemaCUDA/implicit-intrinsic.cu
===
--- test/SemaCUDA/implicit-intrinsic.cu
+++ test/SemaCUDA/implicit-intrinsic.cu
@@ -1,10 +1,10 @@
-// RUN: %clang_cc1 -std=gnu++11 -triple nvptx64-unknown-unknown -fsyntax-only 
-verify %s
+// RUN: %clang_cc1 -triple nvptx64-unknown-unknown -fcuda-is-device 
-fsyntax-only -verify %s
 
 #include "Inputs/cuda.h"
 
 // expected-no-diagnostics
 __device__ void __threadfence_system() {
-  // This shouldn't produce an error, since __nvvm_membar_sys is inferred to
-  // be __host__ __device__ and thus callable from device code.
+  // This shouldn't produce an error, since __nvvm_membar_sys should be
+  // __device__ and thus callable from device code.
   __nvvm_membar_sys();
 }
Index: test/SemaCUDA/builtins.cu
===
--- /dev/null
+++ test/SemaCUDA/builtins.cu
@@ -0,0 +1,35 @@
+// Tests that target-specific builtins have appropriate host/device
+// attributes and that CUDA call restrictions are enforced. Also
+// verify that non-target builtins can be used from both host and
+// device functions.
+//
+// REQUIRES: x86-registered-target
+// REQUIRES: nvptx-registered-target
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple nvptx64-unknown-cuda -fcuda-is-device \
+// RUN:   -fsyntax-only -verify %s
+
+
+#ifdef __CUDA_ARCH__
+// Device-side builtins are not allowed to be called from host functions.
+void hf() {
+  int x = __builtin_ptx_read_tid_x(); // expected-note  
{{'__builtin_ptx_read_tid_x' declared here}}
+  // expected-error@-1 {{reference to __device__ function 
'__builtin_ptx_read_tid_x' in __host__ function}}
+  x = __builtin_abs(1);
+}
+__attribute__((device)) void df() {
+  int x = __builtin_ptx_read_tid_x();
+  x = __builtin_abs(1);
+}
+#else
+// Host-side builtins are not allowed to be called from device functions.
+__attribute__((device)) void df() {
+  int x = __builtin_ia32_rdtsc();   // expected-note {{'__builtin_ia32_rdtsc' 
declared here}}
+  // expected-error@-1 {{reference to __host__ function '__builtin_ia32_rdtsc' 
in __device__ function}}
+  x = __builtin_abs(1);
+}
+void hf() {
+  int x = __builtin_ia32_rdtsc();
+  x = __builtin_abs(1);
+}
+#endif
Index: lib/Sema/SemaDecl.cpp
===
--- lib/Sema/SemaDecl.cpp
+++ lib/Sema/SemaDecl.cpp
@@ -11161,6 +11161,13 @@
   FD->addAttr(NoThrowAttr::CreateImplicit(Context, FD->getLocation()));
 if (Context.BuiltinInfo.isConst(BuiltinID) && !FD->hasAttr())
   FD->addAttr(ConstAttr::CreateImplicit(Context, FD->getLocation()));
+if (getLangOpts().CUDA && Context.BuiltinInfo.isTSBuiltin(BuiltinID) &&
+!FD->hasAttr() && !FD->hasAttr()) {
+  if (getLangOpts().CUDAIsDevice)
+FD->addAttr(CUDADeviceAttr::CreateImplicit(Context, 
FD->getLocation()));
+  else
+FD->addAttr(CUDAHostAttr::CreateImplicit(Context, FD->getLocation()));
+}
   }
 
   IdentifierInfo *Name = FD->getIdentifier();
Index: include/clang/Basic/Builtins.h
===
--- include/clang/Basic/Builtins.h
+++ include/clang/Basic/Builtins.h
@@ -81,6 +81,11 @@
 return getRecord(ID).Type;
   }
 
+  /// \brief Return true if this function is a target-specific builtin
+  bool isTSBuiltin(unsigned ID) const {
+return ID >= Builtin::FirstTSBuiltin;
+  }
+
   /// \brief Return true if this function has no side effects and doesn't
   /// read memory.
   bool isConst(unsigned ID) const {


Index: test/SemaCUDA/implicit-intrinsic.cu
===
--- test/SemaCUDA/implicit-intrinsic.cu
+++ test/SemaCUDA/implicit-intrinsic.cu
@@ -1,10 +1,10 @@
-// RUN: %clang_cc1 -std=gnu++11 -triple nvptx64-unknown-unknown -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple nvptx64-unknown-unknown -fcuda-is-device -fsyntax-only -verify %s
 
 #include "Inputs/cuda.h"
 
 // expected-no-diagnostics
 __device__ void __threadfence_system() {
-  // This shouldn't produce an error, since __nvvm_membar_sys is inferred to
-  // be __host__ __device__ and thus callable from device code.
+  // This shouldn't produce an error, since __nvvm_membar_sys should be
+  // __device__ and thus callable from device code.
   __nvvm_membar_sys();
 }
Index: test/SemaCUDA/builtins.cu
===
--- /dev/nul

[PATCH] D12123: [analyzer] Skip Pre/Post handlers for ObjC calls when receiver is nil.

[Devin Coughlin via cfe-commits]

dcoughlin created this revision.
dcoughlin added reviewers: zaks.anna, jordan_rose, xazax.hun.
dcoughlin added a subscriber: cfe-commits.
Herald added a subscriber: aemerson.

In Objective-C, method calls with nil receivers are essentially no-ops. They
do not fault (although the returned value may be garbage depending on the
declared return type and architecture). Programmers are aware of this
behavior and will complain about a false alarm when the analyzer
diagnoses API violations for method calls when the receiver is known to
be nil.

Rather than require each individual checker to be aware of this behavior
and suppress a warning when the receiver is nil, this patch
changes ExprEngineObjC so that VisitObjCMessage skips calling checker
pre/post handlers when the receiver is nil definitely nil. Instead, it adds a
new event, ObjCMessageNil, that is only called in that case.

The CallAndMessageChecker explicitly cares about this case, so I've changed it
to add a callback for ObjCMessageNil and moved the logic that handles nil 
receivers
in its PreObjCMessage callback to the new callback.

rdar://problem/18092611

http://reviews.llvm.org/D12123

Files:
  include/clang/StaticAnalyzer/Core/Checker.h
  include/clang/StaticAnalyzer/Core/CheckerManager.h
  lib/StaticAnalyzer/Checkers/CallAndMessageChecker.cpp
  lib/StaticAnalyzer/Core/CheckerManager.cpp
  lib/StaticAnalyzer/Core/ExprEngineObjC.cpp
  test/Analysis/NSContainers.m

Index: test/Analysis/NSContainers.m
===
--- test/Analysis/NSContainers.m
+++ test/Analysis/NSContainers.m
@@ -24,6 +24,8 @@
 @interface NSObject  {}
 - (id)init;
 + (id)alloc;
+
+- (id)mutableCopy;
 @end
 
 typedef struct {
@@ -292,3 +294,16 @@
   [arr addObject:0 safe:1]; // no-warning
 }
 
+@interface MyView : NSObject
+-(NSArray *)subviews;
+@end
+
+void testNoReportWhenReceiverNil(NSMutableArray *array, int b) {
+  if (array == 0) {
+[array addObject:0];
+  }
+
+  MyView *view = b ? [[MyView alloc] init] : 0;
+  NSMutableArray *subviews = [[view subviews] mutableCopy];
+  [subviews addObject:view];
+}
Index: lib/StaticAnalyzer/Core/ExprEngineObjC.cpp
===
--- lib/StaticAnalyzer/Core/ExprEngineObjC.cpp
+++ lib/StaticAnalyzer/Core/ExprEngineObjC.cpp
@@ -139,6 +139,31 @@
   CallEventRef Msg =
 CEMgr.getObjCMethodCall(ME, Pred->getState(), Pred->getLocationContext());
 
+  // If the receiver is definitely nil, skip the pre/post callbacks and instead
+  // call the ObjCMessageNil callbacks and return.
+  if (Msg->isInstanceMessage()) {
+SVal recVal = Msg->getReceiverSVal();
+if (!recVal.isUndef()) {
+  // Bifurcate the state into nil and non-nil ones.
+  DefinedOrUnknownSVal receiverVal =
+  recVal.castAs();
+  ProgramStateRef State = Pred->getState();
+
+  ProgramStateRef notNilState, nilState;
+  std::tie(notNilState, nilState) = State->assume(receiverVal);
+  if (nilState && !notNilState) {
+ExplodedNodeSet dstNil;
+StmtNodeBuilder Bldr(Pred, dstNil, *currBldrCtx);
+
+Pred = Bldr.generateNode(ME, Pred, nilState);
+assert(Pred && "Should have cached out already!");
+getCheckerManager().runCheckersForObjCMessageNil(Dst, dstNil,
+ *Msg, *this);
+return;
+  }
+}
+  }
+
   // Handle the previsits checks.
   ExplodedNodeSet dstPrevisit;
   getCheckerManager().runCheckersForPreObjCMessage(dstPrevisit, Pred,
@@ -160,35 +185,12 @@
 if (UpdatedMsg->isInstanceMessage()) {
   SVal recVal = UpdatedMsg->getReceiverSVal();
   if (!recVal.isUndef()) {
-// Bifurcate the state into nil and non-nil ones.
-DefinedOrUnknownSVal receiverVal =
-recVal.castAs();
-
-ProgramStateRef notNilState, nilState;
-std::tie(notNilState, nilState) = State->assume(receiverVal);
-
-// There are three cases: can be nil or non-nil, must be nil, must be
-// non-nil. We ignore must be nil, and merge the rest two into non-nil.
-// FIXME: This ignores many potential bugs ().
-// Revisit once we have lazier constraints.
-if (nilState && !notNilState) {
-  continue;
-}
-
-// Check if the "raise" message was sent.
-assert(notNilState);
 if (ObjCNoRet.isImplicitNoReturn(ME)) {
   // If we raise an exception, for now treat it as a sink.
   // Eventually we will want to handle exceptions properly.
   Bldr.generateSink(ME, Pred, State);
   continue;
 }
-
-// Generate a transition to non-Nil state.
-if (notNilState != State) {
-  Pred = Bldr.generateNode(ME, Pred, notNilState);
-  assert(Pred && "Should have cached out already!");
-}
   }
 } else {
   // Check for special class methods that are known to not ret

r245378 - Devirtualize EHScopeStack::Cleanup's dtor because it's never destroyed polymorphically

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Tue Aug 18 17:40:54 2015
New Revision: 245378

URL: http://llvm.org/viewvc/llvm-project?rev=245378&view=rev
Log:
Devirtualize EHScopeStack::Cleanup's dtor because it's never destroyed 
polymorphically

Modified:
cfe/trunk/lib/CodeGen/CGBlocks.cpp
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/lib/CodeGen/CGClass.cpp
cfe/trunk/lib/CodeGen/CGDecl.cpp
cfe/trunk/lib/CodeGen/CGException.cpp
cfe/trunk/lib/CodeGen/CGExprCXX.cpp
cfe/trunk/lib/CodeGen/CGObjC.cpp
cfe/trunk/lib/CodeGen/CGObjCMac.cpp
cfe/trunk/lib/CodeGen/CGObjCRuntime.cpp
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
cfe/trunk/lib/CodeGen/EHScopeStack.h
cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp

Modified: cfe/trunk/lib/CodeGen/CGBlocks.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBlocks.cpp?rev=245378&r1=245377&r2=245378&view=diff
==
--- cfe/trunk/lib/CodeGen/CGBlocks.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBlocks.cpp Tue Aug 18 17:40:54 2015
@@ -2239,7 +2239,7 @@ void CodeGenFunction::BuildBlockRelease(
 }
 
 namespace {
-  struct CallBlockRelease : EHScopeStack::Cleanup {
+  struct CallBlockRelease final : EHScopeStack::Cleanup {
 llvm::Value *Addr;
 CallBlockRelease(llvm::Value *Addr) : Addr(Addr) {}
 

Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=245378&r1=245377&r2=245378&view=diff
==
--- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCall.cpp Tue Aug 18 17:40:54 2015
@@ -2851,7 +2851,7 @@ void CodeGenFunction::EmitCallArgs(
 
 namespace {
 
-struct DestroyUnpassedArg : EHScopeStack::Cleanup {
+struct DestroyUnpassedArg final : EHScopeStack::Cleanup {
   DestroyUnpassedArg(llvm::Value *Addr, QualType Ty)
   : Addr(Addr), Ty(Ty) {}
 

Modified: cfe/trunk/lib/CodeGen/CGClass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGClass.cpp?rev=245378&r1=245377&r2=245378&view=diff
==
--- cfe/trunk/lib/CodeGen/CGClass.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGClass.cpp Tue Aug 18 17:40:54 2015
@@ -345,7 +345,7 @@ llvm::Value *CodeGenFunction::GetVTTPara
 
 namespace {
   /// Call the destructor for a direct base class.
-  struct CallBaseDtor : EHScopeStack::Cleanup {
+  struct CallBaseDtor final : EHScopeStack::Cleanup {
 const CXXRecordDecl *BaseClass;
 bool BaseIsVirtual;
 CallBaseDtor(const CXXRecordDecl *Base, bool BaseIsVirtual)
@@ -1526,7 +1526,7 @@ void CodeGenFunction::emitImplicitAssign
 
 namespace {
   /// Call the operator delete associated with the current destructor.
-  struct CallDtorDelete : EHScopeStack::Cleanup {
+  struct CallDtorDelete final : EHScopeStack::Cleanup {
 CallDtorDelete() {}
 
 void Emit(CodeGenFunction &CGF, Flags flags) override {
@@ -1537,7 +1537,7 @@ namespace {
 }
   };
 
-  struct CallDtorDeleteConditional : EHScopeStack::Cleanup {
+  struct CallDtorDeleteConditional final : EHScopeStack::Cleanup {
 llvm::Value *ShouldDeleteCondition;
   public:
 CallDtorDeleteConditional(llvm::Value *ShouldDeleteCondition)
@@ -1563,7 +1563,7 @@ namespace {
 }
   };
 
-  class DestroyField  : public EHScopeStack::Cleanup {
+  class DestroyField  final : public EHScopeStack::Cleanup {
 const FieldDecl *field;
 CodeGenFunction::Destroyer *destroyer;
 bool useEHCleanupForArray;
@@ -1933,7 +1933,7 @@ CodeGenFunction::EmitDelegateCXXConstruc
 }
 
 namespace {
-  struct CallDelegatingCtorDtor : EHScopeStack::Cleanup {
+  struct CallDelegatingCtorDtor final : EHScopeStack::Cleanup {
 const CXXDestructorDecl *Dtor;
 llvm::Value *Addr;
 CXXDtorType Type;
@@ -1987,7 +1987,7 @@ void CodeGenFunction::EmitCXXDestructorC
 }
 
 namespace {
-  struct CallLocalDtor : EHScopeStack::Cleanup {
+  struct CallLocalDtor final : EHScopeStack::Cleanup {
 const CXXDestructorDecl *Dtor;
 llvm::Value *Addr;
 

Modified: cfe/trunk/lib/CodeGen/CGDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDecl.cpp?rev=245378&r1=245377&r2=245378&view=diff
==
--- cfe/trunk/lib/CodeGen/CGDecl.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDecl.cpp Tue Aug 18 17:40:54 2015
@@ -400,7 +400,7 @@ void CodeGenFunction::EmitStaticVarDecl(
 }
 
 namespace {
-  struct DestroyObject : EHScopeStack::Cleanup {
+  struct DestroyObject final : EHScopeStack::Cleanup {
 DestroyObject(llvm::Value *addr, QualType type,
   CodeGenFunction::Destroyer *destroyer,
   bool useEHCleanupForArray)
@@ -421,7 +421,7 @@ namespace {
 }
   };
 
-  struct DestroyNRVOVariable : EHScopeStack::Cleanup {
+  struct DestroyN

Re: [PATCH] D12123: [analyzer] Skip Pre/Post handlers for ObjC calls when receiver is nil.

[Ted Kremenek via cfe-commits]

krememek added a subscriber: krememek.
krememek added a comment.

I think this is a great refinement overall, with a few minor nits.  It also 
isn't clear what the test does.



Comment at: include/clang/StaticAnalyzer/Core/CheckerManager.h:577
@@ -559,1 +576,3 @@
 
+  const std::vector &
+  getObjCMessageCheckers(ObjCCheckerKind Kind);

Can we break with tradition here and add a documentation comment?


Comment at: lib/StaticAnalyzer/Checkers/CallAndMessageChecker.cpp:64
@@ -62,2 +63,3 @@
   void checkPreObjCMessage(const ObjCMethodCall &msg, CheckerContext &C) const;
+  void checkObjCMessageNil(const ObjCMethodCall &msg, CheckerContext &C) const;
   void checkPreCall(const CallEvent &Call, CheckerContext &C) const;

Can we break with tradition here and actually add a small documentation comment?


Comment at: test/Analysis/NSContainers.m:297
@@ -294,1 +296,3 @@
 
+@interface MyView : NSObject
+-(NSArray *)subviews;

Can we add a comment above this test that makes it clear what this test is 
doing?  It is not obvious at all from basic inspection.

There's also no matching 'no-warning' or 'expected-warning', so it is not clear 
at all what it is testing.  Having the comment clearly say what the test is 
testing will make it more resilient to somebody accidentally deleting it.


http://reviews.llvm.org/D12123



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

Re: r244266 - [ItaniumCXXABI] Don't import RTTI data for classes with key functions

[Reid Kleckner via cfe-commits]

On Tue, Aug 18, 2015 at 3:00 PM, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Fri, Aug 14, 2015 at 11:27 AM, Hans Wennborg via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> On Tue, Aug 11, 2015 at 1:41 PM, Hans Wennborg  wrote:
>> > On Thu, Aug 6, 2015 at 1:56 PM, David Majnemer via cfe-commits
>> >  wrote:
>> >> Author: majnemer
>> >> Date: Thu Aug  6 15:56:55 2015
>> >> New Revision: 244266
>> >>
>> >> URL: http://llvm.org/viewvc/llvm-project?rev=244266&view=rev
>> >> Log:
>> >> [ItaniumCXXABI] Don't import RTTI data for classes with key functions
>> >>
>> >> MinGW has some pretty strange behvaior around RTTI and
>> >> dllimport/dllexport:
>> >> - RTTI data is never imported
>> >> - RTTI data is only exported if the class has no key function.
>> >>
>> >> Modified:
>> >> cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
>> >> cfe/trunk/test/CodeGenCXX/dllimport-rtti.cpp
>> >
>> > I tried to merge this to 3.7 (as discussed on the commit thread for
>> > r244488), but the test doesn't pass:
>> >
>> > --
>> >
>> /usr/local/google/work/llvm-3.7/cfe.src/test/CodeGenCXX/dllimport-rtti.cpp:22:13:
>> > error: expected string not found in input
>> > // GNU-DAG: @_ZTV1V = available_externally dllimport
>> > ^
>> > :1:1: note: scanning from here
>> > ; ModuleID =
>> '/usr/local/google/work/llvm-3.7/cfe.src/test/CodeGenCXX/dllimport-rtti.cpp'
>> > ^
>> > :15:1: note: possible intended match here
>> > @_ZTV1S = available_externally dllimport unnamed_addr constant [3 x
>> > i8*] [i8* null, i8* bitcast (i8** @_ZTI1S to i8*), i8* bitcast (void
>> > (%struct.S*)* @_ZN1S1fEv to i8*)], align 4
>> > ^
>> > --
>> >
>> > I assume there's some other commit this depends on, but I haven't been
>> > able to figure out which. Can you take a look?
>>
>> Ping?
>>
>
> Looks like the test depends on r243090, which shouldn't go to the branch.
> I'd guess we could fix the test by changing that check line to "// GNU-DAG:
> @_ZTV1V = external" or similar. David?
>

external linkage works as long as it's still dllimport. I was just about to
give this a shot myself.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D12122: [CUDA] Add appropriate host/device attribute to target-specific builtins.

[Eli Bendersky via cfe-commits]

eliben added inline comments.


Comment at: include/clang/Basic/Builtins.h:85
@@ +84,3 @@
+  /// \brief Return true if this function is a target-specific builtin
+  bool isTSBuiltin(unsigned ID) const {
+return ID >= Builtin::FirstTSBuiltin;

You can also use it in SemaChecking now


Comment at: lib/Sema/SemaDecl.cpp:11166
@@ +11165,3 @@
+!FD->hasAttr() && !FD->hasAttr()) {
+  if (getLangOpts().CUDAIsDevice)
+FD->addAttr(CUDADeviceAttr::CreateImplicit(Context, 
FD->getLocation()));

It is not immediately clear why you would mark target-specific builtins as 
__host__ in host compilation mode. So for example __builtin_ptx_read_tid_x 
would be callable from a host function when compiling in host mode? Can you 
clarify this with a comment here, and also add a relevant test?


http://reviews.llvm.org/D12122



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

Re: r244488 - [dllimport] A non-imported class with an imported key can't have a key

[Reid Kleckner via cfe-commits]

I merged both of them and tweaked the test case to make it work.

On Tue, Aug 18, 2015 at 2:55 PM, Hans Wennborg  wrote:

> On Tue, Aug 11, 2015 at 9:40 AM, Hans Wennborg  wrote:
> > On Mon, Aug 10, 2015 at 12:39 PM, Reid Kleckner via cfe-commits
> >  wrote:
> >> Author: rnk
> >> Date: Mon Aug 10 14:39:01 2015
> >> New Revision: 244488
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=244488&view=rev
> >> Log:
> >> [dllimport] A non-imported class with an imported key can't have a key
> >>
> >> Summary:
> >> The vtable takes its DLL storage class from the class, not the key
> >> function. When they disagree, the vtable won't be exported by the DLL
> >> that defines the key function. The easiest way to ensure that importers
> >> of the class emit their own vtable is to say that the class has no key
> >> function.
> >>
> >> Reviewers: hans, majnemer
> >>
> >> Subscribers: cfe-commits
> >>
> >> Differential Revision: http://reviews.llvm.org/D11913
> >
> > Should we merge this and r244266 to 3.7?
>
> As pointed out on the r244266 thread, these patches are still not
> merged as the tests don't pass on 3.7. I was hoping someone more
> familiar with the patches could take a look.
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D11046: [libcxx] Add Atomic test helper and fix TSAN failures.

[Eric Fiselier via cfe-commits]

EricWF updated this revision to Diff 32473.
EricWF added a comment.

Fix more failing TSAN tests.


http://reviews.llvm.org/D11046

Files:
  test/std/thread/thread.condition/notify_all_at_thread_exit.pass.cpp
  test/std/thread/thread.condition/thread.condition.condvar/notify_one.pass.cpp
  
test/std/thread/thread.condition/thread.condition.condvarany/wait.exception.pass.cpp
  
test/std/thread/thread.condition/thread.condition.condvarany/wait_for.exception.pass.cpp
  
test/std/thread/thread.condition/thread.condition.condvarany/wait_terminates.sh.cpp
  
test/std/thread/thread.threads/thread.thread.class/thread.thread.constr/F.pass.cpp
  
test/std/thread/thread.threads/thread.thread.class/thread.thread.destr/dtor.pass.cpp
  test/support/test_atomic.h

Index: test/support/test_atomic.h
===
--- /dev/null
+++ test/support/test_atomic.h
@@ -0,0 +1,109 @@
+#ifndef SUPPORT_TEST_ATOMIC_H
+#define SUPPORT_TEST_ATOMIC_H
+
+// If the atomic memory order macros are defined then assume
+// the compiler supports the required atomic builtins.
+#if !defined(__ATOMIC_SEQ_CST)
+#define TEST_HAS_NO_ATOMICS
+#endif
+
+template 
+class Atomic {
+   ValType value;
+   Atomic(Atomic const&);
+   Atomic& operator=(Atomic const&);
+   Atomic& operator=(Atomic const&) volatile;
+private:
+  enum {
+#if !defined(TEST_HAS_NO_ATOMICS)
+AO_Relaxed = __ATOMIC_RELAXED,
+AO_Seq = __ATOMIC_SEQ_CST
+#else
+AO_Relaxed,
+AO_Seq
+#endif
+  };
+  template 
+  static inline void atomic_store_imp(Tp* dest, FromType from, int order = AO_Seq) {
+#if !defined(TEST_HAS_NO_ATOMICS)
+  __atomic_store_n(dest, from, order);
+#else
+*dest = from;
+#endif
+  }
+
+  template 
+  static inline Tp atomic_load_imp(Tp* from, int order = AO_Seq) {
+#if !defined(TEST_HAS_NO_ATOMICS)
+return __atomic_load_n(from, order);
+#else
+return *from;
+#endif
+  }
+
+  template 
+  static inline Tp atomic_add_imp(Tp* val, AddType add, int order = AO_Seq) {
+#if !defined(TEST_HAS_NO_ATOMICS)
+  return __atomic_add_fetch(val, add, order);
+#else
+return *val += add;
+#endif
+  }
+
+  template 
+  static inline Tp atomic_exchange_imp(Tp* val, Tp other, int order = AO_Seq) {
+#if !defined(TEST_HAS_NO_ATOMICS)
+  return __atomic_exchange_n(val, other, order);
+#else
+  Tp old = *val;
+  *val = other;
+  return old;
+#endif
+  }
+public:
+Atomic() : value(0) {}
+Atomic(ValType x) : value(x) {}
+
+ValType operator=(ValType val) {
+   atomic_store_imp(&value, val);
+   return val;
+}
+
+ValType operator=(ValType val) volatile {
+atomic_store_imp(&value, val);
+return val;
+}
+
+ValType load() const volatile { return atomic_load_imp(&value); }
+voidstore(ValType val) volatile { atomic_store_imp(&value, val); }
+
+ValType relaxedLoad() const volatile { return atomic_load_imp(&value, AO_Relaxed); }
+voidrelaxedStore(ValType val) volatile { atomic_store_imp(&value, val, AO_Relaxed); }
+
+ValType exchange(ValType other) volatile { return atomic_exchange_imp(&value, other); }
+booltestAndSet() volatile { return atomic_exchange_imp(&value, 1); }
+voidclear() volatile { atomic_store_imp(&value, 0); }
+
+operator ValType() const { return atomic_load_imp(&value); }
+operator ValType() const volatile { return atomic_load_imp(&value); }
+
+ValType operator+=(ValType val)  { return atomic_add_imp(&value, val); }
+ValType operator-=(ValType val)  { return atomic_add_imp(&value, -val); }
+ValType operator+=(ValType val) volatile { return atomic_add_imp(&value, val); }
+ValType operator-=(ValType val) volatile { return atomic_add_imp(&value, -val); }
+
+ValType operator++()  { return *this += 1; }
+ValType operator++(int) { return (*this += 1) - 1;  }
+ValType operator++() volatile { return *this += 1; }
+ValType operator++(int) volatile { return (*this += 1) - 1;  }
+
+ValType operator--() { return *this -= 1; }
+ValType operator--(int) { return (*this -= 1) + 1; }
+ValType operator--() volatile { return *this -= 1; }
+ValType operator--(int) volatile { return (*this -= 1) + 1; }
+};
+
+typedef Atomic AtomicInt;
+typedef Atomic AtomicBool;
+
+#endif // SUPPORT_TEST_ATOMIC_H
Index: test/std/thread/thread.threads/thread.thread.class/thread.thread.destr/dtor.pass.cpp
===
--- test/std/thread/thread.threads/thread.thread.class/thread.thread.destr/dtor.pass.cpp
+++ test/std/thread/thread.threads/thread.thread.class/thread.thread.destr/dtor.pass.cpp
@@ -9,8 +9,6 @@
 //
 // UNSUPPORTED: libcpp-has-no-threads
 
-// NOTE: TSAN will report this test as leaking a thread.
-// XFAIL: tsan
 
 // 
 
@@ -47,7 +45,7 @@
 
 void f1()
 {
-std::exit(0);
+std::_Exit(0);
 }
 
 int main()
Index: test/std/thread/thread.threads/thread.thread.class/thread.thread.constr/F.pass.cpp
==

Re: r244488 - [dllimport] A non-imported class with an imported key can't have a key

[Hans Wennborg via cfe-commits]

Awesome, thanks!

On Tue, Aug 18, 2015 at 4:27 PM, Reid Kleckner  wrote:
> I merged both of them and tweaked the test case to make it work.
>
> On Tue, Aug 18, 2015 at 2:55 PM, Hans Wennborg  wrote:
>>
>> On Tue, Aug 11, 2015 at 9:40 AM, Hans Wennborg  wrote:
>> > On Mon, Aug 10, 2015 at 12:39 PM, Reid Kleckner via cfe-commits
>> >  wrote:
>> >> Author: rnk
>> >> Date: Mon Aug 10 14:39:01 2015
>> >> New Revision: 244488
>> >>
>> >> URL: http://llvm.org/viewvc/llvm-project?rev=244488&view=rev
>> >> Log:
>> >> [dllimport] A non-imported class with an imported key can't have a key
>> >>
>> >> Summary:
>> >> The vtable takes its DLL storage class from the class, not the key
>> >> function. When they disagree, the vtable won't be exported by the DLL
>> >> that defines the key function. The easiest way to ensure that importers
>> >> of the class emit their own vtable is to say that the class has no key
>> >> function.
>> >>
>> >> Reviewers: hans, majnemer
>> >>
>> >> Subscribers: cfe-commits
>> >>
>> >> Differential Revision: http://reviews.llvm.org/D11913
>> >
>> > Should we merge this and r244266 to 3.7?
>>
>> As pointed out on the r244266 thread, these patches are still not
>> merged as the tests don't pass on 3.7. I was hoping someone more
>> familiar with the patches could take a look.
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxx] r245389 - [libcxx] Add Atomic test helper and fix TSAN failures.

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Tue Aug 18 18:29:59 2015
New Revision: 245389

URL: http://llvm.org/viewvc/llvm-project?rev=245389&view=rev
Log:
[libcxx] Add Atomic test helper and fix TSAN failures.

Summary:
This patch attempts to fix the last 3 TSAN failures on the libc++ bot 
(http://lab.llvm.org:8011/builders/libcxx-libcxxabi-x86_64-linux-ubuntu-tsan/builds/143).
 This patch also adds a `Atomic` test type that can be used where `` 
cannot.

`wait.exception.pass.cpp` and `wait_for.exception.pass.cpp` were failing 
because the test replaced `std::terminate` with `std::exit`. `std::exit` would 
asynchronously run the TLS and static destructors and this would cause a race 
condition. See PR22606 and D8802 for more details. 

This is fixed by using `_Exit` to prevent cleanup.

`notify_all_at_thread_exit.pass.cpp` exercises the same race condition but for 
different reasons. I fixed this test by manually joining the thread before 
beginning program termination.

Reviewers: EricWF, mclow.lists

Subscribers: cfe-commits

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

Added:

libcxx/trunk/test/std/thread/thread.condition/thread.condition.condvarany/wait_terminates.sh.cpp
libcxx/trunk/test/support/test_atomic.h
Removed:

libcxx/trunk/test/std/thread/thread.condition/thread.condition.condvarany/wait.exception.pass.cpp

libcxx/trunk/test/std/thread/thread.condition/thread.condition.condvarany/wait_for.exception.pass.cpp
Modified:

libcxx/trunk/test/std/thread/thread.condition/notify_all_at_thread_exit.pass.cpp

libcxx/trunk/test/std/thread/thread.condition/thread.condition.condvar/notify_one.pass.cpp

libcxx/trunk/test/std/thread/thread.threads/thread.thread.class/thread.thread.constr/F.pass.cpp

libcxx/trunk/test/std/thread/thread.threads/thread.thread.class/thread.thread.destr/dtor.pass.cpp

Modified: 
libcxx/trunk/test/std/thread/thread.condition/notify_all_at_thread_exit.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/thread/thread.condition/notify_all_at_thread_exit.pass.cpp?rev=245389&r1=245388&r2=245389&view=diff
==
--- 
libcxx/trunk/test/std/thread/thread.condition/notify_all_at_thread_exit.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/thread/thread.condition/notify_all_at_thread_exit.pass.cpp
 Tue Aug 18 18:29:59 2015
@@ -36,9 +36,10 @@ void func()
 int main()
 {
 std::unique_lock lk(mut);
-std::thread(func).detach();
+std::thread t(func);
 Clock::time_point t0 = Clock::now();
 cv.wait(lk);
 Clock::time_point t1 = Clock::now();
 assert(t1-t0 > ms(250));
+t.join();
 }

Modified: 
libcxx/trunk/test/std/thread/thread.condition/thread.condition.condvar/notify_one.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/thread/thread.condition/thread.condition.condvar/notify_one.pass.cpp?rev=245389&r1=245388&r2=245389&view=diff
==
--- 
libcxx/trunk/test/std/thread/thread.condition/thread.condition.condvar/notify_one.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/thread/thread.condition/thread.condition.condvar/notify_one.pass.cpp
 Tue Aug 18 18:29:59 2015
@@ -20,12 +20,13 @@
 #include 
 #include 
 
+#include "test_atomic.h"
+
 std::condition_variable cv;
 std::mutex mut;
 
-int test0 = 0;
-int test1 = 0;
-int test2 = 0;
+AtomicInt test1(0);
+AtomicInt test2(0);
 
 void f1()
 {
@@ -64,11 +65,13 @@ int main()
 }
 if (test1 == 2)
 {
+assert(test2 == 1);
 t1.join();
 test1 = 0;
 }
 else if (test2 == 2)
 {
+assert(test1 == 1);
 t2.join();
 test2 = 0;
 }
@@ -81,11 +84,13 @@ int main()
 }
 if (test1 == 2)
 {
+assert(test2 == 0);
 t1.join();
 test1 = 0;
 }
 else if (test2 == 2)
 {
+assert(test1 == 0);
 t2.join();
 test2 = 0;
 }

Removed: 
libcxx/trunk/test/std/thread/thread.condition/thread.condition.condvarany/wait.exception.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/thread/thread.condition/thread.condition.condvarany/wait.exception.pass.cpp?rev=245388&view=auto
==
--- 
libcxx/trunk/test/std/thread/thread.condition/thread.condition.condvarany/wait.exception.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/thread/thread.condition/thread.condition.condvarany/wait.exception.pass.cpp
 (removed)
@@ -1,63 +0,0 @@
-//===--===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is dual licensed under the MIT and the University of Illinois Open
-// Source Licenses. See LICENSE.TXT for details.
-//
-//===--===//
-//
-// UNSUPPORTED: libcpp-has-no-threads
-
-#i

Re: [PATCH] D11682: [libcxxabi] Add "install-libcxxabi" target.

[Eric Fiselier via cfe-commits]

EricWF added a comment.

Followup on @beanz comments.



Comment at: src/CMakeLists.txt:123
@@ -124,1 +122,3 @@
+  LIBRARY DESTINATION lib${LIBCXXABI_LIBDIR_SUFFIX} COMPONENT libcxxabi
+  ARCHIVE DESTINATION lib${LIBCXXABI_LIBDIR_SUFFIX} COMPONENT libcxxabi
   )

beanz wrote:
> You should not specify both ARCHIVE and LIBRARY in the same install command. 
> One of the two will be ignored. As per the documentation 
> (http://www.cmake.org/cmake/help/v3.0/command/install.html).
> 
> You will need to do something similar to what is done in 
> AddLLVM.cmake:507-520.
I don't see where in the documentation that it says you can't use ARCHIVE and 
LIBRARY in the same install command. Could you be more explicit?


http://reviews.llvm.org/D11682



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

Re: [PATCH] D12123: [analyzer] Skip Pre/Post handlers for ObjC calls when receiver is nil.

[Gábor Horváth via cfe-commits]

xazax.hun added a comment.

Looks good to me. There are some minor nits inline.



Comment at: include/clang/StaticAnalyzer/Core/CheckerManager.h:96
@@ -95,1 +95,3 @@
 
+enum class ObjCCheckerKind {
+  PreVisit,

I do not really like the name ObjCCheckerKind, because it is not kind of an 
Obj-C related checker. It is the kind of the visit of the message expression. 
Maybe ObjCMessageVisitKind? Or just MessageVisitKind to be a bit shorter?


Comment at: lib/StaticAnalyzer/Core/ExprEngineObjC.cpp:153
@@ +152,3 @@
+  ProgramStateRef notNilState, nilState;
+  std::tie(notNilState, nilState) = State->assume(receiverVal);
+  if (nilState && !notNilState) {

The old code had a comment about merging two cases and a reference to a rdar. 
Is that rdar already fixed? Maybe it would be good to preserve the at least the 
first part of the commend?


http://reviews.llvm.org/D12123



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

r245390 - [modules] Fix HeaderFileInfo serialization to store all the known owning modules for a header, not just the current favourite.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Tue Aug 18 18:42:23 2015
New Revision: 245390

URL: http://llvm.org/viewvc/llvm-project?rev=245390&view=rev
Log:
[modules] Fix HeaderFileInfo serialization to store all the known owning 
modules for a header, not just the current favourite.

Modified:
cfe/trunk/include/clang/Lex/HeaderSearch.h
cfe/trunk/include/clang/Lex/ModuleMap.h
cfe/trunk/include/clang/Serialization/ASTWriter.h
cfe/trunk/lib/Lex/HeaderSearch.cpp
cfe/trunk/lib/Lex/ModuleMap.cpp
cfe/trunk/lib/Serialization/ASTReader.cpp
cfe/trunk/lib/Serialization/ASTWriter.cpp

Modified: cfe/trunk/include/clang/Lex/HeaderSearch.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Lex/HeaderSearch.h?rev=245390&r1=245389&r2=245390&view=diff
==
--- cfe/trunk/include/clang/Lex/HeaderSearch.h (original)
+++ cfe/trunk/include/clang/Lex/HeaderSearch.h Tue Aug 18 18:42:23 2015
@@ -49,7 +49,8 @@ struct HeaderFileInfo {
   /// SrcMgr::CharacteristicKind.
   unsigned DirInfo : 2;
 
-  /// \brief Whether this header file info was supplied by an external source.
+  /// \brief Whether this header file info was supplied by an external source,
+  /// and has not changed since.
   unsigned External : 1;
 
   /// \brief Whether this header is part of a module.
@@ -58,10 +59,6 @@ struct HeaderFileInfo {
   /// \brief Whether this header is part of the module that we are building.
   unsigned isCompilingModuleHeader : 1;
 
-  /// \brief Whether this header is part of the module that we are building.
-  /// This is an instance of ModuleMap::ModuleHeaderRole.
-  unsigned HeaderRole : 2;
-  
   /// \brief Whether this structure is considered to already have been
   /// "resolved", meaning that it was loaded from the external source.
   unsigned Resolved : 1;
@@ -75,7 +72,7 @@ struct HeaderFileInfo {
   /// those framework headers.
   unsigned IndexHeaderMapHeader : 1;
 
-  /// \brief Whether this file had been looked up as a header.
+  /// \brief Whether this file has been looked up as a header.
   unsigned IsValid : 1;
   
   /// \brief The number of times the file has been included already.
@@ -105,7 +102,6 @@ struct HeaderFileInfo {
   HeaderFileInfo()
 : isImport(false), isPragmaOnce(false), DirInfo(SrcMgr::C_User), 
   External(false), isModuleHeader(false), isCompilingModuleHeader(false),
-  HeaderRole(ModuleMap::NormalHeader),
   Resolved(false), IndexHeaderMapHeader(false), IsValid(0),
   NumIncludes(0), ControllingMacroID(0), ControllingMacro(nullptr)  {}
 
@@ -120,16 +116,6 @@ struct HeaderFileInfo {
 return isImport || isPragmaOnce || NumIncludes || ControllingMacro || 
   ControllingMacroID;
   }
-
-  /// \brief Get the HeaderRole properly typed.
-  ModuleMap::ModuleHeaderRole getHeaderRole() const {
-return static_cast(HeaderRole);
-  }
-
-  /// \brief Set the HeaderRole properly typed.
-  void setHeaderRole(ModuleMap::ModuleHeaderRole Role) {
-HeaderRole = Role;
-  }
 };
 
 /// \brief An external source of header file information, which may supply
@@ -189,7 +175,7 @@ class HeaderSearch {
   
   /// \brief All of the preprocessor-specific data about files that are
   /// included, indexed by the FileEntry's UID.
-  std::vector FileInfo;
+  mutable std::vector FileInfo;
 
   /// Keeps track of each lookup performed by LookupFile.
   struct LookupFileCacheInfo {
@@ -575,20 +561,20 @@ private:
   /// of the given search directory.
   void loadSubdirectoryModuleMaps(DirectoryLookup &SearchDir);
 
-  /// \brief Return the HeaderFileInfo structure for the specified FileEntry.
-  const HeaderFileInfo &getFileInfo(const FileEntry *FE) const {
-return const_cast(this)->getFileInfo(FE);
-  }
-
 public:
   /// \brief Retrieve the module map.
   ModuleMap &getModuleMap() { return ModMap; }
   
+  /// \brief Retrieve the module map.
+  const ModuleMap &getModuleMap() const { return ModMap; }
+  
   unsigned header_file_size() const { return FileInfo.size(); }
 
-  /// \brief Get a \c HeaderFileInfo structure for the specified \c FileEntry,
-  /// if one exists.
-  bool tryGetFileInfo(const FileEntry *FE, HeaderFileInfo &Result) const;
+  /// \brief Return the HeaderFileInfo structure for the specified FileEntry.
+  HeaderFileInfo &getFileInfo(const FileEntry *FE);
+
+  /// \brief Return the HeaderFileInfo structure for the specified FileEntry.
+  const HeaderFileInfo *getExistingFileInfo(const FileEntry *FE) const;
 
   // Used by external tools
   typedef std::vector::const_iterator search_dir_iterator;
@@ -665,9 +651,6 @@ private:
   /// named directory.
   LoadModuleMapResult loadModuleMapFile(const DirectoryEntry *Dir,
 bool IsSystem, bool IsFramework);
-
-  /// \brief Return the HeaderFileInfo structure for the specified FileEntry.
-  HeaderFileInfo &getFileInfo(const FileEntry *FE);
 };
 
 }  // end namespace clang

Modified: cfe/trunk/include/clang/Lex/

r245391 - [modules] Tests for r245390.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Tue Aug 18 18:42:50 2015
New Revision: 245391

URL: http://llvm.org/viewvc/llvm-project?rev=245391&view=rev
Log:
[modules] Tests for r245390.

Added:
cfe/trunk/test/Modules/Inputs/explicit-build-overlap/
cfe/trunk/test/Modules/Inputs/explicit-build-overlap/a.h
cfe/trunk/test/Modules/Inputs/explicit-build-overlap/b.h
cfe/trunk/test/Modules/Inputs/explicit-build-overlap/def.map
cfe/trunk/test/Modules/Inputs/explicit-build-overlap/use.map
cfe/trunk/test/Modules/explicit-build-overlap.cpp

Added: cfe/trunk/test/Modules/Inputs/explicit-build-overlap/a.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/explicit-build-overlap/a.h?rev=245391&view=auto
==
--- cfe/trunk/test/Modules/Inputs/explicit-build-overlap/a.h (added)
+++ cfe/trunk/test/Modules/Inputs/explicit-build-overlap/a.h Tue Aug 18 
18:42:50 2015
@@ -0,0 +1 @@
+struct A {};

Added: cfe/trunk/test/Modules/Inputs/explicit-build-overlap/b.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/explicit-build-overlap/b.h?rev=245391&view=auto
==
--- cfe/trunk/test/Modules/Inputs/explicit-build-overlap/b.h (added)
+++ cfe/trunk/test/Modules/Inputs/explicit-build-overlap/b.h Tue Aug 18 
18:42:50 2015
@@ -0,0 +1 @@
+struct B {};

Added: cfe/trunk/test/Modules/Inputs/explicit-build-overlap/def.map
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/explicit-build-overlap/def.map?rev=245391&view=auto
==
--- cfe/trunk/test/Modules/Inputs/explicit-build-overlap/def.map (added)
+++ cfe/trunk/test/Modules/Inputs/explicit-build-overlap/def.map Tue Aug 18 
18:42:50 2015
@@ -0,0 +1,2 @@
+module a { textual header "a.h" }
+module b { header "a.h" header "b.h" }

Added: cfe/trunk/test/Modules/Inputs/explicit-build-overlap/use.map
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/explicit-build-overlap/use.map?rev=245391&view=auto
==
--- cfe/trunk/test/Modules/Inputs/explicit-build-overlap/use.map (added)
+++ cfe/trunk/test/Modules/Inputs/explicit-build-overlap/use.map Tue Aug 18 
18:42:50 2015
@@ -0,0 +1,3 @@
+module "use" {
+  use a
+}

Added: cfe/trunk/test/Modules/explicit-build-overlap.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/explicit-build-overlap.cpp?rev=245391&view=auto
==
--- cfe/trunk/test/Modules/explicit-build-overlap.cpp (added)
+++ cfe/trunk/test/Modules/explicit-build-overlap.cpp Tue Aug 18 18:42:50 2015
@@ -0,0 +1,14 @@
+// RUN: rm -rf %t
+// RUN: %clang_cc1 -x c++ -fmodules   
%S/Inputs/explicit-build-overlap/def.map -fmodule-name=a -emit-module -o 
%t/a.pcm
+// RUN: %clang_cc1 -x c++ -fmodules   
%S/Inputs/explicit-build-overlap/def.map -fmodule-name=b -emit-module -o 
%t/ba.pcm -fmodule-file=%t/a.pcm
+// RUN: %clang_cc1 -x c++ -fmodules 
-fmodule-map-file=%S/Inputs/explicit-build-overlap/use.map -fmodule-name=use 
-fmodule-file=%t/ba.pcm %s -verify -I%S/Inputs/explicit-build-overlap 
-fmodules-decluse
+//
+// RUN: %clang_cc1 -x c++ -fmodules   
%S/Inputs/explicit-build-overlap/def.map -fmodule-name=b -emit-module -o 
%t/b.pcm
+// RUN: %clang_cc1 -x c++ -fmodules   
%S/Inputs/explicit-build-overlap/def.map -fmodule-name=a -emit-module -o 
%t/ab.pcm -fmodule-file=%t/b.pcm
+// RUN: %clang_cc1 -x c++ -fmodules 
-fmodule-map-file=%S/Inputs/explicit-build-overlap/use.map -fmodule-name=use 
-fmodule-file=%t/ab.pcm %s -verify -I%S/Inputs/explicit-build-overlap 
-fmodules-decluse
+
+// expected-no-diagnostics
+#include "a.h"
+
+A a;
+B b;


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

Re: r245352 - Workaround -Wdeprecated on SemDiagnosticConsumer's tricksy copy ctor.

[Richard Smith via cfe-commits]

On Tue, Aug 18, 2015 at 2:03 PM, David Blaikie  wrote:

> Richard, do you think there's anything we could do better here?
>
> It seems difficult to support proper move semantic behavior for
> [Sema]DiagnosticBuilder across the two common use cases:
>
>   DiagnosticBuilder D;
>   D << x;
>   D << y;
>   return D;
>
> and
>
>   return DiagnosticBuilder() << x << y;
>

Do we actually use this form to return a DiagnosticBuilder, or just to
construct an ActionResult? Can we eliminate uses of this form?


> The only thing I can imagine is if every one of those op<< were function
> templates using universal references (I forget, is that the right name for
> them?) and matching their return value (so in the first case, passed a
> non-const lvalue ref, they return by non-const lvalue ref, and in the
> second case, passed an rvalue, they return the same). But that seems
> painful.
>

It seems tricky to form an unambiguous overload set for this that preserves
the value category, without duplicating all the operator< On Tue, Aug 18, 2015 at 1:54 PM, David Blaikie via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: dblaikie
>> Date: Tue Aug 18 15:54:26 2015
>> New Revision: 245352
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=245352&view=rev
>> Log:
>> Workaround -Wdeprecated on SemDiagnosticConsumer's tricksy copy ctor.
>>
>> Modified:
>> cfe/trunk/include/clang/Sema/Sema.h
>>
>> Modified: cfe/trunk/include/clang/Sema/Sema.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=245352&r1=245351&r2=245352&view=diff
>>
>> ==
>> --- cfe/trunk/include/clang/Sema/Sema.h (original)
>> +++ cfe/trunk/include/clang/Sema/Sema.h Tue Aug 18 15:54:26 2015
>> @@ -1054,6 +1054,14 @@ public:
>>  SemaDiagnosticBuilder(DiagnosticBuilder &DB, Sema &SemaRef, unsigned
>> DiagID)
>>: DiagnosticBuilder(DB), SemaRef(SemaRef), DiagID(DiagID) { }
>>
>> +// This is a cunning lie. DiagnosticBuilder actually performs move
>> +// construction in its copy constructor (but due to varied uses,
>> it's not
>> +// possible to conveniently express this as actual move
>> construction). So
>> +// the default copy ctor here is fine, because the base class
>> disables the
>> +// source anyway, so the user-defined ~SemaDiagnosticBuilder is a
>> safe no-op
>> +// in that case anwyay.
>> +SemaDiagnosticBuilder(const SemaDiagnosticBuilder&) = default;
>> +
>>  ~SemaDiagnosticBuilder() {
>>// If we aren't active, there is nothing to do.
>>if (!isActive()) return;
>>
>>
>> ___
>> 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] D12110: [SemaExpr] Re-enable missing assertion

[Richard Smith via cfe-commits]

rsmith added a subscriber: rsmith.
rsmith added a comment.

LGTM


http://reviews.llvm.org/D12110



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

Re: [PATCH] D12122: [CUDA] Add appropriate host/device attribute to target-specific builtins.

[Artem Belevich via cfe-commits]

tra updated this revision to Diff 32478.
tra marked an inline comment as done.
tra added a comment.

used isTSBuiltin in SemaChecking.cpp


http://reviews.llvm.org/D12122

Files:
  include/clang/Basic/Builtins.h
  lib/Sema/SemaChecking.cpp
  lib/Sema/SemaDecl.cpp
  test/SemaCUDA/builtins.cu
  test/SemaCUDA/implicit-intrinsic.cu

Index: test/SemaCUDA/implicit-intrinsic.cu
===
--- test/SemaCUDA/implicit-intrinsic.cu
+++ test/SemaCUDA/implicit-intrinsic.cu
@@ -1,10 +1,10 @@
-// RUN: %clang_cc1 -std=gnu++11 -triple nvptx64-unknown-unknown -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple nvptx64-unknown-unknown -fcuda-is-device -fsyntax-only -verify %s
 
 #include "Inputs/cuda.h"
 
 // expected-no-diagnostics
 __device__ void __threadfence_system() {
-  // This shouldn't produce an error, since __nvvm_membar_sys is inferred to
-  // be __host__ __device__ and thus callable from device code.
+  // This shouldn't produce an error, since __nvvm_membar_sys should be
+  // __device__ and thus callable from device code.
   __nvvm_membar_sys();
 }
Index: test/SemaCUDA/builtins.cu
===
--- /dev/null
+++ test/SemaCUDA/builtins.cu
@@ -0,0 +1,35 @@
+// Tests that target-specific builtins have appropriate host/device
+// attributes and that CUDA call restrictions are enforced. Also
+// verify that non-target builtins can be used from both host and
+// device functions.
+//
+// REQUIRES: x86-registered-target
+// REQUIRES: nvptx-registered-target
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple nvptx64-unknown-cuda -fcuda-is-device \
+// RUN:   -fsyntax-only -verify %s
+
+
+#ifdef __CUDA_ARCH__
+// Device-side builtins are not allowed to be called from host functions.
+void hf() {
+  int x = __builtin_ptx_read_tid_x(); // expected-note  {{'__builtin_ptx_read_tid_x' declared here}}
+  // expected-error@-1 {{reference to __device__ function '__builtin_ptx_read_tid_x' in __host__ function}}
+  x = __builtin_abs(1);
+}
+__attribute__((device)) void df() {
+  int x = __builtin_ptx_read_tid_x();
+  x = __builtin_abs(1);
+}
+#else
+// Host-side builtins are not allowed to be called from device functions.
+__attribute__((device)) void df() {
+  int x = __builtin_ia32_rdtsc();   // expected-note {{'__builtin_ia32_rdtsc' declared here}}
+  // expected-error@-1 {{reference to __host__ function '__builtin_ia32_rdtsc' in __device__ function}}
+  x = __builtin_abs(1);
+}
+void hf() {
+  int x = __builtin_ia32_rdtsc();
+  x = __builtin_abs(1);
+}
+#endif
Index: lib/Sema/SemaDecl.cpp
===
--- lib/Sema/SemaDecl.cpp
+++ lib/Sema/SemaDecl.cpp
@@ -11161,6 +11161,13 @@
   FD->addAttr(NoThrowAttr::CreateImplicit(Context, FD->getLocation()));
 if (Context.BuiltinInfo.isConst(BuiltinID) && !FD->hasAttr())
   FD->addAttr(ConstAttr::CreateImplicit(Context, FD->getLocation()));
+if (getLangOpts().CUDA && Context.BuiltinInfo.isTSBuiltin(BuiltinID) &&
+!FD->hasAttr() && !FD->hasAttr()) {
+  if (getLangOpts().CUDAIsDevice)
+FD->addAttr(CUDADeviceAttr::CreateImplicit(Context, FD->getLocation()));
+  else
+FD->addAttr(CUDAHostAttr::CreateImplicit(Context, FD->getLocation()));
+}
   }
 
   IdentifierInfo *Name = FD->getIdentifier();
Index: lib/Sema/SemaChecking.cpp
===
--- lib/Sema/SemaChecking.cpp
+++ lib/Sema/SemaChecking.cpp
@@ -525,7 +525,7 @@
 
   // Since the target specific builtins for each arch overlap, only check those
   // of the arch we are compiling for.
-  if (BuiltinID >= Builtin::FirstTSBuiltin) {
+  if (Context.BuiltinInfo.isTSBuiltin(BuiltinID)) {
 switch (Context.getTargetInfo().getTriple().getArch()) {
   case llvm::Triple::arm:
   case llvm::Triple::armeb:
Index: include/clang/Basic/Builtins.h
===
--- include/clang/Basic/Builtins.h
+++ include/clang/Basic/Builtins.h
@@ -81,6 +81,11 @@
 return getRecord(ID).Type;
   }
 
+  /// \brief Return true if this function is a target-specific builtin
+  bool isTSBuiltin(unsigned ID) const {
+return ID >= Builtin::FirstTSBuiltin;
+  }
+
   /// \brief Return true if this function has no side effects and doesn't
   /// read memory.
   bool isConst(unsigned ID) const {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r244902 - Driver: Fix include directories when not using libgcc under mingw

[Richard Smith via cfe-commits]

On Tue, Aug 18, 2015 at 3:00 PM, Hans Wennborg via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Richard, I tried to ping you on the review thread but I'm not sure it
> got through. Martell requested this be merged to 3.7. What do you
> think?


Sure, this looks fine for branch.


> On Thu, Aug 13, 2015 at 8:41 AM, Martell Malone via cfe-commits
>  wrote:
> > Author: martell
> > Date: Thu Aug 13 10:41:04 2015
> > New Revision: 244902
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=244902&view=rev
> > Log:
> > Driver: Fix include directories when not using libgcc under mingw
> >
> > Summary:
> > When we want to use mingw-w64 and clang with compiler-rt we should not
> > need to have libgcc installed. This fixes finding includes when libgcc
> > is not installed
> >
> > Reviewers: yaron.keren
> >
> > Subscribers: cfe-commits
> >
> > Differential Revision: http://reviews.llvm.org/D11808
> >
> > Added:
> > cfe/trunk/test/Driver/Inputs/mingw_clang_tree/
> > cfe/trunk/test/Driver/Inputs/mingw_clang_tree/mingw32/
> >
>  cfe/trunk/test/Driver/Inputs/mingw_clang_tree/mingw32/i686-w64-mingw32/
> >
>  
> cfe/trunk/test/Driver/Inputs/mingw_clang_tree/mingw32/i686-w64-mingw32/include/
> >
>  
> cfe/trunk/test/Driver/Inputs/mingw_clang_tree/mingw32/i686-w64-mingw32/include/.keep
> > cfe/trunk/test/Driver/Inputs/mingw_clang_tree/mingw32/include/
> > cfe/trunk/test/Driver/Inputs/mingw_clang_tree/mingw32/include/.keep
> > Modified:
> > cfe/trunk/lib/Driver/MinGWToolChain.cpp
> > cfe/trunk/test/Driver/mingw.cpp
> >
> > Modified: cfe/trunk/lib/Driver/MinGWToolChain.cpp
> > URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/MinGWToolChain.cpp?rev=244902&r1=244901&r2=244902&view=diff
> >
> ==
> > --- cfe/trunk/lib/Driver/MinGWToolChain.cpp (original)
> > +++ cfe/trunk/lib/Driver/MinGWToolChain.cpp Thu Aug 13 10:41:04 2015
> > @@ -47,7 +47,7 @@ void MinGW::findGccLibDir() {
> >Archs.emplace_back(getTriple().getArchName());
> >Archs[0] += "-w64-mingw32";
> >Archs.emplace_back("mingw32");
> > -  Arch = "unknown";
> > +  Arch = Archs[0].str();
> >// lib: Arch Linux, Ubuntu, Windows
> >// lib64: openSUSE Linux
> >for (StringRef CandidateLib : {"lib", "lib64"}) {
> >
> > Added:
> cfe/trunk/test/Driver/Inputs/mingw_clang_tree/mingw32/i686-w64-mingw32/include/.keep
> > URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/Inputs/mingw_clang_tree/mingw32/i686-w64-mingw32/include/.keep?rev=244902&view=auto
> >
> ==
> > (empty)
> >
> > Added:
> cfe/trunk/test/Driver/Inputs/mingw_clang_tree/mingw32/include/.keep
> > URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/Inputs/mingw_clang_tree/mingw32/include/.keep?rev=244902&view=auto
> >
> ==
> > (empty)
> >
> > Modified: cfe/trunk/test/Driver/mingw.cpp
> > URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/mingw.cpp?rev=244902&r1=244901&r2=244902&view=diff
> >
> ==
> > --- cfe/trunk/test/Driver/mingw.cpp (original)
> > +++ cfe/trunk/test/Driver/mingw.cpp Thu Aug 13 10:41:04 2015
> > @@ -1,3 +1,8 @@
> > +// RUN: %clang -target i686-windows-gnu -c -###
> --sysroot=%S/Inputs/mingw_clang_tree/mingw32 %s 2>&1 | FileCheck
> -check-prefix=CHECK_MINGW_CLANG_TREE %s
> > +// CHECK_MINGW_CLANG_TREE:
> "{{.*}}/Inputs/mingw_clang_tree/mingw32{{/|}}i686-w64-mingw32{{/|}}include"
> > +// CHECK_MINGW_CLANG_TREE:
> "{{.*}}/Inputs/mingw_clang_tree/mingw32{{/|}}include"
> > +
> > +
> >  // RUN: %clang -target i686-pc-windows-gnu -stdlib=libstdc++ -c -###
> --sysroot=%S/Inputs/mingw_mingw_org_tree/mingw %s 2>&1 | FileCheck
> -check-prefix=CHECK_MINGW_ORG_TREE %s
> >  // CHECK_MINGW_ORG_TREE:
> "{{.*}}/Inputs/mingw_mingw_org_tree/mingw{{/|}}lib{{/|}}gcc{{/|}}mingw32{{/|}}4.8.1{{/|}}include{{/|}}c++"
> >  // CHECK_MINGW_ORG_TREE:
> "{{.*}}/Inputs/mingw_mingw_org_tree/mingw{{/|}}lib{{/|}}gcc{{/|}}mingw32{{/|}}4.8.1{{/|}}include{{/|}}c++{{/|}}mingw32"
> >
> >
> > ___
> > 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: [PATCH] D11682: [libcxxabi] Add "install-libcxxabi" target.

[Chris Bieneman via cfe-commits]

beanz added a comment.

The signature is:

  install(TARGETS targets... [EXPORT ]
  [[ARCHIVE|LIBRARY|RUNTIME|FRAMEWORK|BUNDLE|
PRIVATE_HEADER|PUBLIC_HEADER|RESOURCE]
   [DESTINATION ]
   [INCLUDES DESTINATION [ ...]]
   [PERMISSIONS permissions...]
   [CONFIGURATIONS [Debug|Release|...]]
   [COMPONENT ]
   [OPTIONAL] [NAMELINK_ONLY|NAMELINK_SKIP]
  ] [...])

The `|` markers between the argument values mean `OR`.

You may also note that `DESTINATION` only shows up once because only one 
occurrence of it is parsed, and it only accepts one value.

I know that the code you wrote follows a pattern that exists elsewhere in our 
CMake, I'm just saying it doesn't work, so we shouldn't introduce more 
occurrences.


http://reviews.llvm.org/D11682



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

r245392 - unique_ptrify CXXBasePaths::DeclsFound & remove the then-unnecessary user-defined dtor

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Tue Aug 18 18:56:00 2015
New Revision: 245392

URL: http://llvm.org/viewvc/llvm-project?rev=245392&view=rev
Log:
unique_ptrify CXXBasePaths::DeclsFound & remove the then-unnecessary 
user-defined dtor

Maybe this and the NumDeclsFound member should just be a std::vector
instead. (it could be a std::dynarray, but that missed standardization)

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

Modified: cfe/trunk/include/clang/AST/CXXInheritance.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/CXXInheritance.h?rev=245392&r1=245391&r2=245392&view=diff
==
--- cfe/trunk/include/clang/AST/CXXInheritance.h (original)
+++ cfe/trunk/include/clang/AST/CXXInheritance.h Tue Aug 18 18:56:00 2015
@@ -155,7 +155,7 @@ class CXXBasePaths {
   /// \brief Array of the declarations that have been found. This
   /// array is constructed only if needed, e.g., to iterate over the
   /// results within LookupResult.
-  NamedDecl **DeclsFound;
+  std::unique_ptr DeclsFound;
   unsigned NumDeclsFound;
   
   friend class CXXRecordDecl;
@@ -172,15 +172,12 @@ public:
   
   /// BasePaths - Construct a new BasePaths structure to record the
   /// paths for a derived-to-base search.
-  explicit CXXBasePaths(bool FindAmbiguities = true,
-bool RecordPaths = true,
+  explicit CXXBasePaths(bool FindAmbiguities = true, bool RecordPaths = true,
 bool DetectVirtual = true)
-: FindAmbiguities(FindAmbiguities), RecordPaths(RecordPaths),
-  DetectVirtual(DetectVirtual), DetectedVirtual(nullptr),
-  DeclsFound(nullptr), NumDeclsFound(0) { }
-  
-  ~CXXBasePaths() { delete [] DeclsFound; }
-  
+  : FindAmbiguities(FindAmbiguities), RecordPaths(RecordPaths),
+DetectVirtual(DetectVirtual), DetectedVirtual(nullptr),
+NumDeclsFound(0) {}
+
   paths_iterator begin() { return Paths.begin(); }
   paths_iterator end()   { return Paths.end(); }
   const_paths_iterator begin() const { return Paths.begin(); }

Modified: cfe/trunk/lib/AST/CXXInheritance.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/CXXInheritance.cpp?rev=245392&r1=245391&r2=245392&view=diff
==
--- cfe/trunk/lib/AST/CXXInheritance.cpp (original)
+++ cfe/trunk/lib/AST/CXXInheritance.cpp Tue Aug 18 18:56:00 2015
@@ -31,16 +31,16 @@ void CXXBasePaths::ComputeDeclsFound() {
 Decls.insert(Path->Decls.front());
 
   NumDeclsFound = Decls.size();
-  DeclsFound = new NamedDecl * [NumDeclsFound];
-  std::copy(Decls.begin(), Decls.end(), DeclsFound);
+  DeclsFound = llvm::make_unique(NumDeclsFound);
+  std::copy(Decls.begin(), Decls.end(), DeclsFound.get());
 }
 
 CXXBasePaths::decl_range CXXBasePaths::found_decls() {
   if (NumDeclsFound == 0)
 ComputeDeclsFound();
 
-  return decl_range(decl_iterator(DeclsFound),
-decl_iterator(DeclsFound + NumDeclsFound));
+  return decl_range(decl_iterator(DeclsFound.get()),
+decl_iterator(DeclsFound.get() + NumDeclsFound));
 }
 
 /// isAmbiguous - Determines whether the set of paths provided is


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

[PATCH] D12128: Generating available_externally vtables bugfix

[Piotr Padlewski via cfe-commits]

Prazek created this revision.
Prazek added reviewers: rsmith, majnemer, rjmccall.
Prazek added a subscriber: cfe-commits.

Bugfix revealed in r245264.

http://reviews.llvm.org/D12128

Files:
  include/clang/AST/VTableBuilder.h
  lib/CodeGen/ItaniumCXXABI.cpp

Index: lib/CodeGen/ItaniumCXXABI.cpp
===
--- lib/CodeGen/ItaniumCXXABI.cpp
+++ lib/CodeGen/ItaniumCXXABI.cpp
@@ -320,17 +320,15 @@
   void emitCXXStructor(const CXXMethodDecl *MD, StructorType Type) override;
 
  private:
-  /// Checks if function has any virtual inline function.
-  bool hasAnyVirtualInlineFunction(const CXXRecordDecl *RD) const {
+   bool hasAnyUsedVirtualInlineFunction(const CXXRecordDecl *RD) const {
 const auto &VtableLayout =
 CGM.getItaniumVTableContext().getVTableLayout(RD);
 
 for (const auto &VtableComponent : VtableLayout.vtable_components()) {
-  if (VtableComponent.getKind() !=
-  VTableComponent::Kind::CK_FunctionPointer)
+  if (!VtableComponent.isUsedFunctionPointerKind())
 continue;
 
-  const auto &Method = VtableComponent.getFunctionDecl();
+  const CXXMethodDecl *Method = VtableComponent.getFunctionDecl();
   if (Method->getCanonicalDecl()->isInlined())
 return true;
 }
@@ -1536,7 +1534,7 @@
   // then we are safe to emit available_externally copy of vtable.
   // FIXME we can still emit a copy of the vtable if we
   // can emit definition of the inline functions.
-  return !hasAnyVirtualInlineFunction(RD);
+  return !hasAnyUsedVirtualInlineFunction(RD);
 }
 static llvm::Value *performTypeAdjustment(CodeGenFunction &CGF,
   llvm::Value *Ptr,
Index: include/clang/AST/VTableBuilder.h
===
--- include/clang/AST/VTableBuilder.h
+++ include/clang/AST/VTableBuilder.h
@@ -123,29 +123,39 @@
 
   const CXXRecordDecl *getRTTIDecl() const {
 assert(getKind() == CK_RTTI && "Invalid component kind!");
-
 return reinterpret_cast(getPointer());
   }
 
   const CXXMethodDecl *getFunctionDecl() const {
-assert(getKind() == CK_FunctionPointer);
-
+assert(isFunctionPointerKind() && "Invalid component kind!");
+if (isDestructorKind())
+  return getDestructorDecl();
 return reinterpret_cast(getPointer());
   }
 
   const CXXDestructorDecl *getDestructorDecl() const {
-assert((getKind() == CK_CompleteDtorPointer ||
-getKind() == CK_DeletingDtorPointer) && "Invalid component kind!");
-
+assert(isDestructorKind() && "Invalid component kind!");
 return reinterpret_cast(getPointer());
   }
 
   const CXXMethodDecl *getUnusedFunctionDecl() const {
-assert(getKind() == CK_UnusedFunctionPointer);
-
+assert(getKind() == CK_UnusedFunctionPointer && "Invalid component kind!");
 return reinterpret_cast(getPointer());
   }
 
+  bool isDestructorKind() const {
+return getKind() == CK_CompleteDtorPointer ||
+   getKind() == CK_DeletingDtorPointer;
+  }
+
+  bool isUsedFunctionPointerKind() const {
+return getKind() == CK_FunctionPointer || isDestructorKind();
+  }
+
+  bool isFunctionPointerKind() const {
+return isUsedFunctionPointerKind() || getKind() == CK_UnusedFunctionPointer;
+  }
+
 private:
   VTableComponent(Kind ComponentKind, CharUnits Offset) {
 assert((ComponentKind == CK_VCallOffset ||
@@ -158,12 +168,8 @@
   }
 
   VTableComponent(Kind ComponentKind, uintptr_t Ptr) {
-assert((ComponentKind == CK_RTTI ||
-ComponentKind == CK_FunctionPointer ||
-ComponentKind == CK_CompleteDtorPointer ||
-ComponentKind == CK_DeletingDtorPointer ||
-ComponentKind == CK_UnusedFunctionPointer) &&
-"Invalid component kind!");
+assert((ComponentKind == CK_RTTI || isFunctionPointerKind()) &&
+   "Invalid component kind!");
 
 assert((Ptr & 7) == 0 && "Pointer not sufficiently aligned!");
 
@@ -178,11 +184,7 @@
   }
 
   uintptr_t getPointer() const {
-assert((getKind() == CK_RTTI ||
-getKind() == CK_FunctionPointer ||
-getKind() == CK_CompleteDtorPointer ||
-getKind() == CK_DeletingDtorPointer ||
-getKind() == CK_UnusedFunctionPointer) &&
+assert((getKind() == CK_RTTI || isFunctionPointerKind()) &&
"Invalid component kind!");
 
 return static_cast(Value & ~7ULL);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D12122: [CUDA] Add appropriate host/device attribute to target-specific builtins.

[Artem Belevich via cfe-commits]

tra updated this revision to Diff 32481.
tra added a comment.

Added a comment explaining reasoning behind attribute choice for 
target-specific builtins.


http://reviews.llvm.org/D12122

Files:
  include/clang/Basic/Builtins.h
  lib/Sema/SemaChecking.cpp
  lib/Sema/SemaDecl.cpp
  test/SemaCUDA/builtins.cu
  test/SemaCUDA/implicit-intrinsic.cu

Index: test/SemaCUDA/implicit-intrinsic.cu
===
--- test/SemaCUDA/implicit-intrinsic.cu
+++ test/SemaCUDA/implicit-intrinsic.cu
@@ -1,10 +1,10 @@
-// RUN: %clang_cc1 -std=gnu++11 -triple nvptx64-unknown-unknown -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple nvptx64-unknown-unknown -fcuda-is-device -fsyntax-only -verify %s
 
 #include "Inputs/cuda.h"
 
 // expected-no-diagnostics
 __device__ void __threadfence_system() {
-  // This shouldn't produce an error, since __nvvm_membar_sys is inferred to
-  // be __host__ __device__ and thus callable from device code.
+  // This shouldn't produce an error, since __nvvm_membar_sys should be
+  // __device__ and thus callable from device code.
   __nvvm_membar_sys();
 }
Index: test/SemaCUDA/builtins.cu
===
--- /dev/null
+++ test/SemaCUDA/builtins.cu
@@ -0,0 +1,35 @@
+// Tests that target-specific builtins have appropriate host/device
+// attributes and that CUDA call restrictions are enforced. Also
+// verify that non-target builtins can be used from both host and
+// device functions.
+//
+// REQUIRES: x86-registered-target
+// REQUIRES: nvptx-registered-target
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple nvptx64-unknown-cuda -fcuda-is-device \
+// RUN:   -fsyntax-only -verify %s
+
+
+#ifdef __CUDA_ARCH__
+// Device-side builtins are not allowed to be called from host functions.
+void hf() {
+  int x = __builtin_ptx_read_tid_x(); // expected-note  {{'__builtin_ptx_read_tid_x' declared here}}
+  // expected-error@-1 {{reference to __device__ function '__builtin_ptx_read_tid_x' in __host__ function}}
+  x = __builtin_abs(1);
+}
+__attribute__((device)) void df() {
+  int x = __builtin_ptx_read_tid_x();
+  x = __builtin_abs(1);
+}
+#else
+// Host-side builtins are not allowed to be called from device functions.
+__attribute__((device)) void df() {
+  int x = __builtin_ia32_rdtsc();   // expected-note {{'__builtin_ia32_rdtsc' declared here}}
+  // expected-error@-1 {{reference to __host__ function '__builtin_ia32_rdtsc' in __device__ function}}
+  x = __builtin_abs(1);
+}
+void hf() {
+  int x = __builtin_ia32_rdtsc();
+  x = __builtin_abs(1);
+}
+#endif
Index: lib/Sema/SemaDecl.cpp
===
--- lib/Sema/SemaDecl.cpp
+++ lib/Sema/SemaDecl.cpp
@@ -11161,6 +11161,17 @@
   FD->addAttr(NoThrowAttr::CreateImplicit(Context, FD->getLocation()));
 if (Context.BuiltinInfo.isConst(BuiltinID) && !FD->hasAttr())
   FD->addAttr(ConstAttr::CreateImplicit(Context, FD->getLocation()));
+if (getLangOpts().CUDA && Context.BuiltinInfo.isTSBuiltin(BuiltinID) &&
+!FD->hasAttr() && !FD->hasAttr()) {
+  // Target-specific builtins are assumed to be intended for use
+  // in this particular CUDA compilation mode and should have
+  // appropriate attribute set so we can enforce CUDA function
+  // call restrictions.
+  if (getLangOpts().CUDAIsDevice)
+FD->addAttr(CUDADeviceAttr::CreateImplicit(Context, FD->getLocation()));
+  else
+FD->addAttr(CUDAHostAttr::CreateImplicit(Context, FD->getLocation()));
+}
   }
 
   IdentifierInfo *Name = FD->getIdentifier();
Index: lib/Sema/SemaChecking.cpp
===
--- lib/Sema/SemaChecking.cpp
+++ lib/Sema/SemaChecking.cpp
@@ -525,7 +525,7 @@
 
   // Since the target specific builtins for each arch overlap, only check those
   // of the arch we are compiling for.
-  if (BuiltinID >= Builtin::FirstTSBuiltin) {
+  if (Context.BuiltinInfo.isTSBuiltin(BuiltinID)) {
 switch (Context.getTargetInfo().getTriple().getArch()) {
   case llvm::Triple::arm:
   case llvm::Triple::armeb:
Index: include/clang/Basic/Builtins.h
===
--- include/clang/Basic/Builtins.h
+++ include/clang/Basic/Builtins.h
@@ -81,6 +81,11 @@
 return getRecord(ID).Type;
   }
 
+  /// \brief Return true if this function is a target-specific builtin
+  bool isTSBuiltin(unsigned ID) const {
+return ID >= Builtin::FirstTSBuiltin;
+  }
+
   /// \brief Return true if this function has no side effects and doesn't
   /// read memory.
   bool isConst(unsigned ID) const {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D12122: [CUDA] Add appropriate host/device attribute to target-specific builtins.

[Artem Belevich via cfe-commits]

tra marked an inline comment as done.


Comment at: lib/Sema/SemaDecl.cpp:11166
@@ +11165,3 @@
+!FD->hasAttr() && !FD->hasAttr()) {
+  if (getLangOpts().CUDAIsDevice)
+FD->addAttr(CUDADeviceAttr::CreateImplicit(Context, 
FD->getLocation()));

eliben wrote:
> It is not immediately clear why you would mark target-specific builtins as 
> __host__ in host compilation mode. So for example __builtin_ptx_read_tid_x 
> would be callable from a host function when compiling in host mode? Can you 
> clarify this with a comment here, and also add a relevant test?
Target triple used for particular compilation pass is assumed to be valid for 
this particular compilation mode. Builtins provided by the target are therefore 
assumed to be intended to be used in that compilation mode. builtins.cu already 
includes test cases for using target-specific builtins from different targets 
and and non-target-specific builtins in host and device functions in host and 
device compilation.

Your example scenario (__builtin_ptx_read_tid_x getting host attribute) is 
possible only if you compile in host mode *and* use --triple 
nvptx-unknown-cuda. IMO, __host__ would be an appropriate attribute to assign 
to builtins in this scenario, even though I don't think we can currently do 
anything useful with NVPTX as the host at the moment. If you attempt to use 
__builtin_ptx_read_tid_x() during host compilation using non-NVPTX target 
(which is a typical scenario), then compilation will fail because that 
particular builtin would not be available at all.

That said, another corner case would be compiling CUDA for device with the same 
architecture as host. Again, it's not a practical scenario at the moment. 
If/when we get to the point when we may want to do that, it should be easy to 
check for it and treat builtins as __host__ __device__ which would reflect 
their intended use domain.


http://reviews.llvm.org/D12122



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

Re: [PATCH] D11682: [libcxxabi] Add "install-libcxxabi" target.

[Eric Fiselier via cfe-commits]

EricWF added a comment.

What about the extra `[` at the beginning of `ARCHIVE` that spans all the way 
down to the last line. It seems to me that `DESTINATION` can be supplied for 
each library type. There is also an example in the docs that shows using two 
library types in one install command.

However if your still not confident it will work correctly I will make the 
change.


http://reviews.llvm.org/D11682



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

Re: r244902 - Driver: Fix include directories when not using libgcc under mingw

[Hans Wennborg via cfe-commits]

On Tue, Aug 18, 2015 at 4:52 PM, Richard Smith  wrote:
> On Tue, Aug 18, 2015 at 3:00 PM, Hans Wennborg via cfe-commits
>  wrote:
>>
>> Richard, I tried to ping you on the review thread but I'm not sure it
>> got through. Martell requested this be merged to 3.7. What do you
>> think?
>
>
> Sure, this looks fine for branch.

Thanks! r245393.


>> On Thu, Aug 13, 2015 at 8:41 AM, Martell Malone via cfe-commits
>>  wrote:
>> > Author: martell
>> > Date: Thu Aug 13 10:41:04 2015
>> > New Revision: 244902
>> >
>> > URL: http://llvm.org/viewvc/llvm-project?rev=244902&view=rev
>> > Log:
>> > Driver: Fix include directories when not using libgcc under mingw
>> >
>> > Summary:
>> > When we want to use mingw-w64 and clang with compiler-rt we should not
>> > need to have libgcc installed. This fixes finding includes when libgcc
>> > is not installed
>> >
>> > Reviewers: yaron.keren
>> >
>> > Subscribers: cfe-commits
>> >
>> > Differential Revision: http://reviews.llvm.org/D11808
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D11682: [libcxxabi] Add "install-libcxxabi" target.

[Eric Fiselier via cfe-commits]

EricWF added a comment.

@beanz I tested installing both libc++abi.so and libc++abi.a at the same time 
with different destinations. They both installed into the correct destinations.


http://reviews.llvm.org/D11682



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

Re: [PATCH] D12128: Generating available_externally vtables bugfix

[Richard Smith via cfe-commits]

rsmith added a comment.

This looks fine; can you add a testcase?


http://reviews.llvm.org/D12128



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

[PATCH] D12129: [libcxx] Add new Sphinx documentation

[Eric Fiselier via cfe-commits]

EricWF created this revision.
EricWF added reviewers: jroelofs, chandlerc, danalbert, mclow.lists.
EricWF added a subscriber: cfe-commits.

This patch adds Sphinx based documentation to libc++. The goal is to make it 
easier to write documentation for libc++ since writing new documentation in 
HTML is cumbersome. This patch rewrites the main page for libc++ along with the 
instructions for using, building and testing libc++. 

The built documentation can be found and reviewed here: 
http://efcs.ca/libcxx-docs

In order to build the sphinx documentation you need to specify the cmake 
options `-DLLVM_ENABLE_SPHINX=ON -DLIBCXX_INCLUDE_DOCS=ON`. This will add the 
makefile rule `docs-libcxx-html`. 


http://reviews.llvm.org/D12129

Files:
  CMakeLists.txt
  cmake/Modules/HandleOutOfTreeLLVM.cmake
  cmake/config-ix.cmake
  docs/BuildingLibcxx.rst
  docs/CMakeLists.txt
  docs/README.txt
  docs/TestingLibcxx.rst
  docs/UsingLibcxx.rst
  docs/_static/favicon.ico
  docs/_static/lines.gif
  docs/_static/llvm.css
  docs/_templates/indexsidebar.html
  docs/_templates/layout.html
  docs/_themes/llvm-theme/layout.html
  docs/_themes/llvm-theme/static/contents.png
  docs/_themes/llvm-theme/static/llvm-theme.css
  docs/_themes/llvm-theme/static/logo.png
  docs/_themes/llvm-theme/static/navigation.png
  docs/_themes/llvm-theme/theme.conf
  docs/conf.py
  docs/index.rst

Index: docs/index.rst
===
--- /dev/null
+++ docs/index.rst
@@ -0,0 +1,171 @@
+.. _index:
+
+=
+"libc++" C++ Standard Library
+=
+
+Overview
+
+
+libc++ is a new implementation of the C++ standard library, targeting C++11.
+
+* Features and Goals
+
+  * Correctness as defined by the C++11 standard.
+  * Fast execution.
+  * Minimal memory use.
+  * Fast compile times.
+  * ABI compatibility with gcc's libstdc++ for some low-level features
+such as exception objects, rtti and memory allocation.
+  * Extensive unit tests.
+
+* Design and Implementation:
+
+  * Extensive unit tests
+  * Internal linker model can be dumped/read to textual format
+  * Additional linking features can be plugged in as "passes"
+  * OS specific and CPU specific code factored out
+
+
+Getting Started with libc++
+---
+
+.. toctree::
+   :maxdepth: 2
+
+   UsingLibcxx
+   BuildingLibcxx
+   TestingLibcxx
+
+Current Status
+--
+
+After its initial introduction, many people have asked "why start a new
+library instead of contributing to an existing library?" (like Apache's
+libstdcxx, GNU's libstdc++, STLport, etc).  There are many contributing
+reasons, but some of the major ones are:
+
+From years of experience (including having implemented the standard
+library before), we've learned many things about implementing
+the standard containers which require ABI breakage and fundamental changes
+to how they are implemented.  For example, it is generally accepted that
+building std::string using the "short string optimization" instead of
+using Copy On Write (COW) is a superior approach for multicore
+machines (particularly in C++11, which has rvalue references).  Breaking
+ABI compatibility with old versions of the library was
+determined to be critical to achieving the performance goals of
+libc++.
+
+Mainline libstdc++ has switched to GPL3, a license which the developers
+of libc++ cannot use.  libstdc++ 4.2 (the last GPL2 version) could be
+independently extended to support C++11, but this would be a fork of the
+codebase (which is often seen as worse for a project than starting a new
+independent one).  Another problem with libstdc++ is that it is tightly
+integrated with G++ development, tending to be tied fairly closely to the
+matching version of G++.
+
+STLport and the Apache libstdcxx library are two other popular
+candidates, but both lack C++11 support.  Our experience (and the
+experience of libstdc++ developers) is that adding support for C++11 (in
+particular rvalue references and move-only types) requires changes to
+almost every class and function, essentially amounting to a rewrite.
+Faced with a rewrite, we decided to start from scratch and evaluate every
+design decision from first principles based on experience.
+
+Further, both projects are apparently abandoned: STLport 5.2.1 was
+released in Oct'08, and STDCXX 4.2.1 in May'08.
+
+Platform and Compiler Support
+-
+
+libc++ is known to work on the following platforms, using gcc-4.2 and
+clang  (lack of C++11 language support disables some functionality).
+Note that functionality provided by  is only functional with clang
+and GCC.
+
+   
+OS   Arch CompilersABI Library
+   
+Mac OS X i386, x86_64 Clang, GCC   libc++abi
+FreeBSD 10+  i386, x86_64, ARM 

Re: r245084 - WindowsX86: long double is x87DoubleExtended on mingw

[Richard Smith via cfe-commits]

On Tue, Aug 18, 2015 at 3:01 PM, Hans Wennborg  wrote:

> Richard, I tried to ping you on the review thread but I'm not sure it
> got through. Martell requested this be merged to 3.7. What do you
> think?


LGTM


> On Fri, Aug 14, 2015 at 12:05 PM, Martell Malone via cfe-commits
>  wrote:
> > Author: martell
> > Date: Fri Aug 14 14:05:56 2015
> > New Revision: 245084
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=245084&view=rev
> > Log:
> > WindowsX86: long double is x87DoubleExtended on mingw
> >
> > Summary:
> > long double on x86 mingw is 80bits and is aligned to 16bytes
> >
> > Fixes:
> > https://llvm.org/bugs/show_bug.cgi?id=24398
> >
> > Reviewers: rnk
> >
> > Subscribers: cfe-commits
> >
> > Differential Revision: http://reviews.llvm.org/D12037
> >
> > Modified:
> > cfe/trunk/lib/Basic/Targets.cpp
> >
> > Modified: cfe/trunk/lib/Basic/Targets.cpp
> > URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=245084&r1=245083&r2=245084&view=diff
> >
> ==
> > --- cfe/trunk/lib/Basic/Targets.cpp (original)
> > +++ cfe/trunk/lib/Basic/Targets.cpp Fri Aug 14 14:05:56 2015
> > @@ -3784,7 +3784,10 @@ namespace {
> >  class MinGWX86_32TargetInfo : public WindowsX86_32TargetInfo {
> >  public:
> >MinGWX86_32TargetInfo(const llvm::Triple &Triple)
> > -  : WindowsX86_32TargetInfo(Triple) {}
> > +  : WindowsX86_32TargetInfo(Triple) {
> > +LongDoubleWidth = LongDoubleAlign = 128;
> > +LongDoubleFormat = &llvm::APFloat::x87DoubleExtended;
> > +  }
> >void getTargetDefines(const LangOptions &Opts,
> >  MacroBuilder &Builder) const override {
> >  WindowsX86_32TargetInfo::getTargetDefines(Opts, Builder);
> > @@ -4014,7 +4017,10 @@ public:
> >  class MinGWX86_64TargetInfo : public WindowsX86_64TargetInfo {
> >  public:
> >MinGWX86_64TargetInfo(const llvm::Triple &Triple)
> > -  : WindowsX86_64TargetInfo(Triple) {}
> > +  : WindowsX86_64TargetInfo(Triple) {
> > +LongDoubleWidth = LongDoubleAlign = 128;
> > +LongDoubleFormat = &llvm::APFloat::x87DoubleExtended;
> > +  }
> >void getTargetDefines(const LangOptions &Opts,
> >  MacroBuilder &Builder) const override {
> >  WindowsX86_64TargetInfo::getTargetDefines(Opts, Builder);
> >
> >
> > ___
> > 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] D12002: Initial WebAssembly support in clang

[Dan Gohman via cfe-commits]

sunfish updated this revision to Diff 32485.
sunfish marked an inline comment as done.
sunfish added a comment.

The patch evolved enough to prompt posting one more new version; major changes:

- make constructors and destructors return this
- enable -fuse-init-array
- enable -fno-common
- disable -mdisable-fp-elim
- put static init code in ".text.__startup"
- define a "+simd128" feature, -msimd128 option, __wasm_simd128__ macro
- ignore empty struct arguments and return values
- more tests


Repository:
  rL LLVM

http://reviews.llvm.org/D12002

Files:
  include/clang/Basic/BuiltinsWebAssembly.def
  include/clang/Basic/TargetBuiltins.h
  include/clang/Basic/TargetCXXABI.h
  include/clang/Driver/Options.td
  include/clang/module.modulemap
  lib/AST/ASTContext.cpp
  lib/Basic/Targets.cpp
  lib/CodeGen/CGBuiltin.cpp
  lib/CodeGen/CodeGenFunction.h
  lib/CodeGen/CodeGenModule.cpp
  lib/CodeGen/ItaniumCXXABI.cpp
  lib/CodeGen/TargetInfo.cpp
  lib/Driver/Driver.cpp
  lib/Driver/ToolChains.cpp
  lib/Driver/ToolChains.h
  lib/Driver/Tools.cpp
  test/CodeGen/align-wasm.c
  test/CodeGen/builtins-wasm.c
  test/CodeGen/target-data.c
  test/CodeGen/wasm-arguments.c
  test/CodeGen/wasm-regparm.c
  test/CodeGenCXX/constructor-destructor-return-this.cpp
  test/CodeGenCXX/member-alignment.cpp
  test/CodeGenCXX/member-function-pointers.cpp
  test/CodeGenCXX/static-init-wasm.cpp
  test/CodeGenCXX/wasm-args-returns.cpp
  test/Driver/wasm32-unknown-unknown.cpp
  test/Driver/wasm64-unknown-unknown.cpp
  test/Preprocessor/init.c
  test/Preprocessor/wasm-target-features.c

Index: test/Preprocessor/wasm-target-features.c
===
--- test/Preprocessor/wasm-target-features.c
+++ test/Preprocessor/wasm-target-features.c
@@ -0,0 +1,35 @@
+// RUN: %clang -E -dM %s -o - 2>&1 \
+// RUN: -target wasm32-unknown-unknown -msimd128 \
+// RUN:   | FileCheck %s -check-prefix=SIMD128
+// RUN: %clang -E -dM %s -o - 2>&1 \
+// RUN: -target wasm64-unknown-unknown -msimd128 \
+// RUN:   | FileCheck %s -check-prefix=SIMD128
+//
+// SIMD128:#define __wasm_simd128__ 1{{$}}
+//
+// RUN: %clang -E -dM %s -o - 2>&1 \
+// RUN: -target wasm32-unknown-unknown -mcpu=mvp \
+// RUN:   | FileCheck %s -check-prefix=MVP
+// RUN: %clang -E -dM %s -o - 2>&1 \
+// RUN: -target wasm64-unknown-unknown -mcpu=mvp \
+// RUN:   | FileCheck %s -check-prefix=MVP
+//
+// MVP-NOT:#define __wasm_simd128__
+//
+// RUN: %clang -E -dM %s -o - 2>&1 \
+// RUN: -target wasm32-unknown-unknown -mcpu=bleeding-edge \
+// RUN:   | FileCheck %s -check-prefix=BLEEDING_EDGE
+// RUN: %clang -E -dM %s -o - 2>&1 \
+// RUN: -target wasm64-unknown-unknown -mcpu=bleeding-edge \
+// RUN:   | FileCheck %s -check-prefix=BLEEDING_EDGE
+//
+// BLEEDING_EDGE:#define __wasm_simd128__ 1{{$}}
+//
+// RUN: %clang -E -dM %s -o - 2>&1 \
+// RUN: -target wasm32-unknown-unknown -mcpu=bleeding-edge -mno-simd128 \
+// RUN:   | FileCheck %s -check-prefix=BLEEDING_EDGE_NO_SIMD128
+// RUN: %clang -E -dM %s -o - 2>&1 \
+// RUN: -target wasm64-unknown-unknown -mcpu=bleeding-edge -mno-simd128 \
+// RUN:   | FileCheck %s -check-prefix=BLEEDING_EDGE_NO_SIMD128
+//
+// BLEEDING_EDGE_NO_SIMD128-NOT:#define __wasm_simd128__
Index: test/Preprocessor/init.c
===
--- test/Preprocessor/init.c
+++ test/Preprocessor/init.c
@@ -8419,3 +8419,623 @@
 // XCORE:#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
 // XCORE:#define __LITTLE_ENDIAN__ 1
 // XCORE:#define __XS1B__ 1
+//
+// RUN: %clang_cc1 -E -dM -ffreestanding -triple=wasm32-unknown-unknown \
+// RUN:   < /dev/null \
+// RUN:   | FileCheck -check-prefix=WEBASSEMBLY32 %s
+//
+// WEBASSEMBLY32:#define _ILP32 1{{$}}
+// WEBASSEMBLY32-NOT:#define _LP64
+// WEBASSEMBLY32-NEXT:#define __ATOMIC_ACQUIRE 2{{$}}
+// WEBASSEMBLY32-NEXT:#define __ATOMIC_ACQ_REL 4{{$}}
+// WEBASSEMBLY32-NEXT:#define __ATOMIC_CONSUME 1{{$}}
+// WEBASSEMBLY32-NEXT:#define __ATOMIC_RELAXED 0{{$}}
+// WEBASSEMBLY32-NEXT:#define __ATOMIC_RELEASE 3{{$}}
+// WEBASSEMBLY32-NEXT:#define __ATOMIC_SEQ_CST 5{{$}}
+// WEBASSEMBLY32-NEXT:#define __BIGGEST_ALIGNMENT__ 16{{$}}
+// WEBASSEMBLY32-NEXT:#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__{{$}}
+// WEBASSEMBLY32-NEXT:#define __CHAR16_TYPE__ unsigned short{{$}}
+// WEBASSEMBLY32-NEXT:#define __CHAR32_TYPE__ unsigned int{{$}}
+// WEBASSEMBLY32-NEXT:#define __CHAR_BIT__ 8{{$}}
+// WEBASSEMBLY32-NEXT:#define __CONSTANT_CFSTRINGS__ 1{{$}}
+// WEBASSEMBLY32-NEXT:#define __DBL_DECIMAL_DIG__ 17{{$}}
+// WEBASSEMBLY32-NEXT:#define __DBL_DENORM_MIN__ 4.9406564584124654e-324{{$}}
+// WEBASSEMBLY32-NEXT:#define __DBL_DIG__ 15{{$}}
+// WEBASSEMBLY32-NEXT:#define __DBL_EPSILON__ 2.2204460492503131e-16{{$}}
+// WEBASSEMBLY32-NEXT:#define __DBL_HAS_DENORM__ 1{{$}}
+// WEBASSEMBLY32-NEXT:#define __DBL_HAS_INFINITY__ 1{{$}}
+// WEBASSEMBLY32-NEXT:#define __DBL_HAS_QUIET_NAN__ 1{{$}}
+// WEBASSEMBLY32-NEXT:#define __DBL_MANT_DIG__ 

Re: [PATCH] D11194: Instantiate function declarations in instantiated functions.

[Richard Smith via cfe-commits]

On Tue, Aug 18, 2015 at 10:05 AM, Serge Pavlov  wrote:

> sepavloff added inline comments.
>
> 
> Comment at: lib/AST/DeclBase.cpp:273
> @@ +272,3 @@
> +return true;
> +  if (const CXXRecordDecl *ClassD = dyn_cast(LDC))
> +return ClassD->isLocalClass() && !ClassD->isLambda();;
> 
> rsmith wrote:
> > It's not necessary for this change, but to match its documentation this
> function should handle other kinds of `TagDecl` too (enums, C structs).
> Something like:
> >
> >   do {
> > if (LDC->isFunctionOrMethod())
> >   return true;
> > if (!isa(LDC))
> >   return false;
> > LDC = LDC->getLexicalParent();
> >   } while (LDC);
> >   return false;
> >
> > ... maybe?
> The proposed code recognizes lambda as lexically contained within a
> function. As a result, the following test starts to fail (obtained from
> CXX\expr\expr.prim\expr.prim.lambda\default-arguments.cpp):
> ```
> struct NoDefaultCtor {
>   NoDefaultCtor(const NoDefaultCtor&); // expected-note{{candidate
> constructor}}
>   ~NoDefaultCtor();
> };
>
> template
> void defargs_in_template_unused(T t) {
>   auto l1 = [](const T& value = T()) { };
>   l1(t);
> }
>
> template void defargs_in_template_unused(NoDefaultCtor);
> ```
> because default value for lambda argument cannot be instantiated. It is
> not clear whether instantiation of the lambda default argument must always
> occur similar to DR1484. I couldn't find appropriate place in the standard.
> According to spirit it shouldn't as lambda is not a separate declaration
> but a part of instantiated content.


I agree. The default argument must be instantiated as part of instantiating
the surrounding function.


> If so  14.6.4.1p2 is more likely to be applied and the above test must
> pass.
>

The call operator of the lambda is neither a function template nor a member
function of a class template. The relevant rule is 14.7.1/1: "Within a
template declaration, a local class or enumeration and the members
of a local class are never considered to be entities that can be separately
instantiated (this includes their
default arguments, exception-specifications, and non-static data member
initializers, if any)." The lambda expression defines a local class, so its
members' default arguments are instantiated with the surrounding function.


> Maybe we need to rename `isLexicallyWithinFunctionOrMethod` to
> `shouldBeAlwaysInstantiated` or something like that to avoid
> misunderstanding?
>
>
>
> http://reviews.llvm.org/D11194
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D12131: Make [Sema]DiagnosticBuilder move-only, instead of having a sneaky mutating copy ctor.

[David Blaikie via cfe-commits]

dblaikie created this revision.
dblaikie added a reviewer: rsmith.
dblaikie added a subscriber: cfe-commits.

While there wasn't much use of "return Diag(...) << x" outside Sema (one
each in ARCMigrate, Lex, Parse, and 5 in ClangTidy - which were all just
changed to use named local variables, then stream, then return), in Sema
there were quite a few uses. So this extends Sema::Diag to be a variadic
template allowing the extra parameters to be passed directly rather than
via streaming on the resulting temporary expression.

http://reviews.llvm.org/D12131

Files:
  include/clang/Basic/Diagnostic.h
  include/clang/Sema/Sema.h
  lib/ARCMigrate/TransformActions.cpp
  lib/Lex/LiteralSupport.cpp
  lib/Parse/Parser.cpp
  lib/Sema/SemaDeclObjC.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaExprCXX.cpp
  lib/Sema/SemaExprObjC.cpp
  lib/Sema/SemaObjCProperty.cpp
  lib/Sema/SemaOpenMP.cpp
  lib/Sema/SemaStmt.cpp
  lib/Sema/SemaStmtAsm.cpp
  lib/Sema/SemaTemplateVariadic.cpp
  lib/Sema/SemaType.cpp

Index: lib/Sema/SemaType.cpp
===
--- lib/Sema/SemaType.cpp
+++ lib/Sema/SemaType.cpp
@@ -5611,12 +5611,11 @@
 : chunk.Kind == DeclaratorChunk::BlockPointer ? PK_BlockPointer
 : inFunction? PK_MemberFunctionPointer : PK_MemberPointer;
 
-auto diag = state.getSema().Diag(attr.getLoc(),
- diag::warn_nullability_declspec)
-  << DiagNullabilityKind(mapNullabilityAttrKind(attr.getKind()),
- attr.isContextSensitiveKeywordAttribute())
-  << type
-  << static_cast(pointerKind);
+auto diag = state.getSema().Diag(
+attr.getLoc(), diag::warn_nullability_declspec,
+DiagNullabilityKind(mapNullabilityAttrKind(attr.getKind()),
+attr.isContextSensitiveKeywordAttribute()),
+type, static_cast(pointerKind));
 
 // FIXME: MemberPointer chunks don't carry the location of the *.
 if (chunk.Kind != DeclaratorChunk::MemberPointer) {
Index: lib/Sema/SemaTemplateVariadic.cpp
===
--- lib/Sema/SemaTemplateVariadic.cpp
+++ lib/Sema/SemaTemplateVariadic.cpp
@@ -251,8 +251,8 @@
   Locations.push_back(Unexpanded[I].second);
   }
 
-  DiagnosticBuilder DB = Diag(Loc, diag::err_unexpanded_parameter_pack)
- << (int)UPPC << (int)Names.size();
+  DiagnosticBuilder DB = Diag(Loc, diag::err_unexpanded_parameter_pack,
+  (int)UPPC, (int)Names.size());
   for (size_t I = 0, E = std::min(Names.size(), (size_t)2); I != E; ++I)
 DB << Names[I];
 
Index: lib/Sema/SemaStmtAsm.cpp
===
--- lib/Sema/SemaStmtAsm.cpp
+++ lib/Sema/SemaStmtAsm.cpp
@@ -393,9 +393,9 @@
diag::warn_asm_mismatched_size_modifier);
 
   if (!SuggestedModifier.empty()) {
-auto B = Diag(Piece.getRange().getBegin(),
-  diag::note_asm_missing_constraint_modifier)
- << SuggestedModifier;
+auto B =
+Diag(Piece.getRange().getBegin(),
+ diag::note_asm_missing_constraint_modifier, SuggestedModifier);
 SuggestedModifier = "%" + SuggestedModifier + Piece.getString();
 B.AddFixItHint(FixItHint::CreateReplacement(Piece.getRange(),
 SuggestedModifier));
Index: lib/Sema/SemaStmt.cpp
===
--- lib/Sema/SemaStmt.cpp
+++ lib/Sema/SemaStmt.cpp
@@ -604,35 +604,35 @@
 
 SemaDiagnosticBuilder diagnoseNotInt(Sema &S, SourceLocation Loc,
  QualType T) override {
-  return S.Diag(Loc, diag::err_typecheck_statement_requires_integer) << T;
+  return S.Diag(Loc, diag::err_typecheck_statement_requires_integer, T);
 }
 
 SemaDiagnosticBuilder diagnoseIncomplete(
 Sema &S, SourceLocation Loc, QualType T) override {
-  return S.Diag(Loc, diag::err_switch_incomplete_class_type)
-   << T << Cond->getSourceRange();
+  return S.Diag(Loc, diag::err_switch_incomplete_class_type, T,
+Cond->getSourceRange());
 }
 
 SemaDiagnosticBuilder diagnoseExplicitConv(
 Sema &S, SourceLocation Loc, QualType T, QualType ConvTy) override {
-  return S.Diag(Loc, diag::err_switch_explicit_conversion) << T << ConvTy;
+  return S.Diag(Loc, diag::err_switch_explicit_conversion , T , ConvTy);
 }
 
 SemaDiagnosticBuilder noteExplicitConv(
 Sema &S, CXXConversionDecl *Conv, QualType ConvTy) override {
-  return S.Diag(Conv->getLocation(), diag::note_switch_conversion)
-<< ConvTy->isEnumeralType() << ConvTy;
+  return S.Diag(Conv->getLocation(), diag::note_switch_conversion,
+ConvTy->isEnumeralType(), ConvTy);
 }
 
 SemaDiagnosticBuilder diagnoseAmbig

Re: r245352 - Workaround -Wdeprecated on SemDiagnosticConsumer's tricksy copy ctor.

[David Blaikie via cfe-commits]

On Tue, Aug 18, 2015 at 4:46 PM, Richard Smith 
wrote:

> On Tue, Aug 18, 2015 at 2:03 PM, David Blaikie  wrote:
>
>> Richard, do you think there's anything we could do better here?
>>
>> It seems difficult to support proper move semantic behavior for
>> [Sema]DiagnosticBuilder across the two common use cases:
>>
>>   DiagnosticBuilder D;
>>   D << x;
>>   D << y;
>>   return D;
>>
>> and
>>
>>   return DiagnosticBuilder() << x << y;
>>
>
> Do we actually use this form to return a DiagnosticBuilder, or just to
> construct an ActionResult? Can we eliminate uses of this form?
>

We don't use it very often outside of "return S.Diag(...) << x << y" - 3
cases (each in disparate parts of the codebase) in Clang, 5 in Clang-Tidy.

For the Sema case, there seemed to be enough uses that I've experimented
with making Sema::Diag variadic and taking the extra parameters: "return
S.Diag(..., x, y);" which seems to work pretty well. Sent for review in
http://reviews.llvm.org/D12131


>
>
>> The only thing I can imagine is if every one of those op<< were function
>> templates using universal references (I forget, is that the right name for
>> them?) and matching their return value (so in the first case, passed a
>> non-const lvalue ref, they return by non-const lvalue ref, and in the
>> second case, passed an rvalue, they return the same). But that seems
>> painful.
>>
>
> It seems tricky to form an unambiguous overload set for this that
> preserves the value category, without duplicating all the operator<

Yep :/


>
>
>> On Tue, Aug 18, 2015 at 1:54 PM, David Blaikie via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: dblaikie
>>> Date: Tue Aug 18 15:54:26 2015
>>> New Revision: 245352
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=245352&view=rev
>>> Log:
>>> Workaround -Wdeprecated on SemDiagnosticConsumer's tricksy copy ctor.
>>>
>>> Modified:
>>> cfe/trunk/include/clang/Sema/Sema.h
>>>
>>> Modified: cfe/trunk/include/clang/Sema/Sema.h
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=245352&r1=245351&r2=245352&view=diff
>>>
>>> ==
>>> --- cfe/trunk/include/clang/Sema/Sema.h (original)
>>> +++ cfe/trunk/include/clang/Sema/Sema.h Tue Aug 18 15:54:26 2015
>>> @@ -1054,6 +1054,14 @@ public:
>>>  SemaDiagnosticBuilder(DiagnosticBuilder &DB, Sema &SemaRef,
>>> unsigned DiagID)
>>>: DiagnosticBuilder(DB), SemaRef(SemaRef), DiagID(DiagID) { }
>>>
>>> +// This is a cunning lie. DiagnosticBuilder actually performs move
>>> +// construction in its copy constructor (but due to varied uses,
>>> it's not
>>> +// possible to conveniently express this as actual move
>>> construction). So
>>> +// the default copy ctor here is fine, because the base class
>>> disables the
>>> +// source anyway, so the user-defined ~SemaDiagnosticBuilder is a
>>> safe no-op
>>> +// in that case anwyay.
>>> +SemaDiagnosticBuilder(const SemaDiagnosticBuilder&) = default;
>>> +
>>>  ~SemaDiagnosticBuilder() {
>>>// If we aren't active, there is nothing to do.
>>>if (!isActive()) return;
>>>
>>>
>>> ___
>>> 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