r246991 - When building the alloca for a local variable, set its name

[John McCall via cfe-commits]

Author: rjmccall
Date: Tue Sep  8 04:18:30 2015
New Revision: 246991

URL: http://llvm.org/viewvc/llvm-project?rev=246991&view=rev
Log:
When building the alloca for a local variable, set its name
separately from building the instruction so that it's
preserved even in -Asserts builds.

Employ C++'s mystical "comment" feature to discourage
breaking this in the future.

Modified:
cfe/trunk/lib/CodeGen/CGDecl.cpp

Modified: cfe/trunk/lib/CodeGen/CGDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDecl.cpp?rev=246991&r1=246990&r2=246991&view=diff
==
--- cfe/trunk/lib/CodeGen/CGDecl.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDecl.cpp Tue Sep  8 04:18:30 2015
@@ -968,7 +968,11 @@ CodeGenFunction::EmitAutoVarAlloca(const
 allocaAlignment = alignment;
   }
 
-  address = CreateTempAlloca(allocaTy, allocaAlignment, D.getName());
+  // Create the alloca.  Note that we set the name separately from
+  // building the instruction so that it's there even in no-asserts
+  // builds.
+  address = CreateTempAlloca(allocaTy, allocaAlignment);
+  address.getPointer()->setName(D.getName());
 
   // Emit a lifetime intrinsic if meaningful.  There's no point
   // in doing this if we don't have a valid insertion point (?).


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

r246992 - Fix clang/test/CodeGenCXX/alignment.cpp for -Asserts.

[NAKAMURA Takumi via cfe-commits]

Author: chapuni
Date: Tue Sep  8 04:31:04 2015
New Revision: 246992

URL: http://llvm.org/viewvc/llvm-project?rev=246992&view=rev
Log:
Fix clang/test/CodeGenCXX/alignment.cpp for -Asserts.

Modified:
cfe/trunk/test/CodeGenCXX/alignment.cpp

