Re: [PATCH] D15450: Avoid double deletion in Clang driver.

[Serge Pavlov via cfe-commits]

CodeGen action defined in the unit test does not call HandleTranslationUnit,
so the hack implemented in `BackendConsumer::HandleTranslationUnit` does
not run and clang crashes. With the fix no crash occurs.

Thanks,
--Serge

2016-02-05 1:17 GMT+06:00 Serge Pavlov :

> sepavloff added a comment.
>
> Any feedback?
>
> Thanks,
> --Serge
>
>
> http://reviews.llvm.org/D15450
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D16947: [PGO] assignment operator does not get profile data

[Xinliang David Li via cfe-commits]

On Tue, Feb 9, 2016 at 11:30 AM, David Blaikie  wrote:
>
>
> On Tue, Feb 9, 2016 at 11:26 AM, Xinliang David Li 
> wrote:
>>
>> On Tue, Feb 9, 2016 at 11:14 AM, David Blaikie  wrote:
>> >
>> >
>> > On Mon, Feb 8, 2016 at 9:23 PM, Xinliang David Li 
>> > wrote:
>> >>
>> >> Wrong in the sense the the coverage result for the default operators
>> >> (the line where they are declared) is marked as if they are not called
>> >> which can be confusing to the user.
>> >
>> >
>> > Presumably a user would have the same problem with implicit ops - the
>> > class
>> > header/name would be marked as if there was code that was not called
>> > there?
>>
>> that would be confusing though -- as data of many implicitly declared
>> functions will be lumped together and user won't know what that is .
>
>
> Presumably it's still going to be confusing, though - the line table will
> record that line and the counter won't be there, so the header of the type
> will be marked in red & a user worried about coverage may go through some
> contortions to try to discover and cover that code, no? (even though it may
> already be covered & is just being reported incorrectly due to their being
> no counters)

coverage mapping does not use the debug line table for this purpose --
it encodes line info in source regions of its own format. Marking
class header as read will be super confusing if it happens (but does
not).

Further discussion is welcome, but I am going to commit this change soon.

thanks,

David

>
>>
>>
>> David
>>
>> >
>> > - David
>> >
>> >>
>> >>
>> >> David
>> >>
>> >> On Mon, Feb 8, 2016 at 9:09 PM, David Blaikie 
>> >> wrote:
>> >> >
>> >> >
>> >> > On Mon, Feb 8, 2016 at 9:00 PM, Xinliang David Li
>> >> > 
>> >> > wrote:
>> >> >>
>> >> >> On Mon, Feb 8, 2016 at 8:46 PM, David Blaikie 
>> >> >> wrote:
>> >> >> >
>> >> >> > On Mon, Feb 8, 2016 at 7:39 PM, Xinliang David Li
>> >> >> > 
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> I took a look at the problem. The implicitly defaulted operators
>> >> >> >> should not be instrumented as specified -- I actually I just
>> >> >> >> added
>> >> >> >> the
>> >> >> >> new test case for that (checking profile counter not generated)
>> >> >> >> right
>> >> >> >> after my previous reply and it still passes with this patch. The
>> >> >> >> reason is that those operators have 'implicit' bit set, and
>> >> >> >> profile
>> >> >> >> instrumentation in FE is implemented in two stages: 1) counter
>> >> >> >> assignment; 2) actual transformation.  For methods with implicit
>> >> >> >> bit
>> >> >> >> set, step 1) is skipped as designed, so step 2) simply becomes a
>> >> >> >> no-op.
>> >> >> >>
>> >> >> >> In short, the test case still needs explicit '=default', and the
>> >> >> >> implicit case is covered elsewhere.
>> >> >> >
>> >> >> >
>> >> >> > OK, thanks for the explanation!
>> >> >> >
>> >> >> > Why is that the case, though - why would an implicitly default
>> >> >> > function
>> >> >> > be
>> >> >> > any different from a profile (& profile-guided-optimization)
>> >> >> > perspective
>> >> >> > from an explicitly defaulted one?
>> >> >>
>> >> >> There are two factors to consider -- PGO and coverage testing.
>> >> >> Implicitly declared functions are usually small/single BB so
>> >> >> instrumenting them does not bring too much benefit (they will be
>> >> >> inlined most of the cases any way) while increasing instrumentation
>> >> >> overhead. They are not needed for coveraging test either (as there
>> >> >> are
>> >> >> no source lines to cover). This is a good tuning heuristic in most
>> >> >> cases, but can get wrong sometimes (IR based late instrumentation is
>> >> >> more focused on performance thus not depending on this tuning).
>> >> >>
>> >> >> Explicitly defaulted ones are different in the sense that if they
>> >> >> are
>> >> >> not instrumented, the coverage result will be wrong.
>> >> >
>> >> >
>> >> > wrong in what way? Both functions (explicitly or implicitly
>> >> > defaulted)
>> >> > will
>> >> > be emitted, with line tables (looks like the = defaulted one is
>> >> > attributed
>> >> > to the line where the = default was written, and the implicitly
>> >> > defaulted
>> >> > one is attributed to wherever the class name is written)
>> >> >
>> >> > - David
>> >> >
>> >> >>
>> >> >>
>> >> >> thanks,
>> >> >>
>> >> >> David
>> >> >>
>> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >> thanks,
>> >> >> >>
>> >> >> >> David
>> >> >> >>
>> >> >> >> On Mon, Feb 8, 2016 at 5:23 PM, David Blaikie
>> >> >> >> 
>> >> >> >> wrote:
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On Mon, Feb 8, 2016 at 5:05 PM, Xinliang David Li
>> >> >> >> > 
>> >> >> >> > wrote:
>> >> >> >> >>
>> >> >> >> >> ha! somehow I kept thinking you are referring to implicit
>> >> >> >> >> declared
>> >> >> >> >> ctors.
>> >> 

RE: [libcxx] r260235 - Introduce a cmake module to figure out whether we need to link with libatomic.

[Vasileios Kalintiris via cfe-commits]

Hi Hans,

Can we merge this on the 3.8 release branch? It fixes libcxx builds on MIPS by 
linking with libatomic when needed. Also, all the x86_64 and ARM buildbots for 
libcxx look good.

Thanks,
Vasileios


From: cfe-commits [cfe-commits-boun...@lists.llvm.org] on behalf of Vasileios 
Kalintiris via cfe-commits [cfe-commits@lists.llvm.org]
Sent: 09 February 2016 17:00
To: cfe-commits@lists.llvm.org
Subject: [libcxx] r260235 - Introduce a cmake module to figure out whether we 
need to link with libatomic.

Author: vkalintiris
Date: Tue Feb  9 11:00:38 2016
New Revision: 260235

URL: http://llvm.org/viewvc/llvm-project?rev=260235=rev
Log:
Introduce a cmake module to figure out whether we need to link with libatomic.

Summary:
This fixes the tests under std/atomics for 32-bit MIPS CPUs where the
8-byte atomic operations call into the libatomic library.

Reviewers: dsanders, mclow.lists, EricWF, jroelofs, joerg

Subscribers: cfe-commits

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

Added:
libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake
Modified:
libcxx/trunk/cmake/config-ix.cmake
libcxx/trunk/lib/CMakeLists.txt
libcxx/trunk/test/CMakeLists.txt
libcxx/trunk/test/libcxx/test/target_info.py
libcxx/trunk/test/lit.site.cfg.in