Modified: cfe/trunk/test/CodeGenCXX/alignment.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/alignment.cpp?rev=246992&r1=246991&r2=246992&view=diff
==
--- cfe/trunk/test/CodeGenCXX/alignment.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/alignment.cpp Tue Sep  8 04:31:04 2015
@@ -110,6 +110,7 @@ namespace test0 {
 // CHECK: [[C_P:%.*]] = alloca [[C:%.*]], align 2
 C c;
 
+// CHECK: [[CALL:%.*]] = call i32 @_Z10int_sourcev()
 // CHECK: [[T0:%.*]] = bitcast [[C]]* [[C_P]] to i8*
 // CHECK: [[T1:%.*]] = getelementptr inbounds i8, i8* [[T0]], i64 8
 // CHECK: [[B_P:%.*]] = bitcast i8* [[T1]] to [[B]]*


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

r246993 - Another fix to this test, this one apparently working by

[John McCall via cfe-commits]

Author: rjmccall
Date: Tue Sep  8 04:33:33 2015
New Revision: 246993

URL: http://llvm.org/viewvc/llvm-project?rev=246993&view=rev
Log:
Another fix to this test, this one apparently working by
coincidence on all bots.

Modified:
cfe/trunk/test/CodeGenCXX/alignment.cpp

Modified: cfe/trunk/test/CodeGenCXX/alignment.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/alignment.cpp?rev=246993&r1=246992&r2=246993&view=diff
==
--- cfe/trunk/test/CodeGenCXX/alignment.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/alignment.cpp Tue Sep  8 04:33:33 2015
@@ -142,6 +142,7 @@ namespace test0 {
 // CHECK: [[C_P:%.*]] = alloca [[C:%.*]], align 16
 __attribute__((aligned(16))) C c;
 
+// CHECK: [[CALL:%.*]] = call i32 @_Z10int_sourcev()
 // CHECK: [[T0:%.*]] = bitcast [[C]]* [[C_P]] to i8*
 // CHECK: [[T1:%.*]] = getelementptr inbounds i8, i8* [[T0]], i64 8
 // CHECK: [[B_P:%.*]] = bitcast i8* [[T1]] to [[B]]*


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

r246994 - Fix clang/test/CodeGen/mips-varargs.c for -Asserts, possibly typo.

[NAKAMURA Takumi via cfe-commits]

Author: chapuni
Date: Tue Sep  8 04:37:09 2015
New Revision: 246994

URL: http://llvm.org/viewvc/llvm-project?rev=246994&view=rev
Log:
Fix clang/test/CodeGen/mips-varargs.c for -Asserts, possibly typo.

Modified:
cfe/trunk/test/CodeGen/mips-varargs.c

Modified: cfe/trunk/test/CodeGen/mips-varargs.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/mips-varargs.c?rev=246994&r1=246993&r2=246994&view=diff
==
--- cfe/trunk/test/CodeGen/mips-varargs.c (original)
+++ cfe/trunk/test/CodeGen/mips-varargs.c Tue Sep  8 04:37:09 2015
@@ -119,7 +119,7 @@ char *test_ptr(char *fmt, ...) {
 // ALL:   [[ARG:%.+]] = load i8*, i8** [[AP_CAST]], align [[PTRALIGN]]
 // ALL:   store i8* [[ARG]], i8** [[V]], align [[PTRALIGN]]
 //
-// ALL:   [[VA:%.+]] = bitcast i8** %va to i8*
+// ALL:   [[VA1:%.+]] = bitcast i8** %va to i8*
 // ALL:   call void @llvm.va_end(i8* [[VA1]])
 // ALL: }
 


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

Re: recordDecl() AST matcher

[Manuel Klimek via cfe-commits]

Yea, we had that discussion a few times, and I can never remember why we
ended up in the state we're in.
We definitely had a time where we switched to just using the exact same
name as the node's class name for the matchers.
I *think* we didn't do it for cxxRecordDecl, because Richard said that's a
relic we should get rid of anyway, but I'm not sure.

On Fri, Sep 4, 2015 at 8:32 PM Aaron Ballman  wrote:

> It turns out that the recordDecl() AST matcher doesn't match
> RecordDecl objects; instead, it matches CXXRecordDecl objects. This
> is... unfortunate... as it makes writing AST matchers more complicated
> because of having to translate between recordDecl()/CXXRecordDecl. It
> also makes it impossible to match a struct or union declaration in C
> or ObjC. However, given how prevalent recordDecl()'s use is in the
> wild (I'm guessing), changing it at this point would be a Bad Thing.
>
> For people trying to write AST matchers for languages like C or ObjC,
> I would like to propose adding:
>
> structDecl()
> unionDecl()
> tagDecl()
>
> These will match nicely with the existing enumDecl() AST matcher.
>
> Additionally, I would like to add cxxRecordDecl() to match
> CXXRecordDecl objects. While it duplicates the functionality exposed
> by recordDecl(), it more clearly matches the intention of which AST
> node it corresponds to.
>
> Finally, I would like to undocument recordDecl() and change our
> existing documentation and AST matcher uses to use
> cxxRecordDecl/structDecl() instead. Maybe someday we can deprecate
> recordDecl() more officially.
>
> I'm open to other ideas if there are better ways to move forward. If
> you think changing the meaning of recordDecl() is acceptable, I can
> also go that route (though I would still propose adding unionDecl()
> and cxxRecordDecl() in that case).
>

I think changing recordDecl is acceptable. I believe very few tools will
actually start doing wrong things because of it. I'd like more opinions
first, though :)


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

r246995 - clangCodeGen: Fix comments. [-Wdocumentation]

[NAKAMURA Takumi via cfe-commits]

Author: chapuni
Date: Tue Sep  8 04:42:41 2015
New Revision: 246995

URL: http://llvm.org/viewvc/llvm-project?rev=246995&view=rev
Log:
clangCodeGen: Fix comments. [-Wdocumentation]

Modified:
cfe/trunk/lib/CodeGen/CGClass.cpp
cfe/trunk/lib/CodeGen/CGDecl.cpp
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h

Modified: cfe/trunk/lib/CodeGen/CGClass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGClass.cpp?rev=246995&r1=246994&r2=246995&view=diff
==
--- cfe/trunk/lib/CodeGen/CGClass.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGClass.cpp Tue Sep  8 04:42:41 2015
@@ -1865,7 +1865,7 @@ void CodeGenFunction::EmitCXXAggrConstru
 /// \param ctor the constructor to call for each element
 /// \param numElements the number of elements in the array;
 ///   may be zero
-/// \param arrayBegin a T*, where T is the type constructed by ctor
+/// \param arrayBase a T*, where T is the type constructed by ctor
 /// \param zeroInitialize true if each element should be
 ///   zero-initialized before it is constructed
 void CodeGenFunction::EmitCXXAggrConstructorCall(const CXXConstructorDecl 
*ctor,

Modified: cfe/trunk/lib/CodeGen/CGDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDecl.cpp?rev=246995&r1=246994&r2=246995&view=diff
==
--- cfe/trunk/lib/CodeGen/CGDecl.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDecl.cpp Tue Sep  8 04:42:41 2015
@@ -1463,7 +1463,7 @@ void CodeGenFunction::emitDestroy(Addres
 ///
 /// \param begin - a type* denoting the first element of the array
 /// \param end - a type* denoting one past the end of the array
-/// \param type - the element type of the array
+/// \param elementType - the element type of the array
 /// \param destroyer - the function to call to destroy elements
 /// \param useEHCleanup - whether to push an EH cleanup to destroy
 ///   the remaining elements in case the destruction of a single

Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h?rev=246995&r1=246994&r2=246995&view=diff
==
--- cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h (original)
+++ cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h Tue Sep  8 04:42:41 2015
@@ -474,6 +474,12 @@ public:
   ///
   virtual bool isDynamic(OpenMPScheduleClauseKind ScheduleKind) const;
 
+  virtual void emitForDispatchInit(CodeGenFunction &CGF, SourceLocation Loc,
+   OpenMPScheduleClauseKind SchedKind,
+   unsigned IVSize, bool IVSigned,
+   bool Ordered, llvm::Value *UB,
+   llvm::Value *Chunk = nullptr);
+
   /// \brief Call the appropriate runtime routine to initialize it before start
   /// of loop.
   ///
@@ -498,11 +504,6 @@ public:
   /// \param Chunk Value of the chunk for the static_chunked scheduled loop.
   /// For the default (nullptr) value, the chunk 1 will be used.
   ///
-  virtual void emitForDispatchInit(CodeGenFunction &CGF, SourceLocation Loc,
-   OpenMPScheduleClauseKind SchedKind,
-   unsigned IVSize, bool IVSigned,
-   bool Ordered, llvm::Value *UB,
-   llvm::Value *Chunk = nullptr);
   virtual void emitForStaticInit(CodeGenFunction &CGF, SourceLocation Loc,
  OpenMPScheduleClauseKind SchedKind,
  unsigned IVSize, bool IVSigned, bool Ordered,


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

[clang-tools-extra] r246996 - [clang-tidy] Updated docs.

[Alexander Kornienko via cfe-commits]

Author: alexfh
Date: Tue Sep  8 04:44:04 2015
New Revision: 246996

URL: http://llvm.org/viewvc/llvm-project?rev=246996&view=rev
Log:
[clang-tidy] Updated docs.

Added:

clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-replace-auto-ptr.rst
clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-use-auto.rst
Modified:
clang-tools-extra/trunk/clang-tidy/modernize/ReplaceAutoPtrCheck.h
clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst

Modified: clang-tools-extra/trunk/clang-tidy/modernize/ReplaceAutoPtrCheck.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/modernize/ReplaceAutoPtrCheck.h?rev=246996&r1=246995&r2=246996&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/modernize/ReplaceAutoPtrCheck.h 
(original)
+++ clang-tools-extra/trunk/clang-tidy/modernize/ReplaceAutoPtrCheck.h Tue Sep  
8 04:44:04 2015
@@ -17,24 +17,26 @@ namespace clang {
 namespace tidy {
 namespace modernize {
 
-/// \brief Transforms the deprecated \c std::auto_ptr into the C++11 \c
-/// std::unique_ptr.
+/// Transforms the deprecated `std::auto_ptr` into the C++11 `std::unique_ptr`.
 ///
-/// Note that both the \c std::auto_ptr type and the transfer of ownership are
-/// transformed. \c std::auto_ptr provides two ways to transfer the ownership,
+/// Note that both the `std::auto_ptr` type and the transfer of ownership are
+/// transformed. `std::auto_ptr` provides two ways to transfer the ownership,
 /// the copy-constructor and the assignment operator. Unlike most classes these
 /// operations do not 'copy' the resource but they 'steal' it.
-/// \c std::unique_ptr uses move semantics instead, which makes the intent of
+/// `std::unique_ptr` uses move semantics instead, which makes the intent of
 /// transferring the resource explicit. This difference between the two smart
 /// pointers requeres to wrap the copy-ctor and assign-operator with
-/// \c std::move().
+/// `std::move()`.
 ///
 /// For example, given:
+///
 /// \code
 ///   std::auto_ptr i, j;
 ///   i = j;
 /// \endcode
+///
 /// This code is transformed to:
+///
 /// \code
 ///   std::unique_ptr i, j;
 ///   i = std::move(j);

Modified: clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst?rev=246996&r1=246995&r2=246996&view=diff
==
--- clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst (original)
+++ clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst Tue Sep  8 04:44:04 
2015
@@ -40,7 +40,9 @@ List of clang-tidy Checks
misc-unused-raii
modernize-loop-convert
modernize-pass-by-value
+   modernize-replace-auto-ptr
modernize-shrink-to-fit
+   modernize-use-auto
modernize-use-nullptr
modernize-use-override
readability-braces-around-statements
@@ -51,4 +53,4 @@ List of clang-tidy Checks
readability-named-parameter
readability-redundant-smartptr-get
readability-redundant-string-cstr
-   readability-simplify-boolean-expr
+   readability-simplify-boolean-expr
\ No newline at end of file

Added: 
clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-replace-auto-ptr.rst
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-replace-auto-ptr.rst?rev=246996&view=auto
==
--- 
clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-replace-auto-ptr.rst 
(added)
+++ 
clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-replace-auto-ptr.rst 
Tue Sep  8 04:44:04 2015
@@ -0,0 +1,29 @@
+modernize-replace-auto-ptr
+==
+
+
+Transforms the deprecated ``std::auto_ptr`` into the C++11 ``std::unique_ptr``.
+
+Note that both the ``std::auto_ptr`` type and the transfer of ownership are
+transformed. ``std::auto_ptr`` provides two ways to transfer the ownership,
+the copy-constructor and the assignment operator. Unlike most classes these
+operations do not 'copy' the resource but they 'steal' it.
+``std::unique_ptr`` uses move semantics instead, which makes the intent of
+transferring the resource explicit. This difference between the two smart
+pointers requeres to wrap the copy-ctor and assign-operator with
+``std::move()``.
+
+For example, given:
+
+.. code:: c++
+
+  std::auto_ptr i, j;
+  i = j;
+
+This code is transformed to:
+
+.. code:: c++
+
+  std::unique_ptr i, j;
+  i = std::move(j);
+

Added: clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-use-auto.rst
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-use-auto.rst?rev=246996&view=auto
==
--- clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-use-auto.rst 
(added)
+++ clang-tools-extra/trunk

[PATCH] D12689: [libc++][static linking] std streams are not initialized prior to their use in static object constructors

[Evgeny Astigeevich via cfe-commits]

eastig created this revision.
eastig added a subscriber: cfe-commits.

When an executable (e.g. for bare metal environment) is statically linked  with 
libc++ the following code might not work as expected:

```
#include 
 
class Foo {
public:
  Foo(int n) {
std::cout << "Hello World - " << n << std::endl;
  }
};
 
Foo f(5);
 
int main() {
  return 0;
}
```
The program hangs or crashes because 'std::cout' is not initialized before 'Foo 
f(5)'.

The standard says:

> 27.3 Standard iostream objects
> Header  synopsis
> (2) ... The objects are constructed, and the associations are established at 
> some time prior to or during first 
> time an object of class basic_ios::Init is constructed, and in 
> any case before the body of main
> begins execution [264]. The objects are not destroyed during program 
> execution [265].
> 

And footnote 265 says:

> Constructors and destructors for static objects can access these objects to 
> read input from stdin or write output
> to stdout or stderr.

The similar issue was raised more than year ago. A patch was proposed but not 
committed. See discussion of it here:

[[ 
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130304/075363.html 
| initial patch ]]
[[ 
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130325/077130.html 
| review, suggestion for #ifdef ]]

The proposed patch caused initialization/deinitialization of the std streams as 
many times as the static Init objects were created.
The current patch fixes this issue. A number of uses is counted by means of 
__shared_count. It is used instead of a 'int' variable because it is 
thread-safe. The standard allows multi-threaded initialization of static 
objects from different compilation modules.

 

http://reviews.llvm.org/D12689

Files:
  include/ios
  src/iostream.cpp

Index: src/iostream.cpp
===
--- src/iostream.cpp
+++ src/iostream.cpp
@@ -10,6 +10,8 @@
 #include "__std_stream"
 #include "string"
 #include "new"
+#include "cassert"
+#include "memory"
 
 _LIBCPP_BEGIN_NAMESPACE_STD
 
@@ -41,9 +43,7 @@
 _ALIGNAS_TYPE (ostream)  _LIBCPP_FUNC_VIS char clog[sizeof(ostream)];
 _ALIGNAS_TYPE (wostream) _LIBCPP_FUNC_VIS char wclog[sizeof(wostream)];
 
-ios_base::Init __start_std_streams;
-
-ios_base::Init::Init()
+static void init_std_streams()
 {
 #ifndef _LIBCPP_HAS_NO_STDIN
 istream* cin_ptr  = ::new(cin)  istream(::new(__cin)  __stdinbuf (stdin, &mb_cin));
@@ -70,7 +70,7 @@
 #endif
 }
 
-ios_base::Init::~Init()
+static void fini_std_streams()
 {
 #ifndef _LIBCPP_HAS_NO_STDOUT
 ostream* cout_ptr = reinterpret_cast(cout);
@@ -85,4 +85,51 @@
 wclog_ptr->flush();
 }
 
+/// __Init is a utility class that counts the number of ios_base::Init
+/// objects. It automatically deinitializes the std streams when the
+/// last ios_base::Init object is destroyed.
+class __Init: public __shared_count {
+private:
+  void __on_zero_shared() _NOEXCEPT {
+fini_std_streams();
+  }
+public:
+  __Init(long count = 0): __shared_count(count) {
+init_std_streams();
+  }
+};
+
+_ALIGNAS_TYPE (__Init) _LIBCPP_FUNC_VIS static char __init_storage[sizeof(__Init)];
+
+__shared_count *ios_base::Init::UseCount = nullptr;
+
+ios_base::Init::Init()
+{
+  //local static object is initialized only once
+  struct __S {
+__S() {
+  Init::UseCount = ::new(__init_storage) __Init(-1);
+}
+  };
+  static __S __s;
+  UseCount->__add_shared();
+}
+
+ios_base::Init::~Init()
+{
+  assert(UseCount);
+  UseCount->__release_shared();
+}
+
+#ifdef __APPLE__
+// Apple linker has a guarantee for an initialization order:
+// if A links against B, B's initializer will be run before A's.
+// I.e. if you link to libc++.dylib, then cout et al. are guaranteed
+// to be constructed before your initializers run. This way, initialization
+// of __start_std_streams might remain here in module initializer
+// Without Apple linker, the following definition must be in header ,
+// so its initialization will be explicitly executed before any stream usage.
+ios_base::Init __start_std_streams;
+#endif
+
 _LIBCPP_END_NAMESPACE_STD
Index: include/ios
===
--- include/ios
+++ include/ios
@@ -423,13 +423,30 @@
 virtual ~failure() throw();
 };
 
+class __shared_count;
+
 class _LIBCPP_TYPE_VIS ios_base::Init
 {
+private:
+static __shared_count *UseCount;
 public:
 Init();
 ~Init();
 };
 
+#ifndef __APPLE__
+// Apple linker has a guarantee for an initialization order:
+// if A links against B, B's initializer will be run before A's.
+// I.e. if you link to libc++.dylib, then cout et al. are guaranteed
+// to be constructed before your initializers run. This way, definition
+// of __start_std_streams might remain in src/iostream.cpp, and linker arranges
+// its initialization before any stream usage.
+// Without Apple linker, that definition must be here,
+// so its initialization will be 

r246998 - Fix documentation of numSelectorArgs.

[Manuel Klimek via cfe-commits]

Author: klimek
Date: Tue Sep  8 05:11:26 2015
New Revision: 246998

URL: http://llvm.org/viewvc/llvm-project?rev=246998&view=rev
Log:
Fix documentation of numSelectorArgs.

Currently, the documentation for numSelectorArgs includes an incorrect
example. It shows a case where an argument of 1 will match a property
getter, but a getter will be matched only when N == 0.

This diff corrects the documentation and adds a test for numSelectorArgs(0).

Patch by Dave Lee.

Modified:
cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp

Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h?rev=246998&r1=246997&r2=246998&view=diff
==
--- cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h (original)
+++ cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h Tue Sep  8 05:11:26 2015
@@ -2151,7 +2151,7 @@ AST_MATCHER(ObjCMessageExpr, hasKeywordS
 
 /// \brief Matches when the selector has the specified number of arguments
 ///
-///  matcher = objCMessageExpr(numSelectorArgs(1));
+///  matcher = objCMessageExpr(numSelectorArgs(0));
 ///  matches self.bodyView in the code below
 ///
 ///  matcher = objCMessageExpr(numSelectorArgs(2));

Modified: cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp?rev=246998&r1=246997&r2=246998&view=diff
==
--- cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp (original)
+++ cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp Tue Sep  8 05:11:26 2015
@@ -4890,6 +4890,9 @@ TEST(ObjCMessageExprMatcher, SimpleExprs
   objcMessageExpr(hasSelector("contents"), hasUnarySelector(;
   EXPECT_TRUE(matchesObjC(
   Objc1String,
+  objcMessageExpr(hasSelector("contents"), numSelectorArgs(0;
+  EXPECT_TRUE(matchesObjC(
+  Objc1String,
   objcMessageExpr(matchesSelector("uppercase*"),
   argumentCountIs(0)
   )));


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

Re: [PATCH] D12471: Correct documentation for numSelectorArgs matcher

[Manuel Klimek via cfe-commits]

klimek accepted this revision.
klimek added a reviewer: klimek.
klimek added a comment.
This revision is now accepted and ready to land.

LG, as this is a documentation change that looks about right, and comes with 
tests, and the original author doesn't jump in.


http://reviews.llvm.org/D12471



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

Re: [PATCH] D12471: Correct documentation for numSelectorArgs matcher

[Manuel Klimek via cfe-commits]

klimek closed this revision.
klimek added a comment.

Committed as r246998.


http://reviews.llvm.org/D12471



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

r247001 - Update code owners for AST matchers / libtooling.

[Manuel Klimek via cfe-commits]

Author: klimek
Date: Tue Sep  8 05:31:09 2015
New Revision: 247001

URL: http://llvm.org/viewvc/llvm-project?rev=247001&view=rev
Log:
Update code owners for AST matchers / libtooling.

Modified:
cfe/trunk/CODE_OWNERS.TXT

Modified: cfe/trunk/CODE_OWNERS.TXT
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/CODE_OWNERS.TXT?rev=247001&r1=247000&r2=247001&view=diff
==
--- cfe/trunk/CODE_OWNERS.TXT (original)
+++ cfe/trunk/CODE_OWNERS.TXT Tue Sep  8 05:31:09 2015
@@ -33,6 +33,10 @@ N: Reid Kleckner
 E: r...@google.com
 D: Microsoft C++ ABI compatibility and general Windows support
 
+N: Manuel Klimek
+E: kli...@google.com
+D: AST matchers, LibTooling
+
 N: Anton Korobeynikov
 E: an...@korobeynikov.info
 D: Exception handling, Windows codegen, ARM EABI


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

[clang-tools-extra] r247002 - [clang-tidy] Fix run-clang-tidy.py.

[Alexander Kornienko via cfe-commits]

Author: alexfh
Date: Tue Sep  8 05:31:36 2015
New Revision: 247002

URL: http://llvm.org/viewvc/llvm-project?rev=247002&view=rev
Log:
[clang-tidy] Fix run-clang-tidy.py.

Do not add "-*" to the list of checks. Make consistent the list of enabled
checks and the checks in use. Moreover, removing "-*" makes the behaviour
consistent with clang-tidy and allows user to use .clang-tidy configuration...

http://reviews.llvm.org/D12687

Patch by Marek Kurdej!


Modified:
clang-tools-extra/trunk/clang-tidy/tool/run-clang-tidy.py

Modified: clang-tools-extra/trunk/clang-tidy/tool/run-clang-tidy.py
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/tool/run-clang-tidy.py?rev=247002&r1=247001&r2=247002&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/tool/run-clang-tidy.py (original)
+++ clang-tools-extra/trunk/clang-tidy/tool/run-clang-tidy.py Tue Sep  8 
05:31:36 2015
@@ -68,7 +68,7 @@ def get_tidy_invocation(f, clang_tidy_bi
 # Show warnings in all in-project headers by default.
 start.append('-header-filter=^' + build_path + '/.*')
   if checks:
-start.append('-checks=-*,' + checks)
+start.append('-checks=' + checks)
   if tmpdir is not None:
 start.append('-export-fixes')
 # Get a temporary file. We immediately close the handle so clang-tidy can
@@ -133,7 +133,7 @@ def main():
   try:
 invocation = [args.clang_tidy_binary, '-list-checks']
 if args.checks:
-  invocation.append('-checks='+args.checks)
+  invocation.append('-checks=' + args.checks)
 invocation.append('-')
 print subprocess.check_output(invocation)
   except:


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

Re: [PATCH] D12400: Fix store detection for return value in CGCall

[Jakub Kuderski via cfe-commits]

kuhar updated this revision to Diff 34206.
kuhar added a comment.

Merge with the latest changes to CGCall.cpp


Repository:
  rL LLVM

http://reviews.llvm.org/D12400

Files:
  lib/CodeGen/CGCall.cpp
  test/CodeGen/arm_function_epilog.cpp

Index: test/CodeGen/arm_function_epilog.cpp
===
--- /dev/null
+++ test/CodeGen/arm_function_epilog.cpp
@@ -0,0 +1,17 @@
+// REQUIRES: arm-registered-target
+// RUN: %clang_cc1 -triple armv7-none-linux-androideabi -target-abi 
aapcs-linux -mfloat-abi hard -x c++ -emit-llvm %s -o - | FileCheck %s
+
+struct Vec2 {
+union { struct { float x, y; };
+float data[2];
+};
+};
+
+// CHECK: define arm_aapcs_vfpcc %struct.Vec2 @_Z7getVec2v()
+// CHECK: ret %struct.Vec2
+Vec2 getVec2() {
+Vec2 out;
+union { Vec2* v; unsigned char* u; } x;
+x.v = &out;
+return out;
+}
Index: lib/CodeGen/CGCall.cpp
===
--- lib/CodeGen/CGCall.cpp
+++ lib/CodeGen/CGCall.cpp
@@ -2259,6 +2259,18 @@
 
 /// Heuristically search for a dominating store to the return-value slot.
 static llvm::StoreInst *findDominatingStoreToReturnValue(CodeGenFunction &CGF) 
{
+  // Check if a User is a store which pointerOperand is the ReturnValue.
+  // We are looking for stores to the ReturnValue, not for stores of the
+  // ReturnValue to some other location.
+  auto GetStoreIfValid = [&CGF](llvm::User *U) -> llvm::StoreInst * {
+auto *SI = dyn_cast(U);
+if (!SI || SI->getPointerOperand() != CGF.ReturnValue.getPointer())
+  return nullptr;
+// These aren't actually possible for non-coerced returns, and we
+// only care about non-coerced returns on this code path.
+assert(!SI->isAtomic() && !SI->isVolatile());
+return SI;
+  };
   // If there are multiple uses of the return-value slot, just check
   // for something immediately preceding the IP.  Sometimes this can
   // happen with how we generate implicit-returns; it can also happen
@@ -2287,22 +2299,13 @@
   break;
 }
 
-llvm::StoreInst *store = dyn_cast(I);
-if (!store) return nullptr;
-if (store->getPointerOperand() != CGF.ReturnValue.getPointer())
-  return nullptr;
-assert(!store->isAtomic() && !store->isVolatile()); // see below
-return store;
+return GetStoreIfValid(I);
   }
 
   llvm::StoreInst *store =
-dyn_cast(CGF.ReturnValue.getPointer()->user_back());
+  GetStoreIfValid(CGF.ReturnValue.getPointer()->user_back());
   if (!store) return nullptr;
 
-  // These aren't actually possible for non-coerced returns, and we
-  // only care about non-coerced returns on this code path.
-  assert(!store->isAtomic() && !store->isVolatile());
-
   // Now do a first-and-dirty dominance check: just walk up the
   // single-predecessors chain from the current insertion point.
   llvm::BasicBlock *StoreBB = store->getParent();


Index: test/CodeGen/arm_function_epilog.cpp
===
--- /dev/null
+++ test/CodeGen/arm_function_epilog.cpp
@@ -0,0 +1,17 @@
+// REQUIRES: arm-registered-target
+// RUN: %clang_cc1 -triple armv7-none-linux-androideabi -target-abi aapcs-linux -mfloat-abi hard -x c++ -emit-llvm %s -o - | FileCheck %s
+
+struct Vec2 {
+union { struct { float x, y; };
+float data[2];
+};
+};
+
+// CHECK: define arm_aapcs_vfpcc %struct.Vec2 @_Z7getVec2v()
+// CHECK: ret %struct.Vec2
+Vec2 getVec2() {
+Vec2 out;
+union { Vec2* v; unsigned char* u; } x;
+x.v = &out;
+return out;
+}
Index: lib/CodeGen/CGCall.cpp
===
--- lib/CodeGen/CGCall.cpp
+++ lib/CodeGen/CGCall.cpp
@@ -2259,6 +2259,18 @@
 
 /// Heuristically search for a dominating store to the return-value slot.
 static llvm::StoreInst *findDominatingStoreToReturnValue(CodeGenFunction &CGF) {
+  // Check if a User is a store which pointerOperand is the ReturnValue.
+  // We are looking for stores to the ReturnValue, not for stores of the
+  // ReturnValue to some other location.
+  auto GetStoreIfValid = [&CGF](llvm::User *U) -> llvm::StoreInst * {
+auto *SI = dyn_cast(U);
+if (!SI || SI->getPointerOperand() != CGF.ReturnValue.getPointer())
+  return nullptr;
+// These aren't actually possible for non-coerced returns, and we
+// only care about non-coerced returns on this code path.
+assert(!SI->isAtomic() && !SI->isVolatile());
+return SI;
+  };
   // If there are multiple uses of the return-value slot, just check
   // for something immediately preceding the IP.  Sometimes this can
   // happen with how we generate implicit-returns; it can also happen
@@ -2287,22 +2299,13 @@
   break;
 }
 
-llvm::StoreInst *store = dyn_cast(I);
-if (!store) return nullptr;
-if (store->getPointerOperand() != CGF.ReturnValue.getPointer())
-  return nullptr;
-assert(!store->isAtomic() && !store->isVo

r247003 - findDominatingStoreToReturn in CGCall.cpp didn't check if a candidate store

[Jakub Kuderski via cfe-commits]

Author: kuhar
Date: Tue Sep  8 05:36:42 2015
New Revision: 247003

URL: http://llvm.org/viewvc/llvm-project?rev=247003&view=rev
Log:
findDominatingStoreToReturn in CGCall.cpp didn't check if a candidate store
instruction used the ReturnValue as pointer operand or value operand. This
led to wrong code gen - in later stages (load-store elision code) the found
store and its operand would be erased, causing ReturnValue to become a .

The patch adds a check that makes sure that ReturnValue is a pointer operand of
store instruction. Regression test is also added.

This fixes PR24386.
Differential Revision: http://reviews.llvm.org/D12400

Added:
cfe/trunk/test/CodeGen/arm_function_epilog.cpp
Modified:
cfe/trunk/lib/CodeGen/CGCall.cpp

Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=247003&r1=247002&r2=247003&view=diff
==
--- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCall.cpp Tue Sep  8 05:36:42 2015
@@ -2259,6 +2259,18 @@ static llvm::Value *emitAutoreleaseOfRes
 
 /// Heuristically search for a dominating store to the return-value slot.
 static llvm::StoreInst *findDominatingStoreToReturnValue(CodeGenFunction &CGF) 
{
+  // Check if a User is a store which pointerOperand is the ReturnValue.
+  // We are looking for stores to the ReturnValue, not for stores of the
+  // ReturnValue to some other location.
+  auto GetStoreIfValid = [&CGF](llvm::User *U) -> llvm::StoreInst * {
+auto *SI = dyn_cast(U);
+if (!SI || SI->getPointerOperand() != CGF.ReturnValue.getPointer())
+  return nullptr;
+// These aren't actually possible for non-coerced returns, and we
+// only care about non-coerced returns on this code path.
+assert(!SI->isAtomic() && !SI->isVolatile());
+return SI;
+  };
   // If there are multiple uses of the return-value slot, just check
   // for something immediately preceding the IP.  Sometimes this can
   // happen with how we generate implicit-returns; it can also happen
@@ -2287,22 +2299,13 @@ static llvm::StoreInst *findDominatingSt
   break;
 }
 
-llvm::StoreInst *store = dyn_cast(I);
-if (!store) return nullptr;
-if (store->getPointerOperand() != CGF.ReturnValue.getPointer())
-  return nullptr;
-assert(!store->isAtomic() && !store->isVolatile()); // see below
-return store;
+return GetStoreIfValid(I);
   }
 
   llvm::StoreInst *store =
-dyn_cast(CGF.ReturnValue.getPointer()->user_back());
+  GetStoreIfValid(CGF.ReturnValue.getPointer()->user_back());
   if (!store) return nullptr;
 
-  // These aren't actually possible for non-coerced returns, and we
-  // only care about non-coerced returns on this code path.
-  assert(!store->isAtomic() && !store->isVolatile());
-
   // Now do a first-and-dirty dominance check: just walk up the
   // single-predecessors chain from the current insertion point.
   llvm::BasicBlock *StoreBB = store->getParent();

Added: cfe/trunk/test/CodeGen/arm_function_epilog.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/arm_function_epilog.cpp?rev=247003&view=auto
==
--- cfe/trunk/test/CodeGen/arm_function_epilog.cpp (added)
+++ cfe/trunk/test/CodeGen/arm_function_epilog.cpp Tue Sep  8 05:36:42 2015
@@ -0,0 +1,17 @@
+// REQUIRES: arm-registered-target
+// RUN: %clang_cc1 -triple armv7-none-linux-androideabi -target-abi 
aapcs-linux -mfloat-abi hard -x c++ -emit-llvm %s -o - | FileCheck %s
+
+struct Vec2 {
+union { struct { float x, y; };
+float data[2];
+};
+};
+
+// CHECK: define arm_aapcs_vfpcc %struct.Vec2 @_Z7getVec2v()
+// CHECK: ret %struct.Vec2
+Vec2 getVec2() {
+Vec2 out;
+union { Vec2* v; unsigned char* u; } x;
+x.v = &out;
+return out;
+}


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

Re: [PATCH] D12400: Fix store detection for return value in CGCall

[Jakub Kuderski via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL247003: findDominatingStoreToReturn in CGCall.cpp didn't 
check if a candidate store (authored by kuhar).

Changed prior to commit:
  http://reviews.llvm.org/D12400?vs=34206&id=34207#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D12400

Files:
  cfe/trunk/lib/CodeGen/CGCall.cpp
  cfe/trunk/test/CodeGen/arm_function_epilog.cpp

Index: cfe/trunk/test/CodeGen/arm_function_epilog.cpp
===
--- cfe/trunk/test/CodeGen/arm_function_epilog.cpp
+++ cfe/trunk/test/CodeGen/arm_function_epilog.cpp
@@ -0,0 +1,17 @@
+// REQUIRES: arm-registered-target
+// RUN: %clang_cc1 -triple armv7-none-linux-androideabi -target-abi 
aapcs-linux -mfloat-abi hard -x c++ -emit-llvm %s -o - | FileCheck %s
+
+struct Vec2 {
+union { struct { float x, y; };
+float data[2];
+};
+};
+
+// CHECK: define arm_aapcs_vfpcc %struct.Vec2 @_Z7getVec2v()
+// CHECK: ret %struct.Vec2
+Vec2 getVec2() {
+Vec2 out;
+union { Vec2* v; unsigned char* u; } x;
+x.v = &out;
+return out;
+}
Index: cfe/trunk/lib/CodeGen/CGCall.cpp
===
--- cfe/trunk/lib/CodeGen/CGCall.cpp
+++ cfe/trunk/lib/CodeGen/CGCall.cpp
@@ -2259,6 +2259,18 @@
 
 /// Heuristically search for a dominating store to the return-value slot.
 static llvm::StoreInst *findDominatingStoreToReturnValue(CodeGenFunction &CGF) 
{
+  // Check if a User is a store which pointerOperand is the ReturnValue.
+  // We are looking for stores to the ReturnValue, not for stores of the
+  // ReturnValue to some other location.
+  auto GetStoreIfValid = [&CGF](llvm::User *U) -> llvm::StoreInst * {
+auto *SI = dyn_cast(U);
+if (!SI || SI->getPointerOperand() != CGF.ReturnValue.getPointer())
+  return nullptr;
+// These aren't actually possible for non-coerced returns, and we
+// only care about non-coerced returns on this code path.
+assert(!SI->isAtomic() && !SI->isVolatile());
+return SI;
+  };
   // If there are multiple uses of the return-value slot, just check
   // for something immediately preceding the IP.  Sometimes this can
   // happen with how we generate implicit-returns; it can also happen
@@ -2287,22 +2299,13 @@
   break;
 }
 
-llvm::StoreInst *store = dyn_cast(I);
-if (!store) return nullptr;
-if (store->getPointerOperand() != CGF.ReturnValue.getPointer())
-  return nullptr;
-assert(!store->isAtomic() && !store->isVolatile()); // see below
-return store;
+return GetStoreIfValid(I);
   }
 
   llvm::StoreInst *store =
-dyn_cast(CGF.ReturnValue.getPointer()->user_back());
+  GetStoreIfValid(CGF.ReturnValue.getPointer()->user_back());
   if (!store) return nullptr;
 
-  // These aren't actually possible for non-coerced returns, and we
-  // only care about non-coerced returns on this code path.
-  assert(!store->isAtomic() && !store->isVolatile());
-
   // Now do a first-and-dirty dominance check: just walk up the
   // single-predecessors chain from the current insertion point.
   llvm::BasicBlock *StoreBB = store->getParent();


Index: cfe/trunk/test/CodeGen/arm_function_epilog.cpp
===
--- cfe/trunk/test/CodeGen/arm_function_epilog.cpp
+++ cfe/trunk/test/CodeGen/arm_function_epilog.cpp
@@ -0,0 +1,17 @@
+// REQUIRES: arm-registered-target
+// RUN: %clang_cc1 -triple armv7-none-linux-androideabi -target-abi aapcs-linux -mfloat-abi hard -x c++ -emit-llvm %s -o - | FileCheck %s
+
+struct Vec2 {
+union { struct { float x, y; };
+float data[2];
+};
+};
+
+// CHECK: define arm_aapcs_vfpcc %struct.Vec2 @_Z7getVec2v()
+// CHECK: ret %struct.Vec2
+Vec2 getVec2() {
+Vec2 out;
+union { Vec2* v; unsigned char* u; } x;
+x.v = &out;
+return out;
+}
Index: cfe/trunk/lib/CodeGen/CGCall.cpp
===
--- cfe/trunk/lib/CodeGen/CGCall.cpp
+++ cfe/trunk/lib/CodeGen/CGCall.cpp
@@ -2259,6 +2259,18 @@
 
 /// Heuristically search for a dominating store to the return-value slot.
 static llvm::StoreInst *findDominatingStoreToReturnValue(CodeGenFunction &CGF) {
+  // Check if a User is a store which pointerOperand is the ReturnValue.
+  // We are looking for stores to the ReturnValue, not for stores of the
+  // ReturnValue to some other location.
+  auto GetStoreIfValid = [&CGF](llvm::User *U) -> llvm::StoreInst * {
+auto *SI = dyn_cast(U);
+if (!SI || SI->getPointerOperand() != CGF.ReturnValue.getPointer())
+  return nullptr;
+// These aren't actually possible for non-coerced returns, and we
+// only care about non-coerced returns on this code path.
+assert(!SI->isAtomic() && !SI->isVolatile());
+return SI;
+  };
   // If there are multiple uses of the return-value slot, just check
   // for something immediately precedin

Re: [PATCH] D12369: [clang-format] Fix alignConsecutiveAssignments not working properly

[Matt Oakes via cfe-commits]

matto1990 accepted this revision.
matto1990 added a comment.
This revision is now accepted and ready to land.

Looks good to me now!


http://reviews.llvm.org/D12369



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

Re: [PATCH][Solaris] Default to -fno-cxa-finalize

[Joerg Sonnenberger via cfe-commits]

On Fri, Aug 28, 2015 at 07:52:17PM +0200, Xan López via cfe-commits wrote:
> There is no __cxa_finalize symbol available on recent Solaris OS
> versions, so we need this flag to make non trivial C++ programs run.

What do you consider as recent Solaris? When I asked, I've been told
that Illumos has been providing __cxa_atexit since 2013. As such,
disabling it for the Solaris family by default seems just wrong.

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

Re: [PATCH] D12644: Using -isysroot on Apple platform

[Joerg Sonnenberger via cfe-commits]

On Mon, Sep 07, 2015 at 11:50:55PM +, Eric Fiselier via cfe-commits wrote:
> EricWF added a comment.
> 
> Why would we not use "-isysroot" on other platforms as well?

Because otherwise you can't link in a cross-compiling setup?

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

Re: [PATCH] D12646: Add libc++ header path for DarwinClang builds

[Kuba Brecka via cfe-commits]

kubabrecka added a comment.

In what scenario exactly are you seeing an issue?  If it's a just-built clang 
that can't find C++ headers, then you should just build the libcxx project 
alongside.



Comment at: lib/Driver/ToolChains.cpp:290-295
@@ +289,8 @@
+
+  // FIXME: We should really let cmake find this path, e.g.,
+  // assuming we were compiled with clang:
+  // LIBCXX_INCLUDE_DIR=$(dirname $(dirname $(xcrun -f 
clang))..)/include/c++/v1
+  // libc++ installed along side clang
+  "/Applications/Xcode.app/Contents/Developer/Toolchains/"
+  "XcodeDefault.xctoolchain/usr/include/c++/v1"
+};

This is just a default location of Xcode.app and it's wrong to hardcode it, 
because the user can install Xcode to different locations (or have multiple 
installations).  Even letting CMake find the path will be wrong, because the 
location of Xcode is a user's choice.


http://reviews.llvm.org/D12646



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

Re: [PATCH][Solaris] Default to -fno-cxa-finalize

[Xan López via cfe-commits]

On Tue, Sep 08, 2015 at 01:09:02PM +0200, Joerg Sonnenberger via cfe-commits 
wrote:
> On Fri, Aug 28, 2015 at 07:52:17PM +0200, Xan López via cfe-commits wrote:
> > There is no __cxa_finalize symbol available on recent Solaris OS
> > versions, so we need this flag to make non trivial C++ programs run.
> 
> What do you consider as recent Solaris? When I asked, I've been told
> that Illumos has been providing __cxa_atexit since 2013. As such,
> disabling it for the Solaris family by default seems just wrong.

Solaris 11.2, which is the latest non-beta version available.

I found some patches for OpenSolaris from 2013 creating dummy versions
of cxa_finalize.o, but did not seem like that could possibly work. In
any case clang for Solaris has never really worked upstream, the code
before my recent patches was completely hardcoded for a Solaris/x86
version from 2012 with a very specific GCC version, it could not work
anywhere else. So I'm not sure that anyone at Illumos could have been
using upstream, maybe they have their own branch.

Where can I see the __cxa_atexit support in Illumos? If that works and
we can tell Solaris and Illumous apart maybe we can just disable this
for actual Solaris, but I won't be able to test that myself.

Xan

> 
> Joerg
> ___
> 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][Solaris] Default to -fno-cxa-finalize

[Xan López via cfe-commits]

On Tue, Sep 08, 2015 at 01:27:42PM +0200, Xan López via cfe-commits wrote:
> > What do you consider as recent Solaris? When I asked, I've been told
> > that Illumos has been providing __cxa_atexit since 2013. As such,
> > disabling it for the Solaris family by default seems just wrong.
> 
> Solaris 11.2, which is the latest non-beta version available.

(Also, if you read the entire thread you'll see we figured that symbol
was probably never available in Solaris, see the referenced commit
from 2013, so the bit about the version being "recent" is irrelevant
and it was removed from the final commit message)

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

Re: recordDecl() AST matcher

[Aaron Ballman via cfe-commits]

On Tue, Sep 8, 2015 at 5:40 AM, Manuel Klimek  wrote:
> Yea, we had that discussion a few times, and I can never remember why we
> ended up in the state we're in.
> We definitely had a time where we switched to just using the exact same name
> as the node's class name for the matchers.
> I *think* we didn't do it for cxxRecordDecl, because Richard said that's a
> relic we should get rid of anyway, but I'm not sure.

FWIW, I think the state we're in is the worst of all worlds. It's not
intuitive that recordDecl() doesn't match a struct in C mode, and as
it stands, there is no way to match a struct or union declaration in C
at all.

>
> On Fri, Sep 4, 2015 at 8:32 PM Aaron Ballman  wrote:
>>
>> It turns out that the recordDecl() AST matcher doesn't match
>> RecordDecl objects; instead, it matches CXXRecordDecl objects. This
>> is... unfortunate... as it makes writing AST matchers more complicated
>> because of having to translate between recordDecl()/CXXRecordDecl. It
>> also makes it impossible to match a struct or union declaration in C
>> or ObjC. However, given how prevalent recordDecl()'s use is in the
>> wild (I'm guessing), changing it at this point would be a Bad Thing.
>>
>> For people trying to write AST matchers for languages like C or ObjC,
>> I would like to propose adding:
>>
>> structDecl()
>> unionDecl()
>> tagDecl()
>>
>> These will match nicely with the existing enumDecl() AST matcher.
>>
>> Additionally, I would like to add cxxRecordDecl() to match
>> CXXRecordDecl objects. While it duplicates the functionality exposed
>> by recordDecl(), it more clearly matches the intention of which AST
>> node it corresponds to.
>>
>> Finally, I would like to undocument recordDecl() and change our
>> existing documentation and AST matcher uses to use
>> cxxRecordDecl/structDecl() instead. Maybe someday we can deprecate
>> recordDecl() more officially.
>>
>> I'm open to other ideas if there are better ways to move forward. If
>> you think changing the meaning of recordDecl() is acceptable, I can
>> also go that route (though I would still propose adding unionDecl()
>> and cxxRecordDecl() in that case).
>
>
> I think changing recordDecl is acceptable. I believe very few tools will
> actually start doing wrong things because of it. I'd like more opinions
> first, though :)

I was giving this more thought over the long weekend, and I think you
may be right. I think changing recordDecl() to mean RecordDecl will
fix more code than it breaks, so long as we take a holistic approach
to the change and see which narrowing and traversal matchers we need
to fix up at the same time. When I tried to think of AST matchers that
mean CXXRecordDecl but *not* RecordDecl, they were horribly contrived
because you usually are matching on additional selection criteria that
is specific to C++ (such as hasMethod() or isDerivedFrom()) which
would cause the match to continue to fail, as expected. Code that uses
recordDecl() to mean RecordDecl will suddenly start to match in more
cases, but that's likely to be a bug fix more than a breaking change.
To the best of my understanding, the only breaking cases would be
where you wrote recordDecl(), meant CXXRecordDecl, had no further
narrowing or traversal matchers, and were compiling in C mode; with
the result being additional unexpected matches.

So perhaps it would make sense to:

1) Make recordDecl() mean RecordDecl
2) Do a comprehensive review of matchers that take a CXXRecordDecl and
see if they should instead take a RecordDecl
3) Add unionDecl() as a node matcher (or should we add isUnion() and
isStruct() as narrowing matchers?)
4) Add tagDecl() as a node matcher, but not add cxxRecordDecl()

~Aaron

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

[clang-tools-extra] r247007 - Add a redirection page to unbreak external links.

[Alexander Kornienko via cfe-commits]

Author: alexfh
Date: Tue Sep  8 07:26:32 2015
New Revision: 247007

URL: http://llvm.org/viewvc/llvm-project?rev=247007&view=rev
Log:
Add a redirection page to unbreak external links.

Apparently, there are some links to http://clang.llvm.org/extra/clang-tidy.html
in the wild. It's better to keep them working.

Added:
clang-tools-extra/trunk/docs/clang-tidy.rst

Added: clang-tools-extra/trunk/docs/clang-tidy.rst
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/docs/clang-tidy.rst?rev=247007&view=auto
==
--- clang-tools-extra/trunk/docs/clang-tidy.rst (added)
+++ clang-tools-extra/trunk/docs/clang-tidy.rst Tue Sep  8 07:26:32 2015
@@ -0,0 +1 @@
+clang-tidy documentation moved here: http://clang.llvm.org/extra/clang-tidy/


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

Re: [PATCH] D12646: Add libc++ header path for DarwinClang builds

[don hinton via cfe-commits]

hintonda added a comment.

In http://reviews.llvm.org/D12646#241308, @kubabrecka wrote:

> In what scenario exactly are you seeing an issue?  If it's a just-built clang 
> that can't find C++ headers, then you should just build the libcxx project 
> alongside.


clang++ defaults to -stdlib=libc++ for newer versions of MacOS (see 
ToolChains.cpp:902), but since there isn't a way to pass corresponding include 
path via cmake, clang++ doesn't work out of the box, i.e., it only checks 
/usr/include/c++/v1, not the path relative to the version of clang used to 
build it.

I first noticed it when I tried to run the version of clang-tidy I'd just built 
and found I had to pass the path for it to find iostream.

> This is just a default location of Xcode.app and it's wrong to hardcode it, 
> because the user can install Xcode to different locations (or have multiple 
> installations). Even letting CMake find the path will be wrong, because the 
> location of Xcode is a user's choice.


Yes, but if you allow the user to pass the include path via cmake, how could 
that be wrong?  This is equivalent to passing GCC_INSTALL_PREFIX so clang can 
find the gcc headers for libstdc++.

The user can always override it if they want to use a different version, but 
right now, overriding the location is the only way to make it work.  If we're 
not going to generate a working version using libc++, perhaps we shouldn't 
override -stdlib=libc++ unless the appropriate headers can't be found.


http://reviews.llvm.org/D12646



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

Re: recordDecl() AST matcher

[Manuel Klimek via cfe-commits]

On Tue, Sep 8, 2015 at 2:23 PM Aaron Ballman  wrote:

> On Tue, Sep 8, 2015 at 5:40 AM, Manuel Klimek  wrote:
> > Yea, we had that discussion a few times, and I can never remember why we
> > ended up in the state we're in.
> > We definitely had a time where we switched to just using the exact same
> name
> > as the node's class name for the matchers.
> > I *think* we didn't do it for cxxRecordDecl, because Richard said that's
> a
> > relic we should get rid of anyway, but I'm not sure.
>
> FWIW, I think the state we're in is the worst of all worlds. It's not
> intuitive that recordDecl() doesn't match a struct in C mode, and as
> it stands, there is no way to match a struct or union declaration in C
> at all.
>

Agreed. Best intentions. Worst possible outcome. That's software
development :)

>
> > On Fri, Sep 4, 2015 at 8:32 PM Aaron Ballman 
> wrote:
> >>
> >> It turns out that the recordDecl() AST matcher doesn't match
> >> RecordDecl objects; instead, it matches CXXRecordDecl objects. This
> >> is... unfortunate... as it makes writing AST matchers more complicated
> >> because of having to translate between recordDecl()/CXXRecordDecl. It
> >> also makes it impossible to match a struct or union declaration in C
> >> or ObjC. However, given how prevalent recordDecl()'s use is in the
> >> wild (I'm guessing), changing it at this point would be a Bad Thing.
> >>
> >> For people trying to write AST matchers for languages like C or ObjC,
> >> I would like to propose adding:
> >>
> >> structDecl()
> >> unionDecl()
> >> tagDecl()
> >>
> >> These will match nicely with the existing enumDecl() AST matcher.
> >>
> >> Additionally, I would like to add cxxRecordDecl() to match
> >> CXXRecordDecl objects. While it duplicates the functionality exposed
> >> by recordDecl(), it more clearly matches the intention of which AST
> >> node it corresponds to.
> >>
> >> Finally, I would like to undocument recordDecl() and change our
> >> existing documentation and AST matcher uses to use
> >> cxxRecordDecl/structDecl() instead. Maybe someday we can deprecate
> >> recordDecl() more officially.
> >>
> >> I'm open to other ideas if there are better ways to move forward. If
> >> you think changing the meaning of recordDecl() is acceptable, I can
> >> also go that route (though I would still propose adding unionDecl()
> >> and cxxRecordDecl() in that case).
> >
> >
> > I think changing recordDecl is acceptable. I believe very few tools will
> > actually start doing wrong things because of it. I'd like more opinions
> > first, though :)
>
> I was giving this more thought over the long weekend, and I think you
> may be right. I think changing recordDecl() to mean RecordDecl will
> fix more code than it breaks, so long as we take a holistic approach
> to the change and see which narrowing and traversal matchers we need
> to fix up at the same time. When I tried to think of AST matchers that
> mean CXXRecordDecl but *not* RecordDecl, they were horribly contrived
> because you usually are matching on additional selection criteria that
> is specific to C++ (such as hasMethod() or isDerivedFrom()) which
> would cause the match to continue to fail, as expected. Code that uses
> recordDecl() to mean RecordDecl will suddenly start to match in more
> cases, but that's likely to be a bug fix more than a breaking change.
> To the best of my understanding, the only breaking cases would be
> where you wrote recordDecl(), meant CXXRecordDecl, had no further
> narrowing or traversal matchers, and were compiling in C mode; with
> the result being additional unexpected matches.
>

Ah, there's one thing that can break: the compile can break:
recordDecl(hasMethod(...)) will *not* compile (it'll work in the dynamic
matchers and fail as you suggest, but the in-C++ DSL does more static type
checking).
I don't think that's super bad though.


> So perhaps it would make sense to:
>
> 1) Make recordDecl() mean RecordDecl
> 2) Do a comprehensive review of matchers that take a CXXRecordDecl and
> see if they should instead take a RecordDecl
> 3) Add unionDecl() as a node matcher (or should we add isUnion() and
> isStruct() as narrowing matchers?)
> 4) Add tagDecl() as a node matcher, but not add cxxRecordDecl()
>

Why not add cxxRecordDecl()? I think we need it if we want narrowing
matchers on CXXRecordDecl?


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

Re: recordDecl() AST matcher

[Aaron Ballman via cfe-commits]

On Tue, Sep 8, 2015 at 9:18 AM, Manuel Klimek  wrote:
> On Tue, Sep 8, 2015 at 2:23 PM Aaron Ballman  wrote:
>>
>> On Tue, Sep 8, 2015 at 5:40 AM, Manuel Klimek  wrote:
>> > Yea, we had that discussion a few times, and I can never remember why we
>> > ended up in the state we're in.
>> > We definitely had a time where we switched to just using the exact same
>> > name
>> > as the node's class name for the matchers.
>> > I *think* we didn't do it for cxxRecordDecl, because Richard said that's
>> > a
>> > relic we should get rid of anyway, but I'm not sure.
>>
>> FWIW, I think the state we're in is the worst of all worlds. It's not
>> intuitive that recordDecl() doesn't match a struct in C mode, and as
>> it stands, there is no way to match a struct or union declaration in C
>> at all.
>
>
> Agreed. Best intentions. Worst possible outcome. That's software development
> :)
>
>> >
>> > On Fri, Sep 4, 2015 at 8:32 PM Aaron Ballman 
>> > wrote:
>> >>
>> >> It turns out that the recordDecl() AST matcher doesn't match
>> >> RecordDecl objects; instead, it matches CXXRecordDecl objects. This
>> >> is... unfortunate... as it makes writing AST matchers more complicated
>> >> because of having to translate between recordDecl()/CXXRecordDecl. It
>> >> also makes it impossible to match a struct or union declaration in C
>> >> or ObjC. However, given how prevalent recordDecl()'s use is in the
>> >> wild (I'm guessing), changing it at this point would be a Bad Thing.
>> >>
>> >> For people trying to write AST matchers for languages like C or ObjC,
>> >> I would like to propose adding:
>> >>
>> >> structDecl()
>> >> unionDecl()
>> >> tagDecl()
>> >>
>> >> These will match nicely with the existing enumDecl() AST matcher.
>> >>
>> >> Additionally, I would like to add cxxRecordDecl() to match
>> >> CXXRecordDecl objects. While it duplicates the functionality exposed
>> >> by recordDecl(), it more clearly matches the intention of which AST
>> >> node it corresponds to.
>> >>
>> >> Finally, I would like to undocument recordDecl() and change our
>> >> existing documentation and AST matcher uses to use
>> >> cxxRecordDecl/structDecl() instead. Maybe someday we can deprecate
>> >> recordDecl() more officially.
>> >>
>> >> I'm open to other ideas if there are better ways to move forward. If
>> >> you think changing the meaning of recordDecl() is acceptable, I can
>> >> also go that route (though I would still propose adding unionDecl()
>> >> and cxxRecordDecl() in that case).
>> >
>> >
>> > I think changing recordDecl is acceptable. I believe very few tools will
>> > actually start doing wrong things because of it. I'd like more opinions
>> > first, though :)
>>
>> I was giving this more thought over the long weekend, and I think you
>> may be right. I think changing recordDecl() to mean RecordDecl will
>> fix more code than it breaks, so long as we take a holistic approach
>> to the change and see which narrowing and traversal matchers we need
>> to fix up at the same time. When I tried to think of AST matchers that
>> mean CXXRecordDecl but *not* RecordDecl, they were horribly contrived
>> because you usually are matching on additional selection criteria that
>> is specific to C++ (such as hasMethod() or isDerivedFrom()) which
>> would cause the match to continue to fail, as expected. Code that uses
>> recordDecl() to mean RecordDecl will suddenly start to match in more
>> cases, but that's likely to be a bug fix more than a breaking change.
>> To the best of my understanding, the only breaking cases would be
>> where you wrote recordDecl(), meant CXXRecordDecl, had no further
>> narrowing or traversal matchers, and were compiling in C mode; with
>> the result being additional unexpected matches.
>
>
> Ah, there's one thing that can break: the compile can break:
> recordDecl(hasMethod(...)) will *not* compile (it'll work in the dynamic
> matchers and fail as you suggest, but the in-C++ DSL does more static type
> checking).
> I don't think that's super bad though.
>
>>
>> So perhaps it would make sense to:
>>
>> 1) Make recordDecl() mean RecordDecl
>> 2) Do a comprehensive review of matchers that take a CXXRecordDecl and
>> see if they should instead take a RecordDecl
>> 3) Add unionDecl() as a node matcher (or should we add isUnion() and
>> isStruct() as narrowing matchers?)
>> 4) Add tagDecl() as a node matcher, but not add cxxRecordDecl()
>
>
> Why not add cxxRecordDecl()? I think we need it if we want narrowing
> matchers on CXXRecordDecl?

If Richard thinks CXXRecordDecl is an anachronism, I figured we didn't
want to expose it. Instead, we could make hasMethod (et al) accept a
RecordDecl and do the type checking for the caller. Then
recordDecl(hasMethod(...)) continues to compile and work, and when
hasMethod is given a RecordDecl instead of a CXXRecordDecl, it simply
matches nothing. But you bring up a good point about the C++ DSL being
a problem still, I hadn't considered that.

~Aaron

>
>>
>>
>> ~Aaron
>>
>> >
>> >>
>> >>

Re: recordDecl() AST matcher

[Manuel Klimek via cfe-commits]

On Tue, Sep 8, 2015 at 3:23 PM Aaron Ballman  wrote:

> On Tue, Sep 8, 2015 at 9:18 AM, Manuel Klimek  wrote:
> > On Tue, Sep 8, 2015 at 2:23 PM Aaron Ballman 
> wrote:
> >>
> >> On Tue, Sep 8, 2015 at 5:40 AM, Manuel Klimek 
> wrote:
> >> > Yea, we had that discussion a few times, and I can never remember why
> we
> >> > ended up in the state we're in.
> >> > We definitely had a time where we switched to just using the exact
> same
> >> > name
> >> > as the node's class name for the matchers.
> >> > I *think* we didn't do it for cxxRecordDecl, because Richard said
> that's
> >> > a
> >> > relic we should get rid of anyway, but I'm not sure.
> >>
> >> FWIW, I think the state we're in is the worst of all worlds. It's not
> >> intuitive that recordDecl() doesn't match a struct in C mode, and as
> >> it stands, there is no way to match a struct or union declaration in C
> >> at all.
> >
> >
> > Agreed. Best intentions. Worst possible outcome. That's software
> development
> > :)
> >
> >> >
> >> > On Fri, Sep 4, 2015 at 8:32 PM Aaron Ballman 
> >> > wrote:
> >> >>
> >> >> It turns out that the recordDecl() AST matcher doesn't match
> >> >> RecordDecl objects; instead, it matches CXXRecordDecl objects. This
> >> >> is... unfortunate... as it makes writing AST matchers more
> complicated
> >> >> because of having to translate between recordDecl()/CXXRecordDecl. It
> >> >> also makes it impossible to match a struct or union declaration in C
> >> >> or ObjC. However, given how prevalent recordDecl()'s use is in the
> >> >> wild (I'm guessing), changing it at this point would be a Bad Thing.
> >> >>
> >> >> For people trying to write AST matchers for languages like C or ObjC,
> >> >> I would like to propose adding:
> >> >>
> >> >> structDecl()
> >> >> unionDecl()
> >> >> tagDecl()
> >> >>
> >> >> These will match nicely with the existing enumDecl() AST matcher.
> >> >>
> >> >> Additionally, I would like to add cxxRecordDecl() to match
> >> >> CXXRecordDecl objects. While it duplicates the functionality exposed
> >> >> by recordDecl(), it more clearly matches the intention of which AST
> >> >> node it corresponds to.
> >> >>
> >> >> Finally, I would like to undocument recordDecl() and change our
> >> >> existing documentation and AST matcher uses to use
> >> >> cxxRecordDecl/structDecl() instead. Maybe someday we can deprecate
> >> >> recordDecl() more officially.
> >> >>
> >> >> I'm open to other ideas if there are better ways to move forward. If
> >> >> you think changing the meaning of recordDecl() is acceptable, I can
> >> >> also go that route (though I would still propose adding unionDecl()
> >> >> and cxxRecordDecl() in that case).
> >> >
> >> >
> >> > I think changing recordDecl is acceptable. I believe very few tools
> will
> >> > actually start doing wrong things because of it. I'd like more
> opinions
> >> > first, though :)
> >>
> >> I was giving this more thought over the long weekend, and I think you
> >> may be right. I think changing recordDecl() to mean RecordDecl will
> >> fix more code than it breaks, so long as we take a holistic approach
> >> to the change and see which narrowing and traversal matchers we need
> >> to fix up at the same time. When I tried to think of AST matchers that
> >> mean CXXRecordDecl but *not* RecordDecl, they were horribly contrived
> >> because you usually are matching on additional selection criteria that
> >> is specific to C++ (such as hasMethod() or isDerivedFrom()) which
> >> would cause the match to continue to fail, as expected. Code that uses
> >> recordDecl() to mean RecordDecl will suddenly start to match in more
> >> cases, but that's likely to be a bug fix more than a breaking change.
> >> To the best of my understanding, the only breaking cases would be
> >> where you wrote recordDecl(), meant CXXRecordDecl, had no further
> >> narrowing or traversal matchers, and were compiling in C mode; with
> >> the result being additional unexpected matches.
> >
> >
> > Ah, there's one thing that can break: the compile can break:
> > recordDecl(hasMethod(...)) will *not* compile (it'll work in the dynamic
> > matchers and fail as you suggest, but the in-C++ DSL does more static
> type
> > checking).
> > I don't think that's super bad though.
> >
> >>
> >> So perhaps it would make sense to:
> >>
> >> 1) Make recordDecl() mean RecordDecl
> >> 2) Do a comprehensive review of matchers that take a CXXRecordDecl and
> >> see if they should instead take a RecordDecl
> >> 3) Add unionDecl() as a node matcher (or should we add isUnion() and
> >> isStruct() as narrowing matchers?)
> >> 4) Add tagDecl() as a node matcher, but not add cxxRecordDecl()
> >
> >
> > Why not add cxxRecordDecl()? I think we need it if we want narrowing
> > matchers on CXXRecordDecl?
>
> If Richard thinks CXXRecordDecl is an anachronism, I figured we didn't
> want to expose it. Instead, we could make hasMethod (et al) accept a
> RecordDecl and do the type checking for the caller. Then
> recordDecl(hasMe

Re: [PATCH][Solaris] Default to -fno-cxa-finalize

[Joerg Sonnenberger via cfe-commits]

On Tue, Sep 08, 2015 at 01:32:21PM +0200, Xan López via cfe-commits wrote:
> On Tue, Sep 08, 2015 at 01:27:42PM +0200, Xan López via cfe-commits wrote:
> > > What do you consider as recent Solaris? When I asked, I've been told
> > > that Illumos has been providing __cxa_atexit since 2013. As such,
> > > disabling it for the Solaris family by default seems just wrong.
> > 
> > Solaris 11.2, which is the latest non-beta version available.
> 
> (Also, if you read the entire thread you'll see we figured that symbol
> was probably never available in Solaris, see the referenced commit
> from 2013, so the bit about the version being "recent" is irrelevant
> and it was removed from the final commit message)

We don't distinguish Solaris and OpenSolaris forks currently. As such,
changing one for the other is not a good choice, especially since you
are more likely to find clang users for Illumos, IMO.

https://www.illumos.org/issues/3849

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

Re: [PATCH][Solaris] Default to -fno-cxa-finalize

[Xan López via cfe-commits]

On Tue, Sep 08, 2015 at 03:28:12PM +0200, Joerg Sonnenberger via cfe-commits 
wro> We don't distinguish Solaris and OpenSolaris forks currently. As such,
> changing one for the other is not a good choice, especially since you
> are more likely to find clang users for Illumos, IMO.
> 
> https://www.illumos.org/issues/3849

Well I'm still a bit confused about what were they using exactly,
since I'm pretty sure clang has never worked in its upstream form in a
general way from 2012/3. As I said maybe they ship a branch of their
own or something, not sure.

In any case Solaris is not Illumos, so we still need a
solution. Should we add a way to distinguish between them and disable
this feature only for Sun/Oracle Solaris? If they are diverging in
things like this it seems sooner or later it would be needed anyway.

Xan

> 
> Joerg
> ___
> 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] D11328: [clang-tidy] new "throw-by-value-catch-by-reference" check for clang-tidy

[Aaron Ballman via cfe-commits]

aaron.ballman added a comment.

This is looking great! Some mostly minor feedback below. The only things I 
noticed that may require further consideration are throwing function parameters 
and throwing exception handler variables -- I don't think those scenarios 
should emit a diagnostic. The former is a bit chatty because of error handling 
functions, and the latter is correct regardless of the type being thrown 
(though is a bit silly because the user should really just use throw; instead 
of rethrowing the variable).

General nitpick: please make sure all comments in the code and tests have 
proper capitalization, punctuation, etc.



Comment at: clang-tidy/misc/ThrowByValueCatchByReferenceCheck.cpp:23
@@ +22,3 @@
+: ClangTidyCheck(Name, Context),
+  checkAnonymousTemporaries(Options.get("CheckThrowTemporaries", "true") ==
+"true") {}

Can we just use a bool instead of the string "true"? The constructor for 
AssertSideEffectCheck does this, for instance.


Comment at: clang-tidy/misc/ThrowByValueCatchByReferenceCheck.cpp:31
@@ +30,3 @@
+
+  Finder->addMatcher(throwExpr().bind("throw"), this);
+  Finder->addMatcher(catchStmt().bind("catch"), this);

I'm not certain whether this is feasible or not, but if you can check the 
options by this point, you could replace a lot of custom AST logic from check() 
by registering a different matcher if care about anonymous temporaries. For 
instance:

  if (checkAnonymousTemporaries)