Added: libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake?rev=260235=auto
==
--- libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake (added)
+++ libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake Tue Feb  9 11:00:38 2016
@@ -0,0 +1,38 @@
+INCLUDE(CheckCXXSourceCompiles)
+
+# Sometimes linking against libatomic is required for atomic ops, if
+# the platform doesn't support lock-free atomics.
+#
+# We could modify LLVM's CheckAtomic module and have it check for 64-bit
+# atomics instead. However, we would like to avoid careless uses of 64-bit
+# atomics inside LLVM over time on 32-bit platforms.
+
+function(check_cxx_atomics varname)
+  set(OLD_CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS})
+  set(CMAKE_REQUIRED_FLAGS "-std=c++11")
+  check_cxx_source_compiles("
+#include 
+#include 
+std::atomic x;
+std::atomic y;
+int main() {
+  return x + y;
+}
+" ${varname})
+  set(CMAKE_REQUIRED_FLAGS ${OLD_CMAKE_REQUIRED_FLAGS})
+endfunction(check_cxx_atomics)
+
+check_cxx_atomics(HAVE_CXX_ATOMICS_WITHOUT_LIB)
+# If not, check if the library exists, and atomics work with it.
+if(NOT HAVE_CXX_ATOMICS_WITHOUT_LIB)
+  check_library_exists(atomic __atomic_fetch_add_8 "" HAVE_LIBATOMIC)
+  if(HAVE_LIBATOMIC)
+list(APPEND CMAKE_REQUIRED_LIBRARIES "atomic")
+check_cxx_atomics(HAVE_CXX_ATOMICS_WITH_LIB)
+if (NOT HAVE_CXX_ATOMICS_WITH_LIB)
+  message(FATAL_ERROR "Host compiler must support std::atomic!")
+endif()
+  else()
+message(FATAL_ERROR "Host compiler appears to require libatomic, but 
cannot find it.")
+  endif()
+endif()

Modified: libcxx/trunk/cmake/config-ix.cmake
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/config-ix.cmake?rev=260235=260234=260235=diff
==
--- libcxx/trunk/cmake/config-ix.cmake (original)
+++ libcxx/trunk/cmake/config-ix.cmake Tue Feb  9 11:00:38 2016
@@ -1,5 +1,6 @@
 include(CheckLibraryExists)
 include(CheckCXXCompilerFlag)
+include(CheckLibcxxAtomic)

 # Check compiler flags

@@ -17,3 +18,7 @@ check_library_exists(c fopen "" LIBCXX_H
 check_library_exists(m ccos "" LIBCXX_HAS_M_LIB)
 check_library_exists(rt clock_gettime "" LIBCXX_HAS_RT_LIB)
 check_library_exists(gcc_s __gcc_personality_v0 "" LIBCXX_HAS_GCC_S_LIB)
+
+if (NOT HAVE_CXX_ATOMICS_WITHOUT_LIB)
+  set(LIBCXX_HAS_ATOMIC_LIB True)
+endif()

Modified: libcxx/trunk/lib/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/lib/CMakeLists.txt?rev=260235=260234=260235=diff
==
--- libcxx/trunk/lib/CMakeLists.txt (original)
+++ libcxx/trunk/lib/CMakeLists.txt Tue Feb  9 11:00:38 2016
@@ -79,6 +79,7 @@ add_library_flags_if(LIBCXX_HAS_C_LIB c)
 add_library_flags_if(LIBCXX_HAS_M_LIB m)
 add_library_flags_if(LIBCXX_HAS_RT_LIB rt)
 add_library_flags_if(LIBCXX_HAS_GCC_S_LIB gcc_s)
+add_library_flags_if(LIBCXX_HAS_ATOMIC_LIB atomic)

 # Setup flags.
 add_flags_if_supported(-fPIC)

Modified: libcxx/trunk/test/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/CMakeLists.txt?rev=260235=260234=260235=diff
==
--- libcxx/trunk/test/CMakeLists.txt (original)
+++ libcxx/trunk/test/CMakeLists.txt Tue Feb  9 11:00:38 2016
@@ -15,6 +15,7 @@ pythonize_bool(LIBCXX_ENABLE_SHARED)
 pythonize_bool(LIBCXX_BUILD_32_BITS)
 pythonize_bool(LIBCXX_GENERATE_COVERAGE)
 pythonize_bool(LIBCXXABI_USE_LLVM_UNWINDER)

r260246 - Simplify EnterTokenStream API to make it more robust for memory management

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Tue Feb  9 12:52:09 2016
New Revision: 260246

URL: http://llvm.org/viewvc/llvm-project?rev=260246=rev
Log:
Simplify EnterTokenStream API to make it more robust for memory management

While this won't help fix things like the bug that r260219 addressed, it
seems like good tidy up to have anyway.

(it might be nice if "makeArrayRef" always produced a MutableArrayRef &
let it decay to an ArrayRef when needed - then I'd use that for the
MutableArrayRefs in this patch)

If we had std::dynarray I'd use that instead of unique_ptr+size_t,
ideally (but then it'd have to be threaded down through the Preprocessor
all the way - no idea how painful that would be)

Modified:
cfe/trunk/include/clang/Lex/Preprocessor.h
cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp
cfe/trunk/lib/Lex/PPDirectives.cpp
cfe/trunk/lib/Lex/PPMacroExpansion.cpp
cfe/trunk/lib/Lex/Pragma.cpp
cfe/trunk/lib/Parse/ParseCXXInlineMethods.cpp
cfe/trunk/lib/Parse/ParseDecl.cpp
cfe/trunk/lib/Parse/ParseExprCXX.cpp
cfe/trunk/lib/Parse/ParseObjc.cpp
cfe/trunk/lib/Parse/ParsePragma.cpp
cfe/trunk/lib/Parse/ParseStmtAsm.cpp
cfe/trunk/lib/Parse/ParseTemplate.cpp
cfe/trunk/lib/Rewrite/HTMLRewrite.cpp

Modified: cfe/trunk/include/clang/Lex/Preprocessor.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Lex/Preprocessor.h?rev=260246=260245=260246=diff
==
--- cfe/trunk/include/clang/Lex/Preprocessor.h (original)
+++ cfe/trunk/include/clang/Lex/Preprocessor.h Tue Feb  9 12:52:09 2016
@@ -1018,10 +1018,20 @@ public:
   /// If \p OwnsTokens is false, this method assumes that the specified stream
   /// of tokens has a permanent owner somewhere, so they do not need to be
   /// copied. If it is true, it assumes the array of tokens is allocated with
-  /// \c new[] and must be freed.
+  /// \c new[] and the Preprocessor will delete[] it.
+private:
   void EnterTokenStream(const Token *Toks, unsigned NumToks,
 bool DisableMacroExpansion, bool OwnsTokens);
 
+public:
+  void EnterTokenStream(std::unique_ptr Toks, unsigned NumToks,
+bool DisableMacroExpansion) {
+EnterTokenStream(Toks.release(), NumToks, DisableMacroExpansion, true);
+  }
+  void EnterTokenStream(ArrayRef Toks, bool DisableMacroExpansion) {
+EnterTokenStream(Toks.data(), Toks.size(), DisableMacroExpansion, false);
+  }
+
   /// \brief Pop the current lexer/macro exp off the top of the lexer stack.
   ///
   /// This should only be used in situations where the current state of the

Modified: cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp?rev=260246=260245=260246=diff
==
--- cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp (original)
+++ cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp Tue Feb  9 12:52:09 2016
@@ -580,11 +580,10 @@ struct UnknownPragmaHandler : public Pra
 if (ShouldExpandTokens) {
   // The first token does not have expanded macros. Expand them, if
   // required.
-  Token *Toks = new Token[1];
+  auto Toks = llvm::make_unique(1);
   Toks[0] = PragmaTok;
-  PP.EnterTokenStream(Toks, /*NumToks=*/1,
-  /*DisableMacroExpansion=*/false,
-  /*OwnsTokens=*/true);
+  PP.EnterTokenStream(std::move(Toks), /*NumToks=*/1,
+  /*DisableMacroExpansion=*/false);
   PP.Lex(PragmaTok);
 }
 Token PrevToken;

Modified: cfe/trunk/lib/Lex/PPDirectives.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/PPDirectives.cpp?rev=260246=260245=260246=diff
==
--- cfe/trunk/lib/Lex/PPDirectives.cpp (original)
+++ cfe/trunk/lib/Lex/PPDirectives.cpp Tue Feb  9 12:52:09 2016
@@ -907,7 +907,7 @@ void Preprocessor::HandleDirective(Token
   // various pseudo-ops.  Just return the # token and push back the following
   // token to be lexed next time.
   if (getLangOpts().AsmPreprocessor) {
-Token *Toks = new Token[2];
+auto Toks = llvm::make_unique(2);
 // Return the # and the token after it.
 Toks[0] = SavedHash;
 Toks[1] = Result;
@@ -920,7 +920,7 @@ void Preprocessor::HandleDirective(Token
 // Enter this token stream so that we re-lex the tokens.  Make sure to
 // enable macro expansion, in case the token after the # is an identifier
 // that is expanded.
-EnterTokenStream(Toks, 2, false, true);
+EnterTokenStream(std::move(Toks), 2, false);
 return;
   }
 
@@ -1442,13 +1442,13 @@ static void EnterAnnotationToken(Preproc
  tok::TokenKind Kind, void *AnnotationVal) {
   // FIXME: Produce this as the current token directly, 

Re: [PATCH] D16947: [PGO] assignment operator does not get profile data

[Xinliang David Li via cfe-commits]

On Tue, Feb 9, 2016 at 11:14 AM, David Blaikie  wrote:
>
>
> On Mon, Feb 8, 2016 at 9:23 PM, Xinliang David Li 
> wrote:
>>
>> Wrong in the sense the the coverage result for the default operators
>> (the line where they are declared) is marked as if they are not called
>> which can be confusing to the user.
>
>
> Presumably a user would have the same problem with implicit ops - the class
> header/name would be marked as if there was code that was not called there?

that would be confusing though -- as data of many implicitly declared
functions will be lumped together and user won't know what that is .

David

>
> - David
>
>>
>>
>> David
>>
>> On Mon, Feb 8, 2016 at 9:09 PM, David Blaikie  wrote:
>> >
>> >
>> > On Mon, Feb 8, 2016 at 9:00 PM, Xinliang David Li 
>> > wrote:
>> >>
>> >> On Mon, Feb 8, 2016 at 8:46 PM, David Blaikie 
>> >> wrote:
>> >> >
>> >> > On Mon, Feb 8, 2016 at 7:39 PM, Xinliang David Li
>> >> > 
>> >> > wrote:
>> >> >>
>> >> >> I took a look at the problem. The implicitly defaulted operators
>> >> >> should not be instrumented as specified -- I actually I just added
>> >> >> the
>> >> >> new test case for that (checking profile counter not generated)
>> >> >> right
>> >> >> after my previous reply and it still passes with this patch. The
>> >> >> reason is that those operators have 'implicit' bit set, and profile
>> >> >> instrumentation in FE is implemented in two stages: 1) counter
>> >> >> assignment; 2) actual transformation.  For methods with implicit bit
>> >> >> set, step 1) is skipped as designed, so step 2) simply becomes a
>> >> >> no-op.
>> >> >>
>> >> >> In short, the test case still needs explicit '=default', and the
>> >> >> implicit case is covered elsewhere.
>> >> >
>> >> >
>> >> > OK, thanks for the explanation!
>> >> >
>> >> > Why is that the case, though - why would an implicitly default
>> >> > function
>> >> > be
>> >> > any different from a profile (& profile-guided-optimization)
>> >> > perspective
>> >> > from an explicitly defaulted one?
>> >>
>> >> There are two factors to consider -- PGO and coverage testing.
>> >> Implicitly declared functions are usually small/single BB so
>> >> instrumenting them does not bring too much benefit (they will be
>> >> inlined most of the cases any way) while increasing instrumentation
>> >> overhead. They are not needed for coveraging test either (as there are
>> >> no source lines to cover). This is a good tuning heuristic in most
>> >> cases, but can get wrong sometimes (IR based late instrumentation is
>> >> more focused on performance thus not depending on this tuning).
>> >>
>> >> Explicitly defaulted ones are different in the sense that if they are
>> >> not instrumented, the coverage result will be wrong.
>> >
>> >
>> > wrong in what way? Both functions (explicitly or implicitly defaulted)
>> > will
>> > be emitted, with line tables (looks like the = defaulted one is
>> > attributed
>> > to the line where the = default was written, and the implicitly
>> > defaulted
>> > one is attributed to wherever the class name is written)
>> >
>> > - David
>> >
>> >>
>> >>
>> >> thanks,
>> >>
>> >> David
>> >>
>> >> >
>> >> >>
>> >> >>
>> >> >> thanks,
>> >> >>
>> >> >> David
>> >> >>
>> >> >> On Mon, Feb 8, 2016 at 5:23 PM, David Blaikie 
>> >> >> wrote:
>> >> >> >
>> >> >> >
>> >> >> > On Mon, Feb 8, 2016 at 5:05 PM, Xinliang David Li
>> >> >> > 
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> ha! somehow I kept thinking you are referring to implicit
>> >> >> >> declared
>> >> >> >> ctors.
>> >> >> >
>> >> >> >
>> >> >> > Ah, glad we figured out the disconnect - thanks for bearing with
>> >> >> > me!
>> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >> From your test case, it is seems that the implicit copy/move op
>> >> >> >> is
>> >> >> >> also broken and is fixed by this patch too. That means  a missing
>> >> >> >> test
>> >> >> >> case to me.  Will update the case when verified.
>> >> >> >
>> >> >> >
>> >> >> > Again, this is a case where I'd probably just simplify the test,
>> >> >> > as I
>> >> >> > asked
>> >> >> > earlier in the thread (I asked if it mattered if the op was
>> >> >> > explicitly
>> >> >> > or
>> >> >> > implicitly defaulted (& your response: "> Is the fix/codepath
>> >> >> > specifically
>> >> >> > about explicitly defaulted ops?
>> >> >> >
>> >> >> > yes -- explicitly defaulted. There are some test coverage already
>> >> >> > for
>> >> >> > implicitly declared ctors (but not assignment op -- probably worth
>> >> >> > adding some testing too).")
>> >> >> >
>> >> >> > So I'd just simplify the test by removing the "= default" - I
>> >> >> > don't
>> >> >> > think
>> >> >> > there's value in testing both the explicit default and implicit
>> >> >> > default
>> >> >> > if
>> >> >> > it's just the default-y-ness that's relevant here. Otherwise we
>> >> >> > could
>> 

Re: [PATCH] D17034: Add an AST matcher for null pointers

[Aaron Ballman via cfe-commits]

aaron.ballman added inline comments.


Comment at: include/clang/ASTMatchers/ASTMatchers.h:4821
@@ +4820,3 @@
+///   initializer for i.
+AST_MATCHER(Expr, nullPointerConstant) {
+  return Matcher(

sbenza wrote:
> sbenza wrote:
> > Use AST_MATCHER_FUNCTION instead, where the return value is the matcher 
> > (instead of the application of the matcher).
> > It is simpler to write and since it has no arguments it will memoize the 
> > matcher and construct it only once.
> Maybe use Expr::isNullPointerConstant?
Ah, interesting! I hadn't known about that macro. Thank you.


Comment at: include/clang/ASTMatchers/ASTMatchers.h:4821
@@ +4820,3 @@
+///   initializer for i.
+AST_MATCHER(Expr, nullPointerConstant) {
+  return Matcher(

aaron.ballman wrote:
> sbenza wrote:
> > sbenza wrote:
> > > Use AST_MATCHER_FUNCTION instead, where the return value is the matcher 
> > > (instead of the application of the matcher).
> > > It is simpler to write and since it has no arguments it will memoize the 
> > > matcher and construct it only once.
> > Maybe use Expr::isNullPointerConstant?
> Ah, interesting! I hadn't known about that macro. Thank you.
Oh, hey, that's easier still! Would I still use AST_MATCHER_FUNCTION in that 
case though, or should that remain a simple AST_MATCHER?


http://reviews.llvm.org/D17034



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

r260253 - [libclang] indexing: for a synthesized property reference have the parent be the ObjC implementation decl.

[Argyrios Kyrtzidis via cfe-commits]

Author: akirtzidis
Date: Tue Feb  9 13:07:19 2016
New Revision: 260253

URL: http://llvm.org/viewvc/llvm-project?rev=260253=rev
Log:
[libclang] indexing: for a synthesized property reference have the parent be 
the ObjC implementation decl.

Modified:
cfe/trunk/tools/libclang/IndexingContext.cpp

Modified: cfe/trunk/tools/libclang/IndexingContext.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/libclang/IndexingContext.cpp?rev=260253=260252=260253=diff
==
--- cfe/trunk/tools/libclang/IndexingContext.cpp (original)
+++ cfe/trunk/tools/libclang/IndexingContext.cpp Tue Feb  9 13:07:19 2016
@@ -592,8 +592,9 @@ bool IndexingContext::handleObjCMethod(c
 bool IndexingContext::handleSynthesizedObjCProperty(
 const ObjCPropertyImplDecl *D) 
{
   ObjCPropertyDecl *PD = D->getPropertyDecl();
-  return handleReference(PD, D->getLocation(), getCursor(D), nullptr,
- D->getDeclContext());
+  auto *DC = D->getDeclContext();
+  return handleReference(PD, D->getLocation(), getCursor(D),
+ dyn_cast(DC), DC);
 }
 
 bool IndexingContext::handleSynthesizedObjCMethod(const ObjCMethodDecl *D,


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

r260250 - [libclang] indexing: Have the semantic container of synthesized ObjC getter/setter methods be the implementation decl.

[Argyrios Kyrtzidis via cfe-commits]

Author: akirtzidis
Date: Tue Feb  9 13:07:07 2016
New Revision: 260250

URL: http://llvm.org/viewvc/llvm-project?rev=260250=rev
Log:
[libclang] indexing: Have the semantic container of synthesized ObjC 
getter/setter methods be the implementation decl.

Matches the behavior of other ObjC methods.

Modified:
cfe/trunk/tools/libclang/IndexingContext.cpp
cfe/trunk/tools/libclang/IndexingContext.h

Modified: cfe/trunk/tools/libclang/IndexingContext.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/libclang/IndexingContext.cpp?rev=260250=260249=260250=diff
==
--- cfe/trunk/tools/libclang/IndexingContext.cpp (original)
+++ cfe/trunk/tools/libclang/IndexingContext.cpp Tue Feb  9 13:07:07 2016
@@ -309,7 +309,8 @@ void IndexingContext::handleDiagnosticSe
 bool IndexingContext::handleDecl(const NamedDecl *D,
  SourceLocation Loc, CXCursor Cursor,
  DeclInfo ,
- const DeclContext *LexicalDC) {
+ const DeclContext *LexicalDC,
+ const DeclContext *SemaDC) {
   if (!CB.indexDeclaration || !D)
 return false;
   if (D->isImplicit() && shouldIgnoreIfImplicit(D))
@@ -335,10 +336,12 @@ bool IndexingContext::handleDecl(const N
   DInfo.attributes = DInfo.EntInfo.attributes;
   DInfo.numAttributes = DInfo.EntInfo.numAttributes;
 
-  getContainerInfo(D->getDeclContext(), DInfo.SemanticContainer);
+  if (!SemaDC)
+SemaDC = D->getDeclContext();
+  getContainerInfo(SemaDC, DInfo.SemanticContainer);
   DInfo.semanticContainer = 
 
-  if (LexicalDC == D->getDeclContext()) {
+  if (LexicalDC == SemaDC) {
 DInfo.lexicalContainer = 
   } else if (isTemplateImplicitInstantiation(D)) {
 // Implicit instantiations have the lexical context of where they were
@@ -598,7 +601,7 @@ bool IndexingContext::handleSynthesizedO
  const DeclContext *LexicalDC) 
{
   DeclInfo DInfo(/*isRedeclaration=*/true, /*isDefinition=*/true,
  /*isContainer=*/false);
-  return handleDecl(D, Loc, getCursor(D), DInfo, LexicalDC);
+  return handleDecl(D, Loc, getCursor(D), DInfo, LexicalDC, LexicalDC);
 }
 
 bool IndexingContext::handleObjCProperty(const ObjCPropertyDecl *D) {

Modified: cfe/trunk/tools/libclang/IndexingContext.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/libclang/IndexingContext.h?rev=260250=260249=260250=diff
==
--- cfe/trunk/tools/libclang/IndexingContext.h (original)
+++ cfe/trunk/tools/libclang/IndexingContext.h Tue Feb  9 13:07:07 2016
@@ -468,7 +468,8 @@ private:
   bool handleDecl(const NamedDecl *D,
   SourceLocation Loc, CXCursor Cursor,
   DeclInfo ,
-  const DeclContext *LexicalDC = nullptr);
+  const DeclContext *LexicalDC = nullptr,
+  const DeclContext *SemaDC = nullptr);
 
   bool handleObjCContainer(const ObjCContainerDecl *D,
SourceLocation Loc, CXCursor Cursor,


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

r260251 - [ASTUnit] Change the parameter of ASTUnit::LoadFromCompilerInvocationAction to accept a more general FrontendAction.

[Argyrios Kyrtzidis via cfe-commits]

Author: akirtzidis
Date: Tue Feb  9 13:07:13 2016
New Revision: 260251

URL: http://llvm.org/viewvc/llvm-project?rev=260251=rev
Log:
[ASTUnit] Change the parameter of ASTUnit::LoadFromCompilerInvocationAction to 
accept a more general FrontendAction.

Modified:
cfe/trunk/include/clang/Frontend/ASTUnit.h
cfe/trunk/lib/Frontend/ASTUnit.cpp

Modified: cfe/trunk/include/clang/Frontend/ASTUnit.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/ASTUnit.h?rev=260251=260250=260251=diff
==
--- cfe/trunk/include/clang/Frontend/ASTUnit.h (original)
+++ cfe/trunk/include/clang/Frontend/ASTUnit.h Tue Feb  9 13:07:13 2016
@@ -60,7 +60,7 @@ class PCHContainerOperations;
 class PCHContainerReader;
 class SourceManager;
 class TargetInfo;
-class ASTFrontendAction;
+class FrontendAction;
 class ASTDeserializationListener;
 
 /// \brief Utility class for loading a ASTContext from an AST file.
@@ -781,7 +781,7 @@ public:
   CompilerInvocation *CI,
   std::shared_ptr PCHContainerOps,
   IntrusiveRefCntPtr Diags,
-  ASTFrontendAction *Action = nullptr, ASTUnit *Unit = nullptr,
+  FrontendAction *Action = nullptr, ASTUnit *Unit = nullptr,
   bool Persistent = true, StringRef ResourceFilesPath = StringRef(),
   bool OnlyLocalDecls = false, bool CaptureDiagnostics = false,
   unsigned PrecompilePreambleAfterNParses = 0,

Modified: cfe/trunk/lib/Frontend/ASTUnit.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/ASTUnit.cpp?rev=260251=260250=260251=diff
==
--- cfe/trunk/lib/Frontend/ASTUnit.cpp (original)
+++ cfe/trunk/lib/Frontend/ASTUnit.cpp Tue Feb  9 13:07:13 2016
@@ -1723,7 +1723,7 @@ ASTUnit *ASTUnit::create(CompilerInvocat
 ASTUnit *ASTUnit::LoadFromCompilerInvocationAction(
 CompilerInvocation *CI,
 std::shared_ptr PCHContainerOps,
-IntrusiveRefCntPtr Diags, ASTFrontendAction *Action,
+IntrusiveRefCntPtr Diags, FrontendAction *Action,
 ASTUnit *Unit, bool Persistent, StringRef ResourceFilesPath,
 bool OnlyLocalDecls, bool CaptureDiagnostics,
 unsigned PrecompilePreambleAfterNParses, bool CacheCodeCompletionResults,
@@ -1812,7 +1812,7 @@ ASTUnit *ASTUnit::LoadFromCompilerInvoca
   // Create the source manager.
   Clang->setSourceManager(>getSourceManager());
 
-  ASTFrontendAction *Act = Action;
+  FrontendAction *Act = Action;
 
   std::unique_ptr TrackerAct;
   if (!Act) {


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

r260252 - [Frontend] Handle ASTConsumer::shouldSkipFunctionBody via the MultiplexConsumer.

[Argyrios Kyrtzidis via cfe-commits]

Author: akirtzidis
Date: Tue Feb  9 13:07:16 2016
New Revision: 260252

URL: http://llvm.org/viewvc/llvm-project?rev=260252=rev
Log:
[Frontend] Handle ASTConsumer::shouldSkipFunctionBody via the MultiplexConsumer.

Modified:
cfe/trunk/include/clang/Frontend/MultiplexConsumer.h
cfe/trunk/lib/Frontend/MultiplexConsumer.cpp

Modified: cfe/trunk/include/clang/Frontend/MultiplexConsumer.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/MultiplexConsumer.h?rev=260252=260251=260252=diff
==
--- cfe/trunk/include/clang/Frontend/MultiplexConsumer.h (original)
+++ cfe/trunk/include/clang/Frontend/MultiplexConsumer.h Tue Feb  9 13:07:16 
2016
@@ -54,6 +54,7 @@ public:
   ASTMutationListener *GetASTMutationListener() override;
   ASTDeserializationListener *GetASTDeserializationListener() override;
   void PrintStats() override;
+  bool shouldSkipFunctionBody(Decl *D) override;
 
   // SemaConsumer
   void InitializeSema(Sema ) override;

Modified: cfe/trunk/lib/Frontend/MultiplexConsumer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/MultiplexConsumer.cpp?rev=260252=260251=260252=diff
==
--- cfe/trunk/lib/Frontend/MultiplexConsumer.cpp (original)
+++ cfe/trunk/lib/Frontend/MultiplexConsumer.cpp Tue Feb  9 13:07:16 2016
@@ -360,6 +360,13 @@ void MultiplexConsumer::PrintStats() {
 Consumer->PrintStats();
 }
 
+bool MultiplexConsumer::shouldSkipFunctionBody(Decl *D) {
+  bool Skip = true;
+  for (auto  : Consumers)
+Skip = Skip && Consumer->shouldSkipFunctionBody(D);
+  return Skip;
+}
+
 void MultiplexConsumer::InitializeSema(Sema ) {
   for (auto  : Consumers)
 if (SemaConsumer *SC = dyn_cast(Consumer.get()))


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

r260255 - [libclang] indexing: make sure to not visit init-list expressions twice.

[Argyrios Kyrtzidis via cfe-commits]

Author: akirtzidis
Date: Tue Feb  9 13:07:24 2016
New Revision: 260255

URL: http://llvm.org/viewvc/llvm-project?rev=260255=rev
Log:
[libclang] indexing: make sure to not visit init-list expressions twice.

Modified:
cfe/trunk/test/Index/index-refs.cpp
cfe/trunk/tools/libclang/IndexBody.cpp

Modified: cfe/trunk/test/Index/index-refs.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Index/index-refs.cpp?rev=260255=260254=260255=diff
==
--- cfe/trunk/test/Index/index-refs.cpp (original)
+++ cfe/trunk/test/Index/index-refs.cpp Tue Feb  9 13:07:24 2016
@@ -69,6 +69,8 @@ void foo5() {
   struct S2 s = { .y = 1, .x = 4};
 }
 
+int ginitlist[] = {EnumVal};
+
 // RUN: c-index-test -index-file %s | FileCheck %s
 // CHECK:  [indexDeclaration]: kind: namespace | name: NS
 // CHECK-NEXT: [indexDeclaration]: kind: variable | name: gx
@@ -119,3 +121,9 @@ void foo5() {
 
 // CHECK:  [indexEntityReference]: kind: field | name: y | {{.*}} | loc: 
69:20
 // CHECK-NEXT: [indexEntityReference]: kind: field | name: x | {{.*}} | loc: 
69:28
+// CHECK-NOT:  [indexEntityReference]: kind: field | name: y | {{.*}} | loc: 
69:20
+// CHECK-NOT:  [indexEntityReference]: kind: field | name: x | {{.*}} | loc: 
69:28
+
+// CHECK:  [indexDeclaration]: kind: variable | name: ginitlist |
+// CHECK:  [indexEntityReference]: kind: enumerator | name: EnumVal | 
{{.*}} | loc: 72:20
+// CHECK-NOT:  [indexEntityReference]: kind: enumerator | name: EnumVal | 
{{.*}} | loc: 72:20

Modified: cfe/trunk/tools/libclang/IndexBody.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/libclang/IndexBody.cpp?rev=260255=260254=260255=diff
==
--- cfe/trunk/tools/libclang/IndexBody.cpp (original)
+++ cfe/trunk/tools/libclang/IndexBody.cpp Tue Feb  9 13:07:24 2016
@@ -50,17 +50,6 @@ public:
 return true;
   }
 
-  bool VisitDesignatedInitExpr(DesignatedInitExpr *E) {
-for (DesignatedInitExpr::reverse_designators_iterator
-   D = E->designators_rbegin(), DEnd = E->designators_rend();
-   D != DEnd; ++D) {
-  if (D->isFieldDesignator())
-IndexCtx.handleReference(D->getField(), D->getFieldLoc(),
- Parent, ParentDC, E);
-}
-return true;
-  }
-
   bool VisitObjCIvarRefExpr(ObjCIvarRefExpr *E) {
 IndexCtx.handleReference(E->getDecl(), E->getLocation(),
  Parent, ParentDC, E);
@@ -162,6 +151,64 @@ public:
 return true;
   }
 
+  // RecursiveASTVisitor visits both syntactic and semantic forms, duplicating
+  // the things that we visit. Make sure to only visit the semantic form.
+  // Also visit things that are in the syntactic form but not the semantic one,
+  // for example the indices in DesignatedInitExprs.
+  bool TraverseInitListExpr(InitListExpr *S) {
+
+class SyntacticFormIndexer :
+  public RecursiveASTVisitor {
+  IndexingContext 
+  const NamedDecl *Parent;
+  const DeclContext *ParentDC;
+
+public:
+  SyntacticFormIndexer(IndexingContext ,
+const NamedDecl *Parent, const DeclContext *DC)
+: IndexCtx(indexCtx), Parent(Parent), ParentDC(DC) { }
+
+  bool shouldWalkTypesOfTypeLocs() const { return false; }
+
+  bool VisitDesignatedInitExpr(DesignatedInitExpr *E) {
+for (DesignatedInitExpr::reverse_designators_iterator
+   D = E->designators_rbegin(), DEnd = E->designators_rend();
+   D != DEnd; ++D) {
+  if (D->isFieldDesignator())
+IndexCtx.handleReference(D->getField(), D->getFieldLoc(),
+ Parent, ParentDC, E);
+}
+return true;
+  }
+};
+
+auto visitForm = [&](InitListExpr *Form) {
+  for (Stmt *SubStmt : Form->children()) {
+if (!TraverseStmt(SubStmt))
+  return false;
+  }
+  return true;
+};
+
+InitListExpr *SemaForm = S->isSemanticForm() ? S : S->getSemanticForm();
+InitListExpr *SyntaxForm = S->isSemanticForm() ? S->getSyntacticForm() : S;
+
+if (SemaForm) {
+  // Visit things present in syntactic form but not the semantic form.
+  if (SyntaxForm) {
+SyntacticFormIndexer(IndexCtx, Parent, 
ParentDC).TraverseStmt(SyntaxForm);
+  }
+  return visitForm(SemaForm);
+}
+
+// No semantic, try the syntactic.
+if (SyntaxForm) {
+  return visitForm(SyntaxForm);
+}
+
+return true;
+  }
+
 };
 
 } // anonymous namespace


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

Re: Patch for Bug 26283: float.h is missing mandatory C11 fp macros like DBL_DECIMAL_DIG and LDBL_DECIMAL_DIG

[Hubert Tong via cfe-commits]

I see no immediate issue with this patch, but I am not one of the usual
reviewers for this part of the code base.

-- HT

On Tue, Feb 9, 2016 at 2:56 PM, Jorge Teixeira 
wrote:

> Thanks Hubert. Somehow I omitted that prefix when typing the macros,
> and I did not noticed it when I was testing because on my arch
> DECIMAL_DIG is defined to be the LDBL version...
>
> Updated patch is attached.
>
> JT
>
> On Tue, Feb 9, 2016 at 1:41 PM, Hubert Tong
>  wrote:
> > There is a __LDBL_DECIMAL_DIG__ predefined macro. __DECIMAL_DIG__ will
> not
> > always be the same as __LDBL_DECIMAL_DIG__.
> >
> > -- HT
> >
> > On Mon, Feb 8, 2016 at 11:26 PM, Jorge Teixeira via cfe-commits
> >  wrote:
> >>
> >> Hi, I filed the bug (https://llvm.org/bugs/show_bug.cgi?id=26283) some
> >> time ago and nobody picked it up, so here is a trivial patch exposing
> >> the missing macros, that to the best of my ability were already
> >> present as the internal underscored versions.
> >>
> >> Perhaps a more general bug about C11 floating point (lack of)
> >> conformance should be filed, so that some form of unit test/macro
> >> validation could be worked on, but this patch does scratch my current
> >> itch.
> >>
> >> Successfully tested on x86-64 Xubuntu 14.04 with clang 3.8 from the
> >> ppa, patched with the attached diff.
> >>
> >> First contribution, so feel free to suggest improvements or point to
> >> more detailed step-by-step instructions/guidelines.
> >>
> >> Cheers,
> >>
> >> JT
> >>
> >> ___
> >> 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 for Bug 26283: float.h is missing mandatory C11 fp macros like DBL_DECIMAL_DIG and LDBL_DECIMAL_DIG

[Jorge Teixeira via cfe-commits]

Thanks Hubert. Somehow I omitted that prefix when typing the macros,
and I did not noticed it when I was testing because on my arch
DECIMAL_DIG is defined to be the LDBL version...

Updated patch is attached.

JT

On Tue, Feb 9, 2016 at 1:41 PM, Hubert Tong
 wrote:
> There is a __LDBL_DECIMAL_DIG__ predefined macro. __DECIMAL_DIG__ will not
> always be the same as __LDBL_DECIMAL_DIG__.
>
> -- HT
>
> On Mon, Feb 8, 2016 at 11:26 PM, Jorge Teixeira via cfe-commits
>  wrote:
>>
>> Hi, I filed the bug (https://llvm.org/bugs/show_bug.cgi?id=26283) some
>> time ago and nobody picked it up, so here is a trivial patch exposing
>> the missing macros, that to the best of my ability were already
>> present as the internal underscored versions.
>>
>> Perhaps a more general bug about C11 floating point (lack of)
>> conformance should be filed, so that some form of unit test/macro
>> validation could be worked on, but this patch does scratch my current
>> itch.
>>
>> Successfully tested on x86-64 Xubuntu 14.04 with clang 3.8 from the
>> ppa, patched with the attached diff.
>>
>> First contribution, so feel free to suggest improvements or point to
>> more detailed step-by-step instructions/guidelines.
>>
>> Cheers,
>>
>> JT
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
Index: lib/Headers/float.h
===
--- lib/Headers/float.h	(revision 260263)
+++ lib/Headers/float.h	(working copy)
@@ -68,6 +68,9 @@
 #undef FLT_TRUE_MIN
 #undef DBL_TRUE_MIN
 #undef LDBL_TRUE_MIN
+#undef FLT_DECIMAL_DIG
+#undef DBL_DECIMAL_DIG
+#undef LDBL_DECIMAL_DIG
 #  endif
 #endif
 
@@ -119,6 +122,9 @@
 #  define FLT_TRUE_MIN __FLT_DENORM_MIN__
 #  define DBL_TRUE_MIN __DBL_DENORM_MIN__
 #  define LDBL_TRUE_MIN __LDBL_DENORM_MIN__
+#  define FLT_DECIMAL_DIG __FLT_DECIMAL_DIG__
+#  define DBL_DECIMAL_DIG __DBL_DECIMAL_DIG__
+#  define LDBL_DECIMAL_DIG __LDBL_DECIMAL_DIG__
 #endif
 
 #endif /* __FLOAT_H */
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D15861: Support fully-qualified names for all QualTypes

[Sterling Augustine via cfe-commits]

I've updated the change.

Would you mind checking it in? I'll look into switching the implementations
shortly.

On Tue, Feb 9, 2016 at 11:02 AM, Sterling Augustine 
wrote:

> saugustine updated this revision to Diff 47343.
> saugustine added a comment.
>
> - Cleanup dyn_cast usage inside QualTypeNames.
>
>
> http://reviews.llvm.org/D15861
>
> Files:
>   include/clang/Tooling/Core/QualTypeNames.h
>   lib/Tooling/Core/CMakeLists.txt
>   lib/Tooling/Core/QualTypeNames.cpp
>   unittests/Tooling/CMakeLists.txt
>   unittests/Tooling/QualTypeNamesTest.cpp
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r260266 - clang-cl: Enable plugins on Windows

[Ehsan Akhgari via cfe-commits]

Author: ehsan
Date: Tue Feb  9 13:43:13 2016
New Revision: 260266

URL: http://llvm.org/viewvc/llvm-project?rev=260266=rev
Log:
clang-cl: Enable plugins on Windows

Modified:
cfe/trunk/test/Frontend/plugins.c
cfe/trunk/test/lit.cfg

Modified: cfe/trunk/test/Frontend/plugins.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/plugins.c?rev=260266=260265=260266=diff
==
--- cfe/trunk/test/Frontend/plugins.c (original)
+++ cfe/trunk/test/Frontend/plugins.c Tue Feb  9 13:43:13 2016
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -load %llvmshlibdir/PrintFunctionNames%pluginext -plugin 
print-fns %s 2>&1 | FileCheck %s
+// RUN: %clang_cl -Xclang -load -Xclang 
%llvmshlibdir/PrintFunctionNames%pluginext -Xclang -plugin -Xclang print-fns %s 
2>&1 | FileCheck %s
 // REQUIRES: plugins, examples
 
 // CHECK: top-level-decl: "x"

Modified: cfe/trunk/test/lit.cfg
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/lit.cfg?rev=260266=260265=260266=diff
==
--- cfe/trunk/test/lit.cfg (original)
+++ cfe/trunk/test/lit.cfg Tue Feb  9 13:43:13 2016
@@ -196,7 +196,7 @@ if not lit_config.quiet:
 
 # Plugins (loadable modules)
 # TODO: This should be supplied by Makefile or autoconf.
-if sys.platform in ['win32', 'cygwin']:
+if sys.platform in ['cygwin']:
 has_plugins = (config.enable_shared == 1)
 else:
 has_plugins = True


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

r260265 - clang-cl: Support loading plugins on Windows

[Ehsan Akhgari via cfe-commits]

Author: ehsan
Date: Tue Feb  9 13:43:11 2016
New Revision: 260265

URL: http://llvm.org/viewvc/llvm-project?rev=260265=rev
Log:
clang-cl: Support loading plugins on Windows

This builds on the support being added to LLVM to import and export
registries from DLLs.  This will allow us to pick up the registry
entries added in the DLL's copy of FrontendPluginRegistry.

This will allow us to use plugins on Windows using:
$ clang-cl -Xclang -load -Xclang plugin.dll \
   -Xclang -add-plugin -Xclang foo

Modified:
cfe/trunk/docs/ClangPlugins.rst
cfe/trunk/examples/PrintFunctionNames/PrintFunctionNames.cpp
cfe/trunk/lib/FrontendTool/ExecuteCompilerInvocation.cpp

Modified: cfe/trunk/docs/ClangPlugins.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ClangPlugins.rst?rev=260265=260264=260265=diff
==
--- cfe/trunk/docs/ClangPlugins.rst (original)
+++ cfe/trunk/docs/ClangPlugins.rst Tue Feb  9 13:43:11 2016
@@ -37,11 +37,14 @@ Registering a plugin
 
 
 A plugin is loaded from a dynamic library at runtime by the compiler. To
-register a plugin in a library, use ``FrontendPluginRegistry::Add<>``:
+register a plugin in a library, use ``FrontendPluginRegistry::Add<>``.
+On Windows, you also need to export your plugin registry using
+``LLVM_EXPORT_REGISTRY``.  Here is an example:
 
 .. code-block:: c++
 
   static FrontendPluginRegistry::Add X("my-plugin-name", "my plugin 
description");
+  LLVM_EXPORT_REGISTRY(FrontendPluginRegistry)
 
 Putting it all together
 ===

Modified: cfe/trunk/examples/PrintFunctionNames/PrintFunctionNames.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/examples/PrintFunctionNames/PrintFunctionNames.cpp?rev=260265=260264=260265=diff
==
--- cfe/trunk/examples/PrintFunctionNames/PrintFunctionNames.cpp (original)
+++ cfe/trunk/examples/PrintFunctionNames/PrintFunctionNames.cpp Tue Feb  9 
13:43:11 2016
@@ -121,3 +121,4 @@ protected:
 
 static FrontendPluginRegistry::Add
 X("print-fns", "print function names");
+LLVM_EXPORT_REGISTRY(FrontendPluginRegistry)

Modified: cfe/trunk/lib/FrontendTool/ExecuteCompilerInvocation.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/FrontendTool/ExecuteCompilerInvocation.cpp?rev=260265=260264=260265=diff
==
--- cfe/trunk/lib/FrontendTool/ExecuteCompilerInvocation.cpp (original)
+++ cfe/trunk/lib/FrontendTool/ExecuteCompilerInvocation.cpp Tue Feb  9 
13:43:11 2016
@@ -189,9 +189,16 @@ bool clang::ExecuteCompilerInvocation(Co
  e = Clang->getFrontendOpts().Plugins.size(); i != e; ++i) {
 const std::string  = Clang->getFrontendOpts().Plugins[i];
 std::string Error;
-if (llvm::sys::DynamicLibrary::LoadLibraryPermanently(Path.c_str(), 
))
+llvm::sys::DynamicLibrary DL(
+llvm::sys::DynamicLibrary::getPermanentLibrary(Path.c_str(), ));
+if (DL.isValid()) {
+  // On Windows, we need to import the plugin front-end action
+  // dynamically.
+  LLVM_IMPORT_REGISTRY(FrontendPluginRegistry, DL);
+} else {
   Clang->getDiagnostics().Report(diag::err_fe_unable_to_load_plugin)
 << Path << Error;
+}
   }
 
   // Honor -mllvm.


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

Re: Need to use function "getAsCXXRecordDecl" of ASTMatchFinder.cpp in a clang-tidy check

[Richard Smith via cfe-commits]

On Tue, Feb 9, 2016 at 9:03 AM, Cong Liu via cfe-commits
 wrote:
> Hi Richard,
>
> I need to use the function (line 747 of ASTMatchFinder.cpp):
>
>   static CXXRecordDecl *getAsCXXRecordDecl(const Type *TypeNode)
>
> in the misc-virtual-near-miss check of clang-tidy, because it can correctly
> get the declaration of a template type, while QualType::getAsCXXRecordDecl
> cannot.

In what sense correctly? Type::getAsCXXRecordDecl should get the
CXXRecordDecl in every case where we know which record will be used.
If you want to make the assumption that the primary template will be
used for an unknown specialization, you'll need something like that
function in ASTMatchFinder, but it's not generally correct to make
that assumption. I'm not really sure why we're using this
sometimes-incorrect mechanism in MatchASTVisitor:classIsDerivedFrom;
that seems like a bug.

> But this function is not accessible in clang-tidy check. I think we should
> make this function public accessible since its useful. Could you please tell
> me how to do it? Thanks a lot.
>
> Best regards,
> Cong
>
> ___
> 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 for Bug 26283: float.h is missing mandatory C11 fp macros like DBL_DECIMAL_DIG and LDBL_DECIMAL_DIG

[Hubert Tong via cfe-commits]

There is a __LDBL_DECIMAL_DIG__ predefined macro. __DECIMAL_DIG__ will not
always be the same as __LDBL_DECIMAL_DIG__.

-- HT

On Mon, Feb 8, 2016 at 11:26 PM, Jorge Teixeira via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Hi, I filed the bug (https://llvm.org/bugs/show_bug.cgi?id=26283) some
> time ago and nobody picked it up, so here is a trivial patch exposing
> the missing macros, that to the best of my ability were already
> present as the internal underscored versions.
>
> Perhaps a more general bug about C11 floating point (lack of)
> conformance should be filed, so that some form of unit test/macro
> validation could be worked on, but this patch does scratch my current
> itch.
>
> Successfully tested on x86-64 Xubuntu 14.04 with clang 3.8 from the
> ppa, patched with the attached diff.
>
> First contribution, so feel free to suggest improvements or point to
> more detailed step-by-step instructions/guidelines.
>
> Cheers,
>
> JT
>
> ___
> 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] D17034: Add an AST matcher for null pointers

[Samuel Benzaquen via cfe-commits]

sbenza added inline comments.


Comment at: include/clang/ASTMatchers/ASTMatchers.h:4821
@@ +4820,3 @@
+///   initializer for i.
+AST_MATCHER(Expr, nullPointerConstant) {
+  return Matcher(

aaron.ballman wrote:
> aaron.ballman wrote:
> > sbenza wrote:
> > > sbenza wrote:
> > > > Use AST_MATCHER_FUNCTION instead, where the return value is the matcher 
> > > > (instead of the application of the matcher).
> > > > It is simpler to write and since it has no arguments it will memoize 
> > > > the matcher and construct it only once.
> > > Maybe use Expr::isNullPointerConstant?
> > Ah, interesting! I hadn't known about that macro. Thank you.
> Oh, hey, that's easier still! Would I still use AST_MATCHER_FUNCTION in that 
> case though, or should that remain a simple AST_MATCHER?
One or the other.
The _FUNCTION macro is for when the matcher itself is just a matcher 
expression. Saves typing and CPU.
Generating the temporary matchers on each match is expensive as they do memory 
allocation.
If you use Expr::isNullPointerConstant you won't be making any matchers.



http://reviews.llvm.org/D17034



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

r260270 - [PGO] Fix issue: explicitly defaulted assignop is not profiled

[Xinliang David Li via cfe-commits]

Author: davidxl
Date: Tue Feb  9 14:02:59 2016
New Revision: 260270

URL: http://llvm.org/viewvc/llvm-project?rev=260270=rev
Log:
[PGO] Fix issue: explicitly defaulted assignop is not profiled

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




Added:
cfe/trunk/test/Profile/def-assignop.cpp
Modified:
cfe/trunk/lib/CodeGen/CGClass.cpp

Modified: cfe/trunk/lib/CodeGen/CGClass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGClass.cpp?rev=260270=260269=260270=diff
==
--- cfe/trunk/lib/CodeGen/CGClass.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGClass.cpp Tue Feb  9 14:02:59 2016
@@ -1608,6 +1608,7 @@ void CodeGenFunction::emitImplicitAssign
 
   LexicalScope Scope(*this, RootCS->getSourceRange());
 
+  incrementProfileCounter(RootCS);
   AssignmentMemcpyizer AM(*this, AssignOp, Args);
   for (auto *I : RootCS->body())
 AM.emitAssignment(I);

Added: cfe/trunk/test/Profile/def-assignop.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Profile/def-assignop.cpp?rev=260270=auto
==
--- cfe/trunk/test/Profile/def-assignop.cpp (added)
+++ cfe/trunk/test/Profile/def-assignop.cpp Tue Feb  9 14:02:59 2016
@@ -0,0 +1,32 @@
+// RUN: %clang_cc1 -x c++ -std=c++11 %s -triple x86_64-unknown-linux-gnu 
-main-file-name def-assignop.cpp -o - -emit-llvm -fprofile-instrument=clang | 
FileCheck --check-prefix=PGOGEN %s
+// RUN: %clang_cc1 -x c++ -std=c++11 %s -triple x86_64-unknown-linux-gnu 
-main-file-name def-assignop.cpp -o - -emit-llvm -fprofile-instrument=clang 
-fcoverage-mapping | FileCheck --check-prefix=COVMAP %s
+
+struct B {
+  B& operator=(const B );
+  B& operator=(const B &);
+};
+
+struct A {
+  A =(const A &) = default;
+  // PGOGEN: define {{.*}}@_ZN1AaSERKS_(
+  // PGOGEN: %pgocount = load {{.*}} @__profc__ZN1AaSERKS_
+  // PGOGEN: {{.*}}add{{.*}}%pgocount, 1
+  // PGOGEN: store{{.*}}@__profc__ZN1AaSERKS_
+  A =(A &&) = default;
+  // PGOGEN: define {{.*}}@_ZN1AaSEOS_
+  // PGOGEN: %pgocount = load {{.*}} @__profc__ZN1AaSEOS_
+  // PGOGEN: {{.*}}add{{.*}}%pgocount, 1
+  // PGOGEN: store{{.*}}@__profc__ZN1AaSEOS_
+
+  // Check that coverage mapping includes 6 function records including the
+  // defaulted copy and move operators: A::operator=
+  // COVMAP: @__llvm_coverage_mapping = {{.*}} { { i32, i32, i32, i32 }, [3 x 
<{{.*}}>],
+  B b;
+};
+
+int main() {
+  A a1, a2;
+  a1 = a2;
+  a2 = static_cast(a1);
+  return 0;
+}


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

Re: [PATCH] D16947: [PGO] assignment operator does not get profile data

[David Blaikie via cfe-commits]

On Mon, Feb 8, 2016 at 9:23 PM, Xinliang David Li 
wrote:

> Wrong in the sense the the coverage result for the default operators
> (the line where they are declared) is marked as if they are not called
> which can be confusing to the user.
>

Presumably a user would have the same problem with implicit ops - the class
header/name would be marked as if there was code that was not called there?

- David


>
> David
>
> On Mon, Feb 8, 2016 at 9:09 PM, David Blaikie  wrote:
> >
> >
> > On Mon, Feb 8, 2016 at 9:00 PM, Xinliang David Li 
> > wrote:
> >>
> >> On Mon, Feb 8, 2016 at 8:46 PM, David Blaikie 
> wrote:
> >> >
> >> > On Mon, Feb 8, 2016 at 7:39 PM, Xinliang David Li  >
> >> > wrote:
> >> >>
> >> >> I took a look at the problem. The implicitly defaulted operators
> >> >> should not be instrumented as specified -- I actually I just added
> the
> >> >> new test case for that (checking profile counter not generated) right
> >> >> after my previous reply and it still passes with this patch. The
> >> >> reason is that those operators have 'implicit' bit set, and profile
> >> >> instrumentation in FE is implemented in two stages: 1) counter
> >> >> assignment; 2) actual transformation.  For methods with implicit bit
> >> >> set, step 1) is skipped as designed, so step 2) simply becomes a
> >> >> no-op.
> >> >>
> >> >> In short, the test case still needs explicit '=default', and the
> >> >> implicit case is covered elsewhere.
> >> >
> >> >
> >> > OK, thanks for the explanation!
> >> >
> >> > Why is that the case, though - why would an implicitly default
> function
> >> > be
> >> > any different from a profile (& profile-guided-optimization)
> perspective
> >> > from an explicitly defaulted one?
> >>
> >> There are two factors to consider -- PGO and coverage testing.
> >> Implicitly declared functions are usually small/single BB so
> >> instrumenting them does not bring too much benefit (they will be
> >> inlined most of the cases any way) while increasing instrumentation
> >> overhead. They are not needed for coveraging test either (as there are
> >> no source lines to cover). This is a good tuning heuristic in most
> >> cases, but can get wrong sometimes (IR based late instrumentation is
> >> more focused on performance thus not depending on this tuning).
> >>
> >> Explicitly defaulted ones are different in the sense that if they are
> >> not instrumented, the coverage result will be wrong.
> >
> >
> > wrong in what way? Both functions (explicitly or implicitly defaulted)
> will
> > be emitted, with line tables (looks like the = defaulted one is
> attributed
> > to the line where the = default was written, and the implicitly defaulted
> > one is attributed to wherever the class name is written)
> >
> > - David
> >
> >>
> >>
> >> thanks,
> >>
> >> David
> >>
> >> >
> >> >>
> >> >>
> >> >> thanks,
> >> >>
> >> >> David
> >> >>
> >> >> On Mon, Feb 8, 2016 at 5:23 PM, David Blaikie 
> >> >> wrote:
> >> >> >
> >> >> >
> >> >> > On Mon, Feb 8, 2016 at 5:05 PM, Xinliang David Li
> >> >> > 
> >> >> > wrote:
> >> >> >>
> >> >> >> ha! somehow I kept thinking you are referring to implicit declared
> >> >> >> ctors.
> >> >> >
> >> >> >
> >> >> > Ah, glad we figured out the disconnect - thanks for bearing with
> me!
> >> >> >
> >> >> >>
> >> >> >>
> >> >> >> From your test case, it is seems that the implicit copy/move op is
> >> >> >> also broken and is fixed by this patch too. That means  a missing
> >> >> >> test
> >> >> >> case to me.  Will update the case when verified.
> >> >> >
> >> >> >
> >> >> > Again, this is a case where I'd probably just simplify the test,
> as I
> >> >> > asked
> >> >> > earlier in the thread (I asked if it mattered if the op was
> >> >> > explicitly
> >> >> > or
> >> >> > implicitly defaulted (& your response: "> Is the fix/codepath
> >> >> > specifically
> >> >> > about explicitly defaulted ops?
> >> >> >
> >> >> > yes -- explicitly defaulted. There are some test coverage already
> for
> >> >> > implicitly declared ctors (but not assignment op -- probably worth
> >> >> > adding some testing too).")
> >> >> >
> >> >> > So I'd just simplify the test by removing the "= default" - I don't
> >> >> > think
> >> >> > there's value in testing both the explicit default and implicit
> >> >> > default
> >> >> > if
> >> >> > it's just the default-y-ness that's relevant here. Otherwise we
> could
> >> >> > end up
> >> >> > testing all sorts of ways of writing/interacting with dtors which
> >> >> > wouldn't
> >> >> > be relevant to the code/fix/etc.
> >> >> >
> >> >> > This seems like the obvious test for the behavior:
> >> >> >
> >> >> > struct foo {
> >> >> >   // non-trivial ops
> >> >> >   foo =(const foo&);
> >> >> >   foo =(foo&&);
> >> >> > };
> >> >> >
> >> >> > struct bar {
> >> >> >   foo f; // or derive bar from foo, but I think the member version
> is
> 

Re: [PATCH] D17034: Add an AST matcher for null pointers

[Samuel Benzaquen via cfe-commits]

sbenza added inline comments.


Comment at: include/clang/ASTMatchers/ASTMatchers.h:4821
@@ +4820,3 @@
+///   initializer for i.
+AST_MATCHER(Expr, nullPointerConstant) {
+  return Matcher(

Use AST_MATCHER_FUNCTION instead, where the return value is the matcher 
(instead of the application of the matcher).
It is simpler to write and since it has no arguments it will memoize the 
matcher and construct it only once.


Comment at: include/clang/ASTMatchers/ASTMatchers.h:4821
@@ +4820,3 @@
+///   initializer for i.
+AST_MATCHER(Expr, nullPointerConstant) {
+  return Matcher(

sbenza wrote:
> Use AST_MATCHER_FUNCTION instead, where the return value is the matcher 
> (instead of the application of the matcher).
> It is simpler to write and since it has no arguments it will memoize the 
> matcher and construct it only once.
Maybe use Expr::isNullPointerConstant?


http://reviews.llvm.org/D17034



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

Re: [PATCH] D16947: [PGO] assignment operator does not get profile data

[David Li via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL260270: [PGO] Fix issue: explicitly defaulted assignop is 
not profiled (authored by davidxl).

Changed prior to commit:
  http://reviews.llvm.org/D16947?vs=47239=47351#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D16947

Files:
  cfe/trunk/lib/CodeGen/CGClass.cpp
  cfe/trunk/test/Profile/def-assignop.cpp

Index: cfe/trunk/test/Profile/def-assignop.cpp
===
--- cfe/trunk/test/Profile/def-assignop.cpp
+++ cfe/trunk/test/Profile/def-assignop.cpp
@@ -0,0 +1,32 @@
+// RUN: %clang_cc1 -x c++ -std=c++11 %s -triple x86_64-unknown-linux-gnu 
-main-file-name def-assignop.cpp -o - -emit-llvm -fprofile-instrument=clang | 
FileCheck --check-prefix=PGOGEN %s
+// RUN: %clang_cc1 -x c++ -std=c++11 %s -triple x86_64-unknown-linux-gnu 
-main-file-name def-assignop.cpp -o - -emit-llvm -fprofile-instrument=clang 
-fcoverage-mapping | FileCheck --check-prefix=COVMAP %s
+
+struct B {
+  B& operator=(const B );
+  B& operator=(const B &);
+};
+
+struct A {
+  A =(const A &) = default;
+  // PGOGEN: define {{.*}}@_ZN1AaSERKS_(
+  // PGOGEN: %pgocount = load {{.*}} @__profc__ZN1AaSERKS_
+  // PGOGEN: {{.*}}add{{.*}}%pgocount, 1
+  // PGOGEN: store{{.*}}@__profc__ZN1AaSERKS_
+  A =(A &&) = default;
+  // PGOGEN: define {{.*}}@_ZN1AaSEOS_
+  // PGOGEN: %pgocount = load {{.*}} @__profc__ZN1AaSEOS_
+  // PGOGEN: {{.*}}add{{.*}}%pgocount, 1
+  // PGOGEN: store{{.*}}@__profc__ZN1AaSEOS_
+
+  // Check that coverage mapping includes 6 function records including the
+  // defaulted copy and move operators: A::operator=
+  // COVMAP: @__llvm_coverage_mapping = {{.*}} { { i32, i32, i32, i32 }, [3 x 
<{{.*}}>],
+  B b;
+};
+
+int main() {
+  A a1, a2;
+  a1 = a2;
+  a2 = static_cast(a1);
+  return 0;
+}
Index: cfe/trunk/lib/CodeGen/CGClass.cpp
===
--- cfe/trunk/lib/CodeGen/CGClass.cpp
+++ cfe/trunk/lib/CodeGen/CGClass.cpp
@@ -1608,6 +1608,7 @@
 
   LexicalScope Scope(*this, RootCS->getSourceRange());
 
+  incrementProfileCounter(RootCS);
   AssignmentMemcpyizer AM(*this, AssignOp, Args);
   for (auto *I : RootCS->body())
 AM.emitAssignment(I);


Index: cfe/trunk/test/Profile/def-assignop.cpp
===
--- cfe/trunk/test/Profile/def-assignop.cpp
+++ cfe/trunk/test/Profile/def-assignop.cpp
@@ -0,0 +1,32 @@
+// RUN: %clang_cc1 -x c++ -std=c++11 %s -triple x86_64-unknown-linux-gnu -main-file-name def-assignop.cpp -o - -emit-llvm -fprofile-instrument=clang | FileCheck --check-prefix=PGOGEN %s
+// RUN: %clang_cc1 -x c++ -std=c++11 %s -triple x86_64-unknown-linux-gnu -main-file-name def-assignop.cpp -o - -emit-llvm -fprofile-instrument=clang -fcoverage-mapping | FileCheck --check-prefix=COVMAP %s
+
+struct B {
+  B& operator=(const B );
+  B& operator=(const B &);
+};
+
+struct A {
+  A =(const A &) = default;
+  // PGOGEN: define {{.*}}@_ZN1AaSERKS_(
+  // PGOGEN: %pgocount = load {{.*}} @__profc__ZN1AaSERKS_
+  // PGOGEN: {{.*}}add{{.*}}%pgocount, 1
+  // PGOGEN: store{{.*}}@__profc__ZN1AaSERKS_
+  A =(A &&) = default;
+  // PGOGEN: define {{.*}}@_ZN1AaSEOS_
+  // PGOGEN: %pgocount = load {{.*}} @__profc__ZN1AaSEOS_
+  // PGOGEN: {{.*}}add{{.*}}%pgocount, 1
+  // PGOGEN: store{{.*}}@__profc__ZN1AaSEOS_
+
+  // Check that coverage mapping includes 6 function records including the
+  // defaulted copy and move operators: A::operator=
+  // COVMAP: @__llvm_coverage_mapping = {{.*}} { { i32, i32, i32, i32 }, [3 x <{{.*}}>],
+  B b;
+};
+
+int main() {
+  A a1, a2;
+  a1 = a2;
+  a2 = static_cast(a1);
+  return 0;
+}
Index: cfe/trunk/lib/CodeGen/CGClass.cpp
===
--- cfe/trunk/lib/CodeGen/CGClass.cpp
+++ cfe/trunk/lib/CodeGen/CGClass.cpp
@@ -1608,6 +1608,7 @@
 
   LexicalScope Scope(*this, RootCS->getSourceRange());
 
+  incrementProfileCounter(RootCS);
   AssignmentMemcpyizer AM(*this, AssignOp, Args);
   for (auto *I : RootCS->body())
 AM.emitAssignment(I);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r260267 - Pass /bigobj when building lib/ASTMatchers/Dynamic/Registry.cpp

[Aaron Ballman via cfe-commits]

On Tue, Feb 9, 2016 at 2:53 PM, Reid Kleckner via cfe-commits
 wrote:
> Author: rnk
> Date: Tue Feb  9 13:53:30 2016
> New Revision: 260267
>
> URL: http://llvm.org/viewvc/llvm-project?rev=260267=rev
> Log:
> Pass /bigobj when building lib/ASTMatchers/Dynamic/Registry.cpp
>
> This is the third time it has crossed the 2^16 section limit. We've
> already spent time optimizing this file to reduce template
> instantiations, and it's not clear that there is anymore low hanging
> fruit.

Bummer. Do we have any mechanisms in place that will bark loudly at us
when we accidentally introduce a large quantity of symbols from this
file now? That has also happened a few times, and /bigobj warnings
were the primary way we were notified (since it's difficult to tell
from file size alone).

~Aaron

>
> Modified:
> cfe/trunk/lib/ASTMatchers/Dynamic/CMakeLists.txt
>
> Modified: cfe/trunk/lib/ASTMatchers/Dynamic/CMakeLists.txt
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/ASTMatchers/Dynamic/CMakeLists.txt?rev=260267=260266=260267=diff
> ==
> --- cfe/trunk/lib/ASTMatchers/Dynamic/CMakeLists.txt (original)
> +++ cfe/trunk/lib/ASTMatchers/Dynamic/CMakeLists.txt Tue Feb  9 13:53:30 2016
> @@ -1,5 +1,14 @@
>  set(LLVM_LINK_COMPONENTS support)
>
> +# The registry source file ends up generating a lot of sections for each
> +# matcher. Each matcher appears to get a vtable and several methods. Each
> +# method needs .text, .pdata, .xdata, and .debug sections, adding to the
> +# section multiplier. By default MSVC has a 2^16 limit on the number of
> +# sections in an object file, and this needs more than that.
> +if (MSVC)
> +  set_source_files_properties(Registry.cpp PROPERTIES COMPILE_FLAGS /bigobj)
> +endif()
> +
>  add_clang_library(clangDynamicASTMatchers
>Diagnostics.cpp
>VariantValue.cpp
>
>
> ___
> 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

[clang-tools-extra] r260212 - [clang-tidy] Replace a custom ASTMatcher with a built-in one.

[Gabor Horvath via cfe-commits]

Author: xazax
Date: Tue Feb  9 03:26:11 2016
New Revision: 260212

URL: http://llvm.org/viewvc/llvm-project?rev=260212=rev
Log:
[clang-tidy] Replace a custom ASTMatcher with a built-in one.

Modified:
clang-tools-extra/trunk/clang-tidy/readability/ContainerSizeEmptyCheck.cpp

Modified: 
clang-tools-extra/trunk/clang-tidy/readability/ContainerSizeEmptyCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/readability/ContainerSizeEmptyCheck.cpp?rev=260212=260211=260212=diff
==
--- clang-tools-extra/trunk/clang-tidy/readability/ContainerSizeEmptyCheck.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/readability/ContainerSizeEmptyCheck.cpp 
Tue Feb  9 03:26:11 2016
@@ -37,8 +37,6 @@ static bool isContainer(llvm::StringRef
 
 namespace clang {
 namespace {
-AST_MATCHER(QualType, isBoolType) { return Node->isBooleanType(); }
-
 AST_MATCHER(NamedDecl, stlContainer) {
   return isContainer(Node.getQualifiedNameAsString());
 }
@@ -67,11 +65,11 @@ void ContainerSizeEmptyCheck::registerMa
   ignoringImpCasts(integerLiteral(equals(1)))
   .bind("SizeBinaryOp")),
   hasParent(implicitCastExpr(
-  hasImplicitDestinationType(isBoolType()),
+  hasImplicitDestinationType(booleanType()),
   anyOf(
   hasParent(unaryOperator(hasOperatorName("!")).bind("NegOnSize")),
   anything(,
-  hasParent(explicitCastExpr(hasDestinationType(isBoolType();
+  hasParent(explicitCastExpr(hasDestinationType(booleanType();
 
   Finder->addMatcher(
   cxxMemberCallExpr(


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

r260218 - Add AST matcher reference to documentation directory when building HTML docs.

[Manuel Klimek via cfe-commits]

Author: klimek
Date: Tue Feb  9 04:59:21 2016
New Revision: 260218

URL: http://llvm.org/viewvc/llvm-project?rev=260218=rev
Log:
Add AST matcher reference to documentation directory when building HTML docs.

Modified:
cfe/trunk/docs/CMakeLists.txt

Modified: cfe/trunk/docs/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/CMakeLists.txt?rev=260218=260217=260218=diff
==
--- cfe/trunk/docs/CMakeLists.txt (original)
+++ cfe/trunk/docs/CMakeLists.txt Tue Feb  9 04:59:21 2016
@@ -95,6 +95,8 @@ if (LLVM_ENABLE_SPHINX)
 include(AddSphinxTarget)
 if (${SPHINX_OUTPUT_HTML})
   add_sphinx_target(html clang)
+  configure_file(LibASTMatchersReference.html
+"${CMAKE_CURRENT_BINARY_DIR}/html/LibASTMatchersReference.html" 
COPYONLY)
 endif()
 if (${SPHINX_OUTPUT_MAN})
   add_sphinx_target(man clang)


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

[PATCH] D17021: Adding doxygen comments to the LLVM intrinsics (part 5, f16cintrin.h)

[Katya Romanova via cfe-commits]

kromanova created this revision.
kromanova added reviewers: ygao, probinson, echristo, gribozavr, craig.topper, 
jroelofs.
kromanova added a subscriber: cfe-commits.
kromanova set the repository for this revision to rL LLVM.

Eric Christopher told me that from now on it's OK to commit doxygen comments 
for x86 intrinsics without formal OK from the open source reviewers.  
Post-commit reviews could be done later if needed. It should speed up the 
process.

I still think it's worth posting a code review. At first, it's nice for 
bookkeeping. At second, I made one tiny non-comment related change by replacing 
the name of the parameter in one of the intrinsics. It's done for consistency 
purpose. It might be the only thing that needs to be briefly looked at during 
pre-commit review.

=
Here is the patch with the doxygen comments for the intrinsincs in the header 
file f16cintrin.h.
The doxygen comments are automatically generated based on SCE internal 
intrinsics document using DCG tool that I wrote.

I will submit more doxygen comments for the other intrinsic header files as 
soon as this patch is approved.

Here is the link to the general discussion about adding comments to x86 
intrinsics headers.
http://permalink.gmane.org/gmane.comp.compilers.clang.devel/42032

Here are the links to the similar code reviews for the doxygen comments other 
header files.

http://reviews.llvm.org/D8762 (closed)
http://reviews.llvm.org/D15999 (closed)
http://reviews.llvm.org/D16562 (closed)
http://reviews.llvm.org/D16913 (closed)


Repository:
  rL LLVM

http://reviews.llvm.org/D17021

Files:
  f16cintrin.h

Index: f16cintrin.h
===
--- f16cintrin.h
+++ f16cintrin.h
@@ -29,28 +29,94 @@
 #define __F16CINTRIN_H
 
 /* Define the default attributes for the functions in this file. */
-#define __DEFAULT_FN_ATTRS \ 
+#define __DEFAULT_FN_ATTRS \
   __attribute__((__always_inline__, __nodebug__, __target__("f16c")))
 
+/// \brief Converts a 16-bit half-precision float value into a 32-bit float
+///value.
+///
+/// \headerfile 
+///
+/// This intrinsic corresponds to the \c VCVTPH2PS instruction.
+///
+/// \param a
+///A 16-bit half-precision float value.
+/// \returns The converted 32-bit float value.
 static __inline float __DEFAULT_FN_ATTRS
 _cvtsh_ss(unsigned short a)
 {
   __v8hi v = {(short)a, 0, 0, 0, 0, 0, 0, 0};
   __v4sf r = __builtin_ia32_vcvtph2ps(v);
   return r[0];
 }
 
+/// \brief Converts a 32-bit single-precision float value to a 16-bit
+///half-precision float value.
+///
+/// \headerfile 
+///
+/// \code
+/// unsigned short _cvtss_sh(float a, int imm);
+/// \endcode
+///
+/// This intrinsic corresponds to the \c VCVTPS2PH instruction.
+///
+/// \param a
+///A 32-bit single-precision float value to be converted to a 16-bit
+///half-precision float value.
+/// \param imm
+///An immediate value controlling rounding using bits [2:0]:
+///000: Nearest
+///001: Down
+///010: Up
+///011: Truncate
+///1XX: Use MXCSR.RC for rounding
+/// \returns The converted 16-bit half-precision float value.
 #define _cvtss_sh(a, imm)  \
   ((unsigned short)(((__v8hi)__builtin_ia32_vcvtps2ph((__v4sf){a, 0, 0, 0}, \
   (imm)))[0]))
 
+/// \brief Converts a 128-bit vector containing 32-bit float values into a
+///128-bit vector containing 16-bit half-precision float values.
+///
+/// \headerfile 
+///
+/// \code
+/// __m128i _mm_cvtps_ph(__m128 a, int imm);
+/// \endcode
+///
+/// This intrinsic corresponds to the \c VCVTPS2PH instruction.
+///
+/// \param a
+///A 128-bit vector containing 32-bit float values.
+/// \param imm
+///An immediate value controlling rounding using bits [2:0]:
+///000: Nearest
+///001: Down
+///010: Up
+///011: Truncate
+///1XX: Use MXCSR.RC for rounding
+/// \returns A 128-bit vector containing converted 16-bit half-precision float
+///values. The lower 64 bits are used to store the converted 16-bit
+///half-precision floating-point values.
 #define _mm_cvtps_ph(a, imm) \
   ((__m128i)__builtin_ia32_vcvtps2ph((__v4sf)(__m128)(a), (imm)))
 
+/// \brief Converts a 128-bit vector containing 16-bit half-precision float
+///values into a 128-bit vector containing 32-bit float values.
+///
+/// \headerfile 
+///
+/// This intrinsic corresponds to the \c VCVTPH2PS instruction.
+///
+/// \param a
+///A 128-bit vector containing 16-bit half-precision float values. The lower
+///64 bits are used in the conversion.
+/// \returns A 128-bit vector of [4 x float] containing converted float values.
 static __inline __m128 __DEFAULT_FN_ATTRS
-_mm_cvtph_ps(__m128i __a)
+_mm_cvtph_ps(__m128i a)
 {
-  return (__m128)__builtin_ia32_vcvtph2ps((__v8hi)__a);
+  return (__m128)__builtin_ia32_vcvtph2ps((__v8hi)a);
 }
 
 #undef __DEFAULT_FN_ATTRS

Re: [PATCH] D16873: Refactor MemRegionManager::getVarRegion to call two new functions, improving readability

[Aleksei Sidorin via cfe-commits]

a.sidorin added a comment.

Hello Alexander,

Yes, types in `static_cast` should be changed. So, you need only to change 
return type and types in static_cast, and it should work.


http://reviews.llvm.org/D16873



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

r260215 - [OPENMP] Allow to use the variable in the same 'threadprivate'

[Alexey Bataev via cfe-commits]

Author: abataev
Date: Tue Feb  9 03:41:42 2016
New Revision: 260215

URL: http://llvm.org/viewvc/llvm-project?rev=260215=rev
Log:
[OPENMP] Allow to use the variable in the same 'threadprivate'
directive.

Modified:
cfe/trunk/lib/Sema/SemaOpenMP.cpp

Modified: cfe/trunk/lib/Sema/SemaOpenMP.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaOpenMP.cpp?rev=260215=260214=260215=diff
==
--- cfe/trunk/lib/Sema/SemaOpenMP.cpp (original)
+++ cfe/trunk/lib/Sema/SemaOpenMP.cpp Tue Feb  9 03:41:42 2016
@@ -1289,9 +1289,6 @@ Sema::CheckOMPThreadPrivateDecl(SourceLo
 continue;
 }
 
-// Variable is marked already - no need to check.
-if (DSAStack->isThreadPrivate(VD))
-  continue;
 Vars.push_back(RefExpr);
 DSAStack->addDSA(VD, DE, OMPC_threadprivate);
 VD->addAttr(OMPThreadPrivateDeclAttr::CreateImplicit(


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

r260214 - Do not mark variable as threadprivate if it was marked already.

[Alexey Bataev via cfe-commits]

Author: abataev
Date: Tue Feb  9 03:41:33 2016
New Revision: 260214

URL: http://llvm.org/viewvc/llvm-project?rev=260214=rev
Log:
Do not mark variable as threadprivate if it was marked already.

Modified:
cfe/trunk/lib/Sema/SemaOpenMP.cpp

Modified: cfe/trunk/lib/Sema/SemaOpenMP.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaOpenMP.cpp?rev=260214=260213=260214=diff
==
--- cfe/trunk/lib/Sema/SemaOpenMP.cpp (original)
+++ cfe/trunk/lib/Sema/SemaOpenMP.cpp Tue Feb  9 03:41:33 2016
@@ -1289,6 +1289,9 @@ Sema::CheckOMPThreadPrivateDecl(SourceLo
 continue;
 }
 
+// Variable is marked already - no need to check.
+if (DSAStack->isThreadPrivate(VD))
+  continue;
 Vars.push_back(RefExpr);
 DSAStack->addDSA(VD, DE, OMPC_threadprivate);
 VD->addAttr(OMPThreadPrivateDeclAttr::CreateImplicit(


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

r260213 - [OPENMP] Allow to reference threadprivate variable in same directive.

[Alexey Bataev via cfe-commits]

Author: abataev
Date: Tue Feb  9 03:41:09 2016
New Revision: 260213

URL: http://llvm.org/viewvc/llvm-project?rev=260213=rev
Log:
[OPENMP] Allow to reference threadprivate variable in same directive.

Modified:
cfe/trunk/lib/Sema/SemaOpenMP.cpp
cfe/trunk/test/OpenMP/threadprivate_messages.cpp

Modified: cfe/trunk/lib/Sema/SemaOpenMP.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaOpenMP.cpp?rev=260213=260212=260213=diff
==
--- cfe/trunk/lib/Sema/SemaOpenMP.cpp (original)
+++ cfe/trunk/lib/Sema/SemaOpenMP.cpp Tue Feb  9 03:41:09 2016
@@ -1179,8 +1179,10 @@ ExprResult Sema::ActOnOpenMPIdExpression
   }
 
   QualType ExprType = VD->getType().getNonReferenceType();
-  ExprResult DE = buildDeclRefExpr(*this, VD, ExprType, Id.getLoc());
-  return DE;
+  return DeclRefExpr::Create(Context, NestedNameSpecifierLoc(),
+ SourceLocation(), VD,
+ /*RefersToEnclosingVariableOrCapture=*/false,
+ Id.getLoc(), ExprType, VK_LValue);
 }
 
 Sema::DeclGroupPtrTy
@@ -1230,6 +1232,10 @@ Sema::CheckOMPThreadPrivateDecl(SourceLo
 VarDecl *VD = cast(DE->getDecl());
 SourceLocation ILoc = DE->getExprLoc();
 
+// Mark variable as used.
+VD->setReferenced();
+VD->markUsed(Context);
+
 QualType QType = VD->getType();
 if (QType->isDependentType() || QType->isInstantiationDependentType()) {
   // It will be analyzed later.

Modified: cfe/trunk/test/OpenMP/threadprivate_messages.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/threadprivate_messages.cpp?rev=260213=260212=260213=diff
==
--- cfe/trunk/test/OpenMP/threadprivate_messages.cpp (original)
+++ cfe/trunk/test/OpenMP/threadprivate_messages.cpp Tue Feb  9 03:41:09 2016
@@ -70,7 +70,7 @@ class TestClass {
 
 namespace ns {
   int m;
-#pragma omp threadprivate (m)
+#pragma omp threadprivate (m, m)
 }
 #pragma omp threadprivate (m) // expected-error {{use of undeclared identifier 
'm'}}
 #pragma omp threadprivate (ns::m)


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

[clang-tools-extra] r260217 - [clang-tidy] Make readability-container-size-empty work with inline namespaces. Fix PR25812.

[Gabor Horvath via cfe-commits]

Author: xazax
Date: Tue Feb  9 04:20:48 2016
New Revision: 260217

URL: http://llvm.org/viewvc/llvm-project?rev=260217=rev
Log:
[clang-tidy] Make readability-container-size-empty work with inline namespaces. 
Fix PR25812.

Modified:
clang-tools-extra/trunk/clang-tidy/readability/ContainerSizeEmptyCheck.cpp
clang-tools-extra/trunk/test/clang-tidy/readability-container-size-empty.cpp

Modified: 
clang-tools-extra/trunk/clang-tidy/readability/ContainerSizeEmptyCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/readability/ContainerSizeEmptyCheck.cpp?rev=260217=260216=260217=diff
==
--- clang-tools-extra/trunk/clang-tidy/readability/ContainerSizeEmptyCheck.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/readability/ContainerSizeEmptyCheck.cpp 
Tue Feb  9 04:20:48 2016
@@ -14,23 +14,23 @@
 
 using namespace clang::ast_matchers;
 
-static bool isContainer(llvm::StringRef ClassName) {
-  static const char *const ContainerNames[] = {"std::array",
-   "std::deque",
-   "std::forward_list",
-   "std::list",
-   "std::map",
-   "std::multimap",
-   "std::multiset",
-   "std::priority_queue",
-   "std::queue",
-   "std::set",
-   "std::stack",
-   "std::unordered_map",
-   "std::unordered_multimap",
-   "std::unordered_multiset",
-   "std::unordered_set",
-   "std::vector"};
+static bool isContainerName(llvm::StringRef ClassName) {
+  static const char *const ContainerNames[] = {"array",
+   "deque",
+   "forward_list",
+   "list",
+   "map",
+   "multimap",
+   "multiset",
+   "priority_queue",
+   "queue",
+   "set",
+   "stack",
+   "unordered_map",
+   "unordered_multimap",
+   "unordered_multiset",
+   "unordered_set",
+   "vector"};
   return std::binary_search(std::begin(ContainerNames),
 std::end(ContainerNames), ClassName);
 }
@@ -38,7 +38,10 @@ static bool isContainer(llvm::StringRef
 namespace clang {
 namespace {
 AST_MATCHER(NamedDecl, stlContainer) {
-  return isContainer(Node.getQualifiedNameAsString());
+  if (!isContainerName(Node.getName()))
+return false;
+
+  return StringRef(Node.getQualifiedNameAsString()).startswith("std::");
 }
 } // namespace
 

Modified: 
clang-tools-extra/trunk/test/clang-tidy/readability-container-size-empty.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/readability-container-size-empty.cpp?rev=260217=260216=260217=diff
==
--- 
clang-tools-extra/trunk/test/clang-tidy/readability-container-size-empty.cpp 
(original)
+++ 
clang-tools-extra/trunk/test/clang-tidy/readability-container-size-empty.cpp 
Tue Feb  9 04:20:48 2016
@@ -2,17 +2,32 @@
 
 namespace std {
 template  struct vector {
-  vector() {}
+  vector();
   unsigned long size() const;
   bool empty() const;
 };
+
+inline namespace __v2 {
+template  struct set {
+  set();
+  unsigned long size() const;
+  bool empty() const;
+};
+}
+
+
 }
 
 int main() {
+  std::set intSet;
+  if (intSet.size() == 0)
+;
+  // CHECK-MESSAGES: :[[@LINE-2]]:7: warning: the 'empty' method should be 
used to check for emptiness instead of 'size' [readability-container-size-empty]
+  // CHECK-FIXES: {{^  }}if (intSet.empty()){{$}}
   std::vector vect;
   if (vect.size() == 0)
 ;
-  // CHECK-MESSAGES: :[[@LINE-2]]:7: warning: the 'empty' method should be 
used to check for emptiness instead of 'size' [readability-container-size-empty]
+  // CHECK-MESSAGES: :[[@LINE-2]]:7: warning: the 'empty' method should be used
   // CHECK-FIXES: {{^  }}if (vect.empty()){{$}}
   if 

Re: [PATCH] D16183: Added CheckName field to YAML report

[Ilia Gromov via cfe-commits]

Elijah_Th added a comment.

YAML report looks like this now:

---

MainSourceFile:  ''
Diagnostics:

  CheckName:   misc-macro-parentheses
  Replacements:
- FilePath:/media/SSD_/code/zdoom/main_1.cpp
  Offset:  1354
  Length:  0
  ReplacementText: '('
- FilePath:/media/SSD_/code/zdoom/main_1.cpp
  Offset:  1355
  Length:  0
  ReplacementText: ')'

Diagnostics:

  CheckName:   misc-macro-parentheses
  Replacements:
- FilePath:/media/SSD_/code/zdoom/main_1.cpp
  Offset:  1452
  Length:  0
  ReplacementText: '('
- FilePath:/media/SSD_/code/zdoom/main_1.cpp
  Offset:  1453
  Length:  0
  ReplacementText: ')'

...


http://reviews.llvm.org/D16183



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

Re: [PATCH] D16613: Introduce a cmake module to figure out whether we need to link with libatomic.

[Daniel Sanders via cfe-commits]

dsanders accepted this revision.
dsanders added a comment.

LGTM


http://reviews.llvm.org/D16613



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

Re: [PATCH] D15373: Fix for bug 25786 - Assertion "Chunk.Kind == DeclaratorChunk::Function" failed with regparm attribute.

[Alexander Makarov via cfe-commits]

a.makarov added a comment.

Richard, Reid, please take a look.


http://reviews.llvm.org/D15373



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

Re: r260077 - [OPENMP 4.5] Ccapture/codegen of private non-static data members.

[Renato Golin via cfe-commits]

Hi Alexey,

It's still broken on ARM:

http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-full/builds/10409

cheers,
--renato


On 8 February 2016 at 14:25, Alexey Bataev via cfe-commits
 wrote:
> Ok, thanks a lot! Hope it will fix win-based buildbots completely.
>
> Best regards,
> Alexey Bataev
> =
> Software Engineer
> Intel Compiler Team
>
> 08.02.2016 17:11, NAKAMURA Takumi пишет:
>
> Thanks. It didn't pass with i686-mingw32.
>
>   // LAMBDA: call
>   // LAMBDA: call{{.*}} void [[OUTER_LAMBDA:@.+]](
>
>   call x86_thiscallcc void @_ZN2SSC1ERi(%struct.SS* %ss, i32*
> dereferenceable(4) @_ZZ4mainE5sivar)
>   call x86_thiscallcc void @"_ZZ4mainENK3$_0clEv"(%class.anon* %temp.lvalue)
>
> The latter LAMBDA hit "callcc void @_ZN2SSC1ERi("
>
> Fixed in r260093.
>
> I suggest like;
>   // LAMBDA: call{{.*}} void [[OUTER_LAMBDA:@.+]](%class.anon*
>
> On Mon, Feb 8, 2016 at 10:02 PM Alexey Bataev  wrote:
>>
>> Yes, I know, will be fixed in few minutes
>>
>> Best regards,
>> Alexey Bataev
>> =
>> Software Engineer
>> Intel Compiler Team
>>
>> 08.02.2016 15:43, NAKAMURA Takumi пишет:
>>
>> The test is incompatible to i686-pc-win32. See also
>> http://bb.pgr.jp/builders/ninja-clang-i686-msc18-R/builds/5498
>>
>> On Mon, Feb 8, 2016 at 6:33 PM Alexey Bataev via cfe-commits
>>  wrote:
>>>
>>> Author: abataev
>>> Date: Mon Feb  8 03:29:13 2016
>>> New Revision: 260077
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=260077=rev
>>> Log:
>>> [OPENMP 4.5] Ccapture/codegen of private non-static data members.
>>> OpenMP 4.5 introduces privatization of non-static data members of current
>>> class in non-static member functions.
>>> To correctly handle such kind of privatization a new (pseudo)declaration
>>> VarDecl-based node is added. It allows to reuse an existing code for
>>> capturing variables in Lambdas/Block/Captured blocks of code for correct
>>> privatization and codegen.
>>>
>>> Modified:
>>> cfe/trunk/include/clang/AST/DeclOpenMP.h
>>> cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
>>> cfe/trunk/include/clang/Basic/DeclNodes.td
>>> cfe/trunk/include/clang/Sema/Sema.h
>>> cfe/trunk/include/clang/Serialization/ASTBitCodes.h
>>> cfe/trunk/lib/AST/DeclBase.cpp
>>> cfe/trunk/lib/AST/DeclOpenMP.cpp
>>> cfe/trunk/lib/AST/DeclPrinter.cpp
>>> cfe/trunk/lib/AST/StmtPrinter.cpp
>>> cfe/trunk/lib/CodeGen/CGDecl.cpp
>>> cfe/trunk/lib/Sema/SemaExpr.cpp
>>> cfe/trunk/lib/Sema/SemaExprMember.cpp
>>> cfe/trunk/lib/Sema/SemaOpenMP.cpp
>>> cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
>>> cfe/trunk/lib/Serialization/ASTCommon.cpp
>>> cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
>>> cfe/trunk/lib/Serialization/ASTWriterDecl.cpp
>>> cfe/trunk/test/OpenMP/parallel_private_codegen.cpp
>>> cfe/trunk/tools/libclang/CIndex.cpp
>>>
>>> Modified: cfe/trunk/include/clang/AST/DeclOpenMP.h
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclOpenMP.h?rev=260077=260076=260077=diff
>>>
>>> ==
>>> --- cfe/trunk/include/clang/AST/DeclOpenMP.h (original)
>>> +++ cfe/trunk/include/clang/AST/DeclOpenMP.h Mon Feb  8 03:29:13 2016
>>> @@ -87,6 +87,35 @@ public:
>>>static bool classofKind(Kind K) { return K == OMPThreadPrivate; }
>>>  };
>>>
>>> -}  // end namespace clang
>>> +/// Pseudo declaration for capturing of non-static data members in
>>> non-static
>>> +/// member functions.
>>> +///
>>> +/// Clang supports capturing of variables only, but OpenMP 4.5 allows to
>>> +/// privatize non-static members of current class in non-static member
>>> +/// functions. This pseudo-declaration allows properly handle this kind
>>> of
>>> +/// capture by wrapping captured expression into a variable-like
>>> declaration.
>>> +class OMPCapturedFieldDecl final : public VarDecl {
>>> +  friend class ASTDeclReader;
>>> +  void anchor() override;
>>> +
>>> +  OMPCapturedFieldDecl(ASTContext , DeclContext *DC, IdentifierInfo
>>> *Id,
>>> +   QualType Type)
>>> +  : VarDecl(OMPCapturedField, C, DC, SourceLocation(),
>>> SourceLocation(), Id,
>>> +Type, nullptr, SC_None) {
>>> +setImplicit();
>>> +  }
>>> +
>>> +public:
>>> +  static OMPCapturedFieldDecl *Create(ASTContext , DeclContext *DC,
>>> +  IdentifierInfo *Id, QualType T);
>>> +
>>> +  static OMPCapturedFieldDecl *CreateDeserialized(ASTContext ,
>>> unsigned ID);
>>> +
>>> +  // Implement isa/cast/dyncast/etc.
>>> +  static bool classof(const Decl *D) { return classofKind(D->getKind());
>>> }
>>> +  static bool classofKind(Kind K) { return K == OMPCapturedField; }
>>> +};
>>> +
>>> +} // end namespace clang
>>>
>>>  #endif
>>>
>>> Modified: cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
>>> URL:
>>> 

r260219 - Fix possible OOB access found by buildbot

[Alexey Bataev via cfe-commits]

Author: abataev
Date: Tue Feb  9 05:01:58 2016
New Revision: 260219

URL: http://llvm.org/viewvc/llvm-project?rev=260219=rev
Log:
Fix possible OOB access found by buildbot

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

Modified: cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp?rev=260219=260218=260219=diff
==
--- cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp (original)
+++ cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp Tue Feb  9 05:01:58 2016
@@ -573,19 +573,20 @@ struct UnknownPragmaHandler : public Pra
 Token ) override {
 // Figure out what line we went to and insert the appropriate number of
 // newline characters.
+Callbacks->startNewLineIfNeeded();
+Callbacks->MoveToLine(PragmaTok.getLocation());
+Callbacks->OS.write(Prefix, strlen(Prefix));
+
 if (ShouldExpandTokens) {
   // The first token does not have expanded macros. Expand them, if
   // required.
-  Token Toks[] = {PragmaTok};
-  PP.EnterTokenStream(Toks, llvm::array_lengthof(Toks),
+  Token *Toks = new Token[1];
+  Toks[0] = PragmaTok;
+  PP.EnterTokenStream(Toks, /*NumToks=*/1,
   /*DisableMacroExpansion=*/false,
-  /*OwnsTokens=*/false);
+  /*OwnsTokens=*/true);
   PP.Lex(PragmaTok);
 }
-Callbacks->startNewLineIfNeeded();
-Callbacks->MoveToLine(PragmaTok.getLocation());
-Callbacks->OS.write(Prefix, strlen(Prefix));
-
 Token PrevToken;
 Token PrevPrevToken;
 PrevToken.startToken();


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

Re: [PATCH] D15920: [CMake] Add option to switch default C++ stdlib

[Jonas Hahnfeld via cfe-commits]

Hahnfeld added a comment.

ping


http://reviews.llvm.org/D15920



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

Re: [PATCH] D16183: Added CheckName field to YAML report

[Ilia Gromov via cfe-commits]

Elijah_Th updated this revision to Diff 47302.
Elijah_Th added a comment.

Fixed YAML format (was not correct in the last patch).
Grouped replacements in YAML by Diagnostics. It will help to apply replacements 
for one fix at once.


http://reviews.llvm.org/D16183

Files:
  
/media/SSD_/code/LLVM-code/LLVM-trunk_256412/llvm/tools/clang/include/clang/Tooling/Core/Diagnostics.h
  
/media/SSD_/code/LLVM-code/LLVM-trunk_256412/llvm/tools/clang/include/clang/Tooling/DiagnosticsYaml.h
  
/media/SSD_/code/LLVM-code/LLVM-trunk_256412/llvm/tools/clang/lib/Tooling/Core/CMakeLists.txt
  
/media/SSD_/code/LLVM-code/LLVM-trunk_256412/llvm/tools/clang/lib/Tooling/Core/Diagnostics.cpp
  
/media/SSD_/code/LLVM-code/LLVM-trunk_256412/llvm/tools/clang/tools/extra/clang-tidy/ClangTidy.cpp
  
/media/SSD_/code/LLVM-code/LLVM-trunk_256412/llvm/tools/clang/tools/extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp
  
/media/SSD_/code/LLVM-code/LLVM-trunk_256412/llvm/tools/clang/tools/extra/clang-tidy/ClangTidyDiagnosticConsumer.h

Index: /media/SSD_/code/LLVM-code/LLVM-trunk_256412/llvm/tools/clang/include/clang/Tooling/DiagnosticsYaml.h
===
--- /media/SSD_/code/LLVM-code/LLVM-trunk_256412/llvm/tools/clang/include/clang/Tooling/DiagnosticsYaml.h
+++ /media/SSD_/code/LLVM-code/LLVM-trunk_256412/llvm/tools/clang/include/clang/Tooling/DiagnosticsYaml.h
@@ -0,0 +1,55 @@
+//===-- ReplacementsYaml.h -- Serialiazation for Replacements ---*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+///
+/// \file
+/// \brief This file defines the structure of a YAML document for serializing
+/// ClangTidy errors.
+///
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLING_DIAGNOSTICSYAML_H
+#define LLVM_CLANG_TOOLING_DIAGNOSTICSYAML_H
+
+#include "clang/Tooling/Refactoring.h"
+#include "clang/Tooling/Core/Diagnostics.h"
+#include "llvm/Support/YAMLTraits.h"
+#include 
+#include 
+
+LLVM_YAML_IS_SEQUENCE_VECTOR(clang::tooling::Diagnostics)
+
+namespace llvm {
+namespace yaml {
+
+template <> struct MappingTraits {
+  static void mapping(IO ,
+  clang::tooling::Diagnostics ) {
+std::vector fixes(D.Fix.begin(), D.Fix.end());
+Io.mapRequired("CheckName", D.CheckName);
+Io.mapRequired("Replacements", fixes);
+  }
+};
+
+template <> struct MappingTraits {
+  static void mapping(IO ,
+  clang::tooling::TranslationUnitDiagnostics ) {
+Io.mapRequired("MainSourceFile", TUD.MainSourceFile);
+Io.mapOptional("Context", TUD.Context, std::string());
+for (clang::tooling::Diagnostics diag : TUD.Diags) {
+if (diag.Fix.size() > 0) {
+Io.mapRequired("Diagnostics", diag);
+}
+}
+  }
+};
+} // end namespace yaml
+} // end namespace llvm
+
+#endif /* LLVM_CLANG_TOOLING_DIAGNOSTICSYAML_H */
+
Index: /media/SSD_/code/LLVM-code/LLVM-trunk_256412/llvm/tools/clang/include/clang/Tooling/Core/Diagnostics.h
===
--- /media/SSD_/code/LLVM-code/LLVM-trunk_256412/llvm/tools/clang/include/clang/Tooling/Core/Diagnostics.h
+++ /media/SSD_/code/LLVM-code/LLVM-trunk_256412/llvm/tools/clang/include/clang/Tooling/Core/Diagnostics.h
@@ -0,0 +1,70 @@
+//===--- Replacement.h - Framework for clang refactoring tools --*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+//
+//  Classes supporting refactorings that span multiple translation units.
+//  While single translation unit refactorings are supported via the Rewriter,
+//  when refactoring multiple translation units changes must be stored in a
+//  SourceManager independent form, duplicate changes need to be removed, and
+//  all changes must be applied at once at the end of the refactoring so that
+//  the code is always parseable.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLING_CORE_DIAGNOSTICS_H
+#define LLVM_CLANG_TOOLING_CORE_DIAGNOSTICS_H
+
+#include "clang/Basic/Diagnostic.h"
+#include "llvm/ADT/SmallVector.h"
+#include "Replacement.h"
+#include 
+
+namespace clang {
+namespace tooling {
+
+struct DiagnosticsMessage {
+DiagnosticsMessage(StringRef Message = "");
+DiagnosticsMessage(StringRef Message, const SourceManager ,
+SourceLocation Loc);
+std::string Message;
+std::string FilePath;
+unsigned FileOffset;
+};
+
+struct 

r260211 - Fixed preprocessed output of the first token for pragmas.

[Alexey Bataev via cfe-commits]

Author: abataev
Date: Tue Feb  9 02:51:26 2016
New Revision: 260211

URL: http://llvm.org/viewvc/llvm-project?rev=260211=rev
Log:
Fixed preprocessed output of the first token for pragmas.
Clang did not expanded macros in the very first token of the pragmas
during preprocessed output

Modified:
cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp
cfe/trunk/test/Preprocessor/macro_expand.c

Modified: cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp?rev=260211=260210=260211=diff
==
--- cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp (original)
+++ cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp Tue Feb  9 02:51:26 2016
@@ -573,6 +573,15 @@ struct UnknownPragmaHandler : public Pra
 Token ) override {
 // Figure out what line we went to and insert the appropriate number of
 // newline characters.
+if (ShouldExpandTokens) {
+  // The first token does not have expanded macros. Expand them, if
+  // required.
+  Token Toks[] = {PragmaTok};
+  PP.EnterTokenStream(Toks, llvm::array_lengthof(Toks),
+  /*DisableMacroExpansion=*/false,
+  /*OwnsTokens=*/false);
+  PP.Lex(PragmaTok);
+}
 Callbacks->startNewLineIfNeeded();
 Callbacks->MoveToLine(PragmaTok.getLocation());
 Callbacks->OS.write(Prefix, strlen(Prefix));

Modified: cfe/trunk/test/Preprocessor/macro_expand.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Preprocessor/macro_expand.c?rev=260211=260210=260211=diff
==
--- cfe/trunk/test/Preprocessor/macro_expand.c (original)
+++ cfe/trunk/test/Preprocessor/macro_expand.c Tue Feb  9 02:51:26 2016
@@ -19,3 +19,9 @@ C: for(for))
 // rdar://6880648
 #define f(x,y...) y
 f()
+
+// CHECK: #pragma omp parallel for
+#define FOO parallel
+#define Streaming _Pragma("omp FOO for")
+Streaming
+


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

Re: [PATCH] D16524: [clang-format-vs] Fix sort include main include: Use current path for the '-assume-filename'

[Manuel Klimek via cfe-commits]

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

lg


http://reviews.llvm.org/D16524



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

Re: [PATCH] D16308: clang-tidy Enhance readability-simplify-boolean-expr check to handle implicit conversions of integral types to bool and member pointers

[Richard via cfe-commits]

LegalizeAdulthood added a comment.

In article ,

  Aaron Ballman  writes:

> aaron.ballman added a comment.

> 

> This is causing build bot failures:

> 

> http://bb.pgr.jp/builders/cmake-clang-tools-x86_64-linux/builds/23351

>  http://lab.llvm.org:8011/builders/clang-s390x-linux/builds/492

>  http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/812

> 

> The failure is not obvious to me, and I don't have the opportunity to debug

>  locally right now, so I have reverted in r260097.


make check-all passes for me.  I don't see what the problem is in the logs
either.


http://reviews.llvm.org/D16308



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

Re: [PATCH] D16953: Enhance clang-tidy modernize-redundant-void-arg check to apply fixes to header files

[Richard via cfe-commits]

LegalizeAdulthood marked an inline comment as done.


Comment at: test/clang-tidy/check_clang_tidy.py:152
@@ -68,4 +151,3 @@
 
-  has_check_fixes = input_text.find('CHECK-FIXES') >= 0
-  has_check_messages = input_text.find('CHECK-MESSAGES') >= 0
+  has_check_fixes, has_check_messages = has_checks(input_text)
 

LegalizeAdulthood wrote:
> alexfh wrote:
> > This function doesn't look like a particularly useful one: 5 lines of code 
> > instead of 2 lines and an unclear interface (in which order do the two 
> > bools come?). Please revert this part.
> I initially had it doing the same checks on the header file as well and then 
> it made more sense.  I dug myself into a dead-end on that series of changes, 
> reverted and started over.
> 
> What I settled on here was the assumption that you won't have 
> `CHECK-MESSAGES` or `CHECK-FIXES` in your header file, unless you also had 
> them in the associated source file.  If that assumption is invalid, then I 
> should call this function again for the header and change the tests to be 
> asserting fixes in the source or header, messages in the source or header in 
> various places.
IMO, "5 lines instead of 2 lines" isn't the kind of reasoning that is useful.  
Otherwise we would never do [[ 
https://www.industriallogic.com/xp/refactoring/composeMethod.html | Compose 
Method ]] on a long method since the act of breaking a long method down into a 
bunch of smaller methods necessarily introduces more lines of code.

This script originally was one giant function that did everything.  A bunch of 
things need to be done twice now: one for the source file and once for the 
header file.  Applying Compose Method Extracting results in extracting a group 
of smaller functions/methods.

Now the functions have a bunch of state that needs to be passed around between 
them and the functions might be more clearly expressed as methods on a class, 
but I didn't go that far with it.


http://reviews.llvm.org/D16953



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

r260222 - Registering the gnuNullExpr AST matcher as a dynamic matcher so that it is available from clang-query.

[Aaron Ballman via cfe-commits]

Author: aaronballman
Date: Tue Feb  9 08:04:49 2016
New Revision: 260222

URL: http://llvm.org/viewvc/llvm-project?rev=260222=rev
Log:
Registering the gnuNullExpr AST matcher as a dynamic matcher so that it is 
available from clang-query.

Modified:
cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp

Modified: cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp?rev=260222=260221=260222=diff
==
--- cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp (original)
+++ cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp Tue Feb  9 08:04:49 2016
@@ -185,6 +185,7 @@ RegistryMaps::RegistryMaps() {
   REGISTER_MATCHER(functionProtoType);
   REGISTER_MATCHER(functionTemplateDecl);
   REGISTER_MATCHER(functionType);
+  REGISTER_MATCHER(gnuNullExpr);
   REGISTER_MATCHER(gotoStmt);
   REGISTER_MATCHER(has);
   REGISTER_MATCHER(hasAncestor);


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

Re: [clang-tools-extra] r260217 - [clang-tidy] Make readability-container-size-empty work with inline namespaces. Fix PR25812.

[Samuel Benzaquen via cfe-commits]

Now that I submitted the fix to hasName(), I'll work on adding hasAnyName.

On Tue, Feb 9, 2016 at 6:54 AM, Alexander Kornienko 
wrote:

> I think, we need to add a `hasAnyName()` matcher that would take a list of
> names.
>
> On Tue, Feb 9, 2016 at 11:20 AM, Gabor Horvath via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: xazax
>> Date: Tue Feb  9 04:20:48 2016
>> New Revision: 260217
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=260217=rev
>> Log:
>> [clang-tidy] Make readability-container-size-empty work with inline
>> namespaces. Fix PR25812.
>>
>> Modified:
>>
>> clang-tools-extra/trunk/clang-tidy/readability/ContainerSizeEmptyCheck.cpp
>>
>> clang-tools-extra/trunk/test/clang-tidy/readability-container-size-empty.cpp
>>
>> Modified:
>> clang-tools-extra/trunk/clang-tidy/readability/ContainerSizeEmptyCheck.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/readability/ContainerSizeEmptyCheck.cpp?rev=260217=260216=260217=diff
>>
>> ==
>> ---
>> clang-tools-extra/trunk/clang-tidy/readability/ContainerSizeEmptyCheck.cpp
>> (original)
>> +++
>> clang-tools-extra/trunk/clang-tidy/readability/ContainerSizeEmptyCheck.cpp
>> Tue Feb  9 04:20:48 2016
>> @@ -14,23 +14,23 @@
>>
>>  using namespace clang::ast_matchers;
>>
>> -static bool isContainer(llvm::StringRef ClassName) {
>> -  static const char *const ContainerNames[] = {"std::array",
>> -   "std::deque",
>> -   "std::forward_list",
>> -   "std::list",
>> -   "std::map",
>> -   "std::multimap",
>> -   "std::multiset",
>> -   "std::priority_queue",
>> -   "std::queue",
>> -   "std::set",
>> -   "std::stack",
>> -   "std::unordered_map",
>> -   "std::unordered_multimap",
>> -   "std::unordered_multiset",
>> -   "std::unordered_set",
>> -   "std::vector"};
>> +static bool isContainerName(llvm::StringRef ClassName) {
>> +  static const char *const ContainerNames[] = {"array",
>> +   "deque",
>> +   "forward_list",
>> +   "list",
>> +   "map",
>> +   "multimap",
>> +   "multiset",
>> +   "priority_queue",
>> +   "queue",
>> +   "set",
>> +   "stack",
>> +   "unordered_map",
>> +   "unordered_multimap",
>> +   "unordered_multiset",
>> +   "unordered_set",
>> +   "vector"};
>>return std::binary_search(std::begin(ContainerNames),
>>  std::end(ContainerNames), ClassName);
>>  }
>> @@ -38,7 +38,10 @@ static bool isContainer(llvm::StringRef
>>  namespace clang {
>>  namespace {
>>  AST_MATCHER(NamedDecl, stlContainer) {
>> -  return isContainer(Node.getQualifiedNameAsString());
>> +  if (!isContainerName(Node.getName()))
>> +return false;
>> +
>> +  return StringRef(Node.getQualifiedNameAsString()).startswith("std::");
>>  }
>>  } // namespace
>>
>>
>> Modified:
>> clang-tools-extra/trunk/test/clang-tidy/readability-container-size-empty.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/readability-container-size-empty.cpp?rev=260217=260216=260217=diff
>>
>> ==
>> ---
>> clang-tools-extra/trunk/test/clang-tidy/readability-container-size-empty.cpp
>> (original)
>> +++
>> clang-tools-extra/trunk/test/clang-tidy/readability-container-size-empty.cpp
>> Tue Feb  9 04:20:48 2016
>> @@ -2,17 +2,32 @@
>>
>>  namespace std {
>>  template  struct vector {
>> -  vector() {}
>> +  vector();
>>unsigned long size() const;
>>bool empty() const;
>>  };
>> +
>> +inline namespace __v2 {
>> +template  struct set {
>> +  set();
>> +  unsigned long size() const;
>> +  bool empty() 

Re: [PATCH] D16535: [clang-tidy] Check to find unintended semicolons that changes the semantics.

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

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

- Fixed the cases pointed out by the review.


http://reviews.llvm.org/D16535

Files:
  clang-tidy/misc/CMakeLists.txt
  clang-tidy/misc/MiscTidyModule.cpp
  clang-tidy/misc/SuspiciousSemicolonCheck.cpp
  clang-tidy/misc/SuspiciousSemicolonCheck.h
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/misc-suspicious-semicolon.rst
  test/clang-tidy/misc-suspicious-semicolon.cpp

Index: test/clang-tidy/misc-suspicious-semicolon.cpp
===
--- /dev/null
+++ test/clang-tidy/misc-suspicious-semicolon.cpp
@@ -0,0 +1,117 @@
+// RUN: %check_clang_tidy %s misc-suspicious-semicolon %t
+
+int x = 5;
+
+void nop();
+
+void correct1()
+{
+	if(x < 5) nop();
+}
+
+void correct2()
+{
+	if(x == 5)
+		nop();
+}
+
+void correct3()
+{
+	if(x > 5)
+	{
+		nop();
+	}
+}
+
+void fail1()
+{
+  if(x > 5); nop();
+  // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: potentially unintended semicolon [misc-suspicious-semicolon]
+  // CHECK-FIXES: if(x > 5) nop();
+}
+
+void fail2()
+{
+	if(x == 5);
+		nop();
+  // CHECK-MESSAGES: :[[@LINE-2]]:12: warning: potentially unintended semicolon [misc-suspicious-semicolon]
+  // CHECK-FIXES: if(x == 5){{$}}
+}
+
+void fail3()
+{
+	if(x < 5);
+	{
+		nop();
+	}
+  // CHECK-MESSAGES: :[[@LINE-4]]:11: warning: potentially unintended semicolon
+  // CHECK-FIXES: if(x < 5){{$}}
+}
+
+void correct4()
+{
+  while(x % 5 == 1);
+  nop();
+}
+
+void correct5()
+{
+	for(int i = 0; i < x; ++i)
+		;
+}
+
+void fail4()
+{
+	for(int i = 0; i < x; ++i);
+		nop();
+  // CHECK-MESSAGES: :[[@LINE-2]]:28: warning: potentially unintended semicolon
+  // CHECK-FIXES: for(int i = 0; i < x; ++i){{$}}
+}
+
+void fail5()
+{
+	if(x % 5 == 1);
+	  nop();
+  // CHECK-MESSAGES: :[[@LINE-2]]:16: warning: potentially unintended semicolon
+  // CHECK-FIXES: if(x % 5 == 1){{$}}
+}
+
+void fail6() {
+  int a = 0;
+  if (a != 0) {
+  } else if (a != 1);
+a = 2;
+  // CHECK-MESSAGES: :[[@LINE-2]]:21: warning: potentially unintended semicolon
+  // CHECK-FIXES: } else if (a != 1){{$}}
+}
+
+void fail7() {
+  if (true)
+;
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: potentially unintended semicolon
+}
+
+void correct6()
+{
+	do; while(false);
+}
+
+int correct7()
+{
+  int t_num = 0;
+  char c = 'b';
+  char *s = "a";
+  if (s == "(" || s != "'" || c == '"') {
+t_num += 3;
+return (c == ')' && c == '\'');
+  }
+
+  return 0;
+}
+
+void correct8() {
+  if (true)
+;
+  else {
+  }
+}
Index: docs/clang-tidy/checks/misc-suspicious-semicolon.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/misc-suspicious-semicolon.rst
@@ -0,0 +1,72 @@
+.. title:: clang-tidy - misc-suspicious-semicolon
+
+misc-suspicious-semicolon
+=
+
+Finds most instances of stray semicolons that unexpectedly alter the meaning of
+the code. More specifically, it looks for `if`, `while`, `for` and `for-range`
+statements whose body is a single semicolon, and then analyzes the context of
+the code (e.g. indentation) in an attempt to determine whether that is
+intentional.
+
+  .. code-block:: c++
+
+if(x < y);
+{
+  x++;
+}
+
+Here the body of the `if` statement consists of only the semicolon at the end of
+the first line, and `x` will be incremented regardless of the condition.
+
+
+  .. code-block:: c++
+
+while((line = readLine(file)) != NULL);
+  processLine(line);
+
+As a result of this code, `processLine()` will only be called once, when the
+`while` loop with the empty body exits with `line == NULL`. The indentation of
+the code indicates the intention of the programmer.
+
+
+  .. code-block:: c++
+
+if(x >= y);
+x -= y;
+
+While the indentation does not imply any nesting, there is simply no valid
+reason to have an `if` statement with an empty body (but it can make sense for
+a loop).
+
+To solve the issue remove the stray semicolon or in case the empty body is
+intentional, reflect this using code indentation or put the semicolon in a new
+line. For example:
+
+  .. code-block:: c++
+
+while(readWhitespace());
+  Token t = readNextToken();
+
+Here the second line is indented in a way that suggests that it is meant to be
+the body of the `while` loop - whose body is in fact empty, becasue of the
+semicolon at the end of the first line.
+
+Either remove the indentation from the second line:
+
+  .. code-block:: c++
+
+while(readWhitespace());
+Token t = readNextToken();
+
+... or move the semicolon from the end of the first line to a new line:
+
+  .. code-block:: c++
+
+while(readWhitespace())
+  ;
+
+  Token t = readNextToken();
+
+In this case the check will assume that you know what you are doing, and will
+not raise a warning.
Index: docs/clang-tidy/checks/list.rst
===
--- 

[clang-tools-extra] r260223 - [clang-tidy] Add 'misc-misplaced-widening-cast' check.

[Daniel Marjamaki via cfe-commits]

Author: danielmarjamaki
Date: Tue Feb  9 08:08:49 2016
New Revision: 260223

URL: http://llvm.org/viewvc/llvm-project?rev=260223=rev
Log:
[clang-tidy] Add 'misc-misplaced-widening-cast' check.

Reviewers: alexfh

Subscribers: cfe-commits

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

Added:
clang-tools-extra/trunk/clang-tidy/misc/MisplacedWideningCastCheck.cpp
clang-tools-extra/trunk/clang-tidy/misc/MisplacedWideningCastCheck.h

clang-tools-extra/trunk/docs/clang-tidy/checks/misc-misplaced-widening-cast.rst
clang-tools-extra/trunk/test/clang-tidy/misc-misplaced-widening-cast.cpp
Modified:
clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt
clang-tools-extra/trunk/clang-tidy/misc/MiscTidyModule.cpp
clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst

Modified: clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt?rev=260223=260222=260223=diff
==
--- clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt Tue Feb  9 08:08:49 
2016
@@ -12,6 +12,7 @@ add_clang_library(clangTidyMiscModule
   MacroParenthesesCheck.cpp
   MacroRepeatedSideEffectsCheck.cpp
   MiscTidyModule.cpp
+  MisplacedWideningCastCheck.cpp
   MoveConstantArgumentCheck.cpp
   MoveConstructorInitCheck.cpp
   NewDeleteOverloadsCheck.cpp

Modified: clang-tools-extra/trunk/clang-tidy/misc/MiscTidyModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/MiscTidyModule.cpp?rev=260223=260222=260223=diff
==
--- clang-tools-extra/trunk/clang-tidy/misc/MiscTidyModule.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/misc/MiscTidyModule.cpp Tue Feb  9 
08:08:49 2016
@@ -20,6 +20,7 @@
 #include "InefficientAlgorithmCheck.h"
 #include "MacroParenthesesCheck.h"
 #include "MacroRepeatedSideEffectsCheck.h"
+#include "MisplacedWideningCastCheck.h"
 #include "MoveConstantArgumentCheck.h"
 #include "MoveConstructorInitCheck.h"
 #include "NewDeleteOverloadsCheck.h"
@@ -63,6 +64,8 @@ public:
 "misc-macro-parentheses");
 CheckFactories.registerCheck(
 "misc-macro-repeated-side-effects");
+CheckFactories.registerCheck(
+"misc-misplaced-widening-cast");
 CheckFactories.registerCheck(
 "misc-move-const-arg");
 CheckFactories.registerCheck(

Added: clang-tools-extra/trunk/clang-tidy/misc/MisplacedWideningCastCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/MisplacedWideningCastCheck.cpp?rev=260223=auto
==
--- clang-tools-extra/trunk/clang-tidy/misc/MisplacedWideningCastCheck.cpp 
(added)
+++ clang-tools-extra/trunk/clang-tidy/misc/MisplacedWideningCastCheck.cpp Tue 
Feb  9 08:08:49 2016
@@ -0,0 +1,106 @@
+//===--- MisplacedWideningCastCheck.cpp - 
clang-tidy---===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "MisplacedWideningCastCheck.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang {
+namespace tidy {
+namespace misc {
+
+void MisplacedWideningCastCheck::registerMatchers(MatchFinder *Finder) {
+  auto Calc = expr(anyOf(binaryOperator(anyOf(
+ hasOperatorName("+"), hasOperatorName("-"),
+ hasOperatorName("*"), hasOperatorName("<<"))),
+ unaryOperator(hasOperatorName("~"))),
+   hasType(isInteger()))
+  .bind("Calc");
+
+  auto Cast = explicitCastExpr(anyOf(cStyleCastExpr(), cxxStaticCastExpr(),
+ cxxReinterpretCastExpr()),
+   hasDestinationType(isInteger()),
+   has(Calc))
+  .bind("Cast");
+
+  Finder->addMatcher(varDecl(has(Cast)), this);
+  Finder->addMatcher(returnStmt(has(Cast)), this);
+  Finder->addMatcher(binaryOperator(hasOperatorName("="), hasRHS(Cast)), this);
+}
+
+static unsigned getMaxCalculationWidth(ASTContext , const Expr *E) {
+  E = E->IgnoreParenImpCasts();
+
+  if (const auto *Bop = dyn_cast(E)) {
+unsigned LHSWidth = getMaxCalculationWidth(Context, Bop->getLHS());
+unsigned RHSWidth = getMaxCalculationWidth(Context, Bop->getRHS());
+if (Bop->getOpcode() == BO_Mul)
+  return LHSWidth + RHSWidth;
+if (Bop->getOpcode() == BO_Add)
+  return std::max(LHSWidth, RHSWidth) + 1;
+if (Bop->getOpcode() == 

Re: [PATCH] D16535: [clang-tidy] Check to find unintended semicolons that changes the semantics.

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

xazax.hun added a comment.

Thank you, good catches!


http://reviews.llvm.org/D16535



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

Re: [PATCH] D16308: clang-tidy Enhance readability-simplify-boolean-expr check to handle implicit conversions of integral types to bool and member pointers

[Richard via cfe-commits]

In article ,
Aaron Ballman  writes:

> aaron.ballman added a comment.
> 
> This is causing build bot failures:
> 
> http://bb.pgr.jp/builders/cmake-clang-tools-x86_64-linux/builds/23351
> http://lab.llvm.org:8011/builders/clang-s390x-linux/builds/492
> http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/812
> 
> The failure is not obvious to me, and I don't have the opportunity to debug
> locally right now, so I have reverted in r260097.

make check-all passes for me.  I don't see what the problem is in the logs
either.
-- 
"The Direct3D Graphics Pipeline" free book 
 The Computer Graphics Museum 
 The Terminals Wiki 
  Legalize Adulthood! (my blog) 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D16953: Enhance clang-tidy modernize-redundant-void-arg check to apply fixes to header files

[Richard via cfe-commits]

LegalizeAdulthood updated this revision to Diff 47319.
LegalizeAdulthood added a comment.

Update from review comments


http://reviews.llvm.org/D16953

Files:
  clang-tidy/modernize/RedundantVoidArgCheck.cpp
  test/clang-tidy/check_clang_tidy.py
  test/clang-tidy/modernize-redundant-void-arg.cpp
  test/clang-tidy/modernize-redundant-void-arg.h

Index: test/clang-tidy/modernize-redundant-void-arg.h
===
--- /dev/null
+++ test/clang-tidy/modernize-redundant-void-arg.h
@@ -0,0 +1,8 @@
+#ifndef LLVM_CLANG_TOOLS_EXTRA_TEST_CLANG_TIDY_MODERNIZE_REDUNDANT_VOID_ARG_H
+#define LLVM_CLANG_TOOLS_EXTRA_TEST_CLANG_TIDY_MODERNIZE_REDUNDANT_VOID_ARG_H
+
+extern int foo(void);
+// CHECK-MESSAGES: :[[@LINE-1]]:16: warning: redundant void argument list in function declaration [modernize-redundant-void-arg]
+// CHECK-FIXES: {{^}}extern int foo();{{$}}
+
+#endif // LLVM_CLANG_TOOLS_EXTRA_TEST_CLANG_TIDY_MODERNIZE_REDUNDANT_VOID_ARG_H
Index: test/clang-tidy/modernize-redundant-void-arg.cpp
===
--- test/clang-tidy/modernize-redundant-void-arg.cpp
+++ test/clang-tidy/modernize-redundant-void-arg.cpp
@@ -1,4 +1,6 @@
-// RUN: %check_clang_tidy %s modernize-redundant-void-arg %t
+// RUN: %check_clang_tidy --header-filter=modernize-redundant-void-arg.h %s modernize-redundant-void-arg %t
+
+#include "modernize-redundant-void-arg.h"
 
 #define NULL 0
 
Index: test/clang-tidy/check_clang_tidy.py
===
--- test/clang-tidy/check_clang_tidy.py
+++ test/clang-tidy/check_clang_tidy.py
@@ -25,6 +25,7 @@
 """
 
 import argparse
+import os
 import re
 import subprocess
 import sys
@@ -35,16 +36,98 @@
 f.write(text)
 f.truncate()
 
+
+# Remove the contents of the CHECK lines to avoid CHECKs matching on
+# themselves.  We need to keep the comments to preserve line numbers while
+# avoiding empty lines which could potentially trigger formatting-related
+# checks.
+def clean_text(input_text):
+  return re.sub('// *CHECK-[A-Z-]*:[^\r\n]*', '//', input_text)
+
+
+def write_cleaned_header(input_file_path, temp_file_name, header_file_name):
+  src_path = os.path.join(os.path.dirname(input_file_path), header_file_name)
+  fixed_path = os.path.join(os.path.dirname(temp_file_name), header_file_name)
+  with open(src_path, 'r') as input_file:
+cleaned_text = clean_text(input_file.read())
+  cleaned_path = fixed_path + '.orig'
+  write_file(cleaned_path, cleaned_text)
+  write_file(fixed_path, cleaned_text)
+  return cleaned_path, fixed_path, src_path
+
+
+def separate_output(clang_tidy_output, header_file_name, input_file_name):
+  input_file_name = os.path.basename(input_file_name)
+  input_file_output = ''
+  header_file_output = ''
+  input_messages = True
+  for line in clang_tidy_output.splitlines(True):
+if input_messages:
+  if header_file_name in line:
+input_messages = False
+header_file_output += line
+  else:
+input_file_output += line
+else:
+  if input_file_name in line:
+input_messages = True
+input_file_output += line
+  else:
+header_file_output += line
+  return header_file_output, input_file_output
+
+
+def try_run(args):
+  try:
+process_output = \
+  subprocess.check_output(args, stderr=subprocess.STDOUT).decode()
+  except subprocess.CalledProcessError as e:
+print('%s failed:\n%s' % (' '.join(args), e.output.decode()))
+raise
+  return process_output
+
+
+def check_output_for_messages(messages_file, input_file_name):
+  try_run(
+['FileCheck', '-input-file=' + messages_file, input_file_name,
+   '-check-prefix=CHECK-MESSAGES',
+   '-implicit-check-not={{warning|error}}:'])
+
+
+def check_output_for_fixes(temp_file_name, input_file_name):
+  try_run(
+  ['FileCheck', '-input-file=' + temp_file_name, input_file_name,
+   '-check-prefix=CHECK-FIXES', '-strict-whitespace'])
+
+
+def has_checks(input_text):
+  has_check_fixes = input_text.find('CHECK-FIXES') >= 0
+  has_check_messages = input_text.find('CHECK-MESSAGES') >= 0
+  return has_check_fixes, has_check_messages
+
+
+def diff_source_files(original_file_name, temp_file_name):
+  try:
+diff_output = subprocess.check_output(
+  ['diff', '-u', original_file_name, temp_file_name],
+  stderr=subprocess.STDOUT)
+  except subprocess.CalledProcessError as e:
+diff_output = e.output
+  return diff_output
+
+
 def main():
   parser = argparse.ArgumentParser()
   parser.add_argument('-resource-dir')
+  parser.add_argument('--header-filter')
   parser.add_argument('input_file_name')
   parser.add_argument('check_name')
   parser.add_argument('temp_file_name')
 
   args, extra_args = parser.parse_known_args()
 
   resource_dir = args.resource_dir
+  header_filter = args.header_filter
   input_file_name = args.input_file_name
   check_name = args.check_name
   temp_file_name 

r260220 - [OPENMP] Fix test incompatibility with arm buildbots.

[Alexey Bataev via cfe-commits]

Author: abataev
Date: Tue Feb  9 06:16:42 2016
New Revision: 260220

URL: http://llvm.org/viewvc/llvm-project?rev=260220=rev
Log:
[OPENMP] Fix test incompatibility with arm buildbots.

Modified:
cfe/trunk/test/OpenMP/parallel_private_codegen.cpp

Modified: cfe/trunk/test/OpenMP/parallel_private_codegen.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/parallel_private_codegen.cpp?rev=260220=260219=260220=diff
==
--- cfe/trunk/test/OpenMP/parallel_private_codegen.cpp (original)
+++ cfe/trunk/test/OpenMP/parallel_private_codegen.cpp Tue Feb  9 06:16:42 2016
@@ -99,8 +99,9 @@ int main() {
 #ifdef LAMBDA
   // LAMBDA: [[G:@.+]] = global i{{[0-9]+}} 1212,
   // LAMBDA-LABEL: @main
-  // LAMBDA: call{{.*}} void
-  // LAMBDA: call{{.*}} void [[OUTER_LAMBDA:@[^(]+]](
+  // LAMBDA: alloca [[SS_TY]],
+  // LAMBDA: alloca [[CAP_TY:%.+]],
+  // LAMBDA: call{{.*}} void [[OUTER_LAMBDA:@[^(]+]]([[CAP_TY]]*
   [&]() {
   // LAMBDA: define{{.*}} internal{{.*}} void [[OUTER_LAMBDA]](
   // LAMBDA-NOT: = getelementptr inbounds %{{.+}},


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

Re: [PATCH] D16922: [clang-tidy] Added check-fixes for misc-virtual-near-miss.

[Cong Liu via cfe-commits]

congliu updated this revision to Diff 47307.
congliu added a comment.

- Disallowed matches for method in template instantiations. Updated test.


http://reviews.llvm.org/D16922

Files:
  clang-tidy/misc/VirtualNearMissCheck.cpp
  test/clang-tidy/misc-virtual-near-miss.cpp

Index: test/clang-tidy/misc-virtual-near-miss.cpp
===
--- test/clang-tidy/misc-virtual-near-miss.cpp
+++ test/clang-tidy/misc-virtual-near-miss.cpp
@@ -16,22 +16,54 @@
   // overriden by this class.
   virtual void funk();
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: method 'Derived::funk' has a similar name and the same signature as virtual method 'Base::func'; did you mean to override it? [misc-virtual-near-miss]
+  // CHECK-FIXES: virtual void func();
 
   void func2();
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: method 'Derived::func2' has {{.*}} 'Base::func'
+  // CHECK-FIXES: void func();
 
   void func22(); // Should not warn.
 
   void gunk(); // Should not warn: gunk is override.
 
   void fun();
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: method 'Derived::fun' has {{.*}} 'Base::func'
+  // CHECK-FIXES: void func();
 
   Derived ==(const Base &); // Should not warn: operators are ignored.
 
   virtual NoDefinedClass2 *f1(); // Should not crash: non-defined class return type is ignored.
 };
 
+template 
+struct TBase {
+  virtual void tfunc(T t);
+};
+
+template 
+struct TDerived : TBase {
+  virtual void tfunk(T t);
+  // Should not warn for 'TDerived::tfunk' or 'TDerived::tfunk',
+  // because matches in template instantiations are ignored.
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: method 'TDerived::tfunk' has {{.*}} 'TBase::tfunc'
+  // CHECK-FIXES: virtual void tfunc(T t);
+};
+
+TDerived T1;
+TDerived T2;
+
+// Should not fix macro definition
+#define MACRO1 void funcM()
+#define MACRO2(m) void m()
+struct DerivedMacro : Base {
+  MACRO1;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: method 'DerivedMacro::funcM' has {{.*}} 'Base::func'
+
+  MACRO2(func3);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: method 'DerivedMacro::func3' has {{.*}} 'Base::func'
+  // CHECK-FIXES: MACRO2(func);
+};
+
 typedef Derived derived_type;
 
 class Father {
@@ -58,32 +90,40 @@
 
   virtual void func2();
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: method 'Child::func2' has {{.*}} 'Father::func'
+  // CHECK-FIXES: virtual void func();
 
   int methoe(int x, char **strs); // Should not warn: parameter types don't match.
 
   int methoe(int x);
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: method 'Child::methoe' has {{.*}} 'Mother::method'
+  // CHECK-FIXES: int method(int x);
 
   void methof(int x, const char **strs); // Should not warn: return types don't match.
 
   int methoh(int x, const char **strs);
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: method 'Child::methoh' has {{.*}} 'Mother::method'
+  // CHECK-FIXES: int method(int x, const char **strs);
 
   virtual Child *creat(int i);
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: method 'Child::creat' has {{.*}} 'Father::create'
+  // CHECK-FIXES: virtual Child *create(int i);
 
   virtual Derived &();
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: method 'Child::generat' has {{.*}} 'Father::generate'
+  // CHECK-FIXES: virtual Derived &();
 
   int decaz(const char str[]);
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: method 'Child::decaz' has {{.*}} 'Mother::decay'
+  // CHECK-FIXES: int decay(const char str[]);
 
   operator bool();
 
   derived_type *canonica(derived_type D);
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: method 'Child::canonica' has {{.*}} 'Father::canonical'
+  // CHECK-FIXES: derived_type *canonical(derived_type D);
 
 private:
   void funk();
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: method 'Child::funk' has {{.*}} 'Father::func'
+  // CHECK-FIXES: void func();
 };
Index: clang-tidy/misc/VirtualNearMissCheck.cpp
===
--- clang-tidy/misc/VirtualNearMissCheck.cpp
+++ clang-tidy/misc/VirtualNearMissCheck.cpp
@@ -178,6 +178,50 @@
   return false;
 }
 
+/// Get declaration given the type of a class (including template class).
+///
+/// This function is copied from the one defined in ASTMatchFinder.cpp to solve
+/// the problem that QualType::getAsCXXRecordDecl does not work for template
+/// class.
+static CXXRecordDecl *getAsCXXRecordDecl(const Type *TypeNode) {
+  if (TypeNode->getAs() != nullptr ||
+  TypeNode->getAs() != nullptr ||
+  TypeNode->getAs() != nullptr)
+// Dependent names and template TypeNode parameters will be matched when the
+// template is instantiated.
+return nullptr;
+  TemplateSpecializationType const *TemplateType =
+  TypeNode->getAs();
+  if (!TemplateType)
+return TypeNode->getAsCXXRecordDecl();
+
+  if (TemplateType->getTemplateName().isDependent())
+// Dependent template specializations will be matched when the template is
+// instantiated.
+return 

Re: r260077 - [OPENMP 4.5] Ccapture/codegen of private non-static data members.

[Alexey Bataev via cfe-commits]

Renato,
Will be fixed ASAP

Best regards,
Alexey Bataev
=
Software Engineer
Intel Compiler Team

09.02.2016 14:07, Renato Golin пишет:
> Hi Alexey,
>
> It's still broken on ARM:
>
> http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-full/builds/10409
>
> cheers,
> --renato
>
>
> On 8 February 2016 at 14:25, Alexey Bataev via cfe-commits
>  wrote:
>> Ok, thanks a lot! Hope it will fix win-based buildbots completely.
>>
>> Best regards,
>> Alexey Bataev
>> =
>> Software Engineer
>> Intel Compiler Team
>>
>> 08.02.2016 17:11, NAKAMURA Takumi пишет:
>>
>> Thanks. It didn't pass with i686-mingw32.
>>
>>// LAMBDA: call
>>// LAMBDA: call{{.*}} void [[OUTER_LAMBDA:@.+]](
>>
>>call x86_thiscallcc void @_ZN2SSC1ERi(%struct.SS* %ss, i32*
>> dereferenceable(4) @_ZZ4mainE5sivar)
>>call x86_thiscallcc void @"_ZZ4mainENK3$_0clEv"(%class.anon* %temp.lvalue)
>>
>> The latter LAMBDA hit "callcc void @_ZN2SSC1ERi("
>>
>> Fixed in r260093.
>>
>> I suggest like;
>>// LAMBDA: call{{.*}} void [[OUTER_LAMBDA:@.+]](%class.anon*
>>
>> On Mon, Feb 8, 2016 at 10:02 PM Alexey Bataev  wrote:
>>> Yes, I know, will be fixed in few minutes
>>>
>>> Best regards,
>>> Alexey Bataev
>>> =
>>> Software Engineer
>>> Intel Compiler Team
>>>
>>> 08.02.2016 15:43, NAKAMURA Takumi пишет:
>>>
>>> The test is incompatible to i686-pc-win32. See also
>>> http://bb.pgr.jp/builders/ninja-clang-i686-msc18-R/builds/5498
>>>
>>> On Mon, Feb 8, 2016 at 6:33 PM Alexey Bataev via cfe-commits
>>>  wrote:
 Author: abataev
 Date: Mon Feb  8 03:29:13 2016
 New Revision: 260077

 URL: http://llvm.org/viewvc/llvm-project?rev=260077=rev
 Log:
 [OPENMP 4.5] Ccapture/codegen of private non-static data members.
 OpenMP 4.5 introduces privatization of non-static data members of current
 class in non-static member functions.
 To correctly handle such kind of privatization a new (pseudo)declaration
 VarDecl-based node is added. It allows to reuse an existing code for
 capturing variables in Lambdas/Block/Captured blocks of code for correct
 privatization and codegen.

 Modified:
  cfe/trunk/include/clang/AST/DeclOpenMP.h
  cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
  cfe/trunk/include/clang/Basic/DeclNodes.td
  cfe/trunk/include/clang/Sema/Sema.h
  cfe/trunk/include/clang/Serialization/ASTBitCodes.h
  cfe/trunk/lib/AST/DeclBase.cpp
  cfe/trunk/lib/AST/DeclOpenMP.cpp
  cfe/trunk/lib/AST/DeclPrinter.cpp
  cfe/trunk/lib/AST/StmtPrinter.cpp
  cfe/trunk/lib/CodeGen/CGDecl.cpp
  cfe/trunk/lib/Sema/SemaExpr.cpp
  cfe/trunk/lib/Sema/SemaExprMember.cpp
  cfe/trunk/lib/Sema/SemaOpenMP.cpp
  cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
  cfe/trunk/lib/Serialization/ASTCommon.cpp
  cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
  cfe/trunk/lib/Serialization/ASTWriterDecl.cpp
  cfe/trunk/test/OpenMP/parallel_private_codegen.cpp
  cfe/trunk/tools/libclang/CIndex.cpp

 Modified: cfe/trunk/include/clang/AST/DeclOpenMP.h
 URL:
 http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclOpenMP.h?rev=260077=260076=260077=diff

 ==
 --- cfe/trunk/include/clang/AST/DeclOpenMP.h (original)
 +++ cfe/trunk/include/clang/AST/DeclOpenMP.h Mon Feb  8 03:29:13 2016
 @@ -87,6 +87,35 @@ public:
 static bool classofKind(Kind K) { return K == OMPThreadPrivate; }
   };

 -}  // end namespace clang
 +/// Pseudo declaration for capturing of non-static data members in
 non-static
 +/// member functions.
 +///
 +/// Clang supports capturing of variables only, but OpenMP 4.5 allows to
 +/// privatize non-static members of current class in non-static member
 +/// functions. This pseudo-declaration allows properly handle this kind
 of
 +/// capture by wrapping captured expression into a variable-like
 declaration.
 +class OMPCapturedFieldDecl final : public VarDecl {
 +  friend class ASTDeclReader;
 +  void anchor() override;
 +
 +  OMPCapturedFieldDecl(ASTContext , DeclContext *DC, IdentifierInfo
 *Id,
 +   QualType Type)
 +  : VarDecl(OMPCapturedField, C, DC, SourceLocation(),
 SourceLocation(), Id,
 +Type, nullptr, SC_None) {
 +setImplicit();
 +  }
 +
 +public:
 +  static OMPCapturedFieldDecl *Create(ASTContext , DeclContext *DC,
 +  IdentifierInfo *Id, QualType T);
 +
 +  static OMPCapturedFieldDecl *CreateDeserialized(ASTContext ,
 unsigned ID);
 +
 +  // Implement isa/cast/dyncast/etc.
 +  static bool 

Re: [clang-tools-extra] r260217 - [clang-tidy] Make readability-container-size-empty work with inline namespaces. Fix PR25812.

[Alexander Kornienko via cfe-commits]

I think, we need to add a `hasAnyName()` matcher that would take a list of
names.

On Tue, Feb 9, 2016 at 11:20 AM, Gabor Horvath via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: xazax
> Date: Tue Feb  9 04:20:48 2016
> New Revision: 260217
>
> URL: http://llvm.org/viewvc/llvm-project?rev=260217=rev
> Log:
> [clang-tidy] Make readability-container-size-empty work with inline
> namespaces. Fix PR25812.
>
> Modified:
>
> clang-tools-extra/trunk/clang-tidy/readability/ContainerSizeEmptyCheck.cpp
>
> clang-tools-extra/trunk/test/clang-tidy/readability-container-size-empty.cpp
>
> Modified:
> clang-tools-extra/trunk/clang-tidy/readability/ContainerSizeEmptyCheck.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/readability/ContainerSizeEmptyCheck.cpp?rev=260217=260216=260217=diff
>
> ==
> ---
> clang-tools-extra/trunk/clang-tidy/readability/ContainerSizeEmptyCheck.cpp
> (original)
> +++
> clang-tools-extra/trunk/clang-tidy/readability/ContainerSizeEmptyCheck.cpp
> Tue Feb  9 04:20:48 2016
> @@ -14,23 +14,23 @@
>
>  using namespace clang::ast_matchers;
>
> -static bool isContainer(llvm::StringRef ClassName) {
> -  static const char *const ContainerNames[] = {"std::array",
> -   "std::deque",
> -   "std::forward_list",
> -   "std::list",
> -   "std::map",
> -   "std::multimap",
> -   "std::multiset",
> -   "std::priority_queue",
> -   "std::queue",
> -   "std::set",
> -   "std::stack",
> -   "std::unordered_map",
> -   "std::unordered_multimap",
> -   "std::unordered_multiset",
> -   "std::unordered_set",
> -   "std::vector"};
> +static bool isContainerName(llvm::StringRef ClassName) {
> +  static const char *const ContainerNames[] = {"array",
> +   "deque",
> +   "forward_list",
> +   "list",
> +   "map",
> +   "multimap",
> +   "multiset",
> +   "priority_queue",
> +   "queue",
> +   "set",
> +   "stack",
> +   "unordered_map",
> +   "unordered_multimap",
> +   "unordered_multiset",
> +   "unordered_set",
> +   "vector"};
>return std::binary_search(std::begin(ContainerNames),
>  std::end(ContainerNames), ClassName);
>  }
> @@ -38,7 +38,10 @@ static bool isContainer(llvm::StringRef
>  namespace clang {
>  namespace {
>  AST_MATCHER(NamedDecl, stlContainer) {
> -  return isContainer(Node.getQualifiedNameAsString());
> +  if (!isContainerName(Node.getName()))
> +return false;
> +
> +  return StringRef(Node.getQualifiedNameAsString()).startswith("std::");
>  }
>  } // namespace
>
>
> Modified:
> clang-tools-extra/trunk/test/clang-tidy/readability-container-size-empty.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/readability-container-size-empty.cpp?rev=260217=260216=260217=diff
>
> ==
> ---
> clang-tools-extra/trunk/test/clang-tidy/readability-container-size-empty.cpp
> (original)
> +++
> clang-tools-extra/trunk/test/clang-tidy/readability-container-size-empty.cpp
> Tue Feb  9 04:20:48 2016
> @@ -2,17 +2,32 @@
>
>  namespace std {
>  template  struct vector {
> -  vector() {}
> +  vector();
>unsigned long size() const;
>bool empty() const;
>  };
> +
> +inline namespace __v2 {
> +template  struct set {
> +  set();
> +  unsigned long size() const;
> +  bool empty() const;
> +};
> +}
> +
> +
>  }
>
>  int main() {
> +  std::set intSet;
> +  if (intSet.size() == 0)
> +;
> +  // CHECK-MESSAGES: :[[@LINE-2]]:7: warning: the 'empty' method should
> be used to check for emptiness instead of 'size'
> [readability-container-size-empty]
> +  // 

Re: [PATCH] D16535: [clang-tidy] Check to find unintended semicolons that changes the semantics.

[Haojian Wu via cfe-commits]

hokein added inline comments.


Comment at: clang-tidy/misc/SuspiciousSemicolonCheck.cpp:23
@@ +22,3 @@
+  Finder->addMatcher(
+  stmt(anyOf(ifStmt(hasThen(nullStmt().bind("semi"))),
+ forStmt(hasBody(nullStmt().bind("semi"))),

Looks like this check doesn't handle the case that  unintended semicolon is in 
`else` statement.

```
if (condition1) {
} else if (condition2);
  a = 2
```


Comment at: test/clang-tidy/misc-suspicious-semicolon.cpp:28
@@ +27,3 @@
+{
+  if(x > 5); nop();
+  // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: potentially unintended 
semicolon [misc-suspicious-semicolon]

Can you add the following `if` statement cases in the test?

```
if (condition)
  ;
```

```
if (condition)
  ;
else {
}
```

The behavior of the check is that both two cases are not warned. But I think we 
should warn the first one since there is no reason to write `if` code for that.


http://reviews.llvm.org/D16535



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

Re: r259931 - [SystemZ] Define __GCC_HAVE_SYNC_COMPARE_AND_SWAP macros

[Ulrich Weigand via cfe-commits]

Hal Finkel  wrote on 09.02.2016 04:59:21:

> We generally notice this when we try to use some part of the C++
> standard library (std::atomic or std::thread as I recall). Could we
> have something in the test-suite that uses that functionality in a
> way likely to expose this bug?

Well, when I looked into it, the problem was already in the
std::thread constructor, which sets up a data structure incorrectly
so that the new thread immediately crashes on startup.

I guess any application that uses C++11 threads should show this
problem immediately.

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

Patch for Bug 26283: float.h is missing mandatory C11 fp macros like DBL_DECIMAL_DIG and LDBL_DECIMAL_DIG

[Jorge Teixeira via cfe-commits]

Hi, I filed the bug (https://llvm.org/bugs/show_bug.cgi?id=26283) some
time ago and nobody picked it up, so here is a trivial patch exposing
the missing macros, that to the best of my ability were already
present as the internal underscored versions.

Perhaps a more general bug about C11 floating point (lack of)
conformance should be filed, so that some form of unit test/macro
validation could be worked on, but this patch does scratch my current
itch.

Successfully tested on x86-64 Xubuntu 14.04 with clang 3.8 from the
ppa, patched with the attached diff.

First contribution, so feel free to suggest improvements or point to
more detailed step-by-step instructions/guidelines.

Cheers,

JT
Index: lib/Headers/float.h
===
--- lib/Headers/float.h	(revision 260194)
+++ lib/Headers/float.h	(working copy)
@@ -68,6 +68,9 @@
 #undef FLT_TRUE_MIN
 #undef DBL_TRUE_MIN
 #undef LDBL_TRUE_MIN
+#undef FLT_DECIMAL_DIG
+#undef DBL_DECIMAL_DIG
+#undef LDBL_DECIMAL_DIG
 #  endif
 #endif
 
@@ -119,6 +122,9 @@
 #  define FLT_TRUE_MIN __FLT_DENORM_MIN__
 #  define DBL_TRUE_MIN __DBL_DENORM_MIN__
 #  define LDBL_TRUE_MIN __LDBL_DENORM_MIN__
+#  define FLT_DECIMAL_DIG __FLT_DECIMAL_DIG__
+#  define DBL_DECIMAL_DIG __DBL_DECIMAL_DIG__
+#  define LDBL_DECIMAL_DIG __DECIMAL_DIG__
 #endif
 
 #endif /* __FLOAT_H */
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D16639: [libcxx] Limit catopen usage to unix-like OSes

[Marshall Clow via cfe-commits]

mclow.lists added a comment.

I don't have a problem with this change (assuming that it is correct, and it 
looks correct), but I think it should stay in __config, with all the other 
configuration tests.  (There are other configuration tests in the .cpp files, 
but users never see those).

FWIW, looking at locale, I think that code can be significantly cleaned up.


http://reviews.llvm.org/D16639



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

[clang-tools-extra] r260225 - [clang-tidy] Add -target in misc-misplaced-widening-cast test so it will work on various bots

[Daniel Marjamaki via cfe-commits]

Author: danielmarjamaki
Date: Tue Feb  9 09:43:05 2016
New Revision: 260225

URL: http://llvm.org/viewvc/llvm-project?rev=260225=rev
Log:
[clang-tidy] Add -target in misc-misplaced-widening-cast test so it will work 
on various bots

Modified:
clang-tools-extra/trunk/test/clang-tidy/misc-misplaced-widening-cast.cpp

Modified: 
clang-tools-extra/trunk/test/clang-tidy/misc-misplaced-widening-cast.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/misc-misplaced-widening-cast.cpp?rev=260225=260224=260225=diff
==
--- clang-tools-extra/trunk/test/clang-tidy/misc-misplaced-widening-cast.cpp 
(original)
+++ clang-tools-extra/trunk/test/clang-tidy/misc-misplaced-widening-cast.cpp 
Tue Feb  9 09:43:05 2016
@@ -1,4 +1,4 @@
-// RUN: %check_clang_tidy %s misc-misplaced-widening-cast %t
+// RUN: %check_clang_tidy %s misc-misplaced-widening-cast %t -- -- -target 
x86_64-unknown-unknown
 
 void assign(int a, int b) {
   long l;


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

Re: [PATCH] D15539: [libcxxabi] Reducing stack usage of test

[Marshall Clow via cfe-commits]

mclow.lists added a comment.

I think you've reduced the scope of the tests significantly with this change.

If you want to make the objects smaller, that's fine - but please heed Howard's 
advice in the email thread:

- Don't make them too small.  (three digits is better than two)
- Keep the object sizes odd, and their differences more than the max alignment 
for your platform.



Comment at: test/dynamic_cast14.pass.cpp:18
@@ -17,3 +17,3 @@
 {
-char _[43981];
+long double _[13];
 virtual ~A1() {}

Using long double here (instead of char) forces alignment; reducing the scope 
of the tests.
(and means that the sizes are always an even number, and (probably) a multiple 
of 8.


Comment at: test/dynamic_cast14.pass.cpp:36
@@ -35,3 +35,3 @@
 {
-char _[93481];
+long double _[23];
 virtual ~A3() {}

@Howard.Hinnant wrote in the email thread:
> If you need to reduce these numbers for other platforms, I think that would 
> be fine. However I would not reduce them to double digits.  I would keep them 
> as large as you can reasonably get away with.


http://reviews.llvm.org/D15539



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

Re: [PATCH] D15539: [libcxxabi] Reducing stack usage of test

[Ben Craig via cfe-commits]

bcraig added a comment.

Any objections to using the original sizes, but constructing the objects at 
global scope?  That fixes the stack usage without significantly changing the 
layout characteristics of the test?


http://reviews.llvm.org/D15539



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

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

[Anastasia Stulova via cfe-commits]

Anastasia added inline comments.


Comment at: test/SemaOpenCL/implicit-typedef.cl:1
@@ +1,2 @@
+// RUN: %clang_cc1 %s -DTEST_WARNINGS -cl-std=CL2.0 -verify -pedantic 
-fsyntax-only -Wsystem-headers
+// RUN: %clang_cc1 %s -cl-std=CL2.0 -fsyntax-only

do you need -pedantic here?


http://reviews.llvm.org/D16351



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

Re: [PATCH] D15920: [CMake] Add option to switch default C++ stdlib

[Chris Bieneman via cfe-commits]

beanz added a comment.

Is it correct to assume that all the test case changes are needed just to make 
the tests pass if you set CLANG_DEFAULT_CXX_STDLIB=libc++?

I'm not really comfortable approving this patch because I've made all of one or 
two changes ever to the driver, but I can try to pester someone else to take a 
gander. It doesn't look particularly invasive to me.

One comment inline.



Comment at: lib/Driver/ToolChain.cpp:552
@@ -546,3 +551,3 @@
 
   return ToolChain::CST_Libstdcxx;
 }

There are two cases where this line would get hit:

(1) If the stdlib arg is an invalid library, it falls through here after 
printing the diagnostic
(2) if CLANG_DEFAULT_CXX_STDLIB is itself an invalid library value

Can you add a configure-time or compile time check to catch case 2?


http://reviews.llvm.org/D15920



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

Re: [PATCH] D15539: [libcxxabi] Reducing stack usage of test

[Ben Craig via cfe-commits]

bcraig updated the summary for this revision.
bcraig updated this revision to Diff 47327.

http://reviews.llvm.org/D15539

Files:
  test/dynamic_cast14.pass.cpp

Index: test/dynamic_cast14.pass.cpp
===
--- test/dynamic_cast14.pass.cpp
+++ test/dynamic_cast14.pass.cpp
@@ -213,20 +213,20 @@
 A13* getA13() {return this;}
 };
 
+A3 a3;
+A4 a4;
+A5 a5;
+A6 a6;
+A7 a7;
+A8 a8;
+A9 a9;
+A10 a10;
+A11 a11;
+A12 a12;
+A13 a13;
+
 void test()
 {
-A3 a3;
-A4 a4;
-A5 a5;
-A6 a6;
-A7 a7;
-A8 a8;
-A9 a9;
-A10 a10;
-A11 a11;
-A12 a12;
-A13 a13;
-
 assert(dynamic_cast(a3.getA1_3()) == a3.getA3());
 assert(dynamic_cast(a3.getA2()) == a3.getA3());
 
@@ -934,20 +934,20 @@
 A13* getA13() {return this;}
 };
 
+A3 a3;
+A4 a4;
+A5 a5;
+A6 a6;
+A7 a7;
+A8 a8;
+A9 a9;
+A10 a10;
+A11 a11;
+A12 a12;
+A13 a13;
+
 void test()
 {
-A3 a3;
-A4 a4;
-A5 a5;
-A6 a6;
-A7 a7;
-A8 a8;
-A9 a9;
-A10 a10;
-A11 a11;
-A12 a12;
-A13 a13;
-
 assert(dynamic_cast(a3.getA1_3()) == 0);
 assert(dynamic_cast(a3.getA2()) == a3.getA3());
 
@@ -1655,20 +1655,20 @@
 A13* getA13() {return this;}
 };
 
+A3 a3;
+A4 a4;
+A5 a5;
+A6 a6;
+A7 a7;
+A8 a8;
+A9 a9;
+A10 a10;
+A11 a11;
+A12 a12;
+A13 a13;
+
 void test()
 {
-A3 a3;
-A4 a4;
-A5 a5;
-A6 a6;
-A7 a7;
-A8 a8;
-A9 a9;
-A10 a10;
-A11 a11;
-A12 a12;
-A13 a13;
-
 assert(dynamic_cast(a3.getA1_3()) == a3.getA3());
 assert(dynamic_cast(a3.getA2()) == 0);
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D16535: [clang-tidy] Check to find unintended semicolons that changes the semantics.

[Haojian Wu via cfe-commits]

hokein added inline comments.


Comment at: docs/clang-tidy/checks/misc-suspicious-semicolon.rst:35
@@ +34,3 @@
+
+if(x >= y);
+x -= y;

The doc needs to be updated.

With your latest patch, this is also a warning case.


http://reviews.llvm.org/D16535



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

Re: [PATCH] D15465: [git-clang-format]: New option to perform formatting against staged changes only

[Mark Lodato via cfe-commits]

lodato added inline comments.


Comment at: git-clang-format:124
@@ -121,3 +123,3 @@
   del opts.quiet
 
   commit, files = interpret_args(opts.args, dash_dash, opts.commit)

lodato wrote:
> This will work without `--diff` (otherwise it will try to apply changes in 
> the index to the working directory, which doesn't make sense), so could you 
> please add a check that `--staged` requires `--diff`?
Oops, will //not// work.


Repository:
  rL LLVM

http://reviews.llvm.org/D15465



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

Re: [PATCH] D16963: Copy LibASTMatchersReference.html to gen'd docs

[Steve Downey via cfe-commits]

sdowney added a subscriber: sdowney.
sdowney added a comment.

I'll push up a review with the one line link addition later. Thanks!

The html copy should also get applied to the release_38 branch too, if
there's going to be another RC.


http://reviews.llvm.org/D16963



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

Re: [PATCH] D16922: [clang-tidy] Added check-fixes for misc-virtual-near-miss.

[Alexander Kornienko via cfe-commits]

alexfh added inline comments.


Comment at: clang-tidy/misc/VirtualNearMissCheck.cpp:183
@@ +182,3 @@
+///
+/// This function is copied from the one defined in ASTMatchFinder.cpp to solve
+/// the problem that QualType::getAsCXXRecordDecl does not work for template

I'm not fond of code duplication. If this function is useful in more than one 
place, it should be made public (in a separate patch, since this is a different 
repository) and reused, not just copied.


Comment at: clang-tidy/misc/VirtualNearMissCheck.cpp:270
@@ -225,1 +269,3 @@
+   isOverloadedOperator(),
+   clang::ast_matchers::isTemplateInstantiation(
   .bind("method"),

We usually use `isInTemplateInstantiation()`, which also ignores all 
non-template declarations which have template parents. Also, there's no need to 
fully qualify the name.


Comment at: test/clang-tidy/misc-virtual-near-miss.cpp:49
@@ +48,3 @@
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: method 'TDerived::tfunk' has 
{{.*}} 'TBase::tfunc'
+  // CHECK-FIXES: virtual void tfunc(T t);
+};

This CHECK-FIXES pattern could also match the line inside the TBase class. We 
need to make this pattern more specific, e.g. like this:

  // CHECK-FIXES: struct TDerived :
  // CHECK-FIXES-NEXT: virtual void tfunc(T t);


Comment at: test/clang-tidy/misc-virtual-near-miss.cpp:55
@@ +54,3 @@
+
+// Should not fix macro definition
+#define MACRO1 void funcM()

This comment is not enough, please add a CHECK-FIXES ensuring the macro 
definitions are left intact.


http://reviews.llvm.org/D16922



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

Re: [clang-tools-extra] r260225 - [clang-tidy] Add -target in misc-misplaced-widening-cast test so it will work on various bots

[Alexander Kornienko via cfe-commits]

I'm not sure this is a good fix. What was the specific issue (and on which
buildbots)?

On Tue, Feb 9, 2016 at 4:43 PM, Daniel Marjamaki via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: danielmarjamaki
> Date: Tue Feb  9 09:43:05 2016
> New Revision: 260225
>
> URL: http://llvm.org/viewvc/llvm-project?rev=260225=rev
> Log:
> [clang-tidy] Add -target in misc-misplaced-widening-cast test so it will
> work on various bots
>
> Modified:
>
> clang-tools-extra/trunk/test/clang-tidy/misc-misplaced-widening-cast.cpp
>
> Modified:
> clang-tools-extra/trunk/test/clang-tidy/misc-misplaced-widening-cast.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/misc-misplaced-widening-cast.cpp?rev=260225=260224=260225=diff
>
> ==
> ---
> clang-tools-extra/trunk/test/clang-tidy/misc-misplaced-widening-cast.cpp
> (original)
> +++
> clang-tools-extra/trunk/test/clang-tidy/misc-misplaced-widening-cast.cpp
> Tue Feb  9 09:43:05 2016
> @@ -1,4 +1,4 @@
> -// RUN: %check_clang_tidy %s misc-misplaced-widening-cast %t
> +// RUN: %check_clang_tidy %s misc-misplaced-widening-cast %t -- --
> -target x86_64-unknown-unknown
>
>  void assign(int a, int b) {
>long l;
>
>
> ___
> 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] D15465: [git-clang-format]: New option to perform formatting against staged changes only

[Mark Lodato via cfe-commits]

lodato added a subscriber: lodato.
lodato requested changes to this revision.
lodato added a reviewer: lodato.
lodato added a comment.
This revision now requires changes to proceed.

This does not work properly because it calls `clang-format` on the files in the 
working directory, even if `--staged` is given.  To fix, you need to somehow 
pass in the version of the files in the index into `clang-format`.  To do that, 
I think you'd want to pass in the blob via stdin and add `-assume-filename=...` 
to the command line.

Example:

  $ mkdir tmp
  $ cd tmp
  $ git init
  $ cat > foo.cc < foo.cc 

Need to use function "getAsCXXRecordDecl" of ASTMatchFinder.cpp in a clang-tidy check

[Cong Liu via cfe-commits]

Hi Richard,

I need to use the function (line 747 of ASTMatchFinder.cpp
):

  static CXXRecordDecl *getAsCXXRecordDecl(const Type *TypeNode)

in the misc-virtual-near-miss check of clang-tidy, because it can correctly
get the declaration of a template type, while QualType::getAsCXXRecordDecl
cannot.

But this function is not accessible in clang-tidy check. I think we should
make this function public accessible since its useful. Could you please
tell me how to do it? Thanks a lot.

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

Re: [PATCH] D16963: Copy LibASTMatchersReference.html to gen'd docs

[Steve Downey via cfe-commits]

I'll push up a review with the one line link addition later. Thanks!

The html copy should also get applied to the release_38 branch too, if
there's going to be another RC.

On Tue, Feb 9, 2016 at 11:52 AM Manuel Klimek  wrote:

> klimek added a subscriber: klimek.
> klimek added a comment.
>
> I have fixed that in r260218 for LibASTMatcherReference (basically using
> the same mechanism, but only copying the one file). Not sure which is the
> better approach, I considered globbing, but my gut feeling decided against
> it :)
> Definitely check in the link though.
> Thanks!
>
>
> http://reviews.llvm.org/D16963
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D16963: Copy LibASTMatchersReference.html to gen'd docs

[Manuel Klimek via cfe-commits]

klimek added a subscriber: klimek.
klimek added a comment.

I have fixed that in r260218 for LibASTMatcherReference (basically using the 
same mechanism, but only copying the one file). Not sure which is the better 
approach, I considered globbing, but my gut feeling decided against it :)
Definitely check in the link though.
Thanks!


http://reviews.llvm.org/D16963



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

Re: [PATCH] D16639: [libcxx] Limit catopen usage to unix-like OSes

[Ben Craig via cfe-commits]

bcraig updated the summary for this revision.
bcraig updated this revision to Diff 47328.
bcraig added a comment.

Moved the CATOPEN config check back to __config.  Saving a larger locale 
refactor for later (but oh boy is it coming).


http://reviews.llvm.org/D16639

Files:
  include/__config

Index: include/__config
===
--- include/__config
+++ include/__config
@@ -714,10 +714,12 @@
 #define _LIBCPP_LOCALE__L_EXTENSIONS 1
 #endif
 
-#if !defined(_WIN32) && !defined(__ANDROID__) && !defined(_NEWLIB_VERSION) && \
-!defined(__CloudABI__)
+#if defined(__unix__) || (defined(__APPLE__) && defined(__MACH__))
+// Most unix variants have catopen.  These are the specific ones that don't.
+#if !defined(_WIN32) && !defined(__ANDROID__) && !defined(_NEWLIB_VERSION)
 #define _LIBCPP_HAS_CATOPEN 1
 #endif
+#endif
 
 #ifdef __FreeBSD__
 #define _DECLARE_C99_LDBL_MATH 1


Index: include/__config
===
--- include/__config
+++ include/__config
@@ -714,10 +714,12 @@
 #define _LIBCPP_LOCALE__L_EXTENSIONS 1
 #endif
 
-#if !defined(_WIN32) && !defined(__ANDROID__) && !defined(_NEWLIB_VERSION) && \
-!defined(__CloudABI__)
+#if defined(__unix__) || (defined(__APPLE__) && defined(__MACH__))
+// Most unix variants have catopen.  These are the specific ones that don't.
+#if !defined(_WIN32) && !defined(__ANDROID__) && !defined(_NEWLIB_VERSION)
 #define _LIBCPP_HAS_CATOPEN 1
 #endif
+#endif
 
 #ifdef __FreeBSD__
 #define _DECLARE_C99_LDBL_MATH 1
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D16613: Introduce a cmake module to figure out whether we need to link with libatomic.

[Vasileios Kalintiris via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL260235: Introduce a cmake module to figure out whether we 
need to link with libatomic. (authored by vkalintiris).

Changed prior to commit:
  http://reviews.llvm.org/D16613?vs=46286=47329#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D16613

Files:
  libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake
  libcxx/trunk/cmake/config-ix.cmake
  libcxx/trunk/lib/CMakeLists.txt
  libcxx/trunk/test/CMakeLists.txt
  libcxx/trunk/test/libcxx/test/target_info.py
  libcxx/trunk/test/lit.site.cfg.in

Index: libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake
===
--- libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake
+++ libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake
@@ -0,0 +1,38 @@
+INCLUDE(CheckCXXSourceCompiles)
+
+# Sometimes linking against libatomic is required for atomic ops, if
+# the platform doesn't support lock-free atomics.
+#
+# We could modify LLVM's CheckAtomic module and have it check for 64-bit
+# atomics instead. However, we would like to avoid careless uses of 64-bit
+# atomics inside LLVM over time on 32-bit platforms.
+
+function(check_cxx_atomics varname)
+  set(OLD_CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS})
+  set(CMAKE_REQUIRED_FLAGS "-std=c++11")
+  check_cxx_source_compiles("
+#include 
+#include 
+std::atomic x;
+std::atomic y;
+int main() {
+  return x + y;
+}
+" ${varname})
+  set(CMAKE_REQUIRED_FLAGS ${OLD_CMAKE_REQUIRED_FLAGS})
+endfunction(check_cxx_atomics)
+
+check_cxx_atomics(HAVE_CXX_ATOMICS_WITHOUT_LIB)
+# If not, check if the library exists, and atomics work with it.
+if(NOT HAVE_CXX_ATOMICS_WITHOUT_LIB)
+  check_library_exists(atomic __atomic_fetch_add_8 "" HAVE_LIBATOMIC)
+  if(HAVE_LIBATOMIC)
+list(APPEND CMAKE_REQUIRED_LIBRARIES "atomic")
+check_cxx_atomics(HAVE_CXX_ATOMICS_WITH_LIB)
+if (NOT HAVE_CXX_ATOMICS_WITH_LIB)
+  message(FATAL_ERROR "Host compiler must support std::atomic!")
+endif()
+  else()
+message(FATAL_ERROR "Host compiler appears to require libatomic, but cannot find it.")
+  endif()
+endif()
Index: libcxx/trunk/cmake/config-ix.cmake
===
--- libcxx/trunk/cmake/config-ix.cmake
+++ libcxx/trunk/cmake/config-ix.cmake
@@ -1,5 +1,6 @@
 include(CheckLibraryExists)
 include(CheckCXXCompilerFlag)
+include(CheckLibcxxAtomic)
 
 # Check compiler flags
 
@@ -17,3 +18,7 @@
 check_library_exists(m ccos "" LIBCXX_HAS_M_LIB)
 check_library_exists(rt clock_gettime "" LIBCXX_HAS_RT_LIB)
 check_library_exists(gcc_s __gcc_personality_v0 "" LIBCXX_HAS_GCC_S_LIB)
+
+if (NOT HAVE_CXX_ATOMICS_WITHOUT_LIB)
+  set(LIBCXX_HAS_ATOMIC_LIB True)
+endif()
Index: libcxx/trunk/test/lit.site.cfg.in
===
--- libcxx/trunk/test/lit.site.cfg.in
+++ libcxx/trunk/test/lit.site.cfg.in
@@ -20,6 +20,7 @@
 config.target_info  = "@LIBCXX_TARGET_INFO@"
 config.executor = "@LIBCXX_EXECUTOR@"
 config.llvm_unwinder= "@LIBCXXABI_USE_LLVM_UNWINDER@"
+config.use_libatomic= "@LIBCXX_HAS_ATOMIC_LIB@"
 
 # Let the main config do the real work.
 lit_config.load_config(config, "@LIBCXX_SOURCE_DIR@/test/lit.cfg")
Index: libcxx/trunk/test/CMakeLists.txt
===
--- libcxx/trunk/test/CMakeLists.txt
+++ libcxx/trunk/test/CMakeLists.txt
@@ -15,6 +15,7 @@
 pythonize_bool(LIBCXX_BUILD_32_BITS)
 pythonize_bool(LIBCXX_GENERATE_COVERAGE)
 pythonize_bool(LIBCXXABI_USE_LLVM_UNWINDER)
+pythonize_bool(LIBCXX_HAS_ATOMIC_LIB)
 
 # The tests shouldn't link to any ABI library when it has been linked into
 # libc++ statically or via a linker script.
Index: libcxx/trunk/test/libcxx/test/target_info.py
===
--- libcxx/trunk/test/libcxx/test/target_info.py
+++ libcxx/trunk/test/libcxx/test/target_info.py
@@ -172,6 +172,9 @@
 flags += ['-lunwind', '-ldl']
 else:
 flags += ['-lgcc_s', '-lgcc']
+use_libatomic = self.full_config.get_lit_bool('use_libatomic', False)
+if use_libatomic:
+flags += ['-latomic']
 san = self.full_config.get_lit_conf('use_sanitizer', '').strip()
 if san:
 # The libraries and their order are taken from the
Index: libcxx/trunk/lib/CMakeLists.txt
===
--- libcxx/trunk/lib/CMakeLists.txt
+++ libcxx/trunk/lib/CMakeLists.txt
@@ -79,6 +79,7 @@
 add_library_flags_if(LIBCXX_HAS_M_LIB m)
 add_library_flags_if(LIBCXX_HAS_RT_LIB rt)
 add_library_flags_if(LIBCXX_HAS_GCC_S_LIB gcc_s)
+add_library_flags_if(LIBCXX_HAS_ATOMIC_LIB atomic)
 
 # Setup flags.
 add_flags_if_supported(-fPIC)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org

[libcxx] r260235 - Introduce a cmake module to figure out whether we need to link with libatomic.

[Vasileios Kalintiris via cfe-commits]

Author: vkalintiris
Date: Tue Feb  9 11:00:38 2016
New Revision: 260235

URL: http://llvm.org/viewvc/llvm-project?rev=260235=rev
Log:
Introduce a cmake module to figure out whether we need to link with libatomic.

Summary:
This fixes the tests under std/atomics for 32-bit MIPS CPUs where the
8-byte atomic operations call into the libatomic library.

Reviewers: dsanders, mclow.lists, EricWF, jroelofs, joerg

Subscribers: cfe-commits

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

Added:
libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake
Modified:
libcxx/trunk/cmake/config-ix.cmake
libcxx/trunk/lib/CMakeLists.txt
libcxx/trunk/test/CMakeLists.txt
libcxx/trunk/test/libcxx/test/target_info.py
libcxx/trunk/test/lit.site.cfg.in

Added: libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake?rev=260235=auto
==
--- libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake (added)
+++ libcxx/trunk/cmake/Modules/CheckLibcxxAtomic.cmake Tue Feb  9 11:00:38 2016
@@ -0,0 +1,38 @@
+INCLUDE(CheckCXXSourceCompiles)
+
+# Sometimes linking against libatomic is required for atomic ops, if
+# the platform doesn't support lock-free atomics.
+#
+# We could modify LLVM's CheckAtomic module and have it check for 64-bit
+# atomics instead. However, we would like to avoid careless uses of 64-bit
+# atomics inside LLVM over time on 32-bit platforms.
+
+function(check_cxx_atomics varname)
+  set(OLD_CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS})
+  set(CMAKE_REQUIRED_FLAGS "-std=c++11")
+  check_cxx_source_compiles("
+#include 
+#include 
+std::atomic x;
+std::atomic y;
+int main() {
+  return x + y;
+}
+" ${varname})
+  set(CMAKE_REQUIRED_FLAGS ${OLD_CMAKE_REQUIRED_FLAGS})
+endfunction(check_cxx_atomics)
+
+check_cxx_atomics(HAVE_CXX_ATOMICS_WITHOUT_LIB)
+# If not, check if the library exists, and atomics work with it.
+if(NOT HAVE_CXX_ATOMICS_WITHOUT_LIB)
+  check_library_exists(atomic __atomic_fetch_add_8 "" HAVE_LIBATOMIC)
+  if(HAVE_LIBATOMIC)
+list(APPEND CMAKE_REQUIRED_LIBRARIES "atomic")
+check_cxx_atomics(HAVE_CXX_ATOMICS_WITH_LIB)
+if (NOT HAVE_CXX_ATOMICS_WITH_LIB)
+  message(FATAL_ERROR "Host compiler must support std::atomic!")
+endif()
+  else()
+message(FATAL_ERROR "Host compiler appears to require libatomic, but 
cannot find it.")
+  endif()
+endif()

Modified: libcxx/trunk/cmake/config-ix.cmake
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/config-ix.cmake?rev=260235=260234=260235=diff
==
--- libcxx/trunk/cmake/config-ix.cmake (original)
+++ libcxx/trunk/cmake/config-ix.cmake Tue Feb  9 11:00:38 2016
@@ -1,5 +1,6 @@
 include(CheckLibraryExists)
 include(CheckCXXCompilerFlag)
+include(CheckLibcxxAtomic)
 
 # Check compiler flags
 
@@ -17,3 +18,7 @@ check_library_exists(c fopen "" LIBCXX_H
 check_library_exists(m ccos "" LIBCXX_HAS_M_LIB)
 check_library_exists(rt clock_gettime "" LIBCXX_HAS_RT_LIB)
 check_library_exists(gcc_s __gcc_personality_v0 "" LIBCXX_HAS_GCC_S_LIB)
+
+if (NOT HAVE_CXX_ATOMICS_WITHOUT_LIB)
+  set(LIBCXX_HAS_ATOMIC_LIB True)
+endif()

Modified: libcxx/trunk/lib/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/lib/CMakeLists.txt?rev=260235=260234=260235=diff
==
--- libcxx/trunk/lib/CMakeLists.txt (original)
+++ libcxx/trunk/lib/CMakeLists.txt Tue Feb  9 11:00:38 2016
@@ -79,6 +79,7 @@ add_library_flags_if(LIBCXX_HAS_C_LIB c)
 add_library_flags_if(LIBCXX_HAS_M_LIB m)
 add_library_flags_if(LIBCXX_HAS_RT_LIB rt)
 add_library_flags_if(LIBCXX_HAS_GCC_S_LIB gcc_s)
+add_library_flags_if(LIBCXX_HAS_ATOMIC_LIB atomic)
 
 # Setup flags.
 add_flags_if_supported(-fPIC)

Modified: libcxx/trunk/test/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/CMakeLists.txt?rev=260235=260234=260235=diff
==
--- libcxx/trunk/test/CMakeLists.txt (original)
+++ libcxx/trunk/test/CMakeLists.txt Tue Feb  9 11:00:38 2016
@@ -15,6 +15,7 @@ pythonize_bool(LIBCXX_ENABLE_SHARED)
 pythonize_bool(LIBCXX_BUILD_32_BITS)
 pythonize_bool(LIBCXX_GENERATE_COVERAGE)
 pythonize_bool(LIBCXXABI_USE_LLVM_UNWINDER)
+pythonize_bool(LIBCXX_HAS_ATOMIC_LIB)
 
 # The tests shouldn't link to any ABI library when it has been linked into
 # libc++ statically or via a linker script.

Modified: libcxx/trunk/test/libcxx/test/target_info.py
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/libcxx/test/target_info.py?rev=260235=260234=260235=diff
==
--- libcxx/trunk/test/libcxx/test/target_info.py (original)
+++ libcxx/trunk/test/libcxx/test/target_info.py Tue Feb  9 11:00:38 2016
@@ 

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

On Tue, Feb 9, 2016 at 6:45 AM, H.J. Lu  wrote:
> On Mon, Feb 8, 2016 at 3:28 PM, Richard Smith  wrote:
>> On Mon, Feb 8, 2016 at 3:01 PM, H.J. Lu  wrote:
>>> On Mon, Feb 8, 2016 at 2:58 PM, Richard Smith  wrote:
 On Mon, Feb 8, 2016 at 2:54 PM, H.J. Lu  wrote:
> On Mon, Feb 8, 2016 at 2:51 PM, Richard Smith  
> wrote:
>> On Mon, Feb 8, 2016 at 2:46 PM, H.J. Lu  wrote:
>>> On Mon, Feb 8, 2016 at 2:35 PM, Richard Smith  
>>> wrote:
 On Mon, Feb 8, 2016 at 1:40 PM, H.J. Lu  wrote:
>
> On Mon, Feb 8, 2016 at 12:38 PM, Richard Smith 
>  wrote:
> > On Mon, Feb 8, 2016 at 12:05 PM, H.J. Lu  
> > wrote:
> >>
> >> On Mon, Feb 8, 2016 at 11:33 AM, Jonathan Wakely 
> >> 
> >> wrote:
> >> > On 8 February 2016 at 19:23, Richard Smith wrote:
> >> >> "POD for the purpose of layout" is defined in the Itanium C++ 
> >> >> ABI here:
> >> >>
> >> >>   http://mentorembedded.github.io/cxx-abi/abi.html#definitions
> >> >
> >> > Thanks. So there's no problem using "POD for the purposes of 
> >> > layout",
> >> > and the change to "POD for the purpose of standard-layout" was
> >> > unnecessary and just confused things.
> >>
> >> Here is the revised proposal:
> >>
> >> 1. "class type".  A class type is a structure, union or C++ class.
> >> 2. "empty class type".  An empty class type is:
> >>a. A class type without member.  Or
> >>b. A class type with only members of empty class types.  Or
> >
> >
> > (a) is a special case of (b).
> >
> >>c. An array of empty class types.
> >
> >
> > It seems confusing to call an array a class type. Instead, how 
> > about:
> >
> >   2. An empty type is either an array of empty types or a class 
> > type where
> > every member is of empty type.
> >
> >> 3. "empty record".  An empty record is Plain Old Data (POD) for the
> >>purposes of layout and
> >>a. A class type without member.  Or
> >>b. A class type with only members of empty class types.
> >
> >
> > (a) is a special case of (b).
> >
> >> 4. No memory slot nor register should be used to pass or return an 
> >> object
> >> of empty record.
> >
> >
> > Objects of array type are never passed or returned (but if through 
> > some
> > language extension they were, we'd want this rule to apply). So you 
> > don't
> > need rule 3 and this can be just:
> >
> >  3. No memory slot nor register should be used to pass or return an 
> > object
> > of empty type.
>
> Thanks very much for your inputs.  Here is the proposal:
>
> 1. "class type".  A class type is a structure, union or C++ class.
> 2. "empty type".  An empty type is either an array of empty types or a
> class type where every member is of empty type.
> 3. No memory slot nor register should be used to pass or return an 
> object
> of empty type.

 David Majnemer points out that we also need to say something about
 base classes. We could handle that case like this:

  2. "empty type".  An empty type is a type where it and all of its
 subobjects are of class or array type.

 Following the C++ rules, this also means that a class that contains
 only unnamed bitfields is empty, because unnamed bitfields are not
 subobjects, but might be worth explicitly stating for the C case. That
 also matches Clang's behavior.
>>>
>>> Like this?
>>>
>>> 1. "class type".  A class type is a structure, union or C++ class.
>>> 2. "empty type".  An empty type is
>>>a. A type where it and all of its subobjects are of class or array
>>>type. And
>>>b. Either an array of empty types or a class type where every member
>>>is of empty type.
>>
>> You don't need (b). It's implied by (a).
>
> Does (a) cover empty type?

 Yes, (a) is a complete definition of "empty type" by itself: the
 definition is, essentially, that a complete recursive walk of the type
 and all its subobjects never sees anything that would require any
 storage (that is, it only sees class types and array types).
>>>
>>> Is there a definition of subobject?
>>
>> Yes, the C++ standard defines the term (as an 

Re: [PATCH] D15829: [PGO] Clang Option that enables IR level PGO instrumentation

[Rong Xu via cfe-commits]

xur updated this revision to Diff 47331.
xur added a comment.

Ping

(also added the test that missed from last upload).

Thanks,

-Rong


http://reviews.llvm.org/D15829

Files:
  include/clang/Driver/CC1Options.td
  include/clang/Frontend/CodeGenOptions.h
  lib/CodeGen/BackendUtil.cpp
  lib/CodeGen/CodeGenModule.cpp
  lib/Driver/CMakeLists.txt
  lib/Driver/Tools.cpp
  lib/Frontend/CompilerInvocation.cpp
  test/CodeGen/Inputs/pgotestclang.profraw
  test/CodeGen/Inputs/pgotestir.profraw
  test/CodeGen/pgo-instrumentation.c

Index: test/CodeGen/pgo-instrumentation.c
===
--- test/CodeGen/pgo-instrumentation.c
+++ test/CodeGen/pgo-instrumentation.c
@@ -0,0 +1,28 @@
+// Test if PGO instrumentation and use pass are invoked.
+//
+// Ensure Pass PGOInstrumentationGenPass is invoked.
+// RUN: %clang -O2 -c -Xclang -fprofile-instrument=llvm -fprofile-instr-generate %s -mllvm -debug-pass=Structure 2>&1 | FileCheck %s -check-prefix=CHECK-PGOGENPASS-INVOKED-INSTR-GEN
+// CHECK-PGOGENPASS-INVOKED-INSTR-GEN: PGOInstrumentationGenPass
+//
+// Ensure Pass PGOInstrumentationGenPass is invoked.
+// RUN: %clang -O2 -c -Xclang -fprofile-instrument=llvm -fprofile-generate %s -mllvm -debug-pass=Structure 2>&1 | FileCheck %s -check-prefix=CHECK-PGOGENPASS-INVOKED-GEN
+// CHECK-PGOGENPASS-INVOKED-GEN: PGOInstrumentationGenPass
+//
+// Ensure Pass PGOInstrumentationGenPass is not invoked.
+// RUN: %clang -O2 -c -Xclang -fprofile-instrument=clang -fprofile-instr-generate %s -mllvm -debug-pass=Structure 2>&1 | FileCheck %s -check-prefix=CHECK-PGOGENPASS-INVOKED-INSTR-GEN-CLANG
+// CHECK-PGOGENPASS-INVOKED-INSTR-GEN-CLANG-NOT: PGOInstrumentationGenPass
+//
+// Ensure Pass PGOInstrumentationUsePass is invoked.
+// RUN: llvm-profdata merge -o %t.profdata %S/Inputs/pgotestir.profraw
+// RUN: %clang -O2 -c -Xclang -fprofile-instrument=llvm -fprofile-instr-use=%t.profdata %s -mllvm -debug-pass=Structure 2>&1 | FileCheck %s -check-prefix=CHECK-PGOUSEPASS-INVOKED-INSTR-USE
+// CHECK-PGOUSEPASS-INVOKED-INSTR-USE: PGOInstrumentationUsePass
+//
+// Ensure Pass PGOInstrumentationUsePass is invoked.
+// RUN: llvm-profdata merge -o %t.profdata %S/Inputs/pgotestir.profraw
+// RUN: %clang -O2 -c -Xclang -fprofile-instrument=llvm -fprofile-use=%t.profdata %s -mllvm -debug-pass=Structure 2>&1 | FileCheck %s -check-prefix=CHECK-PGOUSEPASS-INVOKED-USE
+// CHECK-PGOUSEPASS-INVOKED-USE: PGOInstrumentationUsePass
+//
+// Ensure Pass PGOInstrumentationUsePass is not invoked.
+// RUN: llvm-profdata merge -o %t.profdata %S/Inputs/pgotestclang.profraw
+// RUN: %clang -O2 -c -Xclang -fprofile-instrument=clang -fprofile-use=%t.profdata %s -mllvm -debug-pass=Structure 2>&1 | FileCheck %s -check-prefix=CHECK-PGOUSEPASS-INVOKED-USE-CLANG
+// CHECK-PGOUSEPASS-INVOKED-USE-CLANG-NOT: PGOInstrumentationUsePass
Index: test/CodeGen/Inputs/pgotestir.profraw
===
--- test/CodeGen/Inputs/pgotestir.profraw
+++ test/CodeGen/Inputs/pgotestir.profraw
@@ -0,0 +1 @@
+:ir
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -478,14 +478,18 @@
   Opts.Autolink = !Args.hasArg(OPT_fno_autolink);
   Opts.SampleProfileFile = Args.getLastArgValue(OPT_fprofile_sample_use_EQ);
 
-  enum PGOInstrumentor { Unknown, None, Clang };
+  enum PGOInstrumentor { Unknown, None, Clang, LLVM };
   if (Arg *A = Args.getLastArg(OPT_fprofile_instrument_EQ)) {
 StringRef Value = A->getValue();
 PGOInstrumentor Method = llvm::StringSwitch(Value)
- .Case("clang", Clang)
  .Case("none", None)
+ .Case("clang", Clang)
+ .Case("llvm", LLVM)
  .Default(Unknown);
 switch (Method) {
+case LLVM:
+  Opts.setProfileInstr(CodeGenOptions::ProfileIRInstr);
+  break;
 case Clang:
   Opts.setProfileInstr(CodeGenOptions::ProfileClangInstr);
   break;
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -32,6 +32,7 @@
 #include "llvm/Option/Arg.h"
 #include "llvm/Option/ArgList.h"
 #include "llvm/Option/Option.h"
+#include "llvm/ProfileData/InstrProfReader.h"
 #include "llvm/Support/CodeGen.h"
 #include "llvm/Support/Compression.h"
 #include "llvm/Support/ErrorHandling.h"
@@ -3196,6 +3197,18 @@
   return VersionTuple();
 }
 
+// Set the profile kind if it's not the default clang kind.
+static void setProfileKindFlag(ArgStringList ,
+   std::string ProfileName) {
+  auto ReaderOrErr = llvm::IndexedInstrProfReader::create(ProfileName);
+  if (ReaderOrErr.getError())
+return;
+  std::unique_ptr PGOReader =
+std::move(ReaderOrErr.get());
+  

Re: [PATCH] D16947: [PGO] assignment operator does not get profile data

[David Blaikie via cfe-commits]

dblaikie added inline comments.


Comment at: cfe/trunk/test/Profile/def-assignop.cpp:27
@@ +26,3 @@
+
+int main() {
+  A a1, a2;

This doesn't need to be main or have an int return. Just make it a void 
function (with some generic name) & drop the "return 0" to keep it simple.


Repository:
  rL LLVM

http://reviews.llvm.org/D16947



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

r260276 - Fix the test added in r260266

[Ehsan Akhgari via cfe-commits]

Author: ehsan
Date: Tue Feb  9 14:49:24 2016
New Revision: 260276

URL: http://llvm.org/viewvc/llvm-project?rev=260276=rev
Log:
Fix the test added in r260266

Modified:
cfe/trunk/test/Frontend/plugins.c

Modified: cfe/trunk/test/Frontend/plugins.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/plugins.c?rev=260276=260275=260276=diff
==
--- cfe/trunk/test/Frontend/plugins.c (original)
+++ cfe/trunk/test/Frontend/plugins.c Tue Feb  9 14:49:24 2016
@@ -1,5 +1,5 @@
 // RUN: %clang_cc1 -load %llvmshlibdir/PrintFunctionNames%pluginext -plugin 
print-fns %s 2>&1 | FileCheck %s
-// RUN: %clang_cl -Xclang -load -Xclang 
%llvmshlibdir/PrintFunctionNames%pluginext -Xclang -plugin -Xclang print-fns %s 
2>&1 | FileCheck %s
+// RUN: %clang_cl -c -Xclang -load -Xclang 
%llvmshlibdir/PrintFunctionNames%pluginext -Xclang -plugin -Xclang print-fns 
-Tc %s 2>&1 | FileCheck %s
 // REQUIRES: plugins, examples
 
 // CHECK: top-level-decl: "x"


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

Re: Patch for Bug 26283: float.h is missing mandatory C11 fp macros like DBL_DECIMAL_DIG and LDBL_DECIMAL_DIG

[Richard Smith via cfe-commits]

Patch looks good. Please also add a testcase to test/Headers.

On Tue, Feb 9, 2016 at 12:08 PM, Hubert Tong via cfe-commits
 wrote:
> I see no immediate issue with this patch, but I am not one of the usual
> reviewers for this part of the code base.
>
> -- HT
>
>
> On Tue, Feb 9, 2016 at 2:56 PM, Jorge Teixeira 
> wrote:
>>
>> Thanks Hubert. Somehow I omitted that prefix when typing the macros,
>> and I did not noticed it when I was testing because on my arch
>> DECIMAL_DIG is defined to be the LDBL version...
>>
>> Updated patch is attached.
>>
>> JT
>>
>> On Tue, Feb 9, 2016 at 1:41 PM, Hubert Tong
>>  wrote:
>> > There is a __LDBL_DECIMAL_DIG__ predefined macro. __DECIMAL_DIG__ will
>> > not
>> > always be the same as __LDBL_DECIMAL_DIG__.
>> >
>> > -- HT
>> >
>> > On Mon, Feb 8, 2016 at 11:26 PM, Jorge Teixeira via cfe-commits
>> >  wrote:
>> >>
>> >> Hi, I filed the bug (https://llvm.org/bugs/show_bug.cgi?id=26283) some
>> >> time ago and nobody picked it up, so here is a trivial patch exposing
>> >> the missing macros, that to the best of my ability were already
>> >> present as the internal underscored versions.
>> >>
>> >> Perhaps a more general bug about C11 floating point (lack of)
>> >> conformance should be filed, so that some form of unit test/macro
>> >> validation could be worked on, but this patch does scratch my current
>> >> itch.
>> >>
>> >> Successfully tested on x86-64 Xubuntu 14.04 with clang 3.8 from the
>> >> ppa, patched with the attached diff.
>> >>
>> >> First contribution, so feel free to suggest improvements or point to
>> >> more detailed step-by-step instructions/guidelines.
>> >>
>> >> Cheers,
>> >>
>> >> JT
>> >>
>> >> ___
>> >> 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: r260267 - Pass /bigobj when building lib/ASTMatchers/Dynamic/Registry.cpp

[Aaron Ballman via cfe-commits]

On Tue, Feb 9, 2016 at 3:59 PM, Reid Kleckner  wrote:
> On Tue, Feb 9, 2016 at 12:32 PM, Aaron Ballman 
> wrote:
>>
>> On Tue, Feb 9, 2016 at 2:53 PM, Reid Kleckner via cfe-commits
>>  wrote:
>> > Author: rnk
>> > Date: Tue Feb  9 13:53:30 2016
>> > New Revision: 260267
>> >
>> > URL: http://llvm.org/viewvc/llvm-project?rev=260267=rev
>> > Log:
>> > Pass /bigobj when building lib/ASTMatchers/Dynamic/Registry.cpp
>> >
>> > This is the third time it has crossed the 2^16 section limit. We've
>> > already spent time optimizing this file to reduce template
>> > instantiations, and it's not clear that there is anymore low hanging
>> > fruit.
>>
>> Bummer. Do we have any mechanisms in place that will bark loudly at us
>> when we accidentally introduce a large quantity of symbols from this
>> file now? That has also happened a few times, and /bigobj warnings
>> were the primary way we were notified (since it's difficult to tell
>> from file size alone).
>
>
> No, there isn't any mechanism. I think what we really should be worrying
> about is overall code size, and that this particular section count limit is
> arbitrary.

It is definitely sub-optimal and arbitrary, yet it has pointed out
real problems in the past that we would be unlikely to catch as
quickly, so it was better than nothing. Note, I am not suggesting this
commit is inappropriate, just unfortunate.

> If we tackled the code size problem directly, we'd use a tool to highlight
> code that has a high source-line-to-code-byte ratio. I know Chromium has
> done this in the past to identify overly inlined functions and things that
> shouldn't be templates.

That would definitely be useful functionality!

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

Re: [PATCH] D15373: Fix for bug 25786 - Assertion "Chunk.Kind == DeclaratorChunk::Function" failed with regparm attribute.

[Reid Kleckner via cfe-commits]

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

Thanks, lgtm!


http://reviews.llvm.org/D15373



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

[libclc] r260303 - configure: Remove cl_khr_fp64 for device that don't support doubles

[Jan Vesely via cfe-commits]

Author: jvesely
Date: Tue Feb  9 16:17:46 2016
New Revision: 260303

URL: http://llvm.org/viewvc/llvm-project?rev=260303=rev
Log:
configure: Remove cl_khr_fp64 for device that don't support doubles

Also remove definitions if provided by clang (3.7+)
This halves the size of builtin.opt.{cedar,barts}.bc

reviewer: tstellard
Signed-off-by: Jan Vesely 

Modified:
libclc/trunk/configure.py

Modified: libclc/trunk/configure.py
URL: 
http://llvm.org/viewvc/llvm-project/libclc/trunk/configure.py?rev=260303=260302=260303=diff
==
--- libclc/trunk/configure.py (original)
+++ libclc/trunk/configure.py Tue Feb  9 16:17:46 2016
@@ -92,16 +92,16 @@ if not cxx_compiler:
 available_targets = {
   'r600--' : { 'devices' :
[{'gpu' : 'cedar',   'aliases' : ['palm', 'sumo', 'sumo2', 
'redwood', 'juniper'],
- 'defines' : {'LLVM3.6':['cl_khr_fp64'], 
'LLVM3.7':['cl_khr_fp64']}},
+ 'defines' : {}},
 {'gpu' : 'cypress', 'aliases' : ['hemlock'],
- 'defines' : {'LLVM3.6':['cl_khr_fp64'], 
'LLVM3.7':['cl_khr_fp64']}},
+ 'defines' : {'LLVM3.6':['cl_khr_fp64']}},
 {'gpu' : 'barts',   'aliases' : ['turks', 'caicos'],
- 'defines' : {'LLVM3.6':['cl_khr_fp64'], 
'LLVM3.7':['cl_khr_fp64']}},
+ 'defines' : {}},
 {'gpu' : 'cayman',  'aliases' : ['aruba'],
- 'defines' : {'LLVM3.6':['cl_khr_fp64'], 
'LLVM3.7':['cl_khr_fp64']}} ]},
+ 'defines' : {'LLVM3.6':['cl_khr_fp64']}} ]},
   'amdgcn--': { 'devices' :
 [{'gpu' : 'tahiti', 'aliases' : ['pitcairn', 'verde', 'oland', 
'hainan', 'bonaire', 'kabini', 'kaveri', 
'hawaii','mullins','tonga','carrizo','iceland','fiji','stoney'],
- 'defines' : {'LLVM3.6':['cl_khr_fp64'], 
'LLVM3.7':['cl_khr_fp64']}} ]},
+ 'defines' : {'LLVM3.6':['cl_khr_fp64']}} ]},
   'nvptx--'   : { 'devices' : [{'gpu' : '', 'aliases' : [],
 'defines' : {'all' : ['cl_khr_fp64']}}]},
   'nvptx64--' : { 'devices' : [{'gpu' : '', 'aliases' : [],


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

[libclc] r260301 - math: Fix log2 vectorization on non-fp64 hw

[Jan Vesely via cfe-commits]

Author: jvesely
Date: Tue Feb  9 16:17:42 2016
New Revision: 260301

URL: http://llvm.org/viewvc/llvm-project?rev=260301=rev
Log:
math: Fix log2 vectorization on non-fp64 hw

reviewer: tstellard
Signed-off-by: Jan Vesely 

Modified:
libclc/trunk/generic/lib/math/log2.cl

Modified: libclc/trunk/generic/lib/math/log2.cl
URL: 
http://llvm.org/viewvc/llvm-project/libclc/trunk/generic/lib/math/log2.cl?rev=260301=260300=260301=diff
==
--- libclc/trunk/generic/lib/math/log2.cl (original)
+++ libclc/trunk/generic/lib/math/log2.cl Tue Feb  9 16:17:42 2016
@@ -34,4 +34,6 @@
 
 _CLC_UNARY_VECTORIZE(_CLC_OVERLOAD _CLC_DEF, float, log2, float);
 
+#ifdef cl_khr_fp64
 _CLC_UNARY_VECTORIZE(_CLC_OVERLOAD _CLC_DEF, double, log2, double);
+#endif // cl_khr_fp64


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

r260311 - Update documentation to reflect that libc++abi provides __cxa_thread_atexit (and has for quite a while). Also document that we have not yet implemented the new inheriting constructor rules.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Tue Feb  9 16:48:14 2016
New Revision: 260311

URL: http://llvm.org/viewvc/llvm-project?rev=260311=rev
Log:
Update documentation to reflect that libc++abi provides __cxa_thread_atexit 
(and has for quite a while). Also document that we have not yet implemented the 
new inheriting constructor rules.

Modified:
cfe/trunk/www/cxx_status.html

Modified: cfe/trunk/www/cxx_status.html
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/www/cxx_status.html?rev=260311=260310=260311=diff
==
--- cfe/trunk/www/cxx_status.html (original)
+++ cfe/trunk/www/cxx_status.html Tue Feb  9 16:48:14 2016
@@ -67,8 +67,7 @@ patches are needed to make libstdc++-4.6
 and libstdc++-4.7 work with Clang
-releases prior to version 3.2 in C++11 mode. thread_local support
-currently requires the C++ runtime library from g++-4.8 or later.
+releases prior to version 3.2 in C++11 mode.
 
 
  
@@ -373,7 +372,7 @@ currently requires the C++ runtime libra
 
   Thread-local storage
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2659.htm;>N2659
-  Clang 3.3
+  Clang 3.3 (5)
 
 
   Dynamic initialization and destruction with concurrency
@@ -402,7 +401,7 @@ currently requires the C++ runtime libra
 
   Extended integral types
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1988.pdf;>N1988
-  N/A (5)
+  N/A (6)
 
 
 
@@ -415,7 +414,11 @@ such as Clang that does not provide garb
 strong compare-exchanges.
 (4): memory_order_consume is lowered to
 memory_order_acquire.
-(5): No compiler changes are required for an implementation
+(5): thread_local support
+requires a C++ runtime library providing __cxa_thread_atexit, such
+as http://libcxxabi.llvm.org;>libc++abi 3.6 or later,
+or libsupc++ 4.8 or later.
+(6): No compiler changes are required for an implementation
 such as Clang that does not provide any extended integer types.
 __int128 is not treated as an extended integer type,
 because changing intmax_t would be an ABI-incompatible
@@ -501,12 +504,12 @@ Clang version in which each feature beca
 
   C++ Sized Deallocation
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3778.html;>N3778
-  Clang 3.4 (6)
+  Clang 3.4 (7)
 
 
 
 
-(6): In Clang 3.7 and later, sized deallocation is only 
enabled
+(7): In Clang 3.7 and later, sized deallocation is only 
enabled
 if the user passes the -fsized-deallocation flag. The user must
 supply definitions of the sized deallocation functions, either by providing 
them
 explicitly or by using a C++ standard library that does. libstdc++
@@ -517,9 +520,9 @@ version 3.7.
 
 C++1z implementation status
 
-Clang has highly experimental support for some proposed features of
-the C++ standard following C++14,
-provisionally named C++1z.  The following table describes which C++1z features
+Clang has experimental support for some proposed features of
+the C++ standard following C++14, provisionally named C++1z.
+The following table describes which C++1z features
 have been implemented in Clang and in which Clang version they became
 available.
 
@@ -564,7 +567,7 @@ as the draft C++1z standard evolves.
 
   New auto rules for direct-list-initialization
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3922.html;>N3922
-  Clang 3.8 (7)
+  Clang 3.8 (8)
 
 
 
@@ -613,10 +616,15 @@ as the draft C++1z standard evolves.
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0061.html;>P0061R1
   Yes
 
+
+  New specification for inheriting constructors (DR1941 et al)
+  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0136r1.html;>P0136R1
+  No
+
 
 
 
-(7): This is a backwards-incompatible change that is applied 
to
+(8): This is a backwards-incompatible change that is applied 
to
 all language versions that allow type deduction from auto
 (per the request of the C++ committee).
 In Clang 3.7, a warning is emitted for all cases that would change meaning.


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

Re: [PATCH] D16524: [clang-format-vs] Fix sort include main include: Use current path for the '-assume-filename'

[Jean-Philippe Dufraigne via cfe-commits]

jeanphilippeD added a comment.

Hi Manuel,

Thank you very much for the review.
I do not have commit access, would you be able to commit this patch for me.

Kind Regards,
Jean-Philippe


http://reviews.llvm.org/D16524



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

Re: [PATCH] D16947: [PGO] assignment operator does not get profile data

[David Blaikie via cfe-commits]

On Tue, Feb 9, 2016 at 12:07 PM, David Li via llvm-commits <
llvm-comm...@lists.llvm.org> wrote:

> This revision was automatically updated to reflect the committed changes.
> Closed by commit rL260270: [PGO] Fix issue: explicitly defaulted assignop
> is not profiled (authored by davidxl).
>

In general, if you send something out for review it's best to wait for
explicit sign-off before committing. Sorry I hadn't taken a moment to look
at the clang test you had added - again, got a bit lost in the noise of the
discussion.


>
> Changed prior to commit:
>   http://reviews.llvm.org/D16947?vs=47239=47351#toc
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D16947
>
> Files:
>   cfe/trunk/lib/CodeGen/CGClass.cpp
>   cfe/trunk/test/Profile/def-assignop.cpp
>
> Index: cfe/trunk/test/Profile/def-assignop.cpp
> ===
> --- cfe/trunk/test/Profile/def-assignop.cpp
> +++ cfe/trunk/test/Profile/def-assignop.cpp
> @@ -0,0 +1,32 @@
> +// RUN: %clang_cc1 -x c++ -std=c++11 %s -triple x86_64-unknown-linux-gnu
> -main-file-name def-assignop.cpp -o - -emit-llvm -fprofile-instrument=clang
> | FileCheck --check-prefix=PGOGEN %s
> +// RUN: %clang_cc1 -x c++ -std=c++11 %s -triple x86_64-unknown-linux-gnu
> -main-file-name def-assignop.cpp -o - -emit-llvm -fprofile-instrument=clang
> -fcoverage-mapping | FileCheck --check-prefix=COVMAP %s
> +
> +struct B {
> +  B& operator=(const B );
> +  B& operator=(const B &);
> +};
> +
> +struct A {
> +  A =(const A &) = default;
> +  // PGOGEN: define {{.*}}@_ZN1AaSERKS_(
> +  // PGOGEN: %pgocount = load {{.*}} @__profc__ZN1AaSERKS_
> +  // PGOGEN: {{.*}}add{{.*}}%pgocount, 1
> +  // PGOGEN: store{{.*}}@__profc__ZN1AaSERKS_
> +  A =(A &&) = default;
> +  // PGOGEN: define {{.*}}@_ZN1AaSEOS_
> +  // PGOGEN: %pgocount = load {{.*}} @__profc__ZN1AaSEOS_
> +  // PGOGEN: {{.*}}add{{.*}}%pgocount, 1
> +  // PGOGEN: store{{.*}}@__profc__ZN1AaSEOS_
> +
> +  // Check that coverage mapping includes 6 function records including the
> +  // defaulted copy and move operators: A::operator=
> +  // COVMAP: @__llvm_coverage_mapping = {{.*}} { { i32, i32, i32, i32 },
> [3 x <{{.*}}>],
> +  B b;
> +};
> +
> +int main() {
> +  A a1, a2;
> +  a1 = a2;
> +  a2 = static_cast(a1);
> +  return 0;
> +}
> Index: cfe/trunk/lib/CodeGen/CGClass.cpp
> ===
> --- cfe/trunk/lib/CodeGen/CGClass.cpp
> +++ cfe/trunk/lib/CodeGen/CGClass.cpp
> @@ -1608,6 +1608,7 @@
>
>LexicalScope Scope(*this, RootCS->getSourceRange());
>
> +  incrementProfileCounter(RootCS);
>AssignmentMemcpyizer AM(*this, AssignOp, Args);
>for (auto *I : RootCS->body())
>  AM.emitAssignment(I);
>
>
>
> ___
> llvm-commits mailing list
> llvm-comm...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r260307 - PR26349: correctly check whether a digit sequence is empty in the presence of digit separators.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Tue Feb  9 16:34:35 2016
New Revision: 260307

URL: http://llvm.org/viewvc/llvm-project?rev=260307=rev
Log:
PR26349: correctly check whether a digit sequence is empty in the presence of 
digit separators.

Modified:
cfe/trunk/include/clang/Lex/LiteralSupport.h
cfe/trunk/lib/Lex/LiteralSupport.cpp
cfe/trunk/test/Lexer/cxx1y_digit_separators.cpp

Modified: cfe/trunk/include/clang/Lex/LiteralSupport.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Lex/LiteralSupport.h?rev=260307=260306=260307=diff
==
--- cfe/trunk/include/clang/Lex/LiteralSupport.h (original)
+++ cfe/trunk/include/clang/Lex/LiteralSupport.h Tue Feb  9 16:34:35 2016
@@ -108,6 +108,12 @@ private:
 
   static bool isDigitSeparator(char C) { return C == '\''; }
 
+  /// \brief Determine whether the sequence of characters [Start, End) contains
+  /// any real digits (not digit separators).
+  bool containsDigits(const char *Start, const char *End) {
+return Start != End && (Start + 1 != End || !isDigitSeparator(Start[0]));
+  }
+
   enum CheckSeparatorKind { CSK_BeforeDigits, CSK_AfterDigits };
 
   /// \brief Ensure that we don't have a digit separator here.

Modified: cfe/trunk/lib/Lex/LiteralSupport.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/LiteralSupport.cpp?rev=260307=260306=260307=diff
==
--- cfe/trunk/lib/Lex/LiteralSupport.cpp (original)
+++ cfe/trunk/lib/Lex/LiteralSupport.cpp Tue Feb  9 16:34:35 2016
@@ -700,7 +700,7 @@ void NumericLiteralParser::ParseDecimalO
 saw_exponent = true;
 if (*s == '+' || *s == '-')  s++; // sign
 const char *first_non_digit = SkipDigits(s);
-if (first_non_digit != s) {
+if (containsDigits(s, first_non_digit)) {
   checkSeparator(TokLoc, s, CSK_BeforeDigits);
   s = first_non_digit;
 } else {
@@ -771,19 +771,21 @@ void NumericLiteralParser::ParseNumberSt
 radix = 16;
 DigitsBegin = s;
 s = SkipHexDigits(s);
-bool noSignificand = (s == DigitsBegin);
+bool HasSignificandDigits = containsDigits(DigitsBegin, s);
 if (s == ThisTokEnd) {
   // Done.
 } else if (*s == '.') {
   s++;
   saw_period = true;
   const char *floatDigitsBegin = s;
-  checkSeparator(TokLoc, s, CSK_BeforeDigits);
   s = SkipHexDigits(s);
-  noSignificand &= (floatDigitsBegin == s);
+  if (containsDigits(floatDigitsBegin, s))
+HasSignificandDigits = true;
+  if (HasSignificandDigits)
+checkSeparator(TokLoc, floatDigitsBegin, CSK_BeforeDigits);
 }
 
-if (noSignificand) {
+if (!HasSignificandDigits) {
   PP.Diag(PP.AdvanceToTokenCharacter(TokLoc, s - ThisTokBegin),
 diag::err_hexconstant_requires) << 1;
   hadError = true;
@@ -799,7 +801,7 @@ void NumericLiteralParser::ParseNumberSt
   saw_exponent = true;
   if (*s == '+' || *s == '-')  s++; // sign
   const char *first_non_digit = SkipDigits(s);
-  if (first_non_digit == s) {
+  if (!containsDigits(s, first_non_digit)) {
 PP.Diag(PP.AdvanceToTokenCharacter(TokLoc, Exponent-ThisTokBegin),
 diag::err_exponent_has_no_digits);
 hadError = true;

Modified: cfe/trunk/test/Lexer/cxx1y_digit_separators.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Lexer/cxx1y_digit_separators.cpp?rev=260307=260306=260307=diff
==
--- cfe/trunk/test/Lexer/cxx1y_digit_separators.cpp (original)
+++ cfe/trunk/test/Lexer/cxx1y_digit_separators.cpp Tue Feb  9 16:34:35 2016
@@ -48,6 +48,9 @@ namespace floating {
   float r = 0.'0e1; // expected-error {{digit separator cannot appear at start 
of digit sequence}}
   float s = 0.0'e1; // expected-error {{digit separator cannot appear at end 
of digit sequence}}
   float t = 0.0e'1; // expected-error {{digit separator cannot appear at start 
of digit sequence}}
+  float u = 0x.'p1f; // expected-error {{hexadecimal floating constants 
require a significand}}
+  float v = 0e'f; // expected-error {{exponent has no digits}}
+  float w = 0x0p'f; // expected-error {{exponent has no digits}}
 }
 
 #line 123'456


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

Re: r260267 - Pass /bigobj when building lib/ASTMatchers/Dynamic/Registry.cpp

[Reid Kleckner via cfe-commits]

On Tue, Feb 9, 2016 at 12:32 PM, Aaron Ballman 
wrote:

> On Tue, Feb 9, 2016 at 2:53 PM, Reid Kleckner via cfe-commits
>  wrote:
> > Author: rnk
> > Date: Tue Feb  9 13:53:30 2016
> > New Revision: 260267
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=260267=rev
> > Log:
> > Pass /bigobj when building lib/ASTMatchers/Dynamic/Registry.cpp
> >
> > This is the third time it has crossed the 2^16 section limit. We've
> > already spent time optimizing this file to reduce template
> > instantiations, and it's not clear that there is anymore low hanging
> > fruit.
>
> Bummer. Do we have any mechanisms in place that will bark loudly at us
> when we accidentally introduce a large quantity of symbols from this
> file now? That has also happened a few times, and /bigobj warnings
> were the primary way we were notified (since it's difficult to tell
> from file size alone).
>

No, there isn't any mechanism. I think what we really should be worrying
about is overall code size, and that this particular section count limit is
arbitrary.

If we tackled the code size problem directly, we'd use a tool to highlight
code that has a high source-line-to-code-byte ratio. I know Chromium has
done this in the past to identify overly inlined functions and things that
shouldn't be templates.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D17002: [lanai] Add Lanai backend to clang driver

[Eli Bendersky via cfe-commits]

eliben added a subscriber: eliben.
eliben added a comment.

Clang-level tests?



Comment at: lib/Basic/Targets.cpp:5873
@@ +5872,3 @@
+"-m:e"  // ELF name manging
+"-p:32:32"  // 32-bit pointers work aligned
+"-i64:64"   // 64 bit integers, 64 bit aligned

Maybe make this consistent with the next line comment?


Comment at: lib/CodeGen/TargetInfo.cpp:6498
@@ +6497,3 @@
+
+  unsigned DefaultNumRegisterParameters;
+

Worth a comment? (I dont see thsi documented elsewhere)


Comment at: lib/CodeGen/TargetInfo.cpp:6535
@@ +6534,3 @@
+  const Type *T = isSingleElementStruct(Ty, getContext());
+  if (!T)
+T = Ty.getTypePtr();

Prefer nullptr comparison (here and elsewhere)


http://reviews.llvm.org/D17002



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

r260278 - Add Tooling functionality to get a name for a QualType that can be used to name

[Richard Smith via cfe-commits]

Author: rsmith
Date: Tue Feb  9 15:04:04 2016
New Revision: 260278

URL: http://llvm.org/viewvc/llvm-project?rev=260278=rev
Log:
Add Tooling functionality to get a name for a QualType that can be used to name
that type from the global scope.

Patch by Sterling Augustine, derived (with permission) from code from Cling by
Vassil Vassilev and Philippe Canal.

Added:
cfe/trunk/include/clang/Tooling/Core/QualTypeNames.h
cfe/trunk/lib/Tooling/Core/QualTypeNames.cpp
cfe/trunk/unittests/Tooling/QualTypeNamesTest.cpp
Modified:
cfe/trunk/lib/Tooling/Core/CMakeLists.txt
cfe/trunk/unittests/Tooling/CMakeLists.txt

Added: cfe/trunk/include/clang/Tooling/Core/QualTypeNames.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Tooling/Core/QualTypeNames.h?rev=260278=auto
==
--- cfe/trunk/include/clang/Tooling/Core/QualTypeNames.h (added)
+++ cfe/trunk/include/clang/Tooling/Core/QualTypeNames.h Tue Feb  9 15:04:04 
2016
@@ -0,0 +1,76 @@
+//===--- QualTypeNames.h - Generate Complete QualType Names *- C++ -*-===//
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+// 
===--===//
+//
+// \file
+// Functionality to generate the fully-qualified names of QualTypes,
+// including recursively expanding any subtypes and template
+// parameters.
+//
+// More precisely: Generates a name that can be used to name the same
+// type if used at the end of the current translation unit--with
+// certain limitations. See below.
+//
+// This code desugars names only very minimally, so in this code:
+//
+// namespace A {
+//   struct X {};
+// }
+// using A::X;
+// namespace B {
+//   using std::tuple;
+//   typedef tuple TX;
+//   TX t;
+// }
+//
+// B::t's type is reported as "B::TX", rather than std::tuple.
+//
+// Also, this code replaces types found via using declarations with
+// their more qualified name, so for the code:
+//
+// using std::tuple;
+// tuple TInt;
+//
+// TInt's type will be named, "std::tuple".
+//
+// Limitations:
+//
+// Some types have ambiguous names at the end of a translation unit,
+// are not namable at all there, or are special cases in other ways.
+//
+// 1) Types with only local scope will have their local names:
+//
+// void foo() {
+//   struct LocalType {} LocalVar;
+// }
+//
+// LocalVar's type will be named, "struct LocalType", without any
+// qualification.
+//
+// 2) Types that have been shadowed are reported normally, but a
+// client using that name at the end of the translation unit will be
+// referring to a different type.
+//
+// 
===--===//
+
+#ifndef LLVM_CLANG_TOOLING_CORE_QUALTYPENAMES_H
+#define LLVM_CLANG_TOOLING_CORE_QUALTYPENAMES_H
+
+#include "clang/AST/ASTContext.h"
+
+namespace clang {
+namespace TypeName {
+/// \brief Get the fully qualified name for a type. This includes full
+/// qualification of all template parameters etc.
+///
+/// \param[in] QT - the type for which the fully qualified name will be
+/// returned.
+/// \param[in] Ctx - the ASTContext to be used.
+std::string getFullyQualifiedName(QualType QT,
+  const ASTContext );
+}  // end namespace TypeName
+}  // end namespace clang
+#endif  // LLVM_CLANG_TOOLING_CORE_QUALTYPENAMES_H

Modified: cfe/trunk/lib/Tooling/Core/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Tooling/Core/CMakeLists.txt?rev=260278=260277=260278=diff
==
--- cfe/trunk/lib/Tooling/Core/CMakeLists.txt (original)
+++ cfe/trunk/lib/Tooling/Core/CMakeLists.txt Tue Feb  9 15:04:04 2016
@@ -3,6 +3,7 @@ set(LLVM_LINK_COMPONENTS support)
 add_clang_library(clangToolingCore
   Lookup.cpp
   Replacement.cpp
+  QualTypeNames.cpp
 
   LINK_LIBS
   clangAST

Added: cfe/trunk/lib/Tooling/Core/QualTypeNames.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Tooling/Core/QualTypeNames.cpp?rev=260278=auto
==
--- cfe/trunk/lib/Tooling/Core/QualTypeNames.cpp (added)
+++ cfe/trunk/lib/Tooling/Core/QualTypeNames.cpp Tue Feb  9 15:04:04 2016
@@ -0,0 +1,432 @@
+//===--- QualTypeNames.cpp - Generate Complete QualType Names 
-===//
+//
+// The LLVM Compiler Infrastructure
+//
+//===--===//
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "clang/Tooling/Core/QualTypeNames.h"
+#include "clang/AST/DeclTemplate.h"
+#include "clang/AST/DeclarationName.h"
+#include "clang/AST/GlobalDecl.h"

[libclc] r260302 - configure: Introduce per device defines

[Jan Vesely via cfe-commits]

Author: jvesely
Date: Tue Feb  9 16:17:45 2016
New Revision: 260302

URL: http://llvm.org/viewvc/llvm-project?rev=260302=rev
Log:
configure: Introduce per device defines

Make cl_khr_fp64 define per-device.
This patch does not change the generated Makefile (for llvm 3.6, 3.7)

v2: Make the device defines per LLVM version, 'all' for all versions

reviewer: tstellard
Signed-off-by: Jan Vesely 

Modified:
libclc/trunk/configure.py

Modified: libclc/trunk/configure.py
URL: 
http://llvm.org/viewvc/llvm-project/libclc/trunk/configure.py?rev=260302=260301=260302=diff
==
--- libclc/trunk/configure.py (original)
+++ libclc/trunk/configure.py Tue Feb  9 16:17:45 2016
@@ -91,16 +91,25 @@ if not cxx_compiler:
 
 available_targets = {
   'r600--' : { 'devices' :
-   [{'gpu' : 'cedar',   'aliases' : ['palm', 'sumo', 'sumo2', 
'redwood', 'juniper']},
-{'gpu' : 'cypress', 'aliases' : ['hemlock']},
-{'gpu' : 'barts',   'aliases' : ['turks', 'caicos']},
-{'gpu' : 'cayman',  'aliases' : ['aruba']}]},
+   [{'gpu' : 'cedar',   'aliases' : ['palm', 'sumo', 'sumo2', 
'redwood', 'juniper'],
+ 'defines' : {'LLVM3.6':['cl_khr_fp64'], 
'LLVM3.7':['cl_khr_fp64']}},
+{'gpu' : 'cypress', 'aliases' : ['hemlock'],
+ 'defines' : {'LLVM3.6':['cl_khr_fp64'], 
'LLVM3.7':['cl_khr_fp64']}},
+{'gpu' : 'barts',   'aliases' : ['turks', 'caicos'],
+ 'defines' : {'LLVM3.6':['cl_khr_fp64'], 
'LLVM3.7':['cl_khr_fp64']}},
+{'gpu' : 'cayman',  'aliases' : ['aruba'],
+ 'defines' : {'LLVM3.6':['cl_khr_fp64'], 
'LLVM3.7':['cl_khr_fp64']}} ]},
   'amdgcn--': { 'devices' :
-[{'gpu' : 'tahiti',  'aliases' : ['pitcairn', 'verde', 
'oland', 'hainan', 'bonaire', 'kabini', 'kaveri', 'hawaii', 'mullins', 
'tonga','carrizo','iceland','fiji','stoney']}]},
-  'nvptx--'   : { 'devices' : [{'gpu' : '', 'aliases' : []}]},
-  'nvptx64--'   : { 'devices' : [{'gpu' : '', 'aliases' : []}] },
-  'nvptx--nvidiacl'   : { 'devices' : [{'gpu' : '', 'aliases' : []}] },
-  'nvptx64--nvidiacl' : { 'devices' : [{'gpu' : '', 'aliases' : []}] }
+[{'gpu' : 'tahiti', 'aliases' : ['pitcairn', 'verde', 'oland', 
'hainan', 'bonaire', 'kabini', 'kaveri', 
'hawaii','mullins','tonga','carrizo','iceland','fiji','stoney'],
+ 'defines' : {'LLVM3.6':['cl_khr_fp64'], 
'LLVM3.7':['cl_khr_fp64']}} ]},
+  'nvptx--'   : { 'devices' : [{'gpu' : '', 'aliases' : [],
+'defines' : {'all' : ['cl_khr_fp64']}}]},
+  'nvptx64--' : { 'devices' : [{'gpu' : '', 'aliases' : [],
+'defines' : {'all' : ['cl_khr_fp64']}}]},
+  'nvptx--nvidiacl'   : { 'devices' : [{'gpu' : '', 'aliases' : [],
+'defines' : {'all' : 
['cl_khr_fp64']}}]},
+  'nvptx64--nvidiacl' : { 'devices' : [{'gpu' : '', 'aliases' : [],
+'defines' : {'all' : 
['cl_khr_fp64']}}]},
 }
 
 default_targets = ['nvptx--nvidiacl', 'nvptx64--nvidiacl', 'r600--', 
'amdgcn--']
@@ -178,13 +187,17 @@ for target in targets:
 
   for device in available_targets[target]['devices']:
 # The rule for building a .bc file for the specified architecture using 
clang.
+device_def_list = (device['defines']['all'] if 'all' in device['defines'] 
else []);
+if llvm_string_version in device['defines']:
+device_def_list += (device['defines'][llvm_string_version]);
+device_defines = ' '.join(["-D%s" % define for define in device_def_list])
 clang_bc_flags = "-target %s -I`dirname $in` %s " \
  "-fno-builtin " \
  "-Dcl_clang_storage_class_specifiers " \
- "-Dcl_khr_fp64 " \
+ "%s " \
  "-Dcles_khr_int64 " \
  "-D__CLC_INTERNAL " \
- "-emit-llvm" % (target, clang_cl_includes)
+ "-emit-llvm" % (target, clang_cl_includes, device_defines)
 if device['gpu'] != '':
   clang_bc_flags += ' -mcpu=' + device['gpu']
 clang_bc_rule = "CLANG_CL_BC_" + target + "_" + device['gpu']


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

[libclc] r260304 - configure: Remove llvm 3.6 defines

[Jan Vesely via cfe-commits]

Author: jvesely
Date: Tue Feb  9 16:17:48 2016
New Revision: 260304

URL: http://llvm.org/viewvc/llvm-project?rev=260304=rev
Log:
configure: Remove llvm 3.6 defines

we require llvm 3.7

reviewer: tstellard
Signed-off-by: Jan Vesely 

Modified:
libclc/trunk/configure.py

Modified: libclc/trunk/configure.py
URL: 
http://llvm.org/viewvc/llvm-project/libclc/trunk/configure.py?rev=260304=260303=260304=diff
==
--- libclc/trunk/configure.py (original)
+++ libclc/trunk/configure.py Tue Feb  9 16:17:48 2016
@@ -94,14 +94,14 @@ available_targets = {
[{'gpu' : 'cedar',   'aliases' : ['palm', 'sumo', 'sumo2', 
'redwood', 'juniper'],
  'defines' : {}},
 {'gpu' : 'cypress', 'aliases' : ['hemlock'],
- 'defines' : {'LLVM3.6':['cl_khr_fp64']}},
+ 'defines' : {}},
 {'gpu' : 'barts',   'aliases' : ['turks', 'caicos'],
  'defines' : {}},
 {'gpu' : 'cayman',  'aliases' : ['aruba'],
- 'defines' : {'LLVM3.6':['cl_khr_fp64']}} ]},
+ 'defines' : {}} ]},
   'amdgcn--': { 'devices' :
 [{'gpu' : 'tahiti', 'aliases' : ['pitcairn', 'verde', 'oland', 
'hainan', 'bonaire', 'kabini', 'kaveri', 
'hawaii','mullins','tonga','carrizo','iceland','fiji','stoney'],
- 'defines' : {'LLVM3.6':['cl_khr_fp64']}} ]},
+ 'defines' : {}} ]},
   'nvptx--'   : { 'devices' : [{'gpu' : '', 'aliases' : [],
 'defines' : {'all' : ['cl_khr_fp64']}}]},
   'nvptx64--' : { 'devices' : [{'gpu' : '', 'aliases' : [],


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

r260277 - Simplify and rename ASTMatchFinder's getCXXRecordDecl to make it more obvious

[Richard Smith via cfe-commits]

Author: rsmith
Date: Tue Feb  9 14:59:05 2016
New Revision: 260277

URL: http://llvm.org/viewvc/llvm-project?rev=260277=rev
Log:
Simplify and rename ASTMatchFinder's getCXXRecordDecl to make it more obvious
what it's actually trying to do.

Modified:
cfe/trunk/lib/ASTMatchers/ASTMatchFinder.cpp

Modified: cfe/trunk/lib/ASTMatchers/ASTMatchFinder.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/ASTMatchers/ASTMatchFinder.cpp?rev=260277=260276=260277=diff
==
--- cfe/trunk/lib/ASTMatchers/ASTMatchFinder.cpp (original)
+++ cfe/trunk/lib/ASTMatchers/ASTMatchFinder.cpp Tue Feb  9 14:59:05 2016
@@ -744,46 +744,25 @@ private:
   MemoizationMap ResultCache;
 };
 
-static CXXRecordDecl *getAsCXXRecordDecl(const Type *TypeNode) {
-  // Type::getAs<...>() drills through typedefs.
-  if (TypeNode->getAs() != nullptr ||
-  TypeNode->getAs() != nullptr ||
-  TypeNode->getAs() != nullptr)
-// Dependent names and template TypeNode parameters will be matched when
-// the template is instantiated.
-return nullptr;
-  TemplateSpecializationType const *TemplateType =
-  TypeNode->getAs();
-  if (!TemplateType) {
-return TypeNode->getAsCXXRecordDecl();
-  }
-  if (TemplateType->getTemplateName().isDependent())
-// Dependent template specializations will be matched when the
-// template is instantiated.
-return nullptr;
-
-  // For template specialization types which are specializing a template
-  // declaration which is an explicit or partial specialization of another
-  // template declaration, getAsCXXRecordDecl() returns the corresponding
-  // ClassTemplateSpecializationDecl.
-  //
-  // For template specialization types which are specializing a template
-  // declaration which is neither an explicit nor partial specialization of
-  // another template declaration, getAsCXXRecordDecl() returns NULL and
-  // we get the CXXRecordDecl of the templated declaration.
-  CXXRecordDecl *SpecializationDecl = TemplateType->getAsCXXRecordDecl();
-  if (SpecializationDecl) {
-return SpecializationDecl;
-  }
-  NamedDecl *Templated =
-  TemplateType->getTemplateName().getAsTemplateDecl()->getTemplatedDecl();
-  if (CXXRecordDecl *TemplatedRecord = dyn_cast(Templated)) {
-return TemplatedRecord;
-  }
-  // Now it can still be that we have an alias template.
-  TypeAliasDecl *AliasDecl = dyn_cast(Templated);
-  assert(AliasDecl);
-  return getAsCXXRecordDecl(AliasDecl->getUnderlyingType().getTypePtr());
+static CXXRecordDecl *
+getAsCXXRecordDeclOrPrimaryTemplate(const Type *TypeNode) {
+  if (auto *RD = TypeNode->getAsCXXRecordDecl())
+return RD;
+
+  // Find the innermost TemplateSpecializationType that isn't an alias 
template.
+  auto *TemplateType = TypeNode->getAs();
+  while (TemplateType && TemplateType->isTypeAlias())
+TemplateType =
+TemplateType->getAliasedType()->getAs();
+
+  // If this is the name of a (dependent) template specialization, use the
+  // definition of the template, even though it might be specialized later.
+  if (TemplateType)
+if (auto *ClassTemplate = dyn_cast_or_null(
+  TemplateType->getTemplateName().getAsTemplateDecl()))
+  return ClassTemplate->getTemplatedDecl();
+
+  return nullptr;
 }
 
 // Returns true if the given class is directly or indirectly derived
@@ -800,7 +779,10 @@ bool MatchASTVisitor::classIsDerivedFrom
 if (typeHasMatchingAlias(TypeNode, Base, Builder))
   return true;
 
-CXXRecordDecl *ClassDecl = getAsCXXRecordDecl(TypeNode);
+// FIXME: Going to the primary template here isn't really correct, but
+// unfortunately we accept a Decl matcher for the base class not a Type
+// matcher, so it's the best thing we can do with our current interface.
+CXXRecordDecl *ClassDecl = getAsCXXRecordDeclOrPrimaryTemplate(TypeNode);
 if (!ClassDecl)
   continue;
 if (ClassDecl == Declaration) {


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

Re: [PATCH] D15861: Support fully-qualified names for all QualTypes

[Richard Smith via cfe-commits]

rsmith closed this revision.
rsmith added a comment.

In r260278.


http://reviews.llvm.org/D15861



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

Re: [PATCH] D15861: Support fully-qualified names for all QualTypes

[Sterling Augustine via cfe-commits]

saugustine updated this revision to Diff 47343.
saugustine added a comment.

- Cleanup dyn_cast usage inside QualTypeNames.


http://reviews.llvm.org/D15861

Files:
  include/clang/Tooling/Core/QualTypeNames.h
  lib/Tooling/Core/CMakeLists.txt
  lib/Tooling/Core/QualTypeNames.cpp
  unittests/Tooling/CMakeLists.txt
  unittests/Tooling/QualTypeNamesTest.cpp

Index: unittests/Tooling/QualTypeNamesTest.cpp
===
--- /dev/null
+++ unittests/Tooling/QualTypeNamesTest.cpp
@@ -0,0 +1,166 @@
+//===- unittest/Tooling/QualTypeNameTest.cpp --===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "clang/Tooling/Core/QualTypeNames.h"
+#include "TestVisitor.h"
+using namespace clang;
+
+namespace {
+struct TypeNameVisitor : TestVisitor {
+  llvm::StringMap ExpectedQualTypeNames;
+
+  // ValueDecls are the least-derived decl with both a qualtype and a
+  // name.
+  bool traverseDecl(Decl *D) {
+return true;  // Always continue
+  }
+
+  bool VisitValueDecl(const ValueDecl *VD) {
+std::string ExpectedName =
+ExpectedQualTypeNames.lookup(VD->getNameAsString());
+if (ExpectedName != "") {
+  std::string ActualName =
+  TypeName::getFullyQualifiedName(VD->getType(), *Context);
+  if (ExpectedName != ActualName) {
+// A custom message makes it much easier to see what declaration
+// failed compared to EXPECT_EQ.
+EXPECT_TRUE(false) << "Typename::getFullyQualifiedName failed for "
+   << VD->getQualifiedNameAsString() << std::endl
+   << "   Actual: " << ActualName << std::endl
+   << " Exepcted: " << ExpectedName;
+  }
+}
+return true;
+  }
+};
+
+// named namespaces inside anonymous namespaces
+
+TEST(QualTypeNameTest, getFullyQualifiedName) {
+  TypeNameVisitor Visitor;
+  // Simple case to test the test framework itself.
+  Visitor.ExpectedQualTypeNames["CheckInt"] = "int";
+
+  // Keeping the names of the variables whose types we check unique
+  // within the entire test--regardless of their own scope--makes it
+  // easier to diagnose test failures.
+
+  // Simple namespace qualifier
+  Visitor.ExpectedQualTypeNames["CheckA"] = "A::B::Class0";
+  // Lookup up the enclosing scopes, then down another one. (These
+  // appear as elaborated type in the AST. In that case--even if
+  // policy.SuppressScope = 0--qual_type.getAsString(policy) only
+  // gives the name as it appears in the source, not the full name.
+  Visitor.ExpectedQualTypeNames["CheckB"] = "A::B::C::Class1";
+  // Template parameter expansion.
+  Visitor.ExpectedQualTypeNames["CheckC"] =
+  "A::B::Template0";
+  // Recursive template parameter expansion.
+  Visitor.ExpectedQualTypeNames["CheckD"] =
+  "A::B::Template0, "
+  "A::B::Template0 >";
+  // Variadic Template expansion.
+  Visitor.ExpectedQualTypeNames["CheckE"] =
+  "A::Variadic, "
+  "A::B::Template1, A::B::C::MyInt>";
+  // Using declarations should be fully expanded.
+  Visitor.ExpectedQualTypeNames["CheckF"] = "A::B::Class0";
+  // Elements found within "using namespace foo;" should be fully
+  // expanded.
+  Visitor.ExpectedQualTypeNames["CheckG"] = "A::B::C::MyInt";
+  // Type inside function
+  Visitor.ExpectedQualTypeNames["CheckH"] = "struct X";
+  // Anonymous Namespaces
+  Visitor.ExpectedQualTypeNames["CheckI"] = "aClass";
+  // Keyword inclusion with namespaces
+  Visitor.ExpectedQualTypeNames["CheckJ"] = "struct A::aStruct";
+  // Anonymous Namespaces nested in named namespaces and vice-versa.
+  Visitor.ExpectedQualTypeNames["CheckK"] = "D::aStruct";
+  // Namespace alias
+  Visitor.ExpectedQualTypeNames["CheckL"] = "A::B::C::MyInt";
+  Visitor.ExpectedQualTypeNames["non_dependent_type_var"] =
+  "template Foo::non_dependent_type";
+  Visitor.runOver(
+  "int CheckInt;\n"
+  "namespace A {\n"
+  " namespace B {\n"
+  "   class Class0 { };\n"
+  "   namespace C {\n"
+  " typedef int MyInt;"
+  "   }\n"
+  "   template class Template0;"
+  "   template class Template1;"
+  "   typedef B::Class0 AnotherClass;\n"
+  "   void Function1(Template0 CheckC);\n"
+  "   void Function2(Template0,\n"
+  "Template0 > CheckD);\n"
+  "  }\n"
+  "template class Variadic {};\n"
+  "Variadic, "
+  " B::Template1, "
+  " 

Re: [PATCH] D16947: [PGO] assignment operator does not get profile data

[David Blaikie via cfe-commits]

On Tue, Feb 9, 2016 at 11:26 AM, Xinliang David Li 
wrote:

> On Tue, Feb 9, 2016 at 11:14 AM, David Blaikie  wrote:
> >
> >
> > On Mon, Feb 8, 2016 at 9:23 PM, Xinliang David Li 
> > wrote:
> >>
> >> Wrong in the sense the the coverage result for the default operators
> >> (the line where they are declared) is marked as if they are not called
> >> which can be confusing to the user.
> >
> >
> > Presumably a user would have the same problem with implicit ops - the
> class
> > header/name would be marked as if there was code that was not called
> there?
>
> that would be confusing though -- as data of many implicitly declared
> functions will be lumped together and user won't know what that is .
>

Presumably it's still going to be confusing, though - the line table will
record that line and the counter won't be there, so the header of the type
will be marked in red & a user worried about coverage may go through some
contortions to try to discover and cover that code, no? (even though it may
already be covered & is just being reported incorrectly due to their being
no counters)


>
> David
>
> >
> > - David
> >
> >>
> >>
> >> David
> >>
> >> On Mon, Feb 8, 2016 at 9:09 PM, David Blaikie 
> wrote:
> >> >
> >> >
> >> > On Mon, Feb 8, 2016 at 9:00 PM, Xinliang David Li  >
> >> > wrote:
> >> >>
> >> >> On Mon, Feb 8, 2016 at 8:46 PM, David Blaikie 
> >> >> wrote:
> >> >> >
> >> >> > On Mon, Feb 8, 2016 at 7:39 PM, Xinliang David Li
> >> >> > 
> >> >> > wrote:
> >> >> >>
> >> >> >> I took a look at the problem. The implicitly defaulted operators
> >> >> >> should not be instrumented as specified -- I actually I just added
> >> >> >> the
> >> >> >> new test case for that (checking profile counter not generated)
> >> >> >> right
> >> >> >> after my previous reply and it still passes with this patch. The
> >> >> >> reason is that those operators have 'implicit' bit set, and
> profile
> >> >> >> instrumentation in FE is implemented in two stages: 1) counter
> >> >> >> assignment; 2) actual transformation.  For methods with implicit
> bit
> >> >> >> set, step 1) is skipped as designed, so step 2) simply becomes a
> >> >> >> no-op.
> >> >> >>
> >> >> >> In short, the test case still needs explicit '=default', and the
> >> >> >> implicit case is covered elsewhere.
> >> >> >
> >> >> >
> >> >> > OK, thanks for the explanation!
> >> >> >
> >> >> > Why is that the case, though - why would an implicitly default
> >> >> > function
> >> >> > be
> >> >> > any different from a profile (& profile-guided-optimization)
> >> >> > perspective
> >> >> > from an explicitly defaulted one?
> >> >>
> >> >> There are two factors to consider -- PGO and coverage testing.
> >> >> Implicitly declared functions are usually small/single BB so
> >> >> instrumenting them does not bring too much benefit (they will be
> >> >> inlined most of the cases any way) while increasing instrumentation
> >> >> overhead. They are not needed for coveraging test either (as there
> are
> >> >> no source lines to cover). This is a good tuning heuristic in most
> >> >> cases, but can get wrong sometimes (IR based late instrumentation is
> >> >> more focused on performance thus not depending on this tuning).
> >> >>
> >> >> Explicitly defaulted ones are different in the sense that if they are
> >> >> not instrumented, the coverage result will be wrong.
> >> >
> >> >
> >> > wrong in what way? Both functions (explicitly or implicitly defaulted)
> >> > will
> >> > be emitted, with line tables (looks like the = defaulted one is
> >> > attributed
> >> > to the line where the = default was written, and the implicitly
> >> > defaulted
> >> > one is attributed to wherever the class name is written)
> >> >
> >> > - David
> >> >
> >> >>
> >> >>
> >> >> thanks,
> >> >>
> >> >> David
> >> >>
> >> >> >
> >> >> >>
> >> >> >>
> >> >> >> thanks,
> >> >> >>
> >> >> >> David
> >> >> >>
> >> >> >> On Mon, Feb 8, 2016 at 5:23 PM, David Blaikie  >
> >> >> >> wrote:
> >> >> >> >
> >> >> >> >
> >> >> >> > On Mon, Feb 8, 2016 at 5:05 PM, Xinliang David Li
> >> >> >> > 
> >> >> >> > wrote:
> >> >> >> >>
> >> >> >> >> ha! somehow I kept thinking you are referring to implicit
> >> >> >> >> declared
> >> >> >> >> ctors.
> >> >> >> >
> >> >> >> >
> >> >> >> > Ah, glad we figured out the disconnect - thanks for bearing with
> >> >> >> > me!
> >> >> >> >
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> From your test case, it is seems that the implicit copy/move op
> >> >> >> >> is
> >> >> >> >> also broken and is fixed by this patch too. That means  a
> missing
> >> >> >> >> test
> >> >> >> >> case to me.  Will update the case when verified.
> >> >> >> >
> >> >> >> >
> >> >> >> > Again, this is a case where I'd probably just simplify the test,
> >> >> >> > as I
> >> >> >> > asked
> >> >> >> > earlier in the thread (I 

Re: [PATCH] D16947: [PGO] assignment operator does not get profile data

[David Blaikie via cfe-commits]

On Tue, Feb 9, 2016 at 11:41 AM, Xinliang David Li 
wrote:

> On Tue, Feb 9, 2016 at 11:30 AM, David Blaikie  wrote:
> >
> >
> > On Tue, Feb 9, 2016 at 11:26 AM, Xinliang David Li 
> > wrote:
> >>
> >> On Tue, Feb 9, 2016 at 11:14 AM, David Blaikie 
> wrote:
> >> >
> >> >
> >> > On Mon, Feb 8, 2016 at 9:23 PM, Xinliang David Li  >
> >> > wrote:
> >> >>
> >> >> Wrong in the sense the the coverage result for the default operators
> >> >> (the line where they are declared) is marked as if they are not
> called
> >> >> which can be confusing to the user.
> >> >
> >> >
> >> > Presumably a user would have the same problem with implicit ops - the
> >> > class
> >> > header/name would be marked as if there was code that was not called
> >> > there?
> >>
> >> that would be confusing though -- as data of many implicitly declared
> >> functions will be lumped together and user won't know what that is .
> >
> >
> > Presumably it's still going to be confusing, though - the line table will
> > record that line and the counter won't be there, so the header of the
> type
> > will be marked in red & a user worried about coverage may go through some
> > contortions to try to discover and cover that code, no? (even though it
> may
> > already be covered & is just being reported incorrectly due to their
> being
> > no counters)
>
> coverage mapping does not use the debug line table for this purpose --
> it encodes line info in source regions of its own format. Marking
> class header as read will be super confusing if it happens (but does
> not).
>

Then why would it be a problem to omit the defaulted versions? It won't be
marked "as if they are not called" (it won't show up red) it'll just be
marked as if there's no code there, right?


> Further discussion is welcome, but I am going to commit this change soon.
>

As for the review - I'd still request that the test be in Clang, where the
code change is. Please defer adding tests like this to compiler-rt until
we've had some discussion with compiler-rt folks (I tried to rope Alexey
into one of these threads, not sure if it got lost in the noise), perhaps
on llvm-dev. Maybe I'm confused about what testing should go in
compiler-rt, but we can defer that to a discussion as there should be a
test in Clang regardless of whether there's also testing for this specific
feature in compiler-rt.

- David


>
> thanks,
>
> David
>
> >
> >>
> >>
> >> David
> >>
> >> >
> >> > - David
> >> >
> >> >>
> >> >>
> >> >> David
> >> >>
> >> >> On Mon, Feb 8, 2016 at 9:09 PM, David Blaikie 
> >> >> wrote:
> >> >> >
> >> >> >
> >> >> > On Mon, Feb 8, 2016 at 9:00 PM, Xinliang David Li
> >> >> > 
> >> >> > wrote:
> >> >> >>
> >> >> >> On Mon, Feb 8, 2016 at 8:46 PM, David Blaikie  >
> >> >> >> wrote:
> >> >> >> >
> >> >> >> > On Mon, Feb 8, 2016 at 7:39 PM, Xinliang David Li
> >> >> >> > 
> >> >> >> > wrote:
> >> >> >> >>
> >> >> >> >> I took a look at the problem. The implicitly defaulted
> operators
> >> >> >> >> should not be instrumented as specified -- I actually I just
> >> >> >> >> added
> >> >> >> >> the
> >> >> >> >> new test case for that (checking profile counter not generated)
> >> >> >> >> right
> >> >> >> >> after my previous reply and it still passes with this patch.
> The
> >> >> >> >> reason is that those operators have 'implicit' bit set, and
> >> >> >> >> profile
> >> >> >> >> instrumentation in FE is implemented in two stages: 1) counter
> >> >> >> >> assignment; 2) actual transformation.  For methods with
> implicit
> >> >> >> >> bit
> >> >> >> >> set, step 1) is skipped as designed, so step 2) simply becomes
> a
> >> >> >> >> no-op.
> >> >> >> >>
> >> >> >> >> In short, the test case still needs explicit '=default', and
> the
> >> >> >> >> implicit case is covered elsewhere.
> >> >> >> >
> >> >> >> >
> >> >> >> > OK, thanks for the explanation!
> >> >> >> >
> >> >> >> > Why is that the case, though - why would an implicitly default
> >> >> >> > function
> >> >> >> > be
> >> >> >> > any different from a profile (& profile-guided-optimization)
> >> >> >> > perspective
> >> >> >> > from an explicitly defaulted one?
> >> >> >>
> >> >> >> There are two factors to consider -- PGO and coverage testing.
> >> >> >> Implicitly declared functions are usually small/single BB so
> >> >> >> instrumenting them does not bring too much benefit (they will be
> >> >> >> inlined most of the cases any way) while increasing
> instrumentation
> >> >> >> overhead. They are not needed for coveraging test either (as there
> >> >> >> are
> >> >> >> no source lines to cover). This is a good tuning heuristic in most
> >> >> >> cases, but can get wrong sometimes (IR based late instrumentation
> is
> >> >> >> more focused on performance thus not depending on this tuning).
> >> >> >>
> >> >> >> Explicitly defaulted ones are 

Re: [PATCH] D16947: [PGO] assignment operator does not get profile data

[Xinliang David Li via cfe-commits]

On Tue, Feb 9, 2016 at 11:44 AM, David Blaikie  wrote:
>
>
> On Tue, Feb 9, 2016 at 11:41 AM, Xinliang David Li 
> wrote:
>>
>> On Tue, Feb 9, 2016 at 11:30 AM, David Blaikie  wrote:
>> >
>> >
>> > On Tue, Feb 9, 2016 at 11:26 AM, Xinliang David Li 
>> > wrote:
>> >>
>> >> On Tue, Feb 9, 2016 at 11:14 AM, David Blaikie 
>> >> wrote:
>> >> >
>> >> >
>> >> > On Mon, Feb 8, 2016 at 9:23 PM, Xinliang David Li
>> >> > 
>> >> > wrote:
>> >> >>
>> >> >> Wrong in the sense the the coverage result for the default operators
>> >> >> (the line where they are declared) is marked as if they are not
>> >> >> called
>> >> >> which can be confusing to the user.
>> >> >
>> >> >
>> >> > Presumably a user would have the same problem with implicit ops - the
>> >> > class
>> >> > header/name would be marked as if there was code that was not called
>> >> > there?
>> >>
>> >> that would be confusing though -- as data of many implicitly declared
>> >> functions will be lumped together and user won't know what that is .
>> >
>> >
>> > Presumably it's still going to be confusing, though - the line table
>> > will
>> > record that line and the counter won't be there, so the header of the
>> > type
>> > will be marked in red & a user worried about coverage may go through
>> > some
>> > contortions to try to discover and cover that code, no? (even though it
>> > may
>> > already be covered & is just being reported incorrectly due to their
>> > being
>> > no counters)
>>
>> coverage mapping does not use the debug line table for this purpose --
>> it encodes line info in source regions of its own format. Marking
>> class header as read will be super confusing if it happens (but does
>> not).
>
>
> Then why would it be a problem to omit the defaulted versions? It won't be
> marked "as if they are not called" (it won't show up red) it'll just be
> marked as if there's no code there, right?

This is subjective  -- but it is clear to me if a user explicitly
write a defaulted function, he/she would expect the function to be
covered in test. Class/struct tag on the hand, won't be expected to be
covered. By the way, we can do this one way or the other, but they
need to be consistent.

>
>>
>> Further discussion is welcome, but I am going to commit this change soon.
>
>
> As for the review - I'd still request that the test be in Clang, where the
> code change is.

Yes -- this patch only includes clang change.

 Please defer adding tests like this to compiler-rt until
> we've had some discussion with compiler-rt folks (I tried to rope Alexey
> into one of these threads, not sure if it got lost in the noise), perhaps on
> llvm-dev. Maybe I'm confused about what testing should go in compiler-rt,
> but we can defer that to a discussion as there should be a test in Clang
> regardless of whether there's also testing for this specific feature in
> compiler-rt.

I disagree. There are hundreds of such tests in compiler-rt, so I
don't see the point of holding off one more test case (or be a problem
for future batch porting).

David



>
> - David
>
>>
>>
>> thanks,
>>
>> David
>>
>> >
>> >>
>> >>
>> >> David
>> >>
>> >> >
>> >> > - David
>> >> >
>> >> >>
>> >> >>
>> >> >> David
>> >> >>
>> >> >> On Mon, Feb 8, 2016 at 9:09 PM, David Blaikie 
>> >> >> wrote:
>> >> >> >
>> >> >> >
>> >> >> > On Mon, Feb 8, 2016 at 9:00 PM, Xinliang David Li
>> >> >> > 
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> On Mon, Feb 8, 2016 at 8:46 PM, David Blaikie
>> >> >> >> 
>> >> >> >> wrote:
>> >> >> >> >
>> >> >> >> > On Mon, Feb 8, 2016 at 7:39 PM, Xinliang David Li
>> >> >> >> > 
>> >> >> >> > wrote:
>> >> >> >> >>
>> >> >> >> >> I took a look at the problem. The implicitly defaulted
>> >> >> >> >> operators
>> >> >> >> >> should not be instrumented as specified -- I actually I just
>> >> >> >> >> added
>> >> >> >> >> the
>> >> >> >> >> new test case for that (checking profile counter not
>> >> >> >> >> generated)
>> >> >> >> >> right
>> >> >> >> >> after my previous reply and it still passes with this patch.
>> >> >> >> >> The
>> >> >> >> >> reason is that those operators have 'implicit' bit set, and
>> >> >> >> >> profile
>> >> >> >> >> instrumentation in FE is implemented in two stages: 1) counter
>> >> >> >> >> assignment; 2) actual transformation.  For methods with
>> >> >> >> >> implicit
>> >> >> >> >> bit
>> >> >> >> >> set, step 1) is skipped as designed, so step 2) simply becomes
>> >> >> >> >> a
>> >> >> >> >> no-op.
>> >> >> >> >>
>> >> >> >> >> In short, the test case still needs explicit '=default', and
>> >> >> >> >> the
>> >> >> >> >> implicit case is covered elsewhere.
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > OK, thanks for the explanation!
>> >> >> >> >
>> >> >> >> > Why is that the case, though - why would an implicitly default
>> >> >> >> > function
>> >> >>