Finder->addMatcher(throwExpr(unless(anyOf(hasDescendant(anyOf(declRefExpr(to(parmVarDecl())),
 declRefExpr(to(varDecl(isExceptionVar(, 
constructExpr(hasDescendant(materializeTemporaryExpr())), 
expr(hasType(hasCanonicalType(builtinType()), unless(has(expr()), this);
  else
Finder->addMatcher(throwExpr(), this);

(Leaving the bindings out, but you get the idea).


Comment at: clang-tidy/misc/ThrowByValueCatchByReferenceCheck.cpp:43
@@ +42,3 @@
+  const auto *throwExpr = Result.Nodes.getNodeAs("throw");
+  if (throwExpr != nullptr) {
+auto *subExpr = throwExpr->getSubExpr();

No need for the != nullptr.

May want to consider splitting the throw and catch logic into helper methods to 
reduce indenting. e.g.,

  if (throwExpr)
doThrowStuff(throwExpr);
  
  if (catchExpr)
doCatchStuff(catchExpr);
  


Comment at: clang-tidy/misc/ThrowByValueCatchByReferenceCheck.cpp:44
@@ +43,3 @@
+  if (throwExpr != nullptr) {
+auto *subExpr = throwExpr->getSubExpr();
+auto qualType = subExpr->getType();

I think we want throwExpr->getSubExpr()->IgnoreParenImpCasts(). This looks 
through *all* implicit casts (and paren expressions, etc), so you can get rid 
of the if (isa) from below and just look at 
isa. This will then allow code like the following to be properly 
checked: throw ("I am not a kind person");


Comment at: clang-tidy/misc/ThrowByValueCatchByReferenceCheck.cpp:55
@@ +54,3 @@
+  }
+  diag(subExpr->getLocStart(), "avoid throwing pointer");
+}

How about: "throw expression throws a pointer value; should throw a non-pointer 
value instead"?


Comment at: clang-tidy/misc/ThrowByValueCatchByReferenceCheck.cpp:63
@@ +62,3 @@
+
+// algorithm
+// from CXXThrowExpr, move through all casts until you either encounter an

No need to state that this is an algorithm. The reader can likely guess as 
much. ;-)


Comment at: clang-tidy/misc/ThrowByValueCatchByReferenceCheck.cpp:74
@@ +73,3 @@
+  auto *currentSubExpr = subExpr;
+  while (isa(currentSubExpr)) {
+auto *currentCast = cast(currentSubExpr);

I think we want IgnoreParenImpCasts() here as well.


Comment at: clang-tidy/misc/ThrowByValueCatchByReferenceCheck.cpp:98
@@ +97,3 @@
+  auto *currentSubExpr = *argIter;
+  while (isa(currentSubExpr)) {
+auto *currentCast = cast(currentSubExpr);

IgnoreParenImpCasts(), again?


Comment at: clang-tidy/misc/ThrowByValueCatchByReferenceCheck.cpp:102
@@ +101,3 @@
+  }
+  // if the subexpr is now a DeclRefExpr, it's a real variable
+  if (isa(currentSubExpr))

I think the correct way to do this is check to see whether the constructor is 
passed a MaterializeTemporaryExpr. and if so, we don't want to emit the 
diagnostic (otherwise we do).

Also, this code does not look to see whether there is a DeclRefExpr that refers 
to a parameter variable declaration. In my testing, this accounted for a 
sizable number of false positives because of code like:

  void handle_error(const someObj &o) {
throw o; // Shouldn't diagnose, this isn't dangerous
  }


Comment at: clang-tidy/misc/ThrowByValueCatchByReferenceCheck.cpp:108
@@ +107,3 @@
+  if (emit)
+

r247015 - clang/test/CodeGen/complex-convert.c: Appease for targeting powerpc64-*.

[NAKAMURA Takumi via cfe-commits]

Author: chapuni
Date: Tue Sep  8 09:19:13 2015
New Revision: 247015

URL: http://llvm.org/viewvc/llvm-project?rev=247015&view=rev
Log:
clang/test/CodeGen/complex-convert.c: Appease for targeting powerpc64-*.

Modified:
cfe/trunk/test/CodeGen/complex-convert.c

Modified: cfe/trunk/test/CodeGen/complex-convert.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/complex-convert.c?rev=247015&r1=247014&r2=247015&view=diff
==
--- cfe/trunk/test/CodeGen/complex-convert.c (original)
+++ cfe/trunk/test/CodeGen/complex-convert.c Tue Sep  8 09:19:13 2015
@@ -31,6 +31,8 @@ void foo(signed char sc, unsigned char u
   // CHECK: alloca i[[CHSIZE]], align [[CHALIGN:[0-9]+]]
   // CHECK: alloca i[[LLSIZE]], align [[LLALIGN:[0-9]+]]
 
+  // CHECK: store i64 %ull,
+
   sc1 = csc;
   // CHECK: %[[VAR1:[A-Za-z0-9.]+]] = getelementptr inbounds { i[[CHSIZE]], 
i[[CHSIZE]]  }, { i[[CHSIZE]], i[[CHSIZE]]  }* %[[CSC:[A-Za-z0-9.]+]], 
i{{[0-9]+}} 0, i{{[0-9]+}} 0
   // CHECK-NEXT: %[[VAR2:[A-Za-z0-9.]+]] = load i[[CHSIZE]], i[[CHSIZE]]* 
%[[VAR1]]


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

[PATCH] D12695: [Driver] Use UniversalCRT on Windows if available

[Igor Kudrin via cfe-commits]

ikudrin created this revision.
ikudrin added a subscriber: cfe-commits.

With Visual Studio 2015 release, a part of runtime library was extracted and 
now comes with Windows Kits. This patch enables clang to use Universal CRT 
library if  %INCLUDE or %LIB environment varaibles are not specified.

See also https://llvm.org/bugs/show_bug.cgi?id=24741

http://reviews.llvm.org/D12695

Files:
  lib/Driver/MSVCToolChain.cpp
  lib/Driver/ToolChains.h
  lib/Driver/Tools.cpp

Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -8953,6 +8953,11 @@
   Args.MakeArgString(std::string("-libpath:") + LibDir.c_str()));
 }
 
+std::string UniversalCRTLibPath;
+if (MSVC.getUniversalCRTLibraryPath(UniversalCRTLibPath))
+  CmdArgs.push_back(Args.MakeArgString(std::string("-libpath:") +
+   UniversalCRTLibPath.c_str()));
+
 std::string WindowsSdkLibPath;
 if (MSVC.getWindowsSDKLibraryPath(WindowsSdkLibPath))
   CmdArgs.push_back(Args.MakeArgString(std::string("-libpath:") +
Index: lib/Driver/ToolChains.h
===
--- lib/Driver/ToolChains.h
+++ lib/Driver/ToolChains.h
@@ -836,6 +836,9 @@
 
   bool getWindowsSDKDir(std::string &path, int &major, int &minor) const;
   bool getWindowsSDKLibraryPath(std::string &path) const;
+  bool getUniversalCRTSdkDir(std::string &path,
+std::string &ucrtVersion) const;
+  bool getUniversalCRTLibraryPath(std::string &path) const;
   bool getVisualStudioInstallDir(std::string &path) const;
   bool getVisualStudioBinariesFolder(const char *clangProgramPath,
  std::string &path) const;
Index: lib/Driver/MSVCToolChain.cpp
===
--- lib/Driver/MSVCToolChain.cpp
+++ lib/Driver/MSVCToolChain.cpp
@@ -283,6 +283,66 @@
   return true;
 }
 
+bool MSVCToolChain::getUniversalCRTSdkDir(std::string &path,
+  std::string &ucrtVersion) const
+{
+  // vcvarsqueryregistry.bat for Visual Studio 2015 queries the registry
+  // for the specific key "KitsRoot10". So do we.
+  if (!getSystemRegistryString(
+"SOFTWARE\\Microsoft\\Windows Kits\\Installed Roots",
+"KitsRoot10", path, nullptr))
+return false;
+
+  ucrtVersion.clear();
+
+  // Find the most recent version of Universal CRT.
+  // vcvarsqueryregistry.bat sorts entries in the include directory by names and
+  // uses the last one of the list.
+  // So we compare entry names lexicographically to find the greatest one.
+  std::error_code ec;
+  llvm::SmallString<128> includePath(path);
+  llvm::sys::path::append(includePath, "Include");
+  for (llvm::sys::fs::directory_iterator dirIt(includePath, ec), dirEnd;
+  dirIt != dirEnd && !ec; dirIt.increment(ec)) {
+if (!llvm::sys::fs::is_directory(dirIt->path()))
+  continue;
+StringRef name = llvm::sys::path::filename(dirIt->path());
+if (name > ucrtVersion)
+  ucrtVersion = name;
+  }
+
+  return !ucrtVersion.empty();
+}
+
+bool MSVCToolChain::getUniversalCRTLibraryPath(std::string &path) const
+{
+  std::string universalCRTSdkPath;
+  std::string ucrtVersion;
+
+  path.clear();
+  if (!getUniversalCRTSdkDir(universalCRTSdkPath, ucrtVersion))
+return false;
+
+  llvm::SmallString<128> libPath(universalCRTSdkPath);
+  llvm::sys::path::append(libPath, "Lib", ucrtVersion, "ucrt");
+  switch (getArch()) {
+  case llvm::Triple::x86:
+llvm::sys::path::append(libPath, "x86");
+break;
+  case llvm::Triple::x86_64:
+llvm::sys::path::append(libPath, "x64");
+break;
+  case llvm::Triple::arm:
+llvm::sys::path::append(libPath, "arm");
+break;
+  default:
+return false;
+  }
+
+  path = libPath.str();
+  return true;
+}
+
 // Get the location to use for Visual Studio binaries.  The location priority
 // is: %VCINSTALLDIR% > %PATH% > newest copy of Visual Studio installed on
 // system (as reported by the registry).
@@ -460,6 +520,14 @@
   if (getVisualStudioInstallDir(VSDir)) {
 AddSystemIncludeWithSubfolder(DriverArgs, CC1Args, VSDir, "VC\\include");
 
+std::string universalCRTSdkPath;
+std::string ucrtVersion;
+if (getUniversalCRTSdkDir(universalCRTSdkPath, ucrtVersion)) {
+  llvm::SmallString<128> ucrtIncludePath(universalCRTSdkPath);
+  llvm::sys::path::append(ucrtIncludePath, "Include", ucrtVersion, "ucrt");
+  addSystemInclude(DriverArgs, CC1Args, ucrtIncludePath);
+}
+
 std::string WindowsSDKDir;
 int major, minor;
 if (getWindowsSDKDir(WindowsSDKDir, major, minor)) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D12616: Failing test highlighting no poisoning if dtor undeclared.

[Naomi Musgrave via cfe-commits]

nmusgrave updated this revision to Diff 34220.
nmusgrave marked an inline comment as done.
nmusgrave added a comment.

- Rename test.


http://reviews.llvm.org/D12616

Files:
  test/CodeGenCXX/sanitize-dtor-trivial.cpp

Index: test/CodeGenCXX/sanitize-dtor-trivial.cpp
===
--- /dev/null
+++ test/CodeGenCXX/sanitize-dtor-trivial.cpp
@@ -0,0 +1,15 @@
+// Test -fsanitize-memory-use-after-dtor
+// RUN: %clang_cc1 -O0 -fsanitize=memory -fsanitize-memory-use-after-dtor 
-disable-llvm-optzns -std=c++11 -triple=x86_64-pc-linux -emit-llvm -o - %s | 
FileCheck %s
+// RUN: %clang_cc1 -O1 -fsanitize=memory -fsanitize-memory-use-after-dtor 
-disable-llvm-optzns -std=c++11 -triple=x86_64-pc-linux -emit-llvm -o - %s | 
FileCheck %s
+
+// TODO Success pending on resolution of issue:
+//https://github.com/google/sanitizers/issues/596
+// XFAIL: *
+
+struct Trivial {
+  int a;
+  int b;
+};
+Trivial t;
+
+// CHECK: call void @__sanitizer_dtor_callback


Index: test/CodeGenCXX/sanitize-dtor-trivial.cpp
===
--- /dev/null
+++ test/CodeGenCXX/sanitize-dtor-trivial.cpp
@@ -0,0 +1,15 @@
+// Test -fsanitize-memory-use-after-dtor
+// RUN: %clang_cc1 -O0 -fsanitize=memory -fsanitize-memory-use-after-dtor -disable-llvm-optzns -std=c++11 -triple=x86_64-pc-linux -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -O1 -fsanitize=memory -fsanitize-memory-use-after-dtor -disable-llvm-optzns -std=c++11 -triple=x86_64-pc-linux -emit-llvm -o - %s | FileCheck %s
+
+// TODO Success pending on resolution of issue:
+//https://github.com/google/sanitizers/issues/596
+// XFAIL: *
+
+struct Trivial {
+  int a;
+  int b;
+};
+Trivial t;
+
+// CHECK: call void @__sanitizer_dtor_callback
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r247018 - Fix performance regression when running clang tools.

[Manuel Klimek via cfe-commits]

Author: klimek
Date: Tue Sep  8 10:14:06 2015
New Revision: 247018

URL: http://llvm.org/viewvc/llvm-project?rev=247018&view=rev
Log:
Fix performance regression when running clang tools.

Brings tool start time for a large synthetic test case down from (on my
machine) 4 seconds to 0.5 seconds.

Modified:
cfe/trunk/include/clang/Tooling/JSONCompilationDatabase.h
cfe/trunk/lib/Tooling/JSONCompilationDatabase.cpp
cfe/trunk/unittests/Tooling/CompilationDatabaseTest.cpp

Modified: cfe/trunk/include/clang/Tooling/JSONCompilationDatabase.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Tooling/JSONCompilationDatabase.h?rev=247018&r1=247017&r2=247018&view=diff
==
--- cfe/trunk/include/clang/Tooling/JSONCompilationDatabase.h (original)
+++ cfe/trunk/include/clang/Tooling/JSONCompilationDatabase.h Tue Sep  8 
10:14:06 2015
@@ -99,17 +99,21 @@ private:
   /// failed.
   bool parse(std::string &ErrorMessage);
 
-  // Tuple (directory, commandline) where 'commandline' pointing to the
-  // corresponding nodes in the YAML stream.
-  typedef std::pair> CompileCommandRef;
+  // Tuple (directory, commandline) where 'commandline' points to the
+  // corresponding scalar nodes in the YAML stream.
+  // If the command line contains a single argument, it is a shell-escaped
+  // command line.
+  // Otherwise, each entry in the command line vector is a literal
+  // argument to the compiler.
+  typedef std::pair> CompileCommandRef;
 
   /// \brief Converts the given array of CompileCommandRefs to CompileCommands.
   void getCommands(ArrayRef CommandsRef,
std::vector &Commands) const;
 
   // Maps file paths to the compile command lines for that file.
-  llvm::StringMap< std::vector > IndexByFile;
+  llvm::StringMap> IndexByFile;
 
   FileMatchTrie MatchTrie;
 

Modified: cfe/trunk/lib/Tooling/JSONCompilationDatabase.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Tooling/JSONCompilationDatabase.cpp?rev=247018&r1=247017&r2=247018&view=diff
==
--- cfe/trunk/lib/Tooling/JSONCompilationDatabase.cpp (original)
+++ cfe/trunk/lib/Tooling/JSONCompilationDatabase.cpp Tue Sep  8 10:14:06 2015
@@ -214,15 +214,26 @@ JSONCompilationDatabase::getAllCompileCo
   return Commands;
 }
 
+static std::vector
+nodeToCommandLine(const std::vector &Nodes) {
+  SmallString<1024> Storage;
+  if (Nodes.size() == 1) {
+return unescapeCommandLine(Nodes[0]->getValue(Storage));
+  }
+  std::vector Arguments;
+  for (auto *Node : Nodes) {
+Arguments.push_back(Node->getValue(Storage));
+  }
+  return Arguments;
+}
+
 void JSONCompilationDatabase::getCommands(
-  ArrayRef CommandsRef,
-  std::vector &Commands) const 
{
+ArrayRef CommandsRef,
+std::vector &Commands) const {
   for (int I = 0, E = CommandsRef.size(); I != E; ++I) {
 SmallString<8> DirectoryStorage;
-SmallString<1024> CommandStorage;
-Commands.emplace_back(
-  CommandsRef[I].first->getValue(DirectoryStorage),
-  CommandsRef[I].second);
+Commands.emplace_back(CommandsRef[I].first->getValue(DirectoryStorage),
+  nodeToCommandLine(CommandsRef[I].second));
   }
 }
 
@@ -249,11 +260,8 @@ bool JSONCompilationDatabase::parse(std:
   return false;
 }
 llvm::yaml::ScalarNode *Directory = nullptr;
-std::vector Arguments;
-std::vector Command;
+llvm::Optional> Command;
 llvm::yaml::ScalarNode *File = nullptr;
-bool ArgumentsFound = false;
-bool CommandFound = false;
 for (auto& NextKeyValue : *Object) {
   llvm::yaml::ScalarNode *KeyString =
   dyn_cast(NextKeyValue.getKey());
@@ -282,18 +290,18 @@ bool JSONCompilationDatabase::parse(std:
   if (KeyValue == "directory") {
 Directory = ValueString;
   } else if (KeyValue == "arguments") {
-for (auto& NextArgument : *SequenceString) {
-  SmallString<128> CommandStorage;
-  auto ValueString = dyn_cast(&NextArgument);
-
-  Arguments.push_back(ValueString->getValue(CommandStorage));
+Command = std::vector();
+for (auto &Argument : *SequenceString) {
+  auto Scalar = dyn_cast(&Argument);
+  if (!Scalar) {
+ErrorMessage = "Only strings are allowed in 'arguments'.";
+return false;
+  }
+  Command->push_back(Scalar);
 }
-ArgumentsFound = true;
   } else if (KeyValue == "command") {
-SmallString<1024> CommandStorage;
-// FIXME: Escape correctly:
-Command = unescapeCommandLine(ValueString->getValue(CommandStorage));
-CommandFound = true;
+if (!Command)
+  Command = std::vector(1, ValueString);
   } else if (KeyValue == "file") {
 File = ValueString;
   } else {
@@ -306,7 +314,7 @@

Re: r245036 - Add structed way to express command line options in the compilation database.

[Manuel Klimek via cfe-commits]

In r247018 I get a ~8x speedup on a synthetic benchmark I tried. Can you
validate this fixes the regression?

On Sat, Sep 5, 2015 at 12:56 AM Hans Wennborg  wrote:

> On Fri, Aug 14, 2015 at 2:55 AM, Manuel Klimek via cfe-commits
>  wrote:
> > Author: klimek
> > Date: Fri Aug 14 04:55:36 2015
> > New Revision: 245036
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=245036&view=rev
> > Log:
> > Add structed way to express command line options in the compilation
> database.
> >
> > Currently, arguments are passed via the string attribute 'command',
> > assuming a shell-escaped / quoted command line to extract the original
> > arguments. This works well enough on Unix systems, but turns out to be
> > problematic for Windows tools to generate.
> >
> > This CL adds a new attribute 'arguments', an array of strings, which
> > specifies the exact command line arguments. If 'arguments' is available
> > in the compilation database, it is preferred to 'commands'.
> >
> > Currently there is no plan to retire 'commands': there are enough
> > different use cases where users want to create their own mechanism for
> > creating compilation databases, that it doesn't make sense to force them
> > all to implement shell command line parsing.
> >
> > Patch by Daniel Dilts.
>
> This seems to have caused a bad performance regression for a tool we
> use in Chromium. On the file I tried, run-time went from 0.4 s to 3.0
> s (7.5x slow-down), and peak memory usage from 42 MB to 366 MB (8.7x).
>
> I suspect what's happened is that JSONCompilationDatabase::parse()
> became significantly slower because it's now calling
> unescapeCommandLine() and allocating a std::vector on each "command"
> field during parsing, whereas previously the code wouldn't do that
> until JSONCompilationDatabase::getCommands() was called on a specific
> file or set of files.
>
> One idea for fixing this would be to make the second part of
> CompileCommandRef be a yaml::Node pointer, and look at the node type:
> if it's a ScalarNode, it contains "commands" and needs to be
> unescaped; if it's a SequenceNode, it's "arguments".
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r246991 - When building the alloca for a local variable, set its name

[David Blaikie via cfe-commits]

On Tue, Sep 8, 2015 at 2:18 AM, John McCall via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rjmccall
> Date: Tue Sep  8 04:18:30 2015
> New Revision: 246991
>
> URL: http://llvm.org/viewvc/llvm-project?rev=246991&view=rev
> Log:
> When building the alloca for a local variable, set its name
> separately from building the instruction so that it's
> preserved even in -Asserts builds.
>

Why do we want to preserve this name in particular in -Asserts builds?


>
> Employ C++'s mystical "comment" feature to discourage
> breaking this in the future.
>
> Modified:
> cfe/trunk/lib/CodeGen/CGDecl.cpp
>
> Modified: cfe/trunk/lib/CodeGen/CGDecl.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDecl.cpp?rev=246991&r1=246990&r2=246991&view=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/CGDecl.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGDecl.cpp Tue Sep  8 04:18:30 2015
> @@ -968,7 +968,11 @@ CodeGenFunction::EmitAutoVarAlloca(const
>  allocaAlignment = alignment;
>}
>
> -  address = CreateTempAlloca(allocaTy, allocaAlignment, D.getName());
> +  // Create the alloca.  Note that we set the name separately from
> +  // building the instruction so that it's there even in no-asserts
> +  // builds.
> +  address = CreateTempAlloca(allocaTy, allocaAlignment);
> +  address.getPointer()->setName(D.getName());
>
>// Emit a lifetime intrinsic if meaningful.  There's no point
>// in doing this if we don't have a valid insertion point (?).
>
>
> ___
> 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: r245036 - Add structed way to express command line options in the compilation database.

[Hans Wennborg via cfe-commits]

Yes, the run-time is now back to where it was before the regression. Thanks!

On Tue, Sep 8, 2015 at 8:16 AM, Manuel Klimek  wrote:
> In r247018 I get a ~8x speedup on a synthetic benchmark I tried. Can you
> validate this fixes the regression?
>
> On Sat, Sep 5, 2015 at 12:56 AM Hans Wennborg  wrote:
>>
>> On Fri, Aug 14, 2015 at 2:55 AM, Manuel Klimek via cfe-commits
>>  wrote:
>> > Author: klimek
>> > Date: Fri Aug 14 04:55:36 2015
>> > New Revision: 245036
>> >
>> > URL: http://llvm.org/viewvc/llvm-project?rev=245036&view=rev
>> > Log:
>> > Add structed way to express command line options in the compilation
>> > database.
>> >
>> > Currently, arguments are passed via the string attribute 'command',
>> > assuming a shell-escaped / quoted command line to extract the original
>> > arguments. This works well enough on Unix systems, but turns out to be
>> > problematic for Windows tools to generate.
>> >
>> > This CL adds a new attribute 'arguments', an array of strings, which
>> > specifies the exact command line arguments. If 'arguments' is available
>> > in the compilation database, it is preferred to 'commands'.
>> >
>> > Currently there is no plan to retire 'commands': there are enough
>> > different use cases where users want to create their own mechanism for
>> > creating compilation databases, that it doesn't make sense to force them
>> > all to implement shell command line parsing.
>> >
>> > Patch by Daniel Dilts.
>>
>> This seems to have caused a bad performance regression for a tool we
>> use in Chromium. On the file I tried, run-time went from 0.4 s to 3.0
>> s (7.5x slow-down), and peak memory usage from 42 MB to 366 MB (8.7x).
>>
>> I suspect what's happened is that JSONCompilationDatabase::parse()
>> became significantly slower because it's now calling
>> unescapeCommandLine() and allocating a std::vector on each "command"
>> field during parsing, whereas previously the code wouldn't do that
>> until JSONCompilationDatabase::getCommands() was called on a specific
>> file or set of files.
>>
>> One idea for fixing this would be to make the second part of
>> CompileCommandRef be a yaml::Node pointer, and look at the node type:
>> if it's a ScalarNode, it contains "commands" and needs to be
>> unescaped; if it's a SequenceNode, it's "arguments".
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D12646: Add libc++ header path for DarwinClang builds

[Kuba Brecka via cfe-commits]

kubabrecka added a comment.

> > I first noticed it when I tried to run the version of clang-tidy I'd just 
> > built and found I had to pass the path for it to find iostream.

> 

> 

> I think it works if you a) check out libcxx into llvm/projects/libcxx b) run 
> `make install` and c) run the binary from your install directory.


I don't think b) and c) are necessary.  At least for CMake builds, if you 
checkout libcxx, the output directory will get the C++ headers in the right 
place.


http://reviews.llvm.org/D12646



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

Re: [PATCH] D12646: Add libc++ header path for DarwinClang builds

[don hinton via cfe-commits]

hintonda added a comment.

> I think it works if you a) check out libcxx into llvm/projects/libcxx b) run 
> `make install` and c) run the binary from your install directory.


Yes, that works.  But why shouldn't users be able to use the installed version?

Also, if you want to force users to either build libc++ or have the headers 
installed in /usr/include/c++/v1, then cmake should fail if neither is the case.


http://reviews.llvm.org/D12646



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

Re: [PATCH] D12646: Add libc++ header path for DarwinClang builds

[Nico Weber via cfe-commits]

thakis added a comment.

In http://reviews.llvm.org/D12646#241318, @hintonda wrote:

> In http://reviews.llvm.org/D12646#241308, @kubabrecka wrote:
>
> > In what scenario exactly are you seeing an issue?  If it's a just-built 
> > clang that can't find C++ headers, then you should just build the libcxx 
> > project alongside.
>
>
> clang++ defaults to -stdlib=libc++ for newer versions of MacOS (see 
> ToolChains.cpp:902), but since there isn't a way to pass corresponding 
> include path via cmake, clang++ doesn't work out of the box, i.e., it only 
> checks /usr/include/c++/v1, not the path relative to the version of clang 
> used to build it.
>
> I first noticed it when I tried to run the version of clang-tidy I'd just 
> built and found I had to pass the path for it to find iostream.


I think it works if you a) check out libcxx into llvm/projects/libcxx b) run 
`make install` and c) run the binary from your install directory.


http://reviews.llvm.org/D12646



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

Re: [PATCH] D12646: Add libc++ header path for DarwinClang builds

[Bob Wilson via cfe-commits]

bob.wilson added a comment.

On Darwin platforms, the libc++ headers are expected to be installed alongside 
clang. If you're not doing that, then you're building it wrong. Adding more 
fallback options for finding the headers just makes things worse, because 
instead of a clear failure, you're more likely to get something that works but 
behaves badly in a subtle way (e.g., due to using really old libc++ headers).

I don't think this is the right thing to do.


http://reviews.llvm.org/D12646



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

Re: [PATCH] D12646: Add libc++ header path for DarwinClang builds

[don hinton via cfe-commits]

hintonda added a comment.

In http://reviews.llvm.org/D12646#241493, @bob.wilson wrote:

> On Darwin platforms, the libc++ headers are expected to be installed 
> alongside clang. If you're not doing that, then you're building it wrong. 
> Adding more fallback options for finding the headers just makes things worse, 
> because instead of a clear failure, you're more likely to get something that 
> works but behaves badly in a subtle way (e.g., due to using really old libc++ 
> headers).
>
> I don't think this is the right thing to do.


Okay, I'm comfortable with this solution.  I'll work up a diff that makes cmake 
fail if libc++ isn't included in the build.


http://reviews.llvm.org/D12646



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

r247025 - Failing test highlighting no poisoning if dtor undeclared.

[Naomi Musgrave via cfe-commits]

Author: nmusgrave
Date: Tue Sep  8 11:38:17 2015
New Revision: 247025

URL: http://llvm.org/viewvc/llvm-project?rev=247025&view=rev
Log:
Failing test highlighting no poisoning if dtor undeclared.

Summary:
If class or struct has not declared a destructor,
no destructor is emitted, and members are not poisoned
after destruction. This case highlights bug in current
implementation of use-after-dtor poisoning (detailed
in https://github.com/google/sanitizers/issues/596).

Reviewers: eugenis, kcc

Subscribers: cfe-commits

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

Only check simplest object for existence of sanitizing callback.

Rename test.

Added:
cfe/trunk/test/CodeGenCXX/sanitize-dtor-trivial.cpp

Added: cfe/trunk/test/CodeGenCXX/sanitize-dtor-trivial.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/sanitize-dtor-trivial.cpp?rev=247025&view=auto
==
--- cfe/trunk/test/CodeGenCXX/sanitize-dtor-trivial.cpp (added)
+++ cfe/trunk/test/CodeGenCXX/sanitize-dtor-trivial.cpp Tue Sep  8 11:38:17 2015
@@ -0,0 +1,15 @@
+// Test -fsanitize-memory-use-after-dtor
+// RUN: %clang_cc1 -O0 -fsanitize=memory -fsanitize-memory-use-after-dtor 
-disable-llvm-optzns -std=c++11 -triple=x86_64-pc-linux -emit-llvm -o - %s | 
FileCheck %s
+// RUN: %clang_cc1 -O1 -fsanitize=memory -fsanitize-memory-use-after-dtor 
-disable-llvm-optzns -std=c++11 -triple=x86_64-pc-linux -emit-llvm -o - %s | 
FileCheck %s
+
+// TODO Success pending on resolution of issue:
+//https://github.com/google/sanitizers/issues/596
+// XFAIL: *
+
+struct Trivial {
+  int a;
+  int b;
+};
+Trivial t;
+
+// CHECK: call void @__sanitizer_dtor_callback


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

Re: r246991 - When building the alloca for a local variable, set its name

[John McCall via cfe-commits]

> On Sep 8, 2015, at 8:25 AM, David Blaikie  wrote:
> On Tue, Sep 8, 2015 at 2:18 AM, John McCall via cfe-commits 
> mailto:cfe-commits@lists.llvm.org>> wrote:
> Author: rjmccall
> Date: Tue Sep  8 04:18:30 2015
> New Revision: 246991
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=246991&view=rev 
> 
> Log:
> When building the alloca for a local variable, set its name
> separately from building the instruction so that it's
> preserved even in -Asserts builds.
> 
> Why do we want to preserve this name in particular in -Asserts builds?

It’s a fairly small runtime cost — no twine appending, only present on a tiny 
fraction of instructions, unlikely to collide within a single function — that 
makes reading the IR dramatically easier.  That’s still useful to be able to do 
with a production compiler, both for us and for sophisticated users.

IIRC, Daniel did the perf work on IR names way back when; he might have other 
thoughts.

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

Re: [PATCH] D12453: [CUDA] Allow function overloads based on host/device attributes.

[Artem Belevich via cfe-commits]

tra updated this revision to Diff 34230.
tra marked 2 inline comments as done.
tra added a comment.

Implementes Richard Smiths' suggestions:
Fixed attribute order in name mangling.
Replaced std::function with template argument.


http://reviews.llvm.org/D12453

Files:
  include/clang/Basic/LangOptions.def
  include/clang/Driver/CC1Options.td
  include/clang/Sema/Sema.h
  lib/AST/ItaniumMangle.cpp
  lib/Frontend/CompilerInvocation.cpp
  lib/Sema/SemaCUDA.cpp
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaExprCXX.cpp
  lib/Sema/SemaOverload.cpp
  test/CodeGenCUDA/function-overload.cu
  test/SemaCUDA/function-overload.cu

Index: test/SemaCUDA/function-overload.cu
===
--- /dev/null
+++ test/SemaCUDA/function-overload.cu
@@ -0,0 +1,241 @@
+// REQUIRES: x86-registered-target
+// REQUIRES: nvptx-registered-target
+
+// Make sure we handle target overloads correctly.
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu \
+// RUN:-fsyntax-only -fcuda-target-overloads -verify %s
+// RUN: %clang_cc1 -triple nvptx64-nvidia-cuda \
+// RUN:-fsyntax-only -fcuda-target-overloads -fcuda-is-device -verify %s
+
+// Check target overloads handling with disabled call target checks.
+// RUN: %clang_cc1 -DNOCHECKS -triple x86_64-unknown-linux-gnu -fsyntax-only \
+// RUN:-fcuda-disable-target-call-checks -fcuda-target-overloads -verify %s
+// RUN: %clang_cc1 -DNOCHECKS -triple nvptx64-nvidia-cuda -fsyntax-only \
+// RUN:-fcuda-disable-target-call-checks -fcuda-target-overloads \
+// RUN:-fcuda-is-device -verify %s
+
+#include "Inputs/cuda.h"
+
+typedef int (*fp_t)(void);
+typedef void (*gp_t)(void);
+
+__device__ int dhhd(void) { return 2; }
+__host__ int dhhd(void) { return 1; } // expected-note {{previous definition is here}}
+int dhhd(void) { return 1; } // expected-error {{redefinition of 'dhhd'}}
+__host__ __device__ int dhhd(void) { return 3; }
+
+__host__ int hhd(void) { return 4; }
+__host__ __device__ int dhd(void) { return 5; }
+
+__device__ int dhd(void) { return 6; }
+__host__ __device__ int hhd(void) { return 7; }
+
+__device__ int d(void) { return 8; }
+__host__ int h(void) { return 9; }
+__global__ void g(void) {}
+
+extern "C" __device__ int chd(void) {return 10;}
+extern "C" __host__ int chd(void) {return 11;} // expected-note {{previous definition is here}}
+extern "C" int chd(void) {return 11;} // expected-error {{redefinition of 'chd'}}
+extern "C" __host__ __device__ int chd(void) {return 12;} // expected-note {{previous definition is here}}
+extern "C" __host__ __device__ int chd(void) {return 13;} // expected-error {{redefinition of 'chd'}}
+
+__host__ void hostf(void) {
+  fp_t dhddp = dhhd;
+  fp_t hhdp = hhd;
+  fp_t dhdp = dhd;
+  gp_t gp = g;
+  fp_t dp = d;
+#if !defined(NOCHECKS)
+  // expected-error@-2 {{reference to __device__ function 'd' in __host__ function}}
+  // expected-note@33 {{'d' declared here}}
+#endif
+  fp_t hp = h;
+
+  dhhd();
+  hhd();
+  dhd();
+  chd();
+  d();
+#if !defined(NOCHECKS)
+  // expected-error@-2 {{no matching function for call to 'd'}}
+  // expected-note@33 {{candidate function not viable: call to __device__ function from __host__ function}}
+#endif
+  h();
+
+  g(); // expected-error {{call to global function g not configured}}
+  g<<<0,0>>>();
+}
+
+__device__ void devicef(void) {
+  fp_t dhddp = dhhd;
+  fp_t hhdp = hhd;
+  fp_t dhdp = dhd;
+  gp_t gp = g; // expected-error {{reference to __global__ function 'g' in __device__ function}}
+   // expected-note@35 {{'g' declared here}}
+  fp_t dp = d;
+  fp_t hp = h;
+#if !defined(NOCHECKS)
+  // expected-error@-2 {{reference to __host__ function 'h' in __device__ function}}
+  // expected-note@34 {{'h' declared here}}
+#endif
+
+  dhhd();
+  hhd();
+  dhd();
+  chd();
+  d();
+  h();
+  g();
+#if !defined(NOCHECKS)
+  // expected-error@-3 {{no matching function for call to 'h'}}
+  // expected-note@34 {{candidate function not viable: call to __host__ function from __device__ function}}
+#endif
+  // expected-error@-5 {{no matching function for call to 'g'}}
+  // expected-note@35 {{candidate function not viable: call to __global__ function from __device__ function}}
+  g<<<0,0>>>();
+  // expected-error@-1 {{reference to __global__ function 'g' in __device__ function}}
+  // expected-note@35 {{'g' declared here}}
+}
+
+__global__ void globalf(void) {
+  fp_t dhddp = dhhd;
+  fp_t hhdp = hhd;
+  fp_t dhdp = dhd;
+  gp_t gp = g; // expected-error {{reference to __global__ function 'g' in __global__ function}}
+   // expected-note@35 {{'g' declared here}}
+  fp_t dp = d;
+  fp_t hp = h;
+#if !defined(NOCHECKS)
+  // expected-error@-2 {{reference to __host__ function 'h' in __global__ function}}
+  // expected-note@34 {{'h' declared here}}
+#endif
+
+  dhhd();
+  hhd();
+  dhd();
+  chd();
+  d();
+  h();
+#if !defined(NOCHECKS)
+  // expected-error@-2 {{no matching function for call to 'h'}}
+  // expected-note@34 {{can

Re: [PATCH] D12453: [CUDA] Allow function overloads based on host/device attributes.

[Artem Belevich via cfe-commits]

tra marked 2 inline comments as done.
tra added a comment.

http://reviews.llvm.org/D12453



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

Re: [PATCH] D12622: [Shave]: add a -MT option to moviCompile if there wasn't one

[Chandler Carruth via cfe-commits]

chandlerc accepted this revision.
chandlerc added a comment.
This revision is now accepted and ready to land.

LGTM i guess...

I'm a tiny bit surprised that you have to handle this here rather than 
something else handling this for you... But not a lit surprised...


http://reviews.llvm.org/D12622



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

Re: [PATCH] D11993: [CUDA] Make sure we emit all templated __global__ functions on device side. Again.

[Artem Belevich via cfe-commits]

tra abandoned this revision.
tra added a comment.

Emitting IR is not sufficient to ensure that the kernels survive GDCE, so the 
patch does not work with optimizations on.
http://reviews.llvm.org/D11666 would have to do for now.


http://reviews.llvm.org/D11993



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

Re: r246991 - When building the alloca for a local variable, set its name

[David Blaikie via cfe-commits]

On Tue, Sep 8, 2015 at 10:26 AM, John McCall  wrote:

> On Sep 8, 2015, at 8:25 AM, David Blaikie  wrote:
> On Tue, Sep 8, 2015 at 2:18 AM, John McCall via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: rjmccall
>> Date: Tue Sep  8 04:18:30 2015
>> New Revision: 246991
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=246991&view=rev
>> Log:
>> When building the alloca for a local variable, set its name
>> separately from building the instruction so that it's
>> preserved even in -Asserts builds.
>>
>
> Why do we want to preserve this name in particular in -Asserts builds?
>
>
> It’s a fairly small runtime cost — no twine appending, only present on a
> tiny fraction of instructions, unlikely to collide within a single function
> — that makes reading the IR dramatically easier.  That’s still useful to be
> able to do with a production compiler, both for us and for sophisticated
> users.
>
> IIRC, Daniel did the perf work on IR names way back when; he might have
> other thoughts.
>

*nod* I'd be curious to see/hear/better understand the tradeoffs. I know
I've talked to Chandler (CC'd) about it before when he's expressed a desire
to want to more fully remove names from non-asserts builds (specifically:
optimizations still create named values even in -Asserts builds, I think?
or maybe there was some other - oh, right, as you were saying, the Twine
building cost, even when the name isn't used some names are complex to
create, etc)


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

Re: r246991 - When building the alloca for a local variable, set its name

[Chandler Carruth via cfe-commits]

None of my performance concerns were relevant to this change FWIW.

I think the reason that this got "fixed" was because people had a tendancy
to *rely* on the name downstream when we made it always present. =/
Personally, I like having *no* names in a no-asserts build because it
ensures that absolutely no one is relying on them -- we have debug
information for that.

I wonder if the right way to help the debugging scenario (which is very
real and painful) is to expose a flag for this, or to expose a way to take
an IR file with debug info and synthesize nice names for as much as we can
using the debug info?

On Tue, Sep 8, 2015 at 10:47 AM David Blaikie via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Tue, Sep 8, 2015 at 10:26 AM, John McCall  wrote:
>
>> On Sep 8, 2015, at 8:25 AM, David Blaikie  wrote:
>> On Tue, Sep 8, 2015 at 2:18 AM, John McCall via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: rjmccall
>>> Date: Tue Sep  8 04:18:30 2015
>>> New Revision: 246991
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=246991&view=rev
>>> Log:
>>> When building the alloca for a local variable, set its name
>>> separately from building the instruction so that it's
>>> preserved even in -Asserts builds.
>>>
>>
>> Why do we want to preserve this name in particular in -Asserts builds?
>>
>>
>> It’s a fairly small runtime cost — no twine appending, only present on a
>> tiny fraction of instructions, unlikely to collide within a single function
>> — that makes reading the IR dramatically easier.  That’s still useful to be
>> able to do with a production compiler, both for us and for sophisticated
>> users.
>>
>> IIRC, Daniel did the perf work on IR names way back when; he might have
>> other thoughts.
>>
>
> *nod* I'd be curious to see/hear/better understand the tradeoffs. I know
> I've talked to Chandler (CC'd) about it before when he's expressed a desire
> to want to more fully remove names from non-asserts builds (specifically:
> optimizations still create named values even in -Asserts builds, I think?
> or maybe there was some other - oh, right, as you were saying, the Twine
> building cost, even when the name isn't used some names are complex to
> create, etc)
>
>
>>
>> John.
>>
>
> ___
> 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] r247036 - Implementation of Boyer-Moore and Boyer-Moore-Horspool searchers for the LFTS.

[Marshall Clow via cfe-commits]

Author: marshall
Date: Tue Sep  8 12:59:09 2015
New Revision: 247036

URL: http://llvm.org/viewvc/llvm-project?rev=247036&view=rev
Log:
Implementation of Boyer-Moore and Boyer-Moore-Horspool searchers for the LFTS.

Added:

libcxx/trunk/test/std/experimental/func/func.searchers/func.searchers.boyer_moore/

libcxx/trunk/test/std/experimental/func/func.searchers/func.searchers.boyer_moore/default.pass.cpp

libcxx/trunk/test/std/experimental/func/func.searchers/func.searchers.boyer_moore/hash.pass.cpp

libcxx/trunk/test/std/experimental/func/func.searchers/func.searchers.boyer_moore/hash.pred.pass.cpp

libcxx/trunk/test/std/experimental/func/func.searchers/func.searchers.boyer_moore/pred.pass.cpp

libcxx/trunk/test/std/experimental/func/func.searchers/func.searchers.boyer_moore_horspool/

libcxx/trunk/test/std/experimental/func/func.searchers/func.searchers.boyer_moore_horspool/default.pass.cpp

libcxx/trunk/test/std/experimental/func/func.searchers/func.searchers.boyer_moore_horspool/hash.pass.cpp

libcxx/trunk/test/std/experimental/func/func.searchers/func.searchers.boyer_moore_horspool/hash.pred.pass.cpp

libcxx/trunk/test/std/experimental/func/func.searchers/func.searchers.boyer_moore_horspool/pred.pass.cpp
Modified:
libcxx/trunk/include/experimental/functional
libcxx/trunk/test/std/experimental/algorithms/alg.search/search.pass.cpp
libcxx/trunk/www/ts1z_status.html

Modified: libcxx/trunk/include/experimental/functional
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/experimental/functional?rev=247036&r1=247035&r2=247036&view=diff
==
--- libcxx/trunk/include/experimental/functional (original)
+++ libcxx/trunk/include/experimental/functional Tue Sep  8 12:59:09 2015
@@ -20,7 +20,7 @@ namespace std {
 namespace experimental {
 inline namespace fundamentals_v1 {
 
-// See C++14 §20.9.9, Function object binders
+// See C++14 20.9.9, Function object binders
 template  constexpr bool is_bind_expression_v
   = is_bind_expression::value;
 template  constexpr int is_placeholder_v
@@ -89,7 +89,12 @@ inline namespace fundamentals_v1 {
 
 #include 
 #include 
+
 #include 
+#include 
+#include 
+#include 
+#include 
 
 #include <__undef_min_max>
 
@@ -101,18 +106,23 @@ inline namespace fundamentals_v1 {
 
 _LIBCPP_BEGIN_NAMESPACE_LFTS
 
+#if _LIBCPP_STD_VER > 11
 // default searcher
 template>
+_LIBCPP_TYPE_VIS
 class default_searcher {
 public:
+_LIBCPP_INLINE_VISIBILITY
 default_searcher(_ForwardIterator __f, _ForwardIterator __l, 
_BinaryPredicate __p = _BinaryPredicate())
 : __first_(__f), __last_(__l), __pred_(__p) {}
 
 template 
-_ForwardIterator2 operator () (_ForwardIterator2 __f, _ForwardIterator2 
__l) const {
+_LIBCPP_INLINE_VISIBILITY
+_ForwardIterator2 operator () (_ForwardIterator2 __f, _ForwardIterator2 
__l) const
+{
 return _VSTD::search(__f, __l, __first_, __last_, __pred_);
-}
+}
 
 private:
 _ForwardIterator __first_;
@@ -121,12 +131,323 @@ private:
 };
 
 template>
+_LIBCPP_INLINE_VISIBILITY
 default_searcher<_ForwardIterator, _BinaryPredicate>
 make_default_searcher( _ForwardIterator __f, _ForwardIterator __l, 
_BinaryPredicate __p = _BinaryPredicate ())
 {
 return default_searcher<_ForwardIterator, _BinaryPredicate>(__f, __l, __p);
 }
 
+template class _BMSkipTable;
+
+//  General case for BM data searching; use a map
+template
+class _BMSkipTable<_Key, _Value, _Hash, _BinaryPredicate, false> {
+public: // TODO private:
+typedef _Value value_type;
+typedef _Key   key_type;
+
+const _Value __default_value_;
+std::unordered_map<_Key, _Value, _Hash, _BinaryPredicate> __table;
+
+public:
+_LIBCPP_INLINE_VISIBILITY
+_BMSkipTable(std::size_t __sz, _Value __default, _Hash __hf, 
_BinaryPredicate __pred)
+: __default_value_(__default), __table(__sz, __hf, __pred) {}
+
+_LIBCPP_INLINE_VISIBILITY
+void insert(const key_type &__key, value_type __val)
+{
+__table [__key] = __val;// Would skip_.insert (val) be better here?
+}
+
+_LIBCPP_INLINE_VISIBILITY
+value_type operator [](const key_type & __key) const
+{
+auto __it = __table.find (__key);
+return __it == __table.end() ? __default_value_ : __it->second;
+}
+};
+
+
+//  Special case small numeric values; use an array
+template
+class _BMSkipTable<_Key, _Value, _Hash, _BinaryPredicate, true> {
+private:
+typedef _Value value_type;
+typedef _Key   key_type;
+
+typedef typename std::make_unsigned::type unsigned_key_type;
+typedef std::array::max()> skip_map;
+skip_map __table;
+
+public:
+_LIBCPP_INLINE_VISIBILITY
+_BMSkipTable(std::size_t /*__sz*/, _Value __default, _Hash /*__hf*/, 
_BinaryPredicate /*__pred*/)
+{
+std::fill_n(__table.begin(), __table.size(), __

Re: [PATCH] D11380: Implement LFTS searchers. Boyer_Moore and Boyer_Moore_Horspool

[Marshall Clow via cfe-commits]

mclow.lists closed this revision.
mclow.lists added a comment.

Landed as revision 247036


http://reviews.llvm.org/D11380



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

Re: [PATCH] D11664: [CUDA] Implemented additional processing steps needed to link with CUDA libdevice bitcode.

[Eric Christopher via cfe-commits]

echristo added a comment.

Inline comment.



Comment at: test/CodeGenCUDA/link-device-bitcode.cu:23-28
@@ +22,8 @@
+//
+// NVVMReflect is a target-specific pass runs after -emit-llvm prints
+// IR, so we need to check NVPTX to make sure that the pass did happen
+// and __nvvm_reflect calls were eliminated.
+// RUN: %clang_cc1 -triple nvptx-unknown-cuda -fcuda-is-device \
+// RUN:-mlink-bitcode-file %t.bc -fcuda-uses-libdevice -S -o - %s \
+// RUN:| FileCheck %s -check-prefix CHECK-PTX
+

It would be better here if we could just check the pass structure and rely on 
the backend to test that the pass works.


http://reviews.llvm.org/D11664



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

Re: r246991 - When building the alloca for a local variable, set its name

[David Blaikie via cfe-commits]

On Tue, Sep 8, 2015 at 10:52 AM, Chandler Carruth 
wrote:

> None of my performance concerns were relevant to this change FWIW.
>

Good to know - if we wanted to go down this path I figure we could just
provide overloads - StringRef and Twine, the StringRef one could always use
the name, even in -Asserts and the Twine one would not.

But yeah, your comments below seem worth considering before we figure out
about that path.


> I think the reason that this got "fixed" was because people had a tendancy
> to *rely* on the name downstream when we made it always present. =/
> Personally, I like having *no* names in a no-asserts build because it
> ensures that absolutely no one is relying on them -- we have debug
> information for that.
>
> I wonder if the right way to help the debugging scenario (which is very
> real and painful) is to expose a flag for this, or to expose a way to take
> an IR file with debug info and synthesize nice names for as much as we can
> using the debug info?
>
> On Tue, Sep 8, 2015 at 10:47 AM David Blaikie via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> On Tue, Sep 8, 2015 at 10:26 AM, John McCall  wrote:
>>
>>> On Sep 8, 2015, at 8:25 AM, David Blaikie  wrote:
>>> On Tue, Sep 8, 2015 at 2:18 AM, John McCall via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 Author: rjmccall
 Date: Tue Sep  8 04:18:30 2015
 New Revision: 246991

 URL: http://llvm.org/viewvc/llvm-project?rev=246991&view=rev
 Log:
 When building the alloca for a local variable, set its name
 separately from building the instruction so that it's
 preserved even in -Asserts builds.

>>>
>>> Why do we want to preserve this name in particular in -Asserts builds?
>>>
>>>
>>> It’s a fairly small runtime cost — no twine appending, only present on a
>>> tiny fraction of instructions, unlikely to collide within a single function
>>> — that makes reading the IR dramatically easier.  That’s still useful to be
>>> able to do with a production compiler, both for us and for sophisticated
>>> users.
>>>
>>> IIRC, Daniel did the perf work on IR names way back when; he might have
>>> other thoughts.
>>>
>>
>> *nod* I'd be curious to see/hear/better understand the tradeoffs. I know
>> I've talked to Chandler (CC'd) about it before when he's expressed a desire
>> to want to more fully remove names from non-asserts builds (specifically:
>> optimizations still create named values even in -Asserts builds, I think?
>> or maybe there was some other - oh, right, as you were saying, the Twine
>> building cost, even when the name isn't used some names are complex to
>> create, etc)
>>
>>
>>>
>>> John.
>>>
>>
>> ___
>> 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: r246991 - When building the alloca for a local variable, set its name

[Daniel Dunbar via cfe-commits]

I agree with Chandler the default should be no names for -Asserts builds.

What I wanted originally was that the stripping of names be a runtime
choice (since the performance overhead of it was minimal when I measured
it), so that when we need to debug with a production compiler, it would
still be possible to get the names out. Sometimes that is invaluable when a
bug only handily reproduces with a production compiler you have on hand
(e.g., you might be at a users desktop) and it would help to see the names.

 - Daniel


On Tue, Sep 8, 2015 at 11:06 AM, David Blaikie via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
>
> On Tue, Sep 8, 2015 at 10:52 AM, Chandler Carruth 
> wrote:
>
>> None of my performance concerns were relevant to this change FWIW.
>>
>
> Good to know - if we wanted to go down this path I figure we could just
> provide overloads - StringRef and Twine, the StringRef one could always use
> the name, even in -Asserts and the Twine one would not.
>
> But yeah, your comments below seem worth considering before we figure out
> about that path.
>
>
>> I think the reason that this got "fixed" was because people had a
>> tendancy to *rely* on the name downstream when we made it always present.
>> =/ Personally, I like having *no* names in a no-asserts build because it
>> ensures that absolutely no one is relying on them -- we have debug
>> information for that.
>>
>> I wonder if the right way to help the debugging scenario (which is very
>> real and painful) is to expose a flag for this, or to expose a way to take
>> an IR file with debug info and synthesize nice names for as much as we can
>> using the debug info?
>>
>> On Tue, Sep 8, 2015 at 10:47 AM David Blaikie via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> On Tue, Sep 8, 2015 at 10:26 AM, John McCall  wrote:
>>>
 On Sep 8, 2015, at 8:25 AM, David Blaikie  wrote:
 On Tue, Sep 8, 2015 at 2:18 AM, John McCall via cfe-commits <
 cfe-commits@lists.llvm.org> wrote:

> Author: rjmccall
> Date: Tue Sep  8 04:18:30 2015
> New Revision: 246991
>
> URL: http://llvm.org/viewvc/llvm-project?rev=246991&view=rev
> Log:
> When building the alloca for a local variable, set its name
> separately from building the instruction so that it's
> preserved even in -Asserts builds.
>

 Why do we want to preserve this name in particular in -Asserts builds?


 It’s a fairly small runtime cost — no twine appending, only present on
 a tiny fraction of instructions, unlikely to collide within a single
 function — that makes reading the IR dramatically easier.  That’s still
 useful to be able to do with a production compiler, both for us and for
 sophisticated users.

 IIRC, Daniel did the perf work on IR names way back when; he might have
 other thoughts.

>>>
>>> *nod* I'd be curious to see/hear/better understand the tradeoffs. I know
>>> I've talked to Chandler (CC'd) about it before when he's expressed a desire
>>> to want to more fully remove names from non-asserts builds (specifically:
>>> optimizations still create named values even in -Asserts builds, I think?
>>> or maybe there was some other - oh, right, as you were saying, the Twine
>>> building cost, even when the name isn't used some names are complex to
>>> create, etc)
>>>
>>>

 John.

>>>
>>> ___
>>> 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] D12358: [Analyzer] Handling constant bound loops

[Devin Coughlin via cfe-commits]

Hi Sean,

Ted provided more details off-list. He suspects that the problem is that we 
likely don't add MemSpaceRegions to the worklist because every region is a 
subregion of a MemSpaceRegion, and thus we would invalidate, by default, all 
regions that were in the same MemSpace as the regions we were invalidating.  He 
thinks we want to not change that behavior, but also provide a way of 
invalidating an entire MemSpace if so desired.  That's probably just a slight 
tweak to the algorithm.

I’ll take a look at your updated patch to reproduce what you are seeing and 
investigate to see if that is what is going on.

Thanks,
Devin


> On Sep 2, 2015, at 11:20 PM, Ted Kremenek  wrote:
> 
> krememek added a comment.
> 
> In 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D12358-23238303&d=BQIFaQ&c=eEvniauFctOgLOKGJOplqw&r=DnBGy2nbxhNDknO0DK0VCbUffuO8dI0aqN61uD3KzUU&m=csFsFfIgmsGT7Ht2XuvhMyNifot56bO04tnwaGZNFTY&s=LUjlFLLnrJD-ZC-sWeh6j7eL9EEhYUHMbmP_6QTJrxg&e=
>  , @seaneveson wrote:
> 
>> In 
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D12358-23237099&d=BQIFaQ&c=eEvniauFctOgLOKGJOplqw&r=DnBGy2nbxhNDknO0DK0VCbUffuO8dI0aqN61uD3KzUU&m=csFsFfIgmsGT7Ht2XuvhMyNifot56bO04tnwaGZNFTY&s=R8WzaxQRbHMf18_Ovjwx0V-l-
>> 
>> Do you have any suggestions on what I have done wrong?
> 
> I suspect this has to do with `invalidateRegions` itself.  I will take a 
> look.  In the meantime, can you provide an updated patch that I can try out 
> so I can step through the algorithm (if necessary) in the debugger and 
> reproduce what you are seeing?




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

LLVM buildmaster will be restarted tonight

[Galina Kistanova via cfe-commits]

Hello everyone,

LLVM buildmaster will be restarted after 6 PM Pacific time today.

Thanks

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

Re: [PATCH] D12313: Introduce __builtin_nontemporal_store and __builtin_nontemporal_load.

[Michael Zolotukhin via cfe-commits]

mzolotukhin added a comment.

Hi Richard, Hal,

Does the patch look good now?

Thanks,
Michael


http://reviews.llvm.org/D12313



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

r247049 - Module Debugging: Emit debug type information into clang modules.

[Adrian Prantl via cfe-commits]

Author: adrian
Date: Tue Sep  8 14:20:27 2015
New Revision: 247049

URL: http://llvm.org/viewvc/llvm-project?rev=247049&view=rev
Log:
Module Debugging: Emit debug type information into clang modules.

When -fmodule-format is set to "obj", emit debug info for all types
declared in a module or referenced by a declaration into the module's
object file container.

This patch adds support for C and C++ types.

Added:
cfe/trunk/test/Modules/Inputs/DebugCXX.h
cfe/trunk/test/Modules/ModuleDebugInfo.cpp
Modified:
cfe/trunk/lib/CodeGen/ObjectFilePCHContainerOperations.cpp
cfe/trunk/test/Modules/Inputs/module.map

Modified: cfe/trunk/lib/CodeGen/ObjectFilePCHContainerOperations.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/ObjectFilePCHContainerOperations.cpp?rev=247049&r1=247048&r2=247049&view=diff
==
--- cfe/trunk/lib/CodeGen/ObjectFilePCHContainerOperations.cpp (original)
+++ cfe/trunk/lib/CodeGen/ObjectFilePCHContainerOperations.cpp Tue Sep  8 
14:20:27 2015
@@ -50,6 +50,34 @@ class PCHContainerGenerator : public AST
   raw_pwrite_stream *OS;
   std::shared_ptr Buffer;
 
+  /// Visit every type and emit debug info for it.
+  struct DebugTypeVisitor : public RecursiveASTVisitor {
+clang::CodeGen::CGDebugInfo &DI;
+ASTContext &Ctx;
+DebugTypeVisitor(clang::CodeGen::CGDebugInfo &DI, ASTContext &Ctx)
+: DI(DI), Ctx(Ctx) {}
+
+/// Determine whether this type can be represented in DWARF.
+static bool CanRepresent(const Type *Ty) {
+  return !Ty->isDependentType() && !Ty->isUndeducedType();
+}
+
+bool VisitTypeDecl(TypeDecl *D) {
+  QualType QualTy = Ctx.getTypeDeclType(D);
+  if (!QualTy.isNull() && CanRepresent(QualTy.getTypePtr()))
+DI.getOrCreateStandaloneType(QualTy, D->getLocation());
+  return true;
+}
+
+bool VisitValueDecl(ValueDecl *D) {
+  QualType QualTy = D->getType();
+  if (!QualTy.isNull() && CanRepresent(QualTy.getTypePtr()))
+DI.getOrCreateStandaloneType(QualTy, D->getLocation());
+  return true;
+}
+
+  };
+
 public:
   PCHContainerGenerator(DiagnosticsEngine &diags,
 const HeaderSearchOptions &HSO,
@@ -82,6 +110,36 @@ public:
 *Ctx, HeaderSearchOpts, PreprocessorOpts, CodeGenOpts, *M, Diags));
   }
 
+  bool HandleTopLevelDecl(DeclGroupRef D) override {
+if (Diags.hasErrorOccurred() ||
+(CodeGenOpts.getDebugInfo() == CodeGenOptions::NoDebugInfo))
+  return true;
+
+// Collect debug info for all decls in this group.
+for (auto *I : D)
+  if (!I->isFromASTFile()) {
+DebugTypeVisitor DTV(*Builder->getModuleDebugInfo(), *Ctx);
+DTV.TraverseDecl(I);
+  }
+return true;
+  }
+
+  void HandleTagDeclDefinition(TagDecl *D) override {
+if (Diags.hasErrorOccurred())
+  return;
+
+Builder->UpdateCompletedType(D);
+  }
+
+  void HandleTagDeclRequiredDefinition(const TagDecl *D) override {
+if (Diags.hasErrorOccurred())
+  return;
+
+if (CodeGen::CGDebugInfo *DI = Builder->getModuleDebugInfo())
+  if (const RecordDecl *RD = dyn_cast(D))
+DI->completeRequiredType(RD);
+  }
+
   /// Emit a container holding the serialized AST.
   void HandleTranslationUnit(ASTContext &Ctx) override {
 assert(M && VMContext && Builder);

Added: cfe/trunk/test/Modules/Inputs/DebugCXX.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/DebugCXX.h?rev=247049&view=auto
==
--- cfe/trunk/test/Modules/Inputs/DebugCXX.h (added)
+++ cfe/trunk/test/Modules/Inputs/DebugCXX.h Tue Sep  8 14:20:27 2015
@@ -0,0 +1,52 @@
+/* -*- C++ -*- */
+namespace DebugCXX {
+  // Records.
+  struct Struct {
+int i;
+static int static_member;
+  };
+
+  // Enums.
+  enum Enum {
+Enumerator
+  };
+  enum {
+e1 = '1'
+  };
+  enum {
+e2 = '2'
+  };
+
+  // Templates (instatiations).
+  template struct traits {};
+  template
+  > class Template {
+T member;
+  };
+  extern template class Template;
+
+  extern template struct traits;
+  typedef class Template FloatInstatiation;
+
+  inline void fn() {
+Template invisible;
+  }
+
+  // Non-template inside a template.
+  template  struct Outer {
+Outer();
+struct Inner {
+  Inner(Outer) {}
+};
+  };
+  template  Outer::Outer() {
+Inner a(*this);
+  };
+
+  // Partial template specialization.
+  template  class A;
+  template  class A {};
+  typedef A B;
+  void foo(B) {}
+}

Modified: cfe/trunk/test/Modules/Inputs/module.map
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/module.map?rev=247049&r1=247048&r2=247049&view=diff
==
--- cfe/trunk/test/Modules/Inputs/module.map (original)
+++ cfe/trunk/test/Modules/Inputs/module.map Tue Sep  8 14:20:27 20

Re: [PATCH] D12381: [Static Analyzer] Merge the Objective-C Generics Checker into Dynamic Type Propagation checker.

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

xazax.hun marked 2 inline comments as done.
xazax.hun added a comment.

There are several fallouts from this review, so I decided to split this patch 
up the following way:

1. I created a patch to incorporate the result of this review into 
ObjCGenericsChecker: http://reviews.llvm.org/D12701
2. I will created a separate patch to purge the dynamic type information from 
the GDM for dead symbols.
3. Once the former two patch is accepted I will rebase this patch on the top of 
those, so this will only contain minimal changes required for the merge.


http://reviews.llvm.org/D12381



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

Re: r246991 - When building the alloca for a local variable, set its name

[John McCall via cfe-commits]

> On Sep 8, 2015, at 10:52 AM, Chandler Carruth  wrote:
> None of my performance concerns were relevant to this change FWIW.
> 
> I think the reason that this got "fixed" was because people had a tendancy to 
> *rely* on the name downstream when we made it always present. =/ Personally, 
> I like having *no* names in a no-asserts build because it ensures that 
> absolutely no one is relying on them -- we have debug information for that.
> 
> I wonder if the right way to help the debugging scenario (which is very real 
> and painful) is to expose a flag for this, or to expose a way to take an IR 
> file with debug info and synthesize nice names for as much as we can using 
> the debug info?

It makes sense to me to have a codegen option to preserve some minimal set of 
descriptive names

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

r247052 - [Shave]: add a -MT option to moviCompile if there wasn't one

[Douglas Katzman via cfe-commits]

Author: dougk
Date: Tue Sep  8 14:29:55 2015
New Revision: 247052

URL: http://llvm.org/viewvc/llvm-project?rev=247052&view=rev
Log:
[Shave]: add a -MT option to moviCompile if there wasn't one

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

Modified:
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/test/Driver/shave-toolchain.c

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=247052&r1=247051&r2=247052&view=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Tue Sep  8 14:29:55 2015
@@ -9669,15 +9669,27 @@ void tools::SHAVE::Compiler::ConstructJo
   // Append all -I, -iquote, -isystem paths, defines/undefines,
   // 'f' flags, optimize flags, and warning options.
   // These are spelled the same way in clang and moviCompile.
-  Args.AddAllArgs(CmdArgs,
-  {options::OPT_I_Group, options::OPT_clang_i_Group,
-   options::OPT_D, options::OPT_U,
-   options::OPT_f_Group,
-   options::OPT_f_clang_Group,
-   options::OPT_g_Group,
-   options::OPT_M_Group,
-   options::OPT_O_Group,
-   options::OPT_W_Group});
+  Args.AddAllArgs(CmdArgs, {options::OPT_I_Group, options::OPT_clang_i_Group,
+options::OPT_D, options::OPT_U,
+options::OPT_f_Group, options::OPT_f_clang_Group,
+options::OPT_g_Group, options::OPT_M_Group,
+options::OPT_O_Group, options::OPT_W_Group});
+
+  // If we're producing a dependency file, and assembly is the final action,
+  // then the name of the target in the dependency file should be the '.o'
+  // file, not the '.s' file produced by this step. For example, instead of
+  //  /tmp/mumble.s: mumble.c .../someheader.h
+  // the filename on the lefthand side should be "mumble.o"
+  if (Args.getLastArg(options::OPT_MF) && !Args.getLastArg(options::OPT_MT) &&
+  C.getActions().size() == 1 &&
+  C.getActions()[0]->getKind() == Action::AssembleJobClass) {
+Arg *A = Args.getLastArg(options::OPT_o);
+if (A) {
+  CmdArgs.push_back("-MT");
+  CmdArgs.push_back(Args.MakeArgString(A->getValue()));
+}
+  }
+
   CmdArgs.push_back("-fno-exceptions"); // Always do this even if unspecified.
 
   CmdArgs.push_back(II.getFilename());

Modified: cfe/trunk/test/Driver/shave-toolchain.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/shave-toolchain.c?rev=247052&r1=247051&r2=247052&view=diff
==
--- cfe/trunk/test/Driver/shave-toolchain.c (original)
+++ cfe/trunk/test/Driver/shave-toolchain.c Tue Sep  8 14:29:55 2015
@@ -26,3 +26,7 @@
 // RUN: -ffunction-sections 2>&1 | FileCheck %s -check-prefix=PASSTHRU_OPTIONS
 // PASSTHRU_OPTIONS: "-g" "-fno-inline-functions" 
"-fno-inline-functions-called-once"
 // PASSTHRU_OPTIONS: "-Os" "-Wall" "-MF" "dep.d" "-ffunction-sections"
+
+// RUN: %clang -target shave -c %s -o foo.o -### -MD -MF dep.d 2>&1 \
+// RUN:   | FileCheck %s -check-prefix=MDMF
+// MDMF: "-S" "-MD" "-MF" "dep.d" "-MT" "foo.o"


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

Re: [PATCH] D12622: [Shave]: add a -MT option to moviCompile if there wasn't one

[Douglas Katzman via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL247052: [Shave]: add a -MT option to moviCompile if there 
wasn't one (authored by dougk).

Changed prior to commit:
  http://reviews.llvm.org/D12622?vs=34006&id=34239#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D12622

Files:
  cfe/trunk/lib/Driver/Tools.cpp
  cfe/trunk/test/Driver/shave-toolchain.c

Index: cfe/trunk/test/Driver/shave-toolchain.c
===
--- cfe/trunk/test/Driver/shave-toolchain.c
+++ cfe/trunk/test/Driver/shave-toolchain.c
@@ -26,3 +26,7 @@
 // RUN: -ffunction-sections 2>&1 | FileCheck %s -check-prefix=PASSTHRU_OPTIONS
 // PASSTHRU_OPTIONS: "-g" "-fno-inline-functions" 
"-fno-inline-functions-called-once"
 // PASSTHRU_OPTIONS: "-Os" "-Wall" "-MF" "dep.d" "-ffunction-sections"
+
+// RUN: %clang -target shave -c %s -o foo.o -### -MD -MF dep.d 2>&1 \
+// RUN:   | FileCheck %s -check-prefix=MDMF
+// MDMF: "-S" "-MD" "-MF" "dep.d" "-MT" "foo.o"
Index: cfe/trunk/lib/Driver/Tools.cpp
===
--- cfe/trunk/lib/Driver/Tools.cpp
+++ cfe/trunk/lib/Driver/Tools.cpp
@@ -9669,15 +9669,27 @@
   // Append all -I, -iquote, -isystem paths, defines/undefines,
   // 'f' flags, optimize flags, and warning options.
   // These are spelled the same way in clang and moviCompile.
-  Args.AddAllArgs(CmdArgs,
-  {options::OPT_I_Group, options::OPT_clang_i_Group,
-   options::OPT_D, options::OPT_U,
-   options::OPT_f_Group,
-   options::OPT_f_clang_Group,
-   options::OPT_g_Group,
-   options::OPT_M_Group,
-   options::OPT_O_Group,
-   options::OPT_W_Group});
+  Args.AddAllArgs(CmdArgs, {options::OPT_I_Group, options::OPT_clang_i_Group,
+options::OPT_D, options::OPT_U,
+options::OPT_f_Group, options::OPT_f_clang_Group,
+options::OPT_g_Group, options::OPT_M_Group,
+options::OPT_O_Group, options::OPT_W_Group});
+
+  // If we're producing a dependency file, and assembly is the final action,
+  // then the name of the target in the dependency file should be the '.o'
+  // file, not the '.s' file produced by this step. For example, instead of
+  //  /tmp/mumble.s: mumble.c .../someheader.h
+  // the filename on the lefthand side should be "mumble.o"
+  if (Args.getLastArg(options::OPT_MF) && !Args.getLastArg(options::OPT_MT) &&
+  C.getActions().size() == 1 &&
+  C.getActions()[0]->getKind() == Action::AssembleJobClass) {
+Arg *A = Args.getLastArg(options::OPT_o);
+if (A) {
+  CmdArgs.push_back("-MT");
+  CmdArgs.push_back(Args.MakeArgString(A->getValue()));
+}
+  }
+
   CmdArgs.push_back("-fno-exceptions"); // Always do this even if unspecified.
 
   CmdArgs.push_back(II.getFilename());


Index: cfe/trunk/test/Driver/shave-toolchain.c
===
--- cfe/trunk/test/Driver/shave-toolchain.c
+++ cfe/trunk/test/Driver/shave-toolchain.c
@@ -26,3 +26,7 @@
 // RUN: -ffunction-sections 2>&1 | FileCheck %s -check-prefix=PASSTHRU_OPTIONS
 // PASSTHRU_OPTIONS: "-g" "-fno-inline-functions" "-fno-inline-functions-called-once"
 // PASSTHRU_OPTIONS: "-Os" "-Wall" "-MF" "dep.d" "-ffunction-sections"
+
+// RUN: %clang -target shave -c %s -o foo.o -### -MD -MF dep.d 2>&1 \
+// RUN:   | FileCheck %s -check-prefix=MDMF
+// MDMF: "-S" "-MD" "-MF" "dep.d" "-MT" "foo.o"
Index: cfe/trunk/lib/Driver/Tools.cpp
===
--- cfe/trunk/lib/Driver/Tools.cpp
+++ cfe/trunk/lib/Driver/Tools.cpp
@@ -9669,15 +9669,27 @@
   // Append all -I, -iquote, -isystem paths, defines/undefines,
   // 'f' flags, optimize flags, and warning options.
   // These are spelled the same way in clang and moviCompile.
-  Args.AddAllArgs(CmdArgs,
-  {options::OPT_I_Group, options::OPT_clang_i_Group,
-   options::OPT_D, options::OPT_U,
-   options::OPT_f_Group,
-   options::OPT_f_clang_Group,
-   options::OPT_g_Group,
-   options::OPT_M_Group,
-   options::OPT_O_Group,
-   options::OPT_W_Group});
+  Args.AddAllArgs(CmdArgs, {options::OPT_I_Group, options::OPT_clang_i_Group,
+options::OPT_D, options::OPT_U,
+options::OPT_f_Group, options::OPT_f_clang_Group,
+options::OPT_g_Group, options::OPT_M_Group,
+options::OPT_O_Group, options::OPT_W_Group});
+
+  // If we're producing a dependency file, and assembly is the final action,
+  // then the name of the target in the dependency file should be the '.o'
+  // file, not the '.s' file produced by this 

r247055 - [modules] Write the options records to a separate subblock rather than writing

[Richard Smith via cfe-commits]

Author: rsmith
Date: Tue Sep  8 14:40:14 2015
New Revision: 247055

URL: http://llvm.org/viewvc/llvm-project?rev=247055&view=rev
Log:
[modules] Write the options records to a separate subblock rather than writing
them directly to the control block. These are fairly large, and in a build with
lots of modules / chained PCH, we don't need to read most of them. No
functionality change intended.

Modified:
cfe/trunk/include/clang/Serialization/ASTBitCodes.h
cfe/trunk/include/clang/Serialization/ASTReader.h
cfe/trunk/lib/Serialization/ASTReader.cpp
cfe/trunk/lib/Serialization/ASTWriter.cpp

Modified: cfe/trunk/include/clang/Serialization/ASTBitCodes.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Serialization/ASTBitCodes.h?rev=247055&r1=247054&r2=247055&view=diff
==
--- cfe/trunk/include/clang/Serialization/ASTBitCodes.h (original)
+++ cfe/trunk/include/clang/Serialization/ASTBitCodes.h Tue Sep  8 14:40:14 2015
@@ -233,7 +233,14 @@ namespace clang {
   /// to create this AST file.
   ///
   /// This block is part of the control block.
-  INPUT_FILES_BLOCK_ID
+  INPUT_FILES_BLOCK_ID,
+
+  /// \brief The block of configuration options, used to check that
+  /// a module is being used in a configuration compatible with the
+  /// configuration in which it was built.
+  ///
+  /// This block is part of the control block.
+  OPTIONS_BLOCK_ID,
 };
 
 /// \brief Record types that occur within the control block.
@@ -244,59 +251,63 @@ namespace clang {
 
   /// \brief Record code for the list of other AST files imported by
   /// this AST file.
-  IMPORTS = 2,
-
-  /// \brief Record code for the language options table.
-  ///
-  /// The record with this code contains the contents of the
-  /// LangOptions structure. We serialize the entire contents of
-  /// the structure, and let the reader decide which options are
-  /// actually important to check.
-  LANGUAGE_OPTIONS = 3,
-
-  /// \brief Record code for the target options table.
-  TARGET_OPTIONS = 4,
+  IMPORTS,
 
   /// \brief Record code for the original file that was used to
   /// generate the AST file, including both its file ID and its
   /// name.
-  ORIGINAL_FILE = 5,
+  ORIGINAL_FILE,
   
   /// \brief The directory that the PCH was originally created in.
-  ORIGINAL_PCH_DIR = 6,
+  ORIGINAL_PCH_DIR,
 
   /// \brief Record code for file ID of the file or buffer that was used to
   /// generate the AST file.
-  ORIGINAL_FILE_ID = 7,
+  ORIGINAL_FILE_ID,
 
   /// \brief Offsets into the input-files block where input files
   /// reside.
-  INPUT_FILE_OFFSETS = 8,
-
-  /// \brief Record code for the diagnostic options table.
-  DIAGNOSTIC_OPTIONS = 9,
-
-  /// \brief Record code for the filesystem options table.
-  FILE_SYSTEM_OPTIONS = 10,
-
-  /// \brief Record code for the headers search options table.
-  HEADER_SEARCH_OPTIONS = 11,
-
-  /// \brief Record code for the preprocessor options table.
-  PREPROCESSOR_OPTIONS = 12,
+  INPUT_FILE_OFFSETS,
 
   /// \brief Record code for the module name.
-  MODULE_NAME = 13,
+  MODULE_NAME,
 
   /// \brief Record code for the module map file that was used to build 
this
   /// AST file.
-  MODULE_MAP_FILE = 14,
+  MODULE_MAP_FILE,
 
   /// \brief Record code for the signature that identifiers this AST file.
-  SIGNATURE = 15,
+  SIGNATURE,
 
   /// \brief Record code for the module build directory.
-  MODULE_DIRECTORY = 16,
+  MODULE_DIRECTORY,
+};
+
+/// \brief Record types that occur within the options block inside
+/// the control block.
+enum OptionsRecordTypes {
+  /// \brief Record code for the language options table.
+  ///
+  /// The record with this code contains the contents of the
+  /// LangOptions structure. We serialize the entire contents of
+  /// the structure, and let the reader decide which options are
+  /// actually important to check.
+  LANGUAGE_OPTIONS = 1,
+
+  /// \brief Record code for the target options table.
+  TARGET_OPTIONS,
+
+  /// \brief Record code for the diagnostic options table.
+  DIAGNOSTIC_OPTIONS,
+
+  /// \brief Record code for the filesystem options table.
+  FILE_SYSTEM_OPTIONS,
+
+  /// \brief Record code for the headers search options table.
+  HEADER_SEARCH_OPTIONS,
+
+  /// \brief Record code for the preprocessor options table.
+  PREPROCESSOR_OPTIONS,
 };
 
 /// \brief Record types that occur within the input-files block

Modified: cfe/trunk/include/clang/Serialization/ASTReader.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Serialization/ASTReader.h?rev=247055&r1=247054&r2=247055&view=diff
==

Re: [PATCH] D12038: CodeGen: Introduce CodeGenModule::CreateMetadataIdentifierForType.

[Richard Smith via cfe-commits]

rsmith accepted this revision.
rsmith added a comment.
This revision is now accepted and ready to land.

This seems fine to me.


http://reviews.llvm.org/D12038



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

Re: [PATCH] D12313: Introduce __builtin_nontemporal_store and __builtin_nontemporal_load.

[hfin...@anl.gov via cfe-commits]

hfinkel added a comment.

In http://reviews.llvm.org/D12313#241697, @mzolotukhin wrote:

> Hi Richard, Hal,
>
> Does the patch look good now?


Looks good to me, but please wait for Richard on the changes he requested.

> Thanks,

> Michael



http://reviews.llvm.org/D12313



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

Re: [PATCH] D12313: Introduce __builtin_nontemporal_store and __builtin_nontemporal_load.

[Richard Smith via cfe-commits]

rsmith accepted this revision.
rsmith added a comment.
This revision is now accepted and ready to land.

Looks fine to me.



Comment at: lib/CodeGen/CGBuiltin.cpp:114-128
@@ -113,1 +113,17 @@
 
+static Value *MakeNontemporalStore(CodeGenFunction &CGF, const CallExpr *E) {
+  Value *Val = CGF.EmitScalarExpr(E->getArg(0));
+  Value *Address = CGF.EmitScalarExpr(E->getArg(1));
+
+  // Convert the type of the pointer to a pointer to the stored type.
+  Val = CGF.EmitToMemory(Val, E->getArg(0)->getType());
+  Value *BC = CGF.Builder.CreateBitCast(
+  Address, llvm::PointerType::getUnqual(Val->getType()), "cast");
+  LValue LV = CGF.MakeNaturalAlignAddrLValue(BC, E->getArg(0)->getType());
+  LV.setNontemporal(true);
+  CGF.EmitStoreOfScalar(Val, LV, false);
+  return nullptr;
+}
+
+static Value *MakeNontemporalLoad(CodeGenFunction &CGF, const CallExpr *E) {
+  Value *Address = CGF.EmitScalarExpr(E->getArg(0));

Replace `Make` with `Emit` in both of these.


Comment at: lib/Sema/SemaChecking.cpp:2245-2246
@@ +2244,4 @@
+  Expr *PointerArg = TheCall->getArg(numArgs - 1);
+  ExprResult PointerArgResult =
+  DefaultFunctionArrayLvalueConversion(PointerArg);
+

In the comment on line 2219, you say this has already been done. Please either 
remove this or fix the comment.


http://reviews.llvm.org/D12313



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

Re: [PATCH] D12701: [Static Analyzer] Objective-C Generics checker improvements.

[Anna Zaks via cfe-commits]

zaks.anna accepted this revision.
This revision is now accepted and ready to land.


Comment at: lib/StaticAnalyzer/Checkers/ObjCGenericsChecker.cpp:226
@@ +225,3 @@
+/// Inputs:
+///   There is a static lower bound (SL)
+///   There is a static upper bound (SL <: SU)

http://www.stack.nl/~dimitri/doxygen/manual/commands.html#cmdparam

Is it possible to make sure that the names used in the description match with 
the parameter names?


Comment at: lib/StaticAnalyzer/Checkers/ObjCGenericsChecker.cpp:230
@@ +229,3 @@
+/// Precondition:
+///   SL or SU is specialized. If current is not null, it is specialized.
+/// Possible cases:

Is this precondition checked?


http://reviews.llvm.org/D12701



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

r247068 - Module Debugging: Emit debug type information into clang ObjC modules.

[Adrian Prantl via cfe-commits]

Author: adrian
Date: Tue Sep  8 15:41:52 2015
New Revision: 247068

URL: http://llvm.org/viewvc/llvm-project?rev=247068&view=rev
Log:
Module Debugging: Emit debug type information into clang ObjC modules.

When -fmodule-format is set to "obj", emit debug info for all types
declared in a module or referenced by a declaration into the module's
object file container.

This patch adds support for Objective-C types and methods.

Added:
cfe/trunk/test/Modules/Inputs/DebugObjC.h
cfe/trunk/test/Modules/ModuleDebugInfo.m
Removed:
cfe/trunk/test/Modules/Inputs/DebugModule.h
Modified:
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/lib/CodeGen/CGDebugInfo.h
cfe/trunk/lib/CodeGen/ObjectFilePCHContainerOperations.cpp
cfe/trunk/test/Modules/Inputs/module.map
cfe/trunk/test/Modules/debug-info-moduleimport.m

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=247068&r1=247067&r2=247068&view=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Tue Sep  8 15:41:52 2015
@@ -2515,11 +2515,17 @@ llvm::DISubroutineType *CGDebugInfo::get
 
 Elts.push_back(getOrCreateType(ResultTy, F));
 // "self" pointer is always first argument.
-QualType SelfDeclTy = OMethod->getSelfDecl()->getType();
-Elts.push_back(CreateSelfType(SelfDeclTy, getOrCreateType(SelfDeclTy, F)));
+QualType SelfDeclTy;
+if (auto *SelfDecl = OMethod->getSelfDecl())
+  SelfDeclTy = SelfDecl->getType();
+else if (auto *FPT = dyn_cast(FnType))
+  if (FPT->getNumParams() > 1)
+SelfDeclTy = FPT->getParamType(0);
+if (!SelfDeclTy.isNull())
+  Elts.push_back(CreateSelfType(SelfDeclTy, getOrCreateType(SelfDeclTy, 
F)));
 // "_cmd" pointer is always second argument.
 Elts.push_back(DBuilder.createArtificialType(
-getOrCreateType(OMethod->getCmdDecl()->getType(), F)));
+getOrCreateType(CGM.getContext().getObjCSelType(), F)));
 // Get rest of the arguments.
 for (const auto *PI : OMethod->params())
   Elts.push_back(getOrCreateType(PI->getType(), F));
@@ -2623,6 +2629,49 @@ void CGDebugInfo::EmitFunctionStart(Glob
 RegionMap[D].reset(SP);
 }
 
+void CGDebugInfo::EmitFunctionDecl(GlobalDecl GD, SourceLocation Loc,
+   QualType FnType) {
+  StringRef Name;
+  StringRef LinkageName;
+
+  const Decl *D = GD.getDecl();
+  if (!D)
+return;
+
+  unsigned Flags = 0;
+  llvm::DIFile *Unit = getOrCreateFile(Loc);
+  llvm::DIScope *FDContext = Unit;
+  llvm::DINodeArray TParamsArray;
+  if (isa(D)) {
+// If there is a DISubprogram for this function available then use it.
+collectFunctionDeclProps(GD, Unit, Name, LinkageName, FDContext,
+ TParamsArray, Flags);
+  } else if (const ObjCMethodDecl *OMD = dyn_cast(D)) {
+Name = getObjCMethodName(OMD);
+Flags |= llvm::DINode::FlagPrototyped;
+  } else {
+llvm_unreachable("not a function or ObjC method");
+  }
+  if (!Name.empty() && Name[0] == '\01')
+Name = Name.substr(1);
+
+  if (D->isImplicit()) {
+Flags |= llvm::DINode::FlagArtificial;
+// Artificial functions without a location should not silently reuse 
CurLoc.
+if (Loc.isInvalid())
+  CurLoc = SourceLocation();
+  }
+  unsigned LineNo = getLineNumber(Loc);
+  unsigned ScopeLine = 0;
+
+  DBuilder.createFunction(FDContext, Name, LinkageName, Unit, LineNo,
+  getOrCreateFunctionType(D, FnType, Unit),
+  false /*internalLinkage*/, true /*definition*/,
+  ScopeLine, Flags, CGM.getLangOpts().Optimize, 
nullptr,
+  TParamsArray.get(),
+  getFunctionDeclaration(D));
+}
+
 void CGDebugInfo::EmitLocation(CGBuilderTy &Builder, SourceLocation Loc) {
   // Update our current location
   setLocation(Loc);

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.h?rev=247068&r1=247067&r2=247068&view=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.h (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.h Tue Sep  8 15:41:52 2015
@@ -281,6 +281,9 @@ public:
  SourceLocation ScopeLoc, QualType FnType,
  llvm::Function *Fn, CGBuilderTy &Builder);
 
+  /// Emit debug info for a function declaration.
+  void EmitFunctionDecl(GlobalDecl GD, SourceLocation Loc, QualType FnType);
+
   /// Constructs the debug code for exiting a function.
   void EmitFunctionEnd(CGBuilderTy &Builder);
 

Modified: cfe/trunk/lib/CodeGen/ObjectFilePCHContainerOperations.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/ObjectFilePCHContainerOperations.cpp?rev=247068&r1=247067&r2=247068

Re: [PATCH] D11664: [CUDA] Implemented additional processing steps needed to link with CUDA libdevice bitcode.

[Artem Belevich via cfe-commits]

tra updated the summary for this revision.
tra updated this revision to Diff 34251.
tra added a comment.

Assume (and test) that NVPTX back-end includes NVVMReflect by default.


http://reviews.llvm.org/D11664

Files:
  include/clang/Basic/LangOptions.def
  include/clang/Driver/CC1Options.td
  lib/CodeGen/CodeGenAction.cpp
  lib/Frontend/CompilerInvocation.cpp
  test/CodeGenCUDA/Inputs/device-code.ll
  test/CodeGenCUDA/link-device-bitcode.cu

Index: test/CodeGenCUDA/link-device-bitcode.cu
===
--- /dev/null
+++ test/CodeGenCUDA/link-device-bitcode.cu
@@ -0,0 +1,56 @@
+// Test for linking with CUDA's libdevice as outlined in
+// http://llvm.org/docs/NVPTXUsage.html#linking-with-libdevice
+//
+// REQUIRES: nvptx-registered-target
+//
+// Prepare bitcode file to link with
+// RUN: %clang_cc1 -triple nvptx-unknown-cuda -emit-llvm-bc -o %t.bc \
+// RUN:%S/Inputs/device-code.ll
+//
+// Make sure function in device-code gets linked in and internalized.
+// RUN: %clang_cc1 -triple nvptx-unknown-cuda -fcuda-is-device \
+// RUN:-mlink-bitcode-file %t.bc -fcuda-uses-libdevice -emit-llvm \
+// RUN:-disable-llvm-passes -o - %s \
+// RUN:| FileCheck %s -check-prefix CHECK-IR
+//
+// Make sure function in device-code gets linked but is not internalized
+// without -fcuda-uses-libdevice
+// RUN: %clang_cc1 -triple nvptx-unknown-cuda -fcuda-is-device \
+// RUN:-mlink-bitcode-file %t.bc -emit-llvm \
+// RUN:-disable-llvm-passes -o - %s \
+// RUN:| FileCheck %s -check-prefix CHECK-IR-NLD
+//
+// Make sure NVVMReflect pass is enabled in NVPTX back-end.
+// RUN: %clang_cc1 -triple nvptx-unknown-cuda -fcuda-is-device \
+// RUN:-mlink-bitcode-file %t.bc -fcuda-uses-libdevice -S -o /dev/null %s \
+// RUN:-backend-option -debug-pass=Structure 2>&1 \
+// RUN:| FileCheck %s -check-prefix CHECK-REFLECT
+
+#include "Inputs/cuda.h"
+
+__device__ float device_mul_or_add(float a, float b);
+extern "C" __device__ double __nv_sin(double x);
+extern "C" __device__ double __nv_exp(double x);
+
+// CHECK-IR-LABEL: define void @_Z26should_not_be_internalizedPf(
+// CHECK-PTX-LABEL: .visible .func _Z26should_not_be_internalizedPf(
+__device__ void should_not_be_internalized(float *data) {}
+
+// Make sure kernel call has not been internalized.
+// CHECK-IR-LABEL: define void @_Z6kernelPfS_
+// CHECK-PTX-LABEL: .visible .entry _Z6kernelPfS_(
+__global__ __attribute__((used)) void kernel(float *out, float *in) {
+  *out = device_mul_or_add(in[0], in[1]);
+  *out += __nv_exp(__nv_sin(*out));
+  should_not_be_internalized(out);
+}
+
+// Make sure device_mul_or_add() is present in IR, is internal and
+// calls __nvvm_reflect().
+// CHECK-IR-LABEL: define internal float @_Z17device_mul_or_addff(
+// CHECK-IR-NLD-LABEL: define float @_Z17device_mul_or_addff(
+// CHECK-IR: call i32 @__nvvm_reflect
+// CHECK-IR: ret float
+
+// Verify that NVVMReflect pass is among the passes run by NVPTX back-end.
+// CHECK-REFLECT: Replace occurrences of __nvvm_reflect() calls with 0/1
Index: test/CodeGenCUDA/Inputs/device-code.ll
===
--- /dev/null
+++ test/CodeGenCUDA/Inputs/device-code.ll
@@ -0,0 +1,38 @@
+; Simple bit of IR to mimic CUDA's libdevice. We want to be
+; able to link with it and we need to make sure all __nvvm_reflect
+; calls are eliminated by the time PTX has been produced.
+
+target triple = "nvptx-unknown-cuda"
+
+declare i32 @__nvvm_reflect(i8*)
+
+@"$str" = private addrspace(1) constant [8 x i8] c"USE_MUL\00"
+
+define void @unused_subfunc(float %a) {
+   ret void
+}
+
+define void @used_subfunc(float %a) {
+   ret void
+}
+
+define float @_Z17device_mul_or_addff(float %a, float %b) {
+  %reflect = call i32 @__nvvm_reflect(i8* addrspacecast (i8 addrspace(1)* getelementptr inbounds ([8 x i8], [8 x i8] addrspace(1)* @"$str", i32 0, i32 0) to i8*))
+  %cmp = icmp ne i32 %reflect, 0
+  br i1 %cmp, label %use_mul, label %use_add
+
+use_mul:
+  %ret1 = fmul float %a, %b
+  br label %exit
+
+use_add:
+  %ret2 = fadd float %a, %b
+  br label %exit
+
+exit:
+  %ret = phi float [%ret1, %use_mul], [%ret2, %use_add]
+
+  call void @used_subfunc(float %ret)
+
+  ret float %ret
+}
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -1406,6 +1406,9 @@
   if (Args.hasArg(OPT_fcuda_is_device))
 Opts.CUDAIsDevice = 1;
 
+  if (Args.hasArg(OPT_fcuda_uses_libdevice))
+Opts.CUDAUsesLibDevice = 1;
+
   if (Args.hasArg(OPT_fcuda_allow_host_calls_from_host_device))
 Opts.CUDAAllowHostCallsFromHostDevice = 1;
 
Index: lib/CodeGen/CodeGenAction.cpp
===
--- lib/CodeGen/CodeGenAction.cpp
+++ lib/CodeGen/CodeGenAction.cpp
@@ -26,14 +26,16 @@
 #include "llvm/IR/DebugInfo.h"
 #include "llvm/

Re: [PATCH] D11664: [CUDA] Implemented additional processing steps needed to link with CUDA libdevice bitcode.

[Eric Christopher via cfe-commits]

echristo added a comment.

Works for me, thanks.


http://reviews.llvm.org/D11664



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

Re: [PATCH] D12701: [Static Analyzer] Objective-C Generics checker improvements.

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

xazax.hun marked 2 inline comments as done.
xazax.hun added a comment.

http://reviews.llvm.org/D12701



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

r247075 - Collect SEH captures in a set instead of a vector to avoid

[John McCall via cfe-commits]

Author: rjmccall
Date: Tue Sep  8 16:15:22 2015
New Revision: 247075

URL: http://llvm.org/viewvc/llvm-project?rev=247075&view=rev
Log:
Collect SEH captures in a set instead of a vector to avoid
doing redundant work if a variable is used multiple times.

Fixes PR24751.

Modified:
cfe/trunk/lib/CodeGen/CGException.cpp
cfe/trunk/test/CodeGen/exceptions-seh.c

Modified: cfe/trunk/lib/CodeGen/CGException.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGException.cpp?rev=247075&r1=247074&r2=247075&view=diff
==
--- cfe/trunk/lib/CodeGen/CGException.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGException.cpp Tue Sep  8 16:15:22 2015
@@ -1433,7 +1433,7 @@ namespace {
 struct CaptureFinder : ConstStmtVisitor {
   CodeGenFunction &ParentCGF;
   const VarDecl *ParentThis;
-  SmallVector Captures;
+  llvm::SmallSetVector Captures;
   Address SEHCodeSlot = Address::invalid();
   CaptureFinder(CodeGenFunction &ParentCGF, const VarDecl *ParentThis)
   : ParentCGF(ParentCGF), ParentThis(ParentThis) {}
@@ -1454,17 +1454,17 @@ struct CaptureFinder : ConstStmtVisitor<
   void VisitDeclRefExpr(const DeclRefExpr *E) {
 // If this is already a capture, just make sure we capture 'this'.
 if (E->refersToEnclosingVariableOrCapture()) {
-  Captures.push_back(ParentThis);
+  Captures.insert(ParentThis);
   return;
 }
 
 const auto *D = dyn_cast(E->getDecl());
 if (D && D->isLocalVarDeclOrParm() && D->hasLocalStorage())
-  Captures.push_back(D);
+  Captures.insert(D);
   }
 
   void VisitCXXThisExpr(const CXXThisExpr *E) {
-Captures.push_back(ParentThis);
+Captures.insert(ParentThis);
   }
 
   void VisitCallExpr(const CallExpr *E) {

Modified: cfe/trunk/test/CodeGen/exceptions-seh.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/exceptions-seh.c?rev=247075&r1=247074&r2=247075&view=diff
==
--- cfe/trunk/test/CodeGen/exceptions-seh.c (original)
+++ cfe/trunk/test/CodeGen/exceptions-seh.c Tue Sep  8 16:15:22 2015
@@ -230,4 +230,34 @@ int except_return(void) {
 // CHECK: %[[r:[^ ]*]] = load i32, i32* %[[rv]]
 // CHECK: ret i32 %[[r]]
 
+
+// PR 24751: don't assert if a variable is used twice in a __finally block.
+// Also, make sure we don't do redundant work to capture/project it.
+void finally_capture_twice(int x) {
+  __try {
+  } __finally {
+int y = x;
+int z = x;
+  }
+}
+//  
+// CHECK-LABEL: define void @finally_capture_twice(
+// CHECK: [[X:%.*]] = alloca i32, align 4
+// CHECK: call void (...) @llvm.localescape(i32* [[X]])
+// CHECK-NEXT:store i32 {{.*}}, i32* [[X]], align 4
+// CHECK-NEXT:[[LOCAL:%.*]] = call i8* @llvm.localaddress()
+// CHECK-NEXT:call void [[FINALLY:@.*]](i8{{ zeroext | }}0, i8* [[LOCAL]])
+// CHECK:   define internal void [[FINALLY]](
+// CHECK: [[LOCAL:%.*]] = call i8* @llvm.localrecover(
+// CHECK: [[X:%.*]] = bitcast i8* [[LOCAL]] to i32*
+// CHECK-NEXT:[[Y:%.*]] = alloca i32, align 4
+// CHECK-NEXT:[[Z:%.*]] = alloca i32, align 4
+// CHECK-NEXT:store i8*
+// CHECK-NEXT:store i8
+// CHECK-NEXT:[[T0:%.*]] = load i32, i32* [[X]], align 4
+// CHECK-NEXT:store i32 [[T0]], i32* [[Y]], align 4
+// CHECK-NEXT:[[T0:%.*]] = load i32, i32* [[X]], align 4
+// CHECK-NEXT:store i32 [[T0]], i32* [[Z]], align 4
+// CHECK-NEXT:ret void
+
 // CHECK: attributes #[[NOINLINE]] = { {{.*noinline.*}} }


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

[PATCH] D12708: [PATCH] [AArch64] Enable memory sanitizer on clang

[Adhemerval Zanella via cfe-commits]

zatrazz created this revision.
zatrazz added reviewers: t.p.northover, aemerson, pcc, rengolin.
zatrazz added a subscriber: cfe-commits.
Herald added subscribers: rengolin, aemerson.

This patch enables MSan for aarch64/linux.

http://reviews.llvm.org/D12708

Files:
  lib/Driver/ToolChains.cpp

Index: lib/Driver/ToolChains.cpp
===
--- lib/Driver/ToolChains.cpp
+++ lib/Driver/ToolChains.cpp
@@ -3736,7 +3736,7 @@
 Res |= SanitizerKind::Leak;
   if (IsX86_64 || IsMIPS64 || IsAArch64)
 Res |= SanitizerKind::Thread;
-  if (IsX86_64 || IsMIPS64 || IsPowerPC64)
+  if (IsX86_64 || IsMIPS64 || IsPowerPC64 || IsAArch64)
 Res |= SanitizerKind::Memory;
   if (IsX86 || IsX86_64) {
 Res |= SanitizerKind::Function;


Index: lib/Driver/ToolChains.cpp
===
--- lib/Driver/ToolChains.cpp
+++ lib/Driver/ToolChains.cpp
@@ -3736,7 +3736,7 @@
 Res |= SanitizerKind::Leak;
   if (IsX86_64 || IsMIPS64 || IsAArch64)
 Res |= SanitizerKind::Thread;
-  if (IsX86_64 || IsMIPS64 || IsPowerPC64)
+  if (IsX86_64 || IsMIPS64 || IsPowerPC64 || IsAArch64)
 Res |= SanitizerKind::Memory;
   if (IsX86 || IsX86_64) {
 Res |= SanitizerKind::Function;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D12571: [Analyzer] Fix assertions in commit r246345 (pr22954).

[Devin Coughlin via cfe-commits]

dcoughlin added inline comments.


Comment at: lib/StaticAnalyzer/Checkers/CStringChecker.cpp:843
@@ +842,3 @@
+  if (!Length)
+return true;
+

There doesn't seem to be a test that cares about this returning true (as 
compared to false).


Comment at: lib/StaticAnalyzer/Checkers/CStringChecker.cpp:855
@@ +854,3 @@
+  if (!BufLoc)
+return true;
+

There doesn't appear to be a test that cares about this returning true (as 
compared to false).


Comment at: lib/StaticAnalyzer/Checkers/CStringChecker.cpp:863
@@ +862,3 @@
+  if (!R)
+return true;
+

What's the rationale for treating the array access as in-bounds if the BufEnd 
is unknown? Or if LengthValue is unknown? Should these branches return false? 
Either way, can you add a comment explaining why this is the right thing to do 
and also update the doc comment of IsFirstBufInBound to reflect this behavior 
(e.g., "Returns true if destination buffer of copy function must/may be in 
bound")


Comment at: lib/StaticAnalyzer/Core/RegionStore.cpp:1109
@@ +1108,3 @@
+  }
+  assert(RO.getOffset() >= 0 && "Offset should not be negative");
+  uint64_t LowerOffset = RO.getOffset();

This assertion is triggering on our internal build bots. I'm working to get a 
reduced test case.


Comment at: test/Analysis/pr22954.c:739
@@ +738,3 @@
+// Test tainted values.
+struct yy {
+  char s1[4];

A question: how does this test tainted values?


http://reviews.llvm.org/D12571



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

Re: [PATCH] D12624: Top-level anonymous namespaces are missing import DW_TAG_imported_module and nested anonymous namespaces are not

[Paul Robinson via cfe-commits]

probinson added inline comments.


Comment at: lib/CodeGen/CGDebugInfo.cpp:3263-3264
@@ +3262,4 @@
+  const NamespaceDecl *NSDecl = UD.getNominatedNamespace();
+  if (!NSDecl->isAnonymousNamespace() || 
+  CGM.getTarget().getTriple().isPS4CPU()) { 
+DBuilder.createImportedModule(

rsmith wrote:
> I think we should do this unconditionally, to better match the source 
> language semantics, but I'm curious what David, Eric, and other folks on the 
> DWARF side think.
David (in previous discussions and review comments) has said he thinks it is 
unnecessary as the debugger already must know so much about C++ to get various 
things right, it might as well know that it has to implicitly import the 
anonymous namespace contents.  One example debugger UI allows the user to type 
source-like syntax, and requires the debugger to apply (for example) C++ 
parameter-type matching rules to distinguish between overloaded functions.  
Compared to this, implicit imports are child's play.

I believe Eric agrees with David; I don't remember whether Adrian said anything 
in the previous iterations of this patch.

I believe the explicit (although artificial) import is a good thing, because it 
matches the source language semantics.  I find an important distinction between 
"which declarations are available in this scope" and "how does the user 
disambiguate declarations in this scope."  As a counterpart to the above 
debugger UI example, I postulate a GUI drop-down list of symbols available 
in-scope; this UI needs to know nothing about language semantics and automatic 
imports, if the DWARF provides the correct explicit import.  This suggests to 
me that the DWARF should provide it.

There's also the piddly detail that debuggers are not the only consumers of 
DWARF information, and presenting the DWARF in a more source-language-neutral 
way (i.e., with the explicit artificial import) could be beneficial for those 
other consumers, who might not necessarily want to learn language-specific 
scoping rules.

No debugger will be thrown for a loop if it sees the explicit import; however 
for some debuggers it would be redundant (because they implicitly import the 
anonymous namespace already).  There is a pretty trivial space savings if it's 
omitted.

Katya has mentioned the GCC and ICC precedent; in fairness I will say GCC 
didn't used to emit this, and GDB tolerated that.

Note that the DWARF standard does not tell us what to do; it merely tells us 
how to emit the import, if we want to emit one.  Whether we want to emit one is 
up to us.



http://reviews.llvm.org/D12624



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

r247081 - Remove unneeded #include.

[Adrian Prantl via cfe-commits]

Author: adrian
Date: Tue Sep  8 17:06:40 2015
New Revision: 247081

URL: http://llvm.org/viewvc/llvm-project?rev=247081&view=rev
Log:
Remove unneeded #include.

Modified:
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=247081&r1=247080&r2=247081&view=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Tue Sep  8 17:06:40 2015
@@ -37,7 +37,6 @@
 #include "llvm/IR/Instructions.h"
 #include "llvm/IR/Intrinsics.h"
 #include "llvm/IR/Module.h"
-#include "llvm/Support/Dwarf.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Path.h"
 using namespace clang;


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

r247093 - clang/test/Modules/ModuleDebugInfo.cpp: Add -triple %itanium to appease ms-targeted builds.

[NAKAMURA Takumi via cfe-commits]

Author: chapuni
Date: Tue Sep  8 17:47:32 2015
New Revision: 247093

URL: http://llvm.org/viewvc/llvm-project?rev=247093&view=rev
Log:
clang/test/Modules/ModuleDebugInfo.cpp: Add -triple %itanium to appease 
ms-targeted builds.

I think DebugInfo tests may avoid MS stuff for now.

Modified:
cfe/trunk/test/Modules/ModuleDebugInfo.cpp

Modified: cfe/trunk/test/Modules/ModuleDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/ModuleDebugInfo.cpp?rev=247093&r1=247092&r2=247093&view=diff
==
--- cfe/trunk/test/Modules/ModuleDebugInfo.cpp (original)
+++ cfe/trunk/test/Modules/ModuleDebugInfo.cpp Tue Sep  8 17:47:32 2015
@@ -5,11 +5,11 @@
 
 // Modules:
 // RUN: rm -rf %t
-// RUN: %clang_cc1 -x objective-c++ -std=c++11 -g -fmodules 
-fmodule-format=obj -fimplicit-module-maps -DMODULES -fmodules-cache-path=%t %s 
-I %S/Inputs -I %t -emit-llvm -o %t.ll -mllvm -debug-only=pchcontainer 
&>%t-mod.ll
+// RUN: %clang_cc1 -triple %itanium_abi_triple -x objective-c++ -std=c++11 -g 
-fmodules -fmodule-format=obj -fimplicit-module-maps -DMODULES 
-fmodules-cache-path=%t %s -I %S/Inputs -I %t -emit-llvm -o %t.ll -mllvm 
-debug-only=pchcontainer &>%t-mod.ll
 // RUN: cat %t-mod.ll | FileCheck %s
 
 // PCH:
-// RUN: %clang_cc1 -x c++ -std=c++11 -emit-pch -fmodule-format=obj -I 
%S/Inputs -o %t.pch %S/Inputs/DebugCXX.h -mllvm -debug-only=pchcontainer 
&>%t-pch.ll
+// RUN: %clang_cc1 -triple %itanium_abi_triple -x c++ -std=c++11 -emit-pch 
-fmodule-format=obj -I %S/Inputs -o %t.pch %S/Inputs/DebugCXX.h -mllvm 
-debug-only=pchcontainer &>%t-pch.ll
 // RUN: cat %t-pch.ll | FileCheck %s
 
 #ifdef MODULES


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

Re: [PATCH] D12624: Top-level anonymous namespaces are missing import DW_TAG_imported_module and nested anonymous namespaces are not

[Richard Smith via cfe-commits]

rsmith added inline comments.


Comment at: lib/CodeGen/CGDebugInfo.cpp:3263-3264
@@ +3262,4 @@
+  const NamespaceDecl *NSDecl = UD.getNominatedNamespace();
+  if (!NSDecl->isAnonymousNamespace() || 
+  CGM.getTarget().getTriple().isPS4CPU()) { 
+DBuilder.createImportedModule(

probinson wrote:
> rsmith wrote:
> > I think we should do this unconditionally, to better match the source 
> > language semantics, but I'm curious what David, Eric, and other folks on 
> > the DWARF side think.
> David (in previous discussions and review comments) has said he thinks it is 
> unnecessary as the debugger already must know so much about C++ to get 
> various things right, it might as well know that it has to implicitly import 
> the anonymous namespace contents.  One example debugger UI allows the user to 
> type source-like syntax, and requires the debugger to apply (for example) C++ 
> parameter-type matching rules to distinguish between overloaded functions.  
> Compared to this, implicit imports are child's play.
> 
> I believe Eric agrees with David; I don't remember whether Adrian said 
> anything in the previous iterations of this patch.
> 
> I believe the explicit (although artificial) import is a good thing, because 
> it matches the source language semantics.  I find an important distinction 
> between "which declarations are available in this scope" and "how does the 
> user disambiguate declarations in this scope."  As a counterpart to the above 
> debugger UI example, I postulate a GUI drop-down list of symbols available 
> in-scope; this UI needs to know nothing about language semantics and 
> automatic imports, if the DWARF provides the correct explicit import.  This 
> suggests to me that the DWARF should provide it.
> 
> There's also the piddly detail that debuggers are not the only consumers of 
> DWARF information, and presenting the DWARF in a more source-language-neutral 
> way (i.e., with the explicit artificial import) could be beneficial for those 
> other consumers, who might not necessarily want to learn language-specific 
> scoping rules.
> 
> No debugger will be thrown for a loop if it sees the explicit import; however 
> for some debuggers it would be redundant (because they implicitly import the 
> anonymous namespace already).  There is a pretty trivial space savings if 
> it's omitted.
> 
> Katya has mentioned the GCC and ICC precedent; in fairness I will say GCC 
> didn't used to emit this, and GDB tolerated that.
> 
> Note that the DWARF standard does not tell us what to do; it merely tells us 
> how to emit the import, if we want to emit one.  Whether we want to emit one 
> is up to us.
> 
I've chatted to David about this offline, and he said largely similar things. 
It seems that different DWARF consumers will want and expect different things 
here, so (sadly) we should do different things depending on who we think will 
be consuming the DWARF.

I'm fine keeping this conditional, but I don't think IR generation should be 
making this decision based on the triple, so I'd prefer it was phrased in a 
different way: add a CodeGenOpt for whether to emit imports for anonymous 
namespaces, and enable it for PS4 targets from the frontend.


http://reviews.llvm.org/D12624



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

r247098 - CodeGen: Introduce CodeGenModule::CreateMetadataIdentifierForType.

[Peter Collingbourne via cfe-commits]

Author: pcc
Date: Tue Sep  8 18:01:30 2015
New Revision: 247098

URL: http://llvm.org/viewvc/llvm-project?rev=247098&view=rev
Log:
CodeGen: Introduce CodeGenModule::CreateMetadataIdentifierForType.

This function can be used to create a metadata identifier for a specific
type. No functionality change, but this will be used by D11857 and D12026.

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

Modified:
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/lib/CodeGen/CodeGenModule.h

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=247098&r1=247097&r2=247098&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Tue Sep  8 18:01:30 2015
@@ -3803,6 +3803,25 @@ void CodeGenModule::EmitOMPThreadPrivate
   }
 }
 
+llvm::Metadata *CodeGenModule::CreateMetadataIdentifierForType(QualType T) {
+  llvm::Metadata *&InternalId = MetadataIdMap[T.getCanonicalType()];
+  if (InternalId)
+return InternalId;
+
+  if (isExternallyVisible(T->getLinkage())) {
+std::string OutName;
+llvm::raw_string_ostream Out(OutName);
+getCXXABI().getMangleContext().mangleTypeName(T, Out);
+
+InternalId = llvm::MDString::get(getLLVMContext(), Out.str());
+  } else {
+InternalId = llvm::MDNode::getDistinct(getLLVMContext(),
+   llvm::ArrayRef());
+  }
+
+  return InternalId;
+}
+
 llvm::MDTuple *CodeGenModule::CreateVTableBitSetEntry(
 llvm::GlobalVariable *VTable, CharUnits Offset, const CXXRecordDecl *RD) {
   std::string OutName;

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.h?rev=247098&r1=247097&r2=247098&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.h (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.h Tue Sep  8 18:01:30 2015
@@ -483,6 +483,12 @@ private:
   llvm::DenseMap DeferredEmptyCoverageMappingDecls;
 
   std::unique_ptr CoverageMapping;
+
+  /// Mapping from canonical types to their metadata identifiers. We need to
+  /// maintain this mapping because identifiers may be formed from distinct
+  /// MDNodes.
+  llvm::DenseMap MetadataIdMap;
+
 public:
   CodeGenModule(ASTContext &C, const HeaderSearchOptions &headersearchopts,
 const PreprocessorOptions &ppopts,
@@ -1112,6 +1118,11 @@ public:
   void EmitVTableBitSetEntries(llvm::GlobalVariable *VTable,
const VTableLayout &VTLayout);
 
+  /// Create a metadata identifier for the given type. This may either be an
+  /// MDString (for external identifiers) or a distinct unnamed MDNode (for
+  /// internal identifiers).
+  llvm::Metadata *CreateMetadataIdentifierForType(QualType T);
+
   /// Create a bitset entry for the given vtable.
   llvm::MDTuple *CreateVTableBitSetEntry(llvm::GlobalVariable *VTable,
  CharUnits Offset,


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

Re: [PATCH] D12038: CodeGen: Introduce CodeGenModule::CreateMetadataIdentifierForType.

[Peter Collingbourne via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL247098: CodeGen: Introduce 
CodeGenModule::CreateMetadataIdentifierForType. (authored by pcc).

Changed prior to commit:
  http://reviews.llvm.org/D12038?vs=32173&id=34276#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D12038

Files:
  cfe/trunk/lib/CodeGen/CodeGenModule.cpp
  cfe/trunk/lib/CodeGen/CodeGenModule.h

Index: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
===
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp
@@ -3803,6 +3803,25 @@
   }
 }
 
+llvm::Metadata *CodeGenModule::CreateMetadataIdentifierForType(QualType T) {
+  llvm::Metadata *&InternalId = MetadataIdMap[T.getCanonicalType()];
+  if (InternalId)
+return InternalId;
+
+  if (isExternallyVisible(T->getLinkage())) {
+std::string OutName;
+llvm::raw_string_ostream Out(OutName);
+getCXXABI().getMangleContext().mangleTypeName(T, Out);
+
+InternalId = llvm::MDString::get(getLLVMContext(), Out.str());
+  } else {
+InternalId = llvm::MDNode::getDistinct(getLLVMContext(),
+   llvm::ArrayRef());
+  }
+
+  return InternalId;
+}
+
 llvm::MDTuple *CodeGenModule::CreateVTableBitSetEntry(
 llvm::GlobalVariable *VTable, CharUnits Offset, const CXXRecordDecl *RD) {
   std::string OutName;
Index: cfe/trunk/lib/CodeGen/CodeGenModule.h
===
--- cfe/trunk/lib/CodeGen/CodeGenModule.h
+++ cfe/trunk/lib/CodeGen/CodeGenModule.h
@@ -483,6 +483,12 @@
   llvm::DenseMap DeferredEmptyCoverageMappingDecls;
 
   std::unique_ptr CoverageMapping;
+
+  /// Mapping from canonical types to their metadata identifiers. We need to
+  /// maintain this mapping because identifiers may be formed from distinct
+  /// MDNodes.
+  llvm::DenseMap MetadataIdMap;
+
 public:
   CodeGenModule(ASTContext &C, const HeaderSearchOptions &headersearchopts,
 const PreprocessorOptions &ppopts,
@@ -1112,6 +1118,11 @@
   void EmitVTableBitSetEntries(llvm::GlobalVariable *VTable,
const VTableLayout &VTLayout);
 
+  /// Create a metadata identifier for the given type. This may either be an
+  /// MDString (for external identifiers) or a distinct unnamed MDNode (for
+  /// internal identifiers).
+  llvm::Metadata *CreateMetadataIdentifierForType(QualType T);
+
   /// Create a bitset entry for the given vtable.
   llvm::MDTuple *CreateVTableBitSetEntry(llvm::GlobalVariable *VTable,
  CharUnits Offset,


Index: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
===
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp
@@ -3803,6 +3803,25 @@
   }
 }
 
+llvm::Metadata *CodeGenModule::CreateMetadataIdentifierForType(QualType T) {
+  llvm::Metadata *&InternalId = MetadataIdMap[T.getCanonicalType()];
+  if (InternalId)
+return InternalId;
+
+  if (isExternallyVisible(T->getLinkage())) {
+std::string OutName;
+llvm::raw_string_ostream Out(OutName);
+getCXXABI().getMangleContext().mangleTypeName(T, Out);
+
+InternalId = llvm::MDString::get(getLLVMContext(), Out.str());
+  } else {
+InternalId = llvm::MDNode::getDistinct(getLLVMContext(),
+   llvm::ArrayRef());
+  }
+
+  return InternalId;
+}
+
 llvm::MDTuple *CodeGenModule::CreateVTableBitSetEntry(
 llvm::GlobalVariable *VTable, CharUnits Offset, const CXXRecordDecl *RD) {
   std::string OutName;
Index: cfe/trunk/lib/CodeGen/CodeGenModule.h
===
--- cfe/trunk/lib/CodeGen/CodeGenModule.h
+++ cfe/trunk/lib/CodeGen/CodeGenModule.h
@@ -483,6 +483,12 @@
   llvm::DenseMap DeferredEmptyCoverageMappingDecls;
 
   std::unique_ptr CoverageMapping;
+
+  /// Mapping from canonical types to their metadata identifiers. We need to
+  /// maintain this mapping because identifiers may be formed from distinct
+  /// MDNodes.
+  llvm::DenseMap MetadataIdMap;
+
 public:
   CodeGenModule(ASTContext &C, const HeaderSearchOptions &headersearchopts,
 const PreprocessorOptions &ppopts,
@@ -1112,6 +1118,11 @@
   void EmitVTableBitSetEntries(llvm::GlobalVariable *VTable,
const VTableLayout &VTLayout);
 
+  /// Create a metadata identifier for the given type. This may either be an
+  /// MDString (for external identifiers) or a distinct unnamed MDNode (for
+  /// internal identifiers).
+  llvm::Metadata *CreateMetadataIdentifierForType(QualType T);
+
   /// Create a bitset entry for the given vtable.
   llvm::MDTuple *CreateVTableBitSetEntry(llvm::GlobalVariable *VTable,
  CharUnits Offset,
___
cfe-commits mailing list
cfe-commits@lists

[PATCH] D12712: Implementation and testing for poisoning vtable ptr in dtor.

[Naomi Musgrave via cfe-commits]

nmusgrave created this revision.
nmusgrave added reviewers: eugenis, kcc.
nmusgrave added a subscriber: cfe-commits.

After destruction, invocation of virtual functions prevented
by poisoning vtable pointer.

http://reviews.llvm.org/D12712

Files:
  lib/CodeGen/CGClass.cpp
  test/CodeGenCXX/sanitize-dtor-derived-class.cpp
  test/CodeGenCXX/sanitize-dtor-vtable.cpp

Index: test/CodeGenCXX/sanitize-dtor-vtable.cpp
===
--- /dev/null
+++ test/CodeGenCXX/sanitize-dtor-vtable.cpp
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -O0 -fsanitize=memory -fsanitize-memory-use-after-dtor 
-disable-llvm-optzns -std=c++11 -triple=x86_64-pc-linux -emit-llvm -o - %s | 
FileCheck %s
+// RUN: %clang_cc1 -O1 -fsanitize=memory -fsanitize-memory-use-after-dtor 
-disable-llvm-optzns -std=c++11 -triple=x86_64-pc-linux -emit-llvm -o - %s | 
FileCheck %s
+
+class A {
+ public:
+  int x;
+  A() {}
+  virtual ~A() {}
+};
+A a;
+
+// CHECK-LABEL: define {{.*}}AD2Ev
+// CHECK: call void @__sanitizer_dtor_callback{{.*}}i64 8
+// CHECK: call void @__sanitizer_dtor_callback
+// CHECK-NOT: call void @__sanitizer_dtor_callback
+// CHECK: ret void
Index: test/CodeGenCXX/sanitize-dtor-derived-class.cpp
===
--- test/CodeGenCXX/sanitize-dtor-derived-class.cpp
+++ test/CodeGenCXX/sanitize-dtor-derived-class.cpp
@@ -52,13 +52,17 @@
 // CHECK-NOT: call void @__sanitizer_dtor_callback
 // CHECK: ret void
 
+// Poison member and vtable pointer.
 // CHECK-LABEL: define {{.*}}BaseD2Ev
 // CHECK: call void @__sanitizer_dtor_callback
+// CHECK: call void @__sanitizer_dtor_callback
 // CHECK-NOT: call void @__sanitizer_dtor_callback
 // CHECK: ret void
 
+// Poison member and vtable pointer.
 // CHECK-LABEL: define {{.*}}DerivedD2Ev
 // CHECK: call void @__sanitizer_dtor_callback
+// CHECK: call void @__sanitizer_dtor_callback
 // CHECK-NOT: call void @__sanitizer_dtor_callback
 // CHECK: call void {{.*}}BaseD2Ev
 // CHECK-NOT: call void @__sanitizer_dtor_callback
Index: lib/CodeGen/CGClass.cpp
===
--- lib/CodeGen/CGClass.cpp
+++ lib/CodeGen/CGClass.cpp
@@ -1668,9 +1668,20 @@
   // Prevent the current stack frame from disappearing from the stack 
trace.
   CGF.CurFn->addFnAttr("disable-tail-calls", "true");
 
+  ASTContext &Context = CGF.getContext();
+  // Poison vtable and vtable ptr if they exist for this class.
+  if (Dtor->getParent()->isDynamicClass()) {
+llvm::Value *VTablePtr = CGF.LoadCXXThis();
+
+CharUnits::QuantityType PoisonSize =
+Context.toCharUnitsFromBits(CGF.PointerWidthInBits).getQuantity();
+// Pass in void pointer and size of region as arguments to runtime
+// function
+Poison(CGF, VTablePtr, PoisonSize);
+  }
+
   // Construct pointer to region to begin poisoning, and calculate poison
   // size, so that only members declared in this class are poisoned.
-  ASTContext &Context = CGF.getContext();
   unsigned fieldIndex = 0;
   int startIndex = -1;
   // RecordDecl::field_iterator Field;
@@ -1732,10 +1743,16 @@
   if (PoisonSize == 0)
 return;
 
+  Poison(CGF, OffsetPtr, PoisonSize);
+}
+
+void Poison(CodeGenFunction &CGF, llvm::Value *OffsetPtr,
+CharUnits::QuantityType PoisonSize) {
   // Pass in void pointer and size of region as arguments to runtime
   // function
-  llvm::Value *Args[] = {CGF.Builder.CreateBitCast(OffsetPtr, 
CGF.VoidPtrTy),
- llvm::ConstantInt::get(CGF.SizeTy, PoisonSize)};
+  llvm::Value *Args[] = {
+  CGF.Builder.CreateBitCast(OffsetPtr, CGF.VoidPtrTy),
+  llvm::ConstantInt::get(CGF.SizeTy, PoisonSize)};
 
   llvm::Type *ArgTypes[] = {CGF.VoidPtrTy, CGF.SizeTy};
 


Index: test/CodeGenCXX/sanitize-dtor-vtable.cpp
===
--- /dev/null
+++ test/CodeGenCXX/sanitize-dtor-vtable.cpp
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -O0 -fsanitize=memory -fsanitize-memory-use-after-dtor -disable-llvm-optzns -std=c++11 -triple=x86_64-pc-linux -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -O1 -fsanitize=memory -fsanitize-memory-use-after-dtor -disable-llvm-optzns -std=c++11 -triple=x86_64-pc-linux -emit-llvm -o - %s | FileCheck %s
+
+class A {
+ public:
+  int x;
+  A() {}
+  virtual ~A() {}
+};
+A a;
+
+// CHECK-LABEL: define {{.*}}AD2Ev
+// CHECK: call void @__sanitizer_dtor_callback{{.*}}i64 8
+// CHECK: call void @__sanitizer_dtor_callback
+// CHECK-NOT: call void @__sanitizer_dtor_callback
+// CHECK: ret void
Index: test/CodeGenCXX/sanitize-dtor-derived-class.cpp
===
--- test/CodeGenCXX/sanitize-dtor-derived-class.cpp
+++ test/CodeGenCXX/sanitize-dtor-derived-class.cpp
@@ -52,13 +52,17 @@
 // CHECK-NOT: call void @__s

Re: [PATCH] D11815: Pass subtarget feature "force-align-stack"

[Akira Hatanaka via cfe-commits]

ahatanak added a comment.

In http://reviews.llvm.org/D11815#238209, @vkalintiris wrote:

> In http://reviews.llvm.org/D11815#237541, @ahatanak wrote:
>
> > In http://reviews.llvm.org/D11815#236368, @vkalintiris wrote:
> >
> > > In http://reviews.llvm.org/D11815#235394, @ahatanak wrote:
> > >
> > > >
> > >
> >
> >
> > The purpose of this patch is to make sure -mstackrealign works when doing 
> > LTO
>
>
> Out of curiosity, I was wondering why dynamic stack realignment isn't enough 
> for LTO. I would guess that the alignment of the data types used under SSE 
> might have a smaller alignment than the one required by the ABI.


I'm not sure if I understood your question, but if you are asking why 
-mstackrealign doesn't work when doing LTO, the reason is much simpler. In 
order to force stack realignment in the backend, ForceStackAlign has to be set 
to true, but that doesn't happen because -force-align-stack isn't passed to 
libLTO (or passed as a plugin option if gold is being used).


http://reviews.llvm.org/D11815



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

r247103 - Revert "[Static Analyzer] BugReporter.cpp:2869: Assertion failed: !RemainingNodes.empty() && "No error node found in the trimmed graph""

[Devin Coughlin via cfe-commits]

Author: dcoughlin
Date: Tue Sep  8 18:50:22 2015
New Revision: 247103

URL: http://llvm.org/viewvc/llvm-project?rev=247103&view=rev
Log:
Revert "[Static Analyzer] BugReporter.cpp:2869: Assertion failed: 
!RemainingNodes.empty() && "No error node found in the trimmed graph""

This is making our internal build bot fail because it results in extra warnings 
being
emitted past what should be sink nodes. (There is actually an example of this 
in the
updated malloc.c test in the reverted commit.)

I'm working on a patch to fix the original issue by adding a new checker API to 
explicitly
create error nodes. This API will ensure that error nodes are always tagged in 
order to
prevent them from being reclaimed.

This reverts commit r246188.

Removed:
cfe/trunk/test/Analysis/PR24184.cpp
Modified:
cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h
cfe/trunk/test/Analysis/malloc.c

Modified: 
cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h?rev=247103&r1=247102&r2=247103&view=diff
==
--- cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h 
(original)
+++ cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h 
Tue Sep  8 18:50:22 2015
@@ -287,10 +287,7 @@ private:
  bool MarkAsSink,
  ExplodedNode *P = nullptr,
  const ProgramPointTag *Tag = nullptr) {
-// It may not be safe to use the "Pred" node with no tag because the "Pred"
-// node may be recycled in the reclamation function.
-if (!State || (State == Pred->getState() && !Tag && !MarkAsSink &&
-   Pred->getLocation().getTag()))
+if (!State || (State == Pred->getState() && !Tag && !MarkAsSink))
   return Pred;
 
 Changed = true;

Removed: cfe/trunk/test/Analysis/PR24184.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/PR24184.cpp?rev=247102&view=auto
==
--- cfe/trunk/test/Analysis/PR24184.cpp (original)
+++ cfe/trunk/test/Analysis/PR24184.cpp (removed)
@@ -1,97 +0,0 @@
-// RUN: %clang_cc1 -w -analyze -analyzer-eagerly-assume -fcxx-exceptions 
-analyzer-checker=core 
-analyzer-checker=alpha.core.PointerArithm,alpha.core.CastToStruct 
-analyzer-max-loop 64 -verify %s
-// RUN: %clang_cc1 -w -analyze -analyzer-checker=core 
-analyzer-checker=cplusplus -fcxx-exceptions -analyzer-checker 
alpha.core.PointerArithm,alpha.core.CastToStruct -analyzer-max-loop 63 -verify 
%s
-
-// These tests used to hit an assertion in the bug report. Test case from 
http://llvm.org/PR24184.
-typedef struct {
-  int cbData;
-  unsigned pbData;
-} CRYPT_DATA_BLOB;
-
-typedef enum { DT_NONCE_FIXED } DATA_TYPE;
-int a;
-typedef int *vcreate_t(int *, DATA_TYPE, int, int);
-void fn1(unsigned, unsigned) {
-  char b = 0;
-  for (; 1; a++, &b + a * 0) // expected-warning{{Pointer arithmetic done on 
non-array variables means reliance on memory layout, which is dangerous}}
-;
-}
-
-vcreate_t fn2;
-struct A {
-  CRYPT_DATA_BLOB value;
-  int m_fn1() {
-int c;
-value.pbData == 0;
-fn1(0, 0);
-  }
-};
-struct B {
-  A IkeHashAlg;
-  A IkeGType;
-  A NoncePhase1_r;
-};
-class C {
-  int m_fn2(B *);
-  void m_fn3(B *, int, int, int);
-};
-int C::m_fn2(B *p1) {
-  int *d;
-  int e = p1->IkeHashAlg.m_fn1();
-  unsigned f = p1->IkeGType.m_fn1(), h;
-  int g;
-  d = fn2(0, DT_NONCE_FIXED, (char)0, p1->NoncePhase1_r.value.cbData);
-  h = 0 | 0;
-  m_fn3(p1, 0, 0, 0);
-}
-
-// case 2:
-typedef struct {
-  int cbData;
-  unsigned char *pbData;
-} CRYPT_DATA_BLOB_1;
-typedef unsigned uint32_t;
-void fn1_1(void *p1, const void *p2) { p1 != p2; }
-
-void fn2_1(uint32_t *p1, unsigned char *p2, uint32_t p3) {
-  unsigned i = 0;
-  for (0; i < p3; i++)
-fn1_1(p1 + i, p2 + i * 0);// expected-warning{{Pointer arithmetic done 
on non-array variables means reliance on memory layout, which is dangerous}}
-}
-
-struct A_1 {
-  CRYPT_DATA_BLOB_1 value;
-  uint32_t m_fn1() {
-uint32_t a;
-if (value.pbData)
-  fn2_1(&a, value.pbData, value.cbData);
-return 0;
-  }
-};
-struct {
-  A_1 HashAlgId;
-} *b;
-void fn3() {
-  uint32_t c, d;
-  d = b->HashAlgId.m_fn1();
-  d << 0 | 0 | 0;
-  c = 0;
-  0 | 1 << 0 | 0 && b;
-}
-
-// case 3:
-struct ST {
-  char c;
-};
-char *p;
-int foo1(ST);
-int foo2() {
-  ST *p1 = (ST *)(p);  // expected-warning{{Casting a non-structure type 
to a structure type and accessing a field can lead to memory access errors or 
data corruption}}
-  while (p1->c & 0x0F || p1->c & 0x07)
-p1 = p1 + foo1(*p1);
-}
-
-int foo3(int *node) {
-  int i = foo2();
-  if (i)
-return foo2();
-}
\ No newline at end of file

Modified: cfe/trunk/test/A

r247104 - Introduce __builtin_nontemporal_store and __builtin_nontemporal_load.

[Michael Zolotukhin via cfe-commits]

Author: mzolotukhin
Date: Tue Sep  8 18:52:33 2015
New Revision: 247104

URL: http://llvm.org/viewvc/llvm-project?rev=247104&view=rev
Log:
Introduce __builtin_nontemporal_store and __builtin_nontemporal_load.

Summary:
Currently clang provides no general way to generate nontemporal loads/stores.
There are some architecture specific builtins for doing so (e.g. in x86), but
there is no way to generate non-temporal store on, e.g. AArch64. This patch adds
generic builtins which are expanded to a simple store with '!nontemporal'
attribute in IR.

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

Added:
cfe/trunk/test/CodeGen/Nontemporal.cpp
Modified:
cfe/trunk/include/clang/Basic/Builtins.def
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/lib/CodeGen/CGExpr.cpp
cfe/trunk/lib/CodeGen/CGValue.h
cfe/trunk/lib/CodeGen/CodeGenFunction.h
cfe/trunk/lib/Sema/SemaChecking.cpp

Modified: cfe/trunk/include/clang/Basic/Builtins.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Builtins.def?rev=247104&r1=247103&r2=247104&view=diff
==
--- cfe/trunk/include/clang/Basic/Builtins.def (original)
+++ cfe/trunk/include/clang/Basic/Builtins.def Tue Sep  8 18:52:33 2015
@@ -1245,6 +1245,10 @@ BUILTIN(__builtin_operator_delete, "vv*"
 BUILTIN(__builtin___get_unsafe_stack_start, "v*", "Fn")
 BUILTIN(__builtin___get_unsafe_stack_ptr, "v*", "Fn")
 
+// Nontemporal loads/stores builtins
+BUILTIN(__builtin_nontemporal_store, "v.", "t")
+BUILTIN(__builtin_nontemporal_load, "v.", "t")
+
 #undef BUILTIN
 #undef LIBBUILTIN
 #undef LANGBUILTIN

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=247104&r1=247103&r2=247104&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Tue Sep  8 18:52:33 
2015
@@ -6200,6 +6200,12 @@ def err_atomic_load_store_uses_lib : Err
   "atomic %select{load|store}0 requires runtime support that is not "
   "available for this target">;
 
+def err_nontemporal_builtin_must_be_pointer : Error<
+  "address argument to nontemporal builtin must be a pointer (%0 invalid)">;
+def err_nontemporal_builtin_must_be_pointer_intfltptr_or_vector : Error<
+  "address argument to nontemporal builtin must be a pointer to integer, 
float, "
+  "pointer, or a vector of such types (%0 invalid)">;
+
 def err_deleted_function_use : Error<"attempt to use a deleted function">;
 
 def err_kern_type_not_void_return : Error<

Modified: cfe/trunk/include/clang/Sema/Sema.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=247104&r1=247103&r2=247104&view=diff
==
--- cfe/trunk/include/clang/Sema/Sema.h (original)
+++ cfe/trunk/include/clang/Sema/Sema.h Tue Sep  8 18:52:33 2015
@@ -8851,6 +8851,7 @@ private:
   bool SemaBuiltinLongjmp(CallExpr *TheCall);
   bool SemaBuiltinSetjmp(CallExpr *TheCall);
   ExprResult SemaBuiltinAtomicOverloaded(ExprResult TheCallResult);
+  ExprResult SemaBuiltinNontemporalOverloaded(ExprResult TheCallResult);
   ExprResult SemaAtomicOpsOverloaded(ExprResult TheCallResult,
  AtomicExpr::AtomicOp Op);
   bool SemaBuiltinConstantArg(CallExpr *TheCall, int ArgNum,

Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=247104&r1=247103&r2=247104&view=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Tue Sep  8 18:52:33 2015
@@ -111,6 +111,28 @@ static Value *MakeBinaryAtomicValue(Code
   return EmitFromInt(CGF, Result, T, ValueType);
 }
 
+static Value *EmitNontemporalStore(CodeGenFunction &CGF, const CallExpr *E) {
+  Value *Val = CGF.EmitScalarExpr(E->getArg(0));
+  Value *Address = CGF.EmitScalarExpr(E->getArg(1));
+
+  // Convert the type of the pointer to a pointer to the stored type.
+  Val = CGF.EmitToMemory(Val, E->getArg(0)->getType());
+  Value *BC = CGF.Builder.CreateBitCast(
+  Address, llvm::PointerType::getUnqual(Val->getType()), "cast");
+  LValue LV = CGF.MakeNaturalAlignAddrLValue(BC, E->getArg(0)->getType());
+  LV.setNontemporal(true);
+  CGF.EmitStoreOfScalar(Val, LV, false);
+  return nullptr;
+}
+
+static Value *EmitNontemporalLoad(CodeGenFunction &CGF, const CallExpr *E) {
+  Value *Address = CGF.EmitScalarExpr(E->getArg(0));
+
+  LValue LV = CGF.MakeNaturalAlignAddrLValue(Address, E->getType());
+  LV.setNontemporal(true);
+  return CGF.EmitLoadOfScalar(LV, E->getEx

Re: [PATCH] D12313: Introduce __builtin_nontemporal_store and __builtin_nontemporal_load.

[Michael Zolotukhin via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL247104: Introduce __builtin_nontemporal_store and 
__builtin_nontemporal_load. (authored by mzolotukhin).

Changed prior to commit:
  http://reviews.llvm.org/D12313?vs=33492&id=34281#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D12313

Files:
  cfe/trunk/include/clang/Basic/Builtins.def
  cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
  cfe/trunk/include/clang/Sema/Sema.h
  cfe/trunk/lib/CodeGen/CGBuiltin.cpp
  cfe/trunk/lib/CodeGen/CGExpr.cpp
  cfe/trunk/lib/CodeGen/CGValue.h
  cfe/trunk/lib/CodeGen/CodeGenFunction.h
  cfe/trunk/lib/Sema/SemaChecking.cpp
  cfe/trunk/test/CodeGen/Nontemporal.cpp

Index: cfe/trunk/include/clang/Sema/Sema.h
===
--- cfe/trunk/include/clang/Sema/Sema.h
+++ cfe/trunk/include/clang/Sema/Sema.h
@@ -8851,6 +8851,7 @@
   bool SemaBuiltinLongjmp(CallExpr *TheCall);
   bool SemaBuiltinSetjmp(CallExpr *TheCall);
   ExprResult SemaBuiltinAtomicOverloaded(ExprResult TheCallResult);
+  ExprResult SemaBuiltinNontemporalOverloaded(ExprResult TheCallResult);
   ExprResult SemaAtomicOpsOverloaded(ExprResult TheCallResult,
  AtomicExpr::AtomicOp Op);
   bool SemaBuiltinConstantArg(CallExpr *TheCall, int ArgNum,
Index: cfe/trunk/include/clang/Basic/Builtins.def
===
--- cfe/trunk/include/clang/Basic/Builtins.def
+++ cfe/trunk/include/clang/Basic/Builtins.def
@@ -1245,6 +1245,10 @@
 BUILTIN(__builtin___get_unsafe_stack_start, "v*", "Fn")
 BUILTIN(__builtin___get_unsafe_stack_ptr, "v*", "Fn")
 
+// Nontemporal loads/stores builtins
+BUILTIN(__builtin_nontemporal_store, "v.", "t")
+BUILTIN(__builtin_nontemporal_load, "v.", "t")
+
 #undef BUILTIN
 #undef LIBBUILTIN
 #undef LANGBUILTIN
Index: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
===
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
@@ -6200,6 +6200,12 @@
   "atomic %select{load|store}0 requires runtime support that is not "
   "available for this target">;
 
+def err_nontemporal_builtin_must_be_pointer : Error<
+  "address argument to nontemporal builtin must be a pointer (%0 invalid)">;
+def err_nontemporal_builtin_must_be_pointer_intfltptr_or_vector : Error<
+  "address argument to nontemporal builtin must be a pointer to integer, float, "
+  "pointer, or a vector of such types (%0 invalid)">;
+
 def err_deleted_function_use : Error<"attempt to use a deleted function">;
 
 def err_kern_type_not_void_return : Error<
Index: cfe/trunk/test/CodeGen/Nontemporal.cpp
===
--- cfe/trunk/test/CodeGen/Nontemporal.cpp
+++ cfe/trunk/test/CodeGen/Nontemporal.cpp
@@ -0,0 +1,48 @@
+// Test frontend handling of nontemporal builtins.
+// RUN: %clang_cc1 -triple x86_64-apple-darwin -emit-llvm %s -o - | FileCheck %s
+
+signed char sc;
+unsigned char uc;
+signed short ss;
+unsigned short us;
+signed int si;
+unsigned int ui;
+signed long long sll;
+unsigned long long ull;
+float f1, f2;
+double d1, d2;
+float __attribute__((vector_size(16))) vf1, vf2;
+char __attribute__((vector_size(8))) vc1, vc2;
+bool b1, b2;
+
+void test_all_sizes(void) // CHECK-LABEL: test_all_sizes
+{
+  __builtin_nontemporal_store(true, &b1); // CHECK: store i8 1, i8* @b1, align 1, !nontemporal
+  __builtin_nontemporal_store(b1, &b2);   // CHECK: store i8{{.*}}, align 1, !nontemporal
+  __builtin_nontemporal_store(1, &uc);// CHECK: store i8{{.*}}align 1, !nontemporal
+  __builtin_nontemporal_store(1, &sc);// CHECK: store i8{{.*}}align 1, !nontemporal
+  __builtin_nontemporal_store(1, &us);// CHECK: store i16{{.*}}align 2, !nontemporal
+  __builtin_nontemporal_store(1, &ss);// CHECK: store i16{{.*}}align 2, !nontemporal
+  __builtin_nontemporal_store(1, &ui);// CHECK: store i32{{.*}}align 4, !nontemporal
+  __builtin_nontemporal_store(1, &si);// CHECK: store i32{{.*}}align 4, !nontemporal
+  __builtin_nontemporal_store(1, &ull);   // CHECK: store i64{{.*}}align 8, !nontemporal
+  __builtin_nontemporal_store(1, &sll);   // CHECK: store i64{{.*}}align 8, !nontemporal
+  __builtin_nontemporal_store(1.0, &f1);  // CHECK: store float{{.*}}align 4, !nontemporal
+  __builtin_nontemporal_store(1.0, &d1);  // CHECK: store double{{.*}}align 8, !nontemporal
+  __builtin_nontemporal_store(vf1, &vf2); // CHECK: store <4 x float>{{.*}}align 16, !nontemporal
+  __builtin_nontemporal_store(vc1, &vc2); // CHECK: store <8 x i8>{{.*}}align 8, !nontemporal
+
+  b1 = __builtin_nontemporal_load(&b2);   // CHECK: load i8{{.*}}align 1, !nontemporal
+  uc = __builtin_nontemporal_load(&sc);   // CHECK: load i8{{.*}}align 1, !nontemporal
+  sc = __builtin_nontemporal_load(&uc);   // CHECK: load i8{{.*}}align 1, !n

Re: [PATCH] D12712: Implementation and testing for poisoning vtable ptr in dtor.

[Evgeniy Stepanov via cfe-commits]

eugenis added inline comments.


Comment at: lib/CodeGen/CGClass.cpp:1671
@@ -1670,1 +1670,3 @@
 
+  ASTContext &Context = CGF.getContext();
+  // Poison vtable and vtable ptr if they exist for this class.

You are poisoning the vtable pointer in the base destructor.
Isn't that too early?
For example, in the following case the vptr would be poisoned before ~A, right?
https://github.com/google/sanitizers/wiki/ThreadSanitizerPopularDataRaces#data-race-on-vptr



http://reviews.llvm.org/D12712



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

r247105 - CodeGen: Add CFI unrelated cast checks to the new pointer code path.

[Peter Collingbourne via cfe-commits]

Author: pcc
Date: Tue Sep  8 19:01:31 2015
New Revision: 247105

URL: http://llvm.org/viewvc/llvm-project?rev=247105&view=rev
Log:
CodeGen: Add CFI unrelated cast checks to the new pointer code path.

Modified:
cfe/trunk/lib/CodeGen/CGExpr.cpp
cfe/trunk/test/CodeGenCXX/cfi-cast.cpp

Modified: cfe/trunk/lib/CodeGen/CGExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGExpr.cpp?rev=247105&r1=247104&r2=247105&view=diff
==
--- cfe/trunk/lib/CodeGen/CGExpr.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGExpr.cpp Tue Sep  8 19:01:31 2015
@@ -820,6 +820,14 @@ Address CodeGenFunction::EmitPointerWith
  getNaturalPointeeTypeAlignment(E->getType(), Source));
 }
 
+if (SanOpts.has(SanitizerKind::CFIUnrelatedCast)) {
+  if (auto PT = E->getType()->getAs())
+EmitVTablePtrCheckForCast(PT->getPointeeType(), Addr.getPointer(),
+  /*MayBeNull=*/true,
+  CodeGenFunction::CFITCK_UnrelatedCast,
+  CE->getLocStart());
+}
+
 return Builder.CreateBitCast(Addr, ConvertType(E->getType()));
   }
   break;

Modified: cfe/trunk/test/CodeGenCXX/cfi-cast.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/cfi-cast.cpp?rev=247105&r1=247104&r2=247105&view=diff
==
--- cfe/trunk/test/CodeGenCXX/cfi-cast.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/cfi-cast.cpp Tue Sep  8 19:01:31 2015
@@ -107,3 +107,19 @@ void vcp(void *p) {
   // CHECK-UCAST-STRICT: [[P:%[^ ]*]] = call i1 @llvm.bitset.test(i8* {{%[^ 
]*}}, metadata !"1C")
   static_cast(p);
 }
+
+// CHECK-UCAST-LABEL: define void @_Z3bcpP1B
+// CHECK-UCAST-STRICT-LABEL: define void @_Z3bcpP1B
+void bcp(B *p) {
+  // CHECK-UCAST: [[P:%[^ ]*]] = call i1 @llvm.bitset.test(i8* {{%[^ ]*}}, 
metadata !"1A")
+  // CHECK-UCAST-STRICT: [[P:%[^ ]*]] = call i1 @llvm.bitset.test(i8* {{%[^ 
]*}}, metadata !"1C")
+  (C *)p;
+}
+
+// CHECK-UCAST-LABEL: define void @_Z8bcp_callP1B
+// CHECK-UCAST-STRICT-LABEL: define void @_Z8bcp_callP1B
+void bcp_call(B *p) {
+  // CHECK-UCAST: [[P:%[^ ]*]] = call i1 @llvm.bitset.test(i8* {{%[^ ]*}}, 
metadata !"1A")
+  // CHECK-UCAST-STRICT: [[P:%[^ ]*]] = call i1 @llvm.bitset.test(i8* {{%[^ 
]*}}, metadata !"1C")
+  ((C *)p)->f();
+}


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

[PATCH] D12716: Reduce PGO Instrumentation binary and profile data size (Patch-2)

[David Li via cfe-commits]

davidxl created this revision.
davidxl added reviewers: cfe-commits, bogner, silvas, xur.

See patch-1 for description

http://reviews.llvm.org/D12716

Files:
  include/clang/Driver/Options.td
  include/clang/Frontend/CodeGenOptions.def
  include/clang/Frontend/CodeGenOptions.h
  lib/CodeGen/BackendUtil.cpp
  lib/CodeGen/CodeGenPGO.cpp
  lib/Driver/Tools.cpp
  lib/Frontend/CompilerInvocation.cpp

Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -457,6 +457,9 @@
   Args.hasArg(OPT_fprofile_instr_generate_EQ);
   Opts.InstrProfileOutput = Args.getLastArgValue(OPT_fprofile_instr_generate_EQ);
   Opts.InstrProfileInput = Args.getLastArgValue(OPT_fprofile_instr_use_EQ);
+  Opts.InstrProfileWithNames =
+Args.hasFlag(OPT_fprofile_instr_with_names, 
+		 OPT_fno_profile_instr_with_names, false);
   Opts.CoverageMapping =
   Args.hasFlag(OPT_fcoverage_mapping, OPT_fno_coverage_mapping, false);
   Opts.DumpCoverageMapping = Args.hasArg(OPT_dump_coverage_mapping);
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -2953,6 +2953,19 @@
 }
   }
 
+  if (Args.hasFlag(options::OPT_fprofile_instr_with_names,
+   options::OPT_fno_profile_instr_with_names, true))
+CmdArgs.push_back("-fprofile-instr-with-names");
+
+  if (!Args.hasFlag(options::OPT_fprofile_instr_with_names,
+   options::OPT_fno_profile_instr_with_names, true) &&
+  Args.hasFlag(options::OPT_fcoverage_mapping,
+   options::OPT_fno_coverage_mapping, false))
+D.Diag(diag::err_drv_argument_only_allowed_with)
+<< "-fno-profile-instr-with-names"
+<< "-fno-coverage-mapping";
+
+
   if (Args.hasArg(options::OPT_ftest_coverage) ||
   Args.hasArg(options::OPT_coverage))
 CmdArgs.push_back("-femit-coverage-notes");
Index: lib/CodeGen/CodeGenPGO.cpp
===
--- lib/CodeGen/CodeGenPGO.cpp
+++ lib/CodeGen/CodeGenPGO.cpp
@@ -69,8 +69,12 @@
Linkage == llvm::GlobalValue::ExternalLinkage)
 Linkage = llvm::GlobalValue::PrivateLinkage;
 
-  auto *Value =
-  llvm::ConstantDataArray::getString(CGM.getLLVMContext(), FuncName, false);
+  StringRef FuncNameOrHash = FuncName;
+  if (!CGM.getCodeGenOpts().InstrProfileWithNames)
+FuncNameOrHash = llvm::MD5HashStr(FuncName);
+
+  auto *Value = llvm::ConstantDataArray::getString(CGM.getLLVMContext(),
+   FuncNameOrHash, false);
   FuncNameVar =
   new llvm::GlobalVariable(CGM.getModule(), Value->getType(), true, Linkage,
Value, "__llvm_profile_name_" + FuncName);
Index: lib/CodeGen/BackendUtil.cpp
===
--- lib/CodeGen/BackendUtil.cpp
+++ lib/CodeGen/BackendUtil.cpp
@@ -406,6 +406,7 @@
 
   if (CodeGenOpts.ProfileInstrGenerate) {
 InstrProfOptions Options;
+Options.IncludeNamesInProfile = CodeGenOpts.InstrProfileWithNames;
 Options.NoRedZone = CodeGenOpts.DisableRedZone;
 Options.InstrProfileOutput = CodeGenOpts.InstrProfileOutput;
 MPM->add(createInstrProfilingPass(Options));
Index: include/clang/Frontend/CodeGenOptions.h
===
--- include/clang/Frontend/CodeGenOptions.h
+++ include/clang/Frontend/CodeGenOptions.h
@@ -158,6 +158,10 @@
   /// and -fprofile-generate.
   std::string InstrProfileOutput;
 
+  /// Include full assembly names in profile data. If the flag is false,
+  /// the profile data will use MD5 hash string instead
+  bool InstrProfileWithNames;
+
   /// Name of the profile file to use with -fprofile-sample-use.
   std::string SampleProfileFile;
 
Index: include/clang/Frontend/CodeGenOptions.def
===
--- include/clang/Frontend/CodeGenOptions.def
+++ include/clang/Frontend/CodeGenOptions.def
@@ -101,6 +101,7 @@
 
 CODEGENOPT(ProfileInstrGenerate , 1, 0) ///< Instrument code to generate
 ///< execution counts to use with PGO.
+CODEGENOPT(InstrProfileWithNames, 1, 0) ///< Include full names in profile.
 CODEGENOPT(CoverageMapping , 1, 0) ///< Generate coverage mapping regions to
///< enable code coverage analysis.
 CODEGENOPT(DumpCoverageMapping , 1, 0) ///< Dump the generated coverage mapping
Index: include/clang/Driver/Options.td
===
--- include/clang/Driver/Options.td
+++ include/clang/Driver/Options.td
@@ -441,6 +441,12 @@
 def fno_coverage_mapping : Flag<["-"], "fno-coverage-mapping">,
 Group, Flags<[DriverOption]>,
 HelpText<"Disable code coverage analysis">;
+def fprofi

Re: [PATCH] D12313: Introduce __builtin_nontemporal_store and __builtin_nontemporal_load.

[Michael Zolotukhin via cfe-commits]

mzolotukhin added a comment.

Thanks, Hal, Richard!

I committed the patch with requested changes in r247107.

Michael


Repository:
  rL LLVM

http://reviews.llvm.org/D12313



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

Re: [PATCH] D12624: Top-level anonymous namespaces are missing import DW_TAG_imported_module and nested anonymous namespaces are not

[Paul Robinson via cfe-commits]

probinson added inline comments.


Comment at: lib/CodeGen/CGDebugInfo.cpp:3263-3264
@@ +3262,4 @@
+  const NamespaceDecl *NSDecl = UD.getNominatedNamespace();
+  if (!NSDecl->isAnonymousNamespace() || 
+  CGM.getTarget().getTriple().isPS4CPU()) { 
+DBuilder.createImportedModule(

rsmith wrote:
> probinson wrote:
> > rsmith wrote:
> > > I think we should do this unconditionally, to better match the source 
> > > language semantics, but I'm curious what David, Eric, and other folks on 
> > > the DWARF side think.
> > David (in previous discussions and review comments) has said he thinks it 
> > is unnecessary as the debugger already must know so much about C++ to get 
> > various things right, it might as well know that it has to implicitly 
> > import the anonymous namespace contents.  One example debugger UI allows 
> > the user to type source-like syntax, and requires the debugger to apply 
> > (for example) C++ parameter-type matching rules to distinguish between 
> > overloaded functions.  Compared to this, implicit imports are child's play.
> > 
> > I believe Eric agrees with David; I don't remember whether Adrian said 
> > anything in the previous iterations of this patch.
> > 
> > I believe the explicit (although artificial) import is a good thing, 
> > because it matches the source language semantics.  I find an important 
> > distinction between "which declarations are available in this scope" and 
> > "how does the user disambiguate declarations in this scope."  As a 
> > counterpart to the above debugger UI example, I postulate a GUI drop-down 
> > list of symbols available in-scope; this UI needs to know nothing about 
> > language semantics and automatic imports, if the DWARF provides the correct 
> > explicit import.  This suggests to me that the DWARF should provide it.
> > 
> > There's also the piddly detail that debuggers are not the only consumers of 
> > DWARF information, and presenting the DWARF in a more 
> > source-language-neutral way (i.e., with the explicit artificial import) 
> > could be beneficial for those other consumers, who might not necessarily 
> > want to learn language-specific scoping rules.
> > 
> > No debugger will be thrown for a loop if it sees the explicit import; 
> > however for some debuggers it would be redundant (because they implicitly 
> > import the anonymous namespace already).  There is a pretty trivial space 
> > savings if it's omitted.
> > 
> > Katya has mentioned the GCC and ICC precedent; in fairness I will say GCC 
> > didn't used to emit this, and GDB tolerated that.
> > 
> > Note that the DWARF standard does not tell us what to do; it merely tells 
> > us how to emit the import, if we want to emit one.  Whether we want to emit 
> > one is up to us.
> > 
> I've chatted to David about this offline, and he said largely similar things. 
> It seems that different DWARF consumers will want and expect different things 
> here, so (sadly) we should do different things depending on who we think will 
> be consuming the DWARF.
> 
> I'm fine keeping this conditional, but I don't think IR generation should be 
> making this decision based on the triple, so I'd prefer it was phrased in a 
> different way: add a CodeGenOpt for whether to emit imports for anonymous 
> namespaces, and enable it for PS4 targets from the frontend.
I think including the explicit import is not actively harmful to any consumer, 
or to object-file size; but if somebody insists on not having it, okay.

Assuming Katya is willing to invent the CodeGenOpt, I should add that not too 
far down on my to-do list is plumbing the LLVM "debugger tuning" idea up 
through Clang.  We can make the tuning (rather than the triple) set the 
CodeGenOpt when the time comes.



http://reviews.llvm.org/D12624



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

Re: [PATCH] D12652: [Static Analyzer] Lambda support.

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

xazax.hun updated this revision to Diff 34285.
xazax.hun added a comment.

- Updated to newest trunk.
- Moved the feature behind an option.
- Fixed a crash when an operator() of a lambda is analyzed as a top level 
function, and a ThisExpr is referring to the this in the enclosing scope (this 
can only happen when lambda support is turned off).
- Added a new test case for nested lambdas capturing 'this'.


http://reviews.llvm.org/D12652

Files:
  include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
  include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
  lib/StaticAnalyzer/Core/AnalyzerOptions.cpp
  lib/StaticAnalyzer/Core/ExprEngine.cpp
  lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
  lib/StaticAnalyzer/Core/MemRegion.cpp
  test/Analysis/dead-stores.cpp
  test/Analysis/lambdas.cpp
  test/Analysis/temporaries.cpp

Index: test/Analysis/temporaries.cpp
===
--- test/Analysis/temporaries.cpp
+++ test/Analysis/temporaries.cpp
@@ -299,13 +299,7 @@
   void testRecursiveFramesStart() { testRecursiveFrames(false); }
 
   void testLambdas() {
-// This is the test we would like to write:
-// []() { check(NoReturnDtor()); } != nullptr || check(Dtor());
-// But currently the analyzer stops when it encounters a lambda:
-[] {};
-// The CFG for this now looks correct, but we still do not reach the line
-// below.
-clang_analyzer_warnIfReached(); // FIXME: Should warn.
+[]() { check(NoReturnDtor()); } != nullptr || check(Dtor());
   }
 
   void testGnuExpressionStatements(int v) {
Index: test/Analysis/lambdas.cpp
===
--- test/Analysis/lambdas.cpp
+++ test/Analysis/lambdas.cpp
@@ -1,9 +1,167 @@
-// RUN: %clang_cc1 -std=c++11 -fsyntax-only -analyze -analyzer-checker=debug.DumpCFG %s > %t 2>&1
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -analyze -analyzer-checker=core,debug.ExprInspection -analyzer-config inline-lambdas=true -verify %s 
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -analyze -analyzer-checker=core,debug.DumpCFG -analyzer-config inline-lambdas=true %s > %t 2>&1
 // RUN: FileCheck --input-file=%t %s
 
+void clang_analyzer_warnIfReached();
+void clang_analyzer_eval(int);
+
 struct X { X(const X&); };
 void f(X x) { (void) [x]{}; }
 
+
+// Lambda semantics tests.
+
+void basicCapture() {
+  int i = 5;
+  [i]() mutable {
+// clang_analyzer_eval does nothing in inlined functions.
+if (i != 5)
+  clang_analyzer_warnIfReached();
+++i;
+  }();
+  [&i] {
+if (i != 5)
+  clang_analyzer_warnIfReached();
+  }();
+  [&i] {
+if (i != 5)
+  clang_analyzer_warnIfReached();
+i++;
+  }();
+  clang_analyzer_eval(i == 6); // expected-warning{{TRUE}}
+}
+
+void deferredLambdaCall() {
+  int i = 5;
+  auto l1 = [i]() mutable {
+if (i != 5)
+  clang_analyzer_warnIfReached();
+++i;
+  };
+  auto l2 = [&i] {
+if (i != 5)
+  clang_analyzer_warnIfReached();
+  };
+  auto l3 = [&i] {
+if (i != 5)
+  clang_analyzer_warnIfReached();
+i++;
+  };
+  l1();
+  l2();
+  l3();
+  clang_analyzer_eval(i == 6); // expected-warning{{TRUE}}
+}
+
+void multipleCaptures() {
+  int i = 5, j = 5;
+  [i, &j]() mutable {
+if (i != 5 && j != 5)
+  clang_analyzer_warnIfReached();
+++i;
+++j;
+  }();
+  clang_analyzer_eval(i == 5); // expected-warning{{TRUE}}
+  clang_analyzer_eval(j == 6); // expected-warning{{TRUE}}
+  [=]() mutable {
+if (i != 5 && j != 6)
+  clang_analyzer_warnIfReached();
+++i;
+++j;
+  }();
+  clang_analyzer_eval(i == 5); // expected-warning{{TRUE}}
+  clang_analyzer_eval(j == 6); // expected-warning{{TRUE}}
+  [&]() mutable {
+if (i != 5 && j != 6)
+  clang_analyzer_warnIfReached();
+++i;
+++j;
+  }();
+  clang_analyzer_eval(i == 6); // expected-warning{{TRUE}}
+  clang_analyzer_eval(j == 7); // expected-warning{{TRUE}}
+}
+
+void testReturnValue() {
+  int i = 5;
+  auto l = [i] (int a) {
+return i + a;
+  };
+  int b = l(3);
+  clang_analyzer_eval(b == 8); // expected-warning{{TRUE}}
+}
+
+// Nested lambdas.
+
+void testNestedLambdas() {
+  int i = 5;
+  auto l = [i]() mutable {
+[&i]() {
+  ++i;
+}();
+if (i != 6)
+  clang_analyzer_warnIfReached();
+  };
+  l();
+  clang_analyzer_eval(i == 5); // expected-warning{{TRUE}}
+}
+
+// Captured this.
+
+class RandomClass {
+  int i;
+
+  void captureFields() {
+i = 5;
+[this]() {
+  // clang_analyzer_eval does nothing in inlined functions.
+  if (i != 5)
+clang_analyzer_warnIfReached();
+  ++i;
+}();
+clang_analyzer_eval(i == 6); // expected-warning{{TRUE}}
+  }
+};
+
+
+// Nested this capture.
+
+class RandomClass2 {
+  int i;
+
+  void captureFields() {
+i = 5;
+[this]() {
+  // clang_analyzer_eval does nothing in inlined functions.
+  if (i != 5)
+clang_analyzer_warnIfReached();
+  ++i;
+  [this]() {
+// clang_ana

Re: [PATCH] D12462: [PATCH] [clang-tidy] Add inconsistent declaration parameter name check

[Piotr Dziwinski via cfe-commits]

piotrdz updated this revision to Diff 34267.
piotrdz marked 10 inline comments as done.
piotrdz added a comment.

I hope this is the final re-write of my code. In this version, I addressed most 
recent review comments, while also refactoring code to better handle template 
specializations and correctly display diagnostics in case when function 
definition is visible. In the end I had to change over half of the code, but 
perhaps it was worth it.


http://reviews.llvm.org/D12462

Files:
  clang-tidy/readability/CMakeLists.txt
  clang-tidy/readability/InconsistentDeclarationParameterNameCheck.cpp
  clang-tidy/readability/InconsistentDeclarationParameterNameCheck.h
  clang-tidy/readability/ReadabilityTidyModule.cpp
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/readability-inconsistent-declaration-parameter-name.rst
  test/clang-tidy/readability-inconsistent-declaration-parameter-name.cpp

Index: test/clang-tidy/readability-inconsistent-declaration-parameter-name.cpp
===
--- test/clang-tidy/readability-inconsistent-declaration-parameter-name.cpp
+++ test/clang-tidy/readability-inconsistent-declaration-parameter-name.cpp
@@ -0,0 +1,188 @@
+// RUN: %python %S/check_clang_tidy.py %s readability-inconsistent-declaration-parameter-name %t
+
+void consistentFunction(int a, int b, int c);
+void consistentFunction(int a, int b, int c);
+void consistentFunction(int a, int b, int /*c*/);
+void consistentFunction(int /*c*/, int /*c*/, int /*c*/);
+
+//
+
+// CHECK-MESSAGES: :[[@LINE+1]]:6: warning: function 'inconsistentFunction' has 2 other declarations with differently named parameters [readability-inconsistent-declaration-parameter-name]
+void inconsistentFunction(int a, int b, int c);
+// CHECK-MESSAGES: :[[@LINE+2]]:6: note: 1st inconsistent declaration seen here
+// CHECK-MESSAGES: :[[@LINE+1]]:6: note: differing parameters are named here: ('d', 'e', 'f'), while in other declaration: ('a', 'b', 'c')
+void inconsistentFunction(int d, int e, int f);
+// CHECK-MESSAGES: :[[@LINE+2]]:6: note: 2nd inconsistent declaration seen here
+// CHECK-MESSAGES: :[[@LINE+1]]:6: note: differing parameters are named here: ('x', 'y', 'z'), while in other declaration: ('a', 'b', 'c')
+void inconsistentFunction(int x, int y, int z);
+
+//
+
+// CHECK-MESSAGES: :[[@LINE+4]]:6: warning: function 'inconsistentFunctionWithVisibleDefinition' has a definition with differently named parameters [readability-inconsistent-declaration-parameter-name]
+// CHECK-MESSAGES: :[[@LINE+9]]:6: note: definition seen here
+// CHECK-MESSAGES: :[[@LINE+2]]:6: note: differing parameters are named here: ('a'), while in definition: ('c')
+// CHECK-FIXES: void inconsistentFunctionWithVisibleDefinition(int c);
+void inconsistentFunctionWithVisibleDefinition(int a);
+// CHECK-MESSAGES: :[[@LINE+4]]:6: warning: function 'inconsistentFunctionWithVisibleDefinition' has a definition
+// CHECK-MESSAGES: :[[@LINE+4]]:6: note: definition seen here
+// CHECK-MESSAGES: :[[@LINE+2]]:6: note: differing parameters are named here: ('b'), while in definition: ('c')
+// CHECK-FIXES: void inconsistentFunctionWithVisibleDefinition(int c);
+void inconsistentFunctionWithVisibleDefinition(int b);
+void inconsistentFunctionWithVisibleDefinition(int c) { c; }
+
+// CHECK-MESSAGES: :[[@LINE+3]]:6: warning: function 'inconsidentFunctionWithUnreferencedParameterInDefinition' has a definition
+// CHECK-MESSAGES: :[[@LINE+3]]:6: note: definition seen here
+// CHECK-MESSAGES: :[[@LINE+1]]:6: note: differing parameters are named here: ('a'), while in definition: ('b')
+void inconsidentFunctionWithUnreferencedParameterInDefinition(int a);
+void inconsidentFunctionWithUnreferencedParameterInDefinition(int b) {}
+
+//
+
+struct Struct {
+// CHECK-MESSAGES: :[[@LINE+4]]:8: warning: function 'Struct::inconsistentFunction' has a definition
+// CHECK-MESSAGES: :[[@LINE+6]]:14: note: definition seen here
+// CHECK-MESSAGES: :[[@LINE+2]]:8: note: differing parameters are named here: ('a'), while in definition: ('b')
+// CHECK-FIXES: void inconsistentFunction(int b);
+  void inconsistentFunction(int a);
+};
+
+void Struct::inconsistentFunction(int b) { b = 0; }
+
+//
+
+struct SpecialFunctions {
+// CHECK-MESSAGES: :[[@LINE+4]]:3: warning: function 'SpecialFunctions::SpecialFunctions' has a definition
+// CHECK-MESSAGES: :[[@LINE+12]]:19: note: definition seen here
+// CHECK-MESSAGES: :[[@LINE+2]]:3: note: differing parameters are named here: ('a'), while in definition: ('b')
+// CHECK-FIXES: SpecialFunctions(int b);
+  SpecialFunctions(int a);
+
+// CHECK-MESSAGES: :[[@LINE+4]]:21: warning: function 'SpecialFunctions::operator=' has a definition
+// CHECK-MESSAGES: :[[@LINE+8]]:37: note: definition seen here
+// CHECK-MES

Re: [PATCH] D12462: [PATCH] [clang-tidy] Add inconsistent declaration parameter name check

[Piotr Dziwinski via cfe-commits]

piotrdz added a comment.

@alexfh: What do you think now? Are we getting nearer to making a commit?



Comment at: 
clang-tidy/readability/InconsistentDeclarationParameterNameCheck.cpp:60
@@ +59,3 @@
+  bool IsTemplateSpecialization;
+  DifferingParamsContainer DifferingParams;
+};

alexfh wrote:
> That's what I would do as well: the parameter names from the function 
> definition can be the source of truth (maybe only when they are actually 
> _used_ inside the function body, because unused arguments don't tell us 
> much), everything else is more likely to be outdated.
All right. I added a check for whether the parameter is referenced.


Comment at: 
clang-tidy/readability/InconsistentDeclarationParameterNameCheck.cpp:106
@@ +105,3 @@
+  if (IsTemplateSpecialization) {
+// Template specializations need special handling.
+// What we actually see here is a generated declaration from the main

alexfh wrote:
> I don't see why we couldn't just ignore compiler-generated template 
> specializations (hand-written ones should probably be handled). It should be 
> easy to filter them out by adding `unless(isInTemplateInstantiation())` 
> inside the `functionDecl` matcher.
Unfortunately, it doesn't work like that. We get this declaration not from 
matcher, but by iterating redecls().

In any case, I reconsidered this problem, and I came to conclusion that since 
we need special code for handling template specializations, we may as well do 
it properly. The only reason that this version of code works at all, is because 
of incidental generation of this special declaration appearing in the same 
place where we have function specialization. This, I think, should be 
considered a side effect of how AST generation works now, and not how it must 
necessarily work. It may change or even disappear in the future, making this 
code brittle.

To do this correctly, I believe we should retrieve main template declaration by 
using `getPrimaryTemplate()->getTemplatedDecl()` and process that. This fixes 
the issue of wrong location reporting, and also makes it clear what is 
happening to someone reading the code.

So in the end, partly because of this issue, I ended up rewriting over half of 
my code, but what we're left with is I think much better.


Comment at: 
clang-tidy/readability/InconsistentDeclarationParameterNameCheck.cpp:196
@@ +195,3 @@
+  << FunctionDeclaration
+  << static_cast(InconsistentDeclarations.size());
+

alexfh wrote:
> Why is the cast needed here?
Because without it, there is comple error about ambiguous operator<< overload. 
SmallVector::size() returns unsigned long, while DiagnosticBuilder provides 
operator<< overloads only for int and unsigned int.


Comment at: 
clang-tidy/readability/InconsistentDeclarationParameterNameCheck.cpp:213
@@ +212,3 @@
+  [](const DifferingParamInfo &ParamInfo)
+  -> StringRef { return ParamInfo.OtherName; })
+<< joinParameterNames(InconsistentDeclaration.DifferingParams,

alexfh wrote:
> Is there a specific reason to specify the return type here (`-> StringRef`)?
No, I just prefer that style. Anyway, I removed it.


Comment at: 
clang-tidy/readability/InconsistentDeclarationParameterNameCheck.cpp:227
@@ +226,3 @@
+}
+// TODO: Decide what to do if we see only declarations and no definition.
+

alexfh wrote:
> I don't think we can choose any of the declarations as the source of truth. 
> Choosing more frequently used parameter names could work, if there are more 
> than two declarations and just one of them has different names, but this 
> seems to be a corner case rather than a regular practice to have more than 
> two declarations.
> 
> This TODO seems to be the best solution for now.
All right. In new version of code, I moved this comment to extracted function 
checkIfFixItHintIsApplicable() and extended it to document the current 
reasoning.


Comment at: 
test/clang-tidy/readability-inconsistent-declaration-parameter-name.cpp:21
@@ +20,3 @@
+
+// CHECK-MESSAGES: :[[@LINE+5]]:6: warning: function 
'inconsistentFunctionWithVisibleDefinition' has 1 other declaration with 
differently named parameters 
[readability-inconsistent-declaration-parameter-name]
+// CHECK-MESSAGES: :[[@LINE+3]]:6: note: 1st inconsistent declaration seen here

alexfh wrote:
> I've just noticed that the warning appears on the function definition in this 
> case. It would be more logical to issue a separate warning per each 
> declaration where we think the parameter names are wrong. It's easier for the 
> user to understand when the warning shown is where the (likely) incorrect 
> code is, and when the fix is local to the warning (and not applied somewhere 
> in a different file).
> 
> It also works better wi

Re: r246985 - Compute and preserve alignment more faithfully in IR-generation.

[Steven Wu via cfe-commits]

CreateElementBitcast doesn’t seem to do what the name suggested. If you give it 
VTy, it doesn’t grab the element type to generate bitcast. Is this by-design? 
If so, I need to do this:
PtrOp0 = Builder.CreateElementBitCast(PtrOp0, VTy->getElementType()); 

Steven

>> On Sep 8, 2015, at 5:14 PM, Steven Wu > > wrote:
>> Hi John
>> 
>> It seems this commit breaks arm “vld1_lane” intrinsics. When emitting 
>> “vld1_lane” Ops[0] gets updated so PtrOp0 no longer have the same type as 
>> Ops[0].
> 
> Sorry about that.
> 
>> Here a patch for the fix. Can you review it?
> 
> Slight tweak:
> 
>> From daea3a26c6df07530407318e4f0819e6e2ff9aea Mon Sep 17 00:00:00 2001
>> From: Steven Wu mailto:steve...@apple.com>>
>> Date: Tue, 8 Sep 2015 17:10:25 -0700
>> Subject: [PATCH] Fix assertion when emiting NEON builtin
>> 
>> ---
>> lib/CodeGen/CGBuiltin.cpp | 1 +
>> 1 file changed, 1 insertion(+)
>> 
>> diff --git a/lib/CodeGen/CGBuiltin.cpp b/lib/CodeGen/CGBuiltin.cpp
>> index 729c0a1..ed3f9f6 100644
>> --- a/lib/CodeGen/CGBuiltin.cpp
>> +++ b/lib/CodeGen/CGBuiltin.cpp
>> @@ -3772,6 +3772,7 @@ Value *CodeGenFunction::EmitARMBuiltinExpr(unsigned 
>> BuiltinID,
>>Ops[1] = Builder.CreateBitCast(Ops[1], Ty);
>>Ty = llvm::PointerType::getUnqual(VTy->getElementType());
>>Ops[0] = Builder.CreateBitCast(Ops[0], Ty);
> 
> Please remove these two lines and replace them with:
>  PtrOp0 = Builder.CreateElementBitCast(PtrOp0, VTy);
> 
> You then shouldn’t need this line:
> 
>> +PtrOp0 = Address(Ops[0], PtrOp0.getAlignment());
> 
> Thanks!
> 
> John.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r246985 - Compute and preserve alignment more faithfully in IR-generation.

[John McCall via cfe-commits]

> On Sep 8, 2015, at 6:19 PM, Steven Wu  wrote:
> CreateElementBitcast doesn’t seem to do what the name suggested. If you give 
> it VTy, it doesn’t grab the element type to generate bitcast. Is this 
> by-design? If so, I need to do this:
> PtrOp0 = Builder.CreateElementBitCast(PtrOp0, VTy->getElementType());

Yes, I’m sorry, that’s right.  I missed that you were also drilling down to the 
element type.

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

r247117 - Fix vld1_lane intrinsic generation

[Steven Wu via cfe-commits]

Author: steven_wu
Date: Tue Sep  8 20:37:18 2015
New Revision: 247117

URL: http://llvm.org/viewvc/llvm-project?rev=247117&view=rev
Log:
Fix vld1_lane intrinsic generation

Fix a bug introduced in r246985 which causes assertion when generating
vld1_lane.

Modified:
cfe/trunk/lib/CodeGen/CGBuiltin.cpp

Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=247117&r1=247116&r2=247117&view=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Tue Sep  8 20:37:18 2015
@@ -3770,8 +3770,7 @@ Value *CodeGenFunction::EmitARMBuiltinEx
 // fall through
   case NEON::BI__builtin_neon_vld1_lane_v: {
 Ops[1] = Builder.CreateBitCast(Ops[1], Ty);
-Ty = llvm::PointerType::getUnqual(VTy->getElementType());
-Ops[0] = Builder.CreateBitCast(Ops[0], Ty);
+PtrOp0 = Builder.CreateElementBitCast(PtrOp0, VTy->getElementType());
 Value *Ld = Builder.CreateLoad(PtrOp0);
 return Builder.CreateInsertElement(Ops[1], Ld, Ops[2], "vld1_lane");
   }


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

Re: r246985 - Compute and preserve alignment more faithfully in IR-generation.

[Steven Wu via cfe-commits]

Thanks. Committed in r247117.

Steven

> On Sep 8, 2015, at 6:32 PM, John McCall  wrote:
> 
>> On Sep 8, 2015, at 6:19 PM, Steven Wu  wrote:
>> CreateElementBitcast doesn’t seem to do what the name suggested. If you give 
>> it VTy, it doesn’t grab the element type to generate bitcast. Is this 
>> by-design? If so, I need to do this:
>> PtrOp0 = Builder.CreateElementBitCast(PtrOp0, VTy->getElementType());
> 
> Yes, I’m sorry, that’s right.  I missed that you were also drilling down to 
> the element type.
> 
> John.

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

Re: [PATCH] D10305: [Clang Static Analyzer] Bug identification

[Anna Zaks via cfe-commits]

zaks.anna added a comment.

honggyu.kim,

Uniquing HTML reports is out of the scope of this patch and should be discussed 
elsewhere (either send a design idea to cfe-dev, send a patch for review, or 
file a bugzilla request).

I agree that this patch is a definite improvement to issue identification; 
however, as I mentioned earlier, it needs tests.


http://reviews.llvm.org/D10305



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