Re: [PATCH] D21904: [OpenMP] Initial implementation of parse+sema for clause use_device_ptr of 'target data'

2016-06-30 Thread Alexey Bataev via cfe-commits
ABataev added a comment.

In http://reviews.llvm.org/D21904#472074, @carlo.bertolli wrote:

> I think that Kelvin is right. This is what that sentence refers to:
>  int * bla = ..;
>  #pragma omp target data use_device_ptr(bla)
>  {
>
>   .. bla .. // <-- this is the 'reference' that sentence is about
>
> }
>
> What puzzles me about that sentence is that it seems it is asking us to use 
> bla as following:
>  int addr_bla = 
>  // now can use addr_bla
>
> I am specifically referring to this part of the sentence: "must be to the 
> address of the list item"
>
> Anyway, as Kelvin says, this has nothing to do with what we expect sema for 
> use_device_ptr to accept. Samuel point, but I may be mistaken, is that a 
> reference to a pointer should be considered as a pointer itself.
>  Alexey: if you do not think this is right, I can add a test that excludes 
> references.
>
> Finally, thanks for the very quick review and for all your comments
>
> - Carlo


Carlo, I'm not sure about this sentence at all. If you think that this 
construct may accept references to pointers, then go ahead and ignore my 
previous comment.


Repository:
  rL LLVM

http://reviews.llvm.org/D21904



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


Re: [PATCH] D21918: Make the tuple_element and __make_tuple_types implementations flat.

2016-06-30 Thread Eric Fiselier via cfe-commits
EricWF abandoned this revision.
EricWF added a comment.

Committed in rr274330


http://reviews.llvm.org/D21918



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


Re: [PATCH] D21904: [OpenMP] Initial implementation of parse+sema for clause use_device_ptr of 'target data'

2016-06-30 Thread Carlo Bertolli via cfe-commits
carlo.bertolli added a comment.

I think that Kelvin is right. This is what that sentence refers to:
int * bla = ..;
#pragma omp target data use_device_ptr(bla)
{

  .. bla .. // <-- this is the 'reference' that sentence is about

}

What puzzles me about that sentence is that it seems it is asking us to use bla 
as following:
int addr_bla = 
// now can use addr_bla

I am specifically referring to this part of the sentence: "must be to the 
address of the list item"

Anyway, as Kelvin says, this has nothing to do with what we expect sema for 
use_device_ptr to accept. Samuel point, but I may be mistaken, is that a 
reference to a pointer should be considered as a pointer itself.
Alexey: if you do not think this is right, I can add a test that excludes 
references.

Finally, thanks for the very quick review and for all your comments

- Carlo




Repository:
  rL LLVM

http://reviews.llvm.org/D21904



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


Re: [PATCH] D21904: [OpenMP] Initial implementation of parse+sema for clause use_device_ptr of 'target data'

2016-06-30 Thread Kelvin Li via cfe-commits
kkwli0 added inline comments.


Comment at: lib/Sema/SemaOpenMP.cpp:11377
@@ +11376,3 @@
+// item should be a pointer or array
+if (!Type.getNonReferenceType()->isPointerType()) {
+  Diag(ELoc, diag::err_omp_usedeviceptr_not_a_pointer)

sfantao wrote:
> ABataev wrote:
> > sfantao wrote:
> > > ABataev wrote:
> > > > You should not skip the reference from the type, references are not 
> > > > allowed also
> > > Hi Alexey, I think the item can be a reference to a pointer. I couldn't 
> > > find that restriction in the spec,  can you point me to what you are 
> > > referring to? We should probably refer to that in the preceding comment. 
> > > 
> > > Thanks!
> > Here is the restriction:
> > "2.10.1 target data Construct, restrictions. References in the construct to 
> > a list item that appears in a use_device_ptr clause must be to the address 
> > of the list item."
> > Does it mean that references are allowed?
> Ok, thanks. My interpretation is that that restriction refers to references 
> used in clauses (in the same construct) other than use_device_ptr to 
> declarations used in use_device_ptr. I think the motivation is to restrict 
> the use of the value of the pointer  by other clauses given that value is 
> going to change for that data environment because of the behavior implemented 
> by use_device_ptr. Carlo, what is your interpretation?
I interpret the rule to the list item being used inside the construct instead 
of being used in the other clauses on the same construct.


Repository:
  rL LLVM

http://reviews.llvm.org/D21904



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


Re: [PATCH] D18172: [CUDA][OpenMP] Add a generic offload action builder

2016-06-30 Thread Samuel Antao via cfe-commits
sfantao added a comment.

In http://reviews.llvm.org/D18172#471861, @jlebar wrote:

> Alexey, it seems that you're asking for "final" on all classes that are not 
> inherited from.  Forgive my ignorance, but would you mind pointing me to the 
> document that talks about our position on "final" in LLVM source?  I don't 
> see it in the style guide, but I may be missing something.
>
> The style guide does talk a good bit about writing concise and generally 
> not-misleading code.  My concern is that adding "final" everywhere paints an 
> inaccurate picture and will mislead readers.  Specifically, "final" is useful 
> as a signal to readers that a class cannot safely be inherited from.  "Don't 
> even think about it, buster."  But here we're adding "final" to a lot of 
> classes that, as far as I can tell, aren't distinctive except in that they 
> have no subclasses today.  The problem with this is that, if we use "final" 
> in this way, it dilutes the first "don't even try" meaning.  Now when I see a 
> class with "final" that I want to subclass, I'm just going to rip the "final" 
> off, because chances are, I can do so safely.  Now "final" does not serve as 
> a warning to me that I shouldn't do this.
>
> Sorry to focus on a superficial issue, but I think this really does matter 
> for usability.


Hi Justin,

Thanks for the comment!

I understand both interpretations can be useful for different purposes, i.e. 
"don't inherit, it is not safe" vs "feel free to change this class without 
worrying with subclasses". I tend to think that the latter (which I believe is 
what Alexey has in mind) can, in general, be more useful in the sense that a 
class is usually safe to extend - you can always add features that are somewhat 
orthogonal to what the parent class is doing. I can, of course, imagine cases 
where your argument is valid - you can have an implementation that allocates 
memory based on the type of the parent therefore it does not observe the extra 
storage required by derived classes. However, I think these cases are less 
common.

I also look at the programming guidelines and couldn't find a clear answer to 
the issue you raised.

I don't have a strong opinion about this, just giving my two cents.

Thanks again!
Samuel


http://reviews.llvm.org/D18172



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


[libcxx] r274331 - Flatten tuple_constructible, tuple_convertible and tuple_assignable.

2016-06-30 Thread Eric Fiselier via cfe-commits
Author: ericwf
Date: Thu Jun 30 23:07:39 2016
New Revision: 274331

URL: http://llvm.org/viewvc/llvm-project?rev=274331=rev
Log:
Flatten tuple_constructible, tuple_convertible and tuple_assignable.

This patch is the last in a series that replaces recursive meta-programming
in std::tuple with non-recursive implementations.

Previously std::tuple could only be instantiated with 126 elements before
it blew the max template instantiation depth. Now the size of std::tuple is
essentially unbounded (I've tested with over 5000 elements).

One unfortunate side-effect of this change is that tuple_constructible
and similar no longer short circuit after the first failure. Instead they
evaluate the conditions for all elements. This could be potentially breaking.
I plan to look into this further.

Modified:
libcxx/trunk/include/__tuple
libcxx/trunk/include/tuple

Modified: libcxx/trunk/include/__tuple
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__tuple?rev=274331=274330=274331=diff
==
--- libcxx/trunk/include/__tuple (original)
+++ libcxx/trunk/include/__tuple Thu Jun 30 23:07:39 2016
@@ -255,7 +255,6 @@ using __type_pack_element = typename dec
 typename __make_tuple_indices::type
 >{})
   )::type;
-
 #endif
 
 template 
@@ -266,6 +265,7 @@ public:
 typedef __type_pack_element<_Ip, _Types...> type;
 };
 
+
 template 
 class _LIBCPP_TYPE_VIS_ONLY tuple_size<__tuple_types<_Tp...> >
 : public integral_constant
@@ -364,31 +364,36 @@ struct __make_tuple_types<__tuple_types<
   typedef __tuple_types<_Types...> type;
 };
 
-// __tuple_convertible
-
-template 
-struct __tuple_convertible_imp : public false_type {};
-
-template 
-struct __tuple_convertible_imp<__tuple_types<_Tp0, _Tp...>, 
__tuple_types<_Up0, _Up...> >
-: public integral_constant::value &&
-   __tuple_convertible_imp<__tuple_types<_Tp...>, 
__tuple_types<_Up...> >::value> {};
+template 
+struct __all_dummy;
 
-template <>
-struct __tuple_convertible_imp<__tuple_types<>, __tuple_types<> >
-: public true_type {};
+template 
+using __all = is_same<__all_dummy<_Pred...>, __all_dummy<(_Pred, true)...>>;
 
-template 
-struct __tuple_convertible_apply : public false_type {};
+struct __tuple_sfinae_base {
+  template 
+  static auto __test_constructible(__tuple_types<_FromArgs...>, 
__tuple_types<_ToArgs...>)
+-> __all::value...>;
+  static auto __test_constructible(...) -> false_type;
+  template 
+  using __constructible = decltype(__test_constructible(_Types1{}, _Types2{}));
+
+  template 
+  static auto __test_convertible(__tuple_types<_FromArgs...>, 
__tuple_types<_ToArgs...>)
+-> __all::value...>;
+  static auto __test_convertible(...) -> false_type;
+  template 
+  using __convertible = decltype(__test_convertible(_Types1{}, _Types2{}));
+
+  template 
+  static auto __test_assignable(__tuple_types<_FromArgs...>, 
__tuple_types<_ToArgs...>)
+-> __all::value...>;
+  static auto __test_assignable(...) -> false_type;
+  template 
+  using __assignable = decltype(__test_assignable(_Types1{}, _Types2{}));
+};
 
-template 
-struct __tuple_convertible_apply
-  : public __tuple_convertible_imp<
-  typename __make_tuple_types<_Tp>::type
-, typename __make_tuple_types<_Up>::type
->
-{};
+// __tuple_convertible
 
 template ::type>::value,
 bool = __tuple_like<_Up>::value>
@@ -397,36 +402,14 @@ struct __tuple_convertible
 
 template 
 struct __tuple_convertible<_Tp, _Up, true, true>
-: public __tuple_convertible_apply::value ==
- tuple_size<_Up>::value, _Tp, _Up>
-{};
-
-// __tuple_constructible
-
-template 
-struct __tuple_constructible_imp : public false_type {};
-
-template 
-struct __tuple_constructible_imp<__tuple_types<_Tp0, _Tp...>, 
__tuple_types<_Up0, _Up...> >
-: public integral_constant::value &&
-   
__tuple_constructible_imp<__tuple_types<_Tp...>, __tuple_types<_Up...> 
>::value> {};
-
-template <>
-struct __tuple_constructible_imp<__tuple_types<>, __tuple_types<> >
-: public true_type {};
-
-template 
-struct __tuple_constructible_apply : public false_type {};
-
-template 
-struct __tuple_constructible_apply
-  : public __tuple_constructible_imp<
+: public __tuple_sfinae_base::__convertible<
   typename __make_tuple_types<_Tp>::type
 , typename __make_tuple_types<_Up>::type
 >
 {};
 
+// __tuple_constructible
+
 template ::type>::value,
 bool = 

Re: [PATCH] D18172: [CUDA][OpenMP] Add a generic offload action builder

2016-06-30 Thread Alexey Bataev via cfe-commits
ABataev added a comment.

In http://reviews.llvm.org/D18172#471861, @jlebar wrote:

> Alexey, it seems that you're asking for "final" on all classes that are not 
> inherited from.  Forgive my ignorance, but would you mind pointing me to the 
> document that talks about our position on "final" in LLVM source?  I don't 
> see it in the style guide, but I may be missing something.
>
> The style guide does talk a good bit about writing concise and generally 
> not-misleading code.  My concern is that adding "final" everywhere paints an 
> inaccurate picture and will mislead readers.  Specifically, "final" is useful 
> as a signal to readers that a class cannot safely be inherited from.  "Don't 
> even think about it, buster."  But here we're adding "final" to a lot of 
> classes that, as far as I can tell, aren't distinctive except in that they 
> have no subclasses today.  The problem with this is that, if we use "final" 
> in this way, it dilutes the first "don't even try" meaning.  Now when I see a 
> class with "final" that I want to subclass, I'm just going to rip the "final" 
> off, because chances are, I can do so safely.  Now "final" does not serve as 
> a warning to me that I shouldn't do this.
>
> Sorry to focus on a superficial issue, but I think this really does matter 
> for usability.


Hi Justin,
There are no strict rules on using 'final'. But I believe that it is better to 
protect developers from unintended use of code and if language allows to do it 
we should do it. If some class is not intended to be used as a base class, it 
is better to mark it as 'final' to be sure that nobody will inherit from it for 
sure. Consider it as an additional contract of the class.


http://reviews.llvm.org/D18172



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


Re: [PATCH] D21904: [OpenMP] Initial implementation of parse+sema for clause use_device_ptr of 'target data'

2016-06-30 Thread Samuel Antao via cfe-commits
sfantao added inline comments.


Comment at: lib/Sema/SemaOpenMP.cpp:11377
@@ +11376,3 @@
+// item should be a pointer or array
+if (!Type.getNonReferenceType()->isPointerType()) {
+  Diag(ELoc, diag::err_omp_usedeviceptr_not_a_pointer)

ABataev wrote:
> sfantao wrote:
> > ABataev wrote:
> > > You should not skip the reference from the type, references are not 
> > > allowed also
> > Hi Alexey, I think the item can be a reference to a pointer. I couldn't 
> > find that restriction in the spec,  can you point me to what you are 
> > referring to? We should probably refer to that in the preceding comment. 
> > 
> > Thanks!
> Here is the restriction:
> "2.10.1 target data Construct, restrictions. References in the construct to a 
> list item that appears in a use_device_ptr clause must be to the address of 
> the list item."
> Does it mean that references are allowed?
Ok, thanks. My interpretation is that that restriction refers to references 
used in clauses (in the same construct) other than use_device_ptr to 
declarations used in use_device_ptr. I think the motivation is to restrict the 
use of the value of the pointer  by other clauses given that value is going to 
change for that data environment because of the behavior implemented by 
use_device_ptr. Carlo, what is your interpretation?


Repository:
  rL LLVM

http://reviews.llvm.org/D21904



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


Re: [PATCH] D21904: [OpenMP] Initial implementation of parse+sema for clause use_device_ptr of 'target data'

2016-06-30 Thread Alexey Bataev via cfe-commits
ABataev added inline comments.


Comment at: lib/Sema/SemaOpenMP.cpp:11377
@@ +11376,3 @@
+// item should be a pointer or array
+if (!Type.getNonReferenceType()->isPointerType()) {
+  Diag(ELoc, diag::err_omp_usedeviceptr_not_a_pointer)

sfantao wrote:
> ABataev wrote:
> > You should not skip the reference from the type, references are not allowed 
> > also
> Hi Alexey, I think the item can be a reference to a pointer. I couldn't find 
> that restriction in the spec,  can you point me to what you are referring to? 
> We should probably refer to that in the preceding comment. 
> 
> Thanks!
Here is the restriction:
"2.10.1 target data Construct, restrictions. References in the construct to a 
list item that appears in a use_device_ptr clause must be to the address of the 
list item."
Does it mean that references are allowed?


Repository:
  rL LLVM

http://reviews.llvm.org/D21904



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


Re: [PATCH] D18171: [CUDA][OpenMP] Create generic offload action

2016-06-30 Thread Samuel Antao via cfe-commits
sfantao updated this revision to Diff 62460.
sfantao added a comment.

- Remove \brief.


http://reviews.llvm.org/D18171

Files:
  include/clang/Driver/Action.h
  include/clang/Driver/Compilation.h
  include/clang/Driver/Driver.h
  lib/Driver/Action.cpp
  lib/Driver/Driver.cpp
  lib/Driver/ToolChain.cpp
  lib/Driver/ToolChains.cpp
  lib/Driver/ToolChains.h
  lib/Driver/Tools.cpp
  lib/Driver/Tools.h
  lib/Frontend/CreateInvocationFromCommandLine.cpp

Index: lib/Frontend/CreateInvocationFromCommandLine.cpp
===
--- lib/Frontend/CreateInvocationFromCommandLine.cpp
+++ lib/Frontend/CreateInvocationFromCommandLine.cpp
@@ -60,25 +60,25 @@
   }
 
   // We expect to get back exactly one command job, if we didn't something
-  // failed. CUDA compilation is an exception as it creates multiple jobs. If
-  // that's the case, we proceed with the first job. If caller needs particular
-  // CUDA job, it should be controlled via --cuda-{host|device}-only option
-  // passed to the driver.
+  // failed. Offload compilation is an exception as it creates multiple jobs. If
+  // that's the case, we proceed with the first job. If caller needs a
+  // particular job, it should be controlled via options (e.g.
+  // --cuda-{host|device}-only for CUDA) passed to the driver.
   const driver::JobList  = C->getJobs();
-  bool CudaCompilation = false;
+  bool OffloadCompilation = false;
   if (Jobs.size() > 1) {
 for (auto  : C->getActions()){
   // On MacOSX real actions may end up being wrapped in BindArchAction
   if (isa(A))
 A = *A->input_begin();
-  if (isa(A)) {
-CudaCompilation = true;
+  if (isa(A)) {
+OffloadCompilation = true;
 break;
   }
 }
   }
   if (Jobs.size() == 0 || !isa(*Jobs.begin()) ||
-  (Jobs.size() > 1 && !CudaCompilation)) {
+  (Jobs.size() > 1 && !OffloadCompilation)) {
 SmallString<256> Msg;
 llvm::raw_svector_ostream OS(Msg);
 Jobs.Print(OS, "; ", true);
Index: lib/Driver/Tools.h
===
--- lib/Driver/Tools.h
+++ lib/Driver/Tools.h
@@ -57,8 +57,7 @@
const Driver , const llvm::opt::ArgList ,
llvm::opt::ArgStringList ,
const InputInfo ,
-   const InputInfoList ,
-   const ToolChain *AuxToolChain) const;
+   const InputInfoList ) const;
 
   void AddAArch64TargetArgs(const llvm::opt::ArgList ,
 llvm::opt::ArgStringList ) const;
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -288,12 +288,45 @@
  !O.hasFlag(options::DriverOption) && !O.hasFlag(options::LinkerInput);
 }
 
+/// Add the C++ include args of other offloading toolchains. If this is a host
+/// job, the device toolchains are added. If this is a device job, the host
+/// toolchains will be added.
+static void addExtraOffloadCXXStdlibIncludeArgs(Compilation ,
+const JobAction ,
+const ArgList ,
+ArgStringList ) {
+
+  if (JA.isHostOffloading(Action::OFK_Cuda))
+C.getSingleOffloadToolChain()
+->AddClangCXXStdlibIncludeArgs(Args, CmdArgs);
+  else if (JA.isDeviceOffloading(Action::OFK_Cuda))
+C.getSingleOffloadToolChain()
+->AddClangCXXStdlibIncludeArgs(Args, CmdArgs);
+
+  // TODO: Add support for other programming models here.
+}
+
+/// Add the include args that are specific of each offloading programming model.
+static void addExtraOffloadSpecificIncludeArgs(Compilation ,
+   const JobAction ,
+   const ArgList ,
+   ArgStringList ) {
+
+  if (JA.isHostOffloading(Action::OFK_Cuda))
+C.getSingleOffloadToolChain()->AddCudaIncludeArgs(
+Args, CmdArgs);
+  else if (JA.isDeviceOffloading(Action::OFK_Cuda))
+C.getSingleOffloadToolChain()->AddCudaIncludeArgs(
+Args, CmdArgs);
+
+  // TODO: Add support for other programming models here.
+}
+
 void Clang::AddPreprocessingOptions(Compilation , const JobAction ,
 const Driver , const ArgList ,
 ArgStringList ,
 const InputInfo ,
-const InputInfoList ,
-const ToolChain *AuxToolChain) const {
+const InputInfoList ) const {
   Arg *A;
   const bool IsIAMCU = getToolChain().getTriple().isOSIAMCU();
 
@@ -558,31 +591,27 @@
   // OBJCPLUS_INCLUDE_PATH - system includes 

Re: [PATCH] D18639: Use __builtin_isnan/isinf/isfinite in complex

2016-06-30 Thread Marshall Clow via cfe-commits
mclow.lists added a comment.

Hal and I talked about this in Oulu. In general, I'm good with this approach.

However, I think that the code could be made much clearer.  (some naming 
changes, some code rearrangement)
First off, I think the name `__fast_isinf` is a poor name. I think something 
like `__isinf` would be better, but Hal informs me that *everyone* uses that 
name for something, so I think that `__libcpp_isinf` would be better.

Secondly, instead of duplicating all of the boilerplate code around the 
different versions of whatever we call it, I think we can bury the ifdefs 
inside the inline functions.   I'll try to work up an example, and post it here.


http://reviews.llvm.org/D18639



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


Re: [PATCH] D21904: [OpenMP] Initial implementation of parse+sema for clause use_device_ptr of 'target data'

2016-06-30 Thread Samuel Antao via cfe-commits
sfantao added inline comments.


Comment at: lib/Sema/SemaOpenMP.cpp:11377
@@ +11376,3 @@
+// item should be a pointer or array
+if (!Type.getNonReferenceType()->isPointerType()) {
+  Diag(ELoc, diag::err_omp_usedeviceptr_not_a_pointer)

ABataev wrote:
> You should not skip the reference from the type, references are not allowed 
> also
Hi Alexey, I think the item can be a reference to a pointer. I couldn't find 
that restriction in the spec,  can you point me to what you are referring to? 
We should probably refer to that in the preceding comment. 

Thanks!


Repository:
  rL LLVM

http://reviews.llvm.org/D21904



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


Re: [PATCH] D18171: [CUDA][OpenMP] Create generic offload action

2016-06-30 Thread Samuel Antao via cfe-commits
sfantao added a comment.

In http://reviews.llvm.org/D18171#471824, @sfantao wrote:

> Hi Alexey,
>
> Thanks for the review! I addressed your comments in the last diff.
>
> In http://reviews.llvm.org/D18171#471044, @ABataev wrote:
>
> > No '\brief's
>
>
> When you say  "no \brief" do you mean I am using that where I shouldn't or 
> the other way around. I am only adding that for member functions/vars  that I 
> create, should I do that for member I am modifying too? I noticed two places 
> where I was using that for static functions, I removed \brief in those cases. 
> Let me know if that is what you wanted me to do.
>
> Thanks again,
> Samuel


Ok, I got you. In my comments the abstract can always be the first sentence, so 
\brief is not required. I'll remove that as you suggest.

Thanks,
Samuel


http://reviews.llvm.org/D18171



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


Re: [PATCH] D21904: [OpenMP] Initial implementation of parse+sema for clause use_device_ptr of 'target data'

2016-06-30 Thread Alexey Bataev via cfe-commits
ABataev added inline comments.


Comment at: include/clang/Basic/DiagnosticSemaKinds.td:8318
@@ -8317,1 +8317,3 @@
+def  err_omp_usedeviceptr_not_a_pointer : Error<
+  "item used in 'use_device_pointer' clause is not a pointer">;
 } // end of OpenMP category

It's better to rephrase this message: "expected a variable of pointer type" or 
something like this. Also, it would be good to have a corresponding note, 
describing the provided item.


Comment at: lib/Sema/SemaOpenMP.cpp:11377
@@ +11376,3 @@
+// item should be a pointer or array
+if (!Type.getNonReferenceType()->isPointerType()) {
+  Diag(ELoc, diag::err_omp_usedeviceptr_not_a_pointer)

You should not skip the reference from the type, references are not allowed also


Comment at: lib/Sema/SemaOpenMP.cpp:11382-11394
@@ +11381,15 @@
+}
+Type = Type.getUnqualifiedType();
+auto VDPrivate = buildVarDecl(*this, ELoc, Type, D->getName(),
+  D->hasAttrs() ? >getAttrs() : nullptr);
+if (VDPrivate->isInvalidDecl())
+  continue;
+auto VDPrivateRefExpr = buildDeclRefExpr(
+*this, VDPrivate, RefExpr->getType().getUnqualifiedType(), ELoc);
+
+DeclRefExpr *Ref = nullptr;
+if (!VD)
+  Ref = buildCapture(*this, D, SimpleRefExpr, /*WithInit=*/false);
+Vars.push_back(VD ? RefExpr->IgnoreParens() : Ref);
+PrivateCopies.push_back(VDPrivateRefExpr);
+  }

I don't think that this patch requires some private copies right now. They will 
be required only during codegen. I think the private copies must be excluded 
from parsing/sema patch


Repository:
  rL LLVM

http://reviews.llvm.org/D21904



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


r274326 - [DebugInfo] Set DISubprogram ThisAdjustment in the MS ABI

2016-06-30 Thread Reid Kleckner via cfe-commits
Author: rnk
Date: Thu Jun 30 21:41:25 2016
New Revision: 274326

URL: http://llvm.org/viewvc/llvm-project?rev=274326=rev
Log:
[DebugInfo] Set DISubprogram ThisAdjustment in the MS ABI

Modified:
cfe/trunk/lib/CodeGen/CGCXXABI.h
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp

Modified: cfe/trunk/lib/CodeGen/CGCXXABI.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCXXABI.h?rev=274326=274325=274326=diff
==
--- cfe/trunk/lib/CodeGen/CGCXXABI.h (original)
+++ cfe/trunk/lib/CodeGen/CGCXXABI.h Thu Jun 30 21:41:25 2016
@@ -336,6 +336,12 @@ public:
   virtual void addImplicitStructorParams(CodeGenFunction , QualType ,
  FunctionArgList ) = 0;
 
+  /// Get the ABI-specific "this" parameter adjustment to apply in the prologue
+  /// of a virtual function.
+  virtual CharUnits getVirtualFunctionPrologueThisAdjustment(GlobalDecl GD) {
+return CharUnits::Zero();
+  }
+
   /// Perform ABI-specific "this" parameter adjustment in a virtual function
   /// prologue.
   virtual llvm::Value *adjustThisParameterInVirtualFunctionPrologue(

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=274326=274325=274326=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Thu Jun 30 21:41:25 2016
@@ -1206,6 +1206,7 @@ llvm::DISubprogram *CGDebugInfo::CreateC
   unsigned Virtuality = 0;
   unsigned VIndex = 0;
   unsigned Flags = 0;
+  int ThisAdjustment = 0;
 
   if (Method->isVirtual()) {
 if (Method->isPure())
@@ -1235,9 +1236,12 @@ llvm::DISubprogram *CGDebugInfo::CreateC
   if (Method->begin_overridden_methods() == 
Method->end_overridden_methods())
 Flags |= llvm::DINode::FlagIntroducedVirtual;
 
-  // FIXME: Pass down ML.VFPtrOffset and ML.VBTableIndex. The debugger 
needs
-  // these to synthesize a call to a virtual method in a complex 
inheritance
-  // hierarchy.
+  // The 'this' adjustment accounts for both the virtual and non-virtual
+  // portions of the adjustment. Presumably the debugger only uses it when
+  // it knows the dynamic type of an object.
+  ThisAdjustment = CGM.getCXXABI()
+   .getVirtualFunctionPrologueThisAdjustment(GD)
+   .getQuantity();
 }
 ContainingType = RecordTy;
   }
@@ -1263,9 +1267,9 @@ llvm::DISubprogram *CGDebugInfo::CreateC
   llvm::DINodeArray TParamsArray = CollectFunctionTemplateParams(Method, Unit);
   llvm::DISubprogram *SP = DBuilder.createMethod(
   RecordTy, MethodName, MethodLinkageName, MethodDefUnit, MethodLine,
-  MethodTy, /*isLocalToUnit=*/false,
-  /* isDefinition=*/false, Virtuality, VIndex, ContainingType, Flags,
-  CGM.getLangOpts().Optimize, TParamsArray.get());
+  MethodTy, /*isLocalToUnit=*/false, /*isDefinition=*/false, Virtuality,
+  VIndex, ThisAdjustment, ContainingType, Flags, 
CGM.getLangOpts().Optimize,
+  TParamsArray.get());
 
   SPCache[Method->getCanonicalDecl()].reset(SP);
 

Modified: cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp?rev=274326=274325=274326=diff
==
--- cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp (original)
+++ cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp Thu Jun 30 21:41:25 2016
@@ -551,7 +551,7 @@ private:
 return  llvm::Constant::getAllOnesValue(CGM.IntTy);
   }
 
-  CharUnits getVirtualFunctionPrologueThisAdjustment(GlobalDecl GD);
+  CharUnits getVirtualFunctionPrologueThisAdjustment(GlobalDecl GD) override;
 
   void
   GetNullMemberPointerFields(const MemberPointerType *MPT,


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


Re: [PATCH] D18639: Use __builtin_isnan/isinf/isfinite in complex

2016-06-30 Thread Hal Finkel via cfe-commits
hfinkel added a comment.

In http://reviews.llvm.org/D18639#472010, @chandlerc wrote:

> I'm fine with this change, but we should also get Steve to comment on it, and 
> make sure we have a good way of explaining this to users.
>
> In particular, we probably need some documentation around these fast routines 
> that clearly indicates they should only be used when optimizations such as 
> `-ffast-math` and `-ffinite-math-only` should strip the checks. We want to be 
> careful to only use the optimizable forms when that behavior is appropriate. 
> And auditing the ones you've switched for that is something Steve might be 
> better suited to do...


Also, I spoke to Marshall offline about this last week, and I expect he'll also 
comment.


http://reviews.llvm.org/D18639



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


Re: [PATCH] D5896: Emit more intrinsics for builtin functions

2016-06-30 Thread Matt Arsenault via cfe-commits
arsenm added a comment.

ping


http://reviews.llvm.org/D5896



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


RE: r274246 - [codeview] Emit qualified display names if -gline-tables-only is on

2016-06-30 Thread Robinson, Paul via cfe-commits
The rationale is no different for DWARF than for CodeView, there's no other way 
to get the fully qualified name of an inlined function.  Unless you want to 
connect this up to the existing DWARF hook for putting linkage names on inlined 
subprograms?  The downside there is that linkage names are probably going to be 
longer than the qualified names, so maybe that's not such a good idea.  Not 
knowing how these names get used by a consumer of –gmlt data, hard for me to 
judge.

IIRC when I put linkage-names in for inlined functions, it added ~1% to the 
normal ("limited") debug-info size.  You'd be adding smaller names to much 
smaller debug-info so the percentage is bound to be bigger.  You'll want to 
collect some hard data but I'd guess it would not be horrifying.
--paulr

From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of Reid 
Kleckner via cfe-commits
Sent: Thursday, June 30, 2016 11:06 AM
To: cfe-commits; David Blaikie; Robinson, Paul
Subject: Re: r274246 - [codeview] Emit qualified display names if 
-gline-tables-only is on

David and Paul,

Do you think I should enable this behavior for DWARF as well? We only emit a 
DW_TAG_subprogram when a function is inlined or contains inlined functions, 
which might not be that many. IIRC Paul did something similar with 
DW_AT_linkage_name, and the object file size cost wasn't that bad.

Reid

On Thu, Jun 30, 2016 at 10:41 AM, Reid Kleckner via cfe-commits 
> wrote:
Author: rnk
Date: Thu Jun 30 12:41:31 2016
New Revision: 274246

URL: http://llvm.org/viewvc/llvm-project?rev=274246=rev
Log:
[codeview] Emit qualified display names if -gline-tables-only is on

When -gmlt is on, we don't emit namespace or class scope information,
and the CodeView emission code in LLVM can't compute the fully qualified
name. If we know LLVM won't be able to get the name right, go ahead and
emit the qualified name in the frontend.

We could change our -gmlt emission strategy to include those scopes when
emitting codeview, but that would increase memory usage and slow down
LTO and add more complexity to debug info emission.

The same problem exists when you debug a -gmlt binary with GDB, so we
should consider removing '&& EmitCodeView' from the condition here at
some point in the future after evaluating the impact on object file
size.

Modified:
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/test/CodeGenCXX/debug-info-codeview-display-name.cpp

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=274246=274245=274246=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Thu Jun 30 12:41:31 2016
@@ -185,17 +185,27 @@ StringRef CGDebugInfo::getFunctionName(c
   FunctionTemplateSpecializationInfo *Info =
   FD->getTemplateSpecializationInfo();

-  if (!Info && FII)
+  // Emit the unqualified name in normal operation. LLVM and the debugger can
+  // compute the fully qualified name from the scope chain. If we're only
+  // emitting line table info, there won't be any scope chains, so emit the
+  // fully qualified name here so that stack traces are more accurate.
+  // FIXME: Do this when emitting DWARF as well as when emitting CodeView after
+  // evaluating the size impact.
+  bool UseQualifiedName = DebugKind == codegenoptions::DebugLineTablesOnly &&
+  CGM.getCodeGenOpts().EmitCodeView;
+
+  if (!Info && FII && !UseQualifiedName)
 return FII->getName();

-  // Otherwise construct human readable name for debug info.
   SmallString<128> NS;
   llvm::raw_svector_ostream OS(NS);
   PrintingPolicy Policy(CGM.getLangOpts());
   Policy.MSVCFormatting = CGM.getCodeGenOpts().EmitCodeView;
+  if (!UseQualifiedName)
+FD->printName(OS);
+  else
+FD->printQualifiedName(OS, Policy);

-  // Print the unqualified name with some template arguments.
-  FD->printName(OS);
   // Add any template specialization args.
   if (Info) {
 const TemplateArgumentList *TArgs = Info->TemplateArguments;

Modified: cfe/trunk/test/CodeGenCXX/debug-info-codeview-display-name.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-codeview-display-name.cpp?rev=274246=274245=274246=diff
==
--- cfe/trunk/test/CodeGenCXX/debug-info-codeview-display-name.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/debug-info-codeview-display-name.cpp Thu Jun 30 
12:41:31 2016
@@ -1,14 +1,22 @@
-// RUN: %clang_cc1 -fblocks -debug-info-kind=limited -gcodeview -emit-llvm %s 
-o - -triple=x86_64-pc-win32 -std=c++98 | \
-// RUN:  grep 'DISubprogram' | sed -e 's/.*name: "\([^"]*\)".*/"\1"/' | 
FileCheck %s
+// RUN: %clang_cc1 -fblocks -debug-info-kind=limited -gcodeview -emit-llvm %s \
+// RUN:   -o - 

r274316 - [Feature] Add a builtin for indexing into parameter packs. Patch by Louis Dionne.

2016-06-30 Thread Eric Fiselier via cfe-commits
Author: ericwf
Date: Thu Jun 30 20:24:09 2016
New Revision: 274316

URL: http://llvm.org/viewvc/llvm-project?rev=274316=rev
Log:
[Feature] Add a builtin for indexing into parameter packs. Patch by Louis 
Dionne.

This patch adds a __nth_element builtin that allows fetching the n-th type of a
parameter pack with very little compile-time overhead. The patch was inspired by
r252036 and r252115 by David Majnemer, which add a similar __make_integer_seq
builtin for efficiently creating a std::integer_sequence.

Reviewed as D15421. http://reviews.llvm.org/D15421


Added:
cfe/trunk/test/PCH/type_pack_element.cpp
cfe/trunk/test/SemaCXX/type_pack_element.cpp
Modified:
cfe/trunk/include/clang/AST/ASTContext.h
cfe/trunk/include/clang/AST/DeclTemplate.h
cfe/trunk/include/clang/Basic/Builtins.h
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/include/clang/Serialization/ASTBitCodes.h
cfe/trunk/lib/AST/ASTContext.cpp
cfe/trunk/lib/AST/DeclTemplate.cpp
cfe/trunk/lib/Lex/PPMacroExpansion.cpp
cfe/trunk/lib/Sema/SemaLookup.cpp
cfe/trunk/lib/Sema/SemaTemplate.cpp
cfe/trunk/lib/Serialization/ASTReader.cpp
cfe/trunk/lib/Serialization/ASTWriter.cpp

Modified: cfe/trunk/include/clang/AST/ASTContext.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTContext.h?rev=274316=274315=274316=diff
==
--- cfe/trunk/include/clang/AST/ASTContext.h (original)
+++ cfe/trunk/include/clang/AST/ASTContext.h Thu Jun 30 20:24:09 2016
@@ -255,6 +255,9 @@ class ASTContext : public RefCountedBase
   /// The identifier '__make_integer_seq'.
   mutable IdentifierInfo *MakeIntegerSeqName = nullptr;
 
+  /// The identifier '__type_pack_element'.
+  mutable IdentifierInfo *TypePackElementName = nullptr;
+
   QualType ObjCConstantStringType;
   mutable RecordDecl *CFConstantStringTagDecl;
   mutable TypedefDecl *CFConstantStringTypeDecl;
@@ -410,6 +413,7 @@ private:
   TranslationUnitDecl *TUDecl;
   mutable ExternCContextDecl *ExternCContext;
   mutable BuiltinTemplateDecl *MakeIntegerSeqDecl;
+  mutable BuiltinTemplateDecl *TypePackElementDecl;
 
   /// \brief The associated SourceManager object.a
   SourceManager 
@@ -880,6 +884,7 @@ public:
 
   ExternCContextDecl *getExternCContextDecl() const;
   BuiltinTemplateDecl *getMakeIntegerSeqDecl() const;
+  BuiltinTemplateDecl *getTypePackElementDecl() const;
 
   // Builtin Types.
   CanQualType VoidTy;
@@ -1473,6 +1478,12 @@ public:
 return MakeIntegerSeqName;
   }
 
+  IdentifierInfo *getTypePackElementName() const {
+if (!TypePackElementName)
+  TypePackElementName = ("__type_pack_element");
+return TypePackElementName;
+  }
+
   /// \brief Retrieve the Objective-C "instancetype" type, if already known;
   /// otherwise, returns a NULL type;
   QualType getObjCInstanceType() {

Modified: cfe/trunk/include/clang/AST/DeclTemplate.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclTemplate.h?rev=274316=274315=274316=diff
==
--- cfe/trunk/include/clang/AST/DeclTemplate.h (original)
+++ cfe/trunk/include/clang/AST/DeclTemplate.h Thu Jun 30 20:24:09 2016
@@ -1490,8 +1490,8 @@ public:
 };
 
 /// \brief Represents the builtin template declaration which is used to
-/// implement __make_integer_seq.  It serves no real purpose beyond existing as
-/// a place to hold template parameters.
+/// implement __make_integer_seq and other builtin templates.  It serves
+/// no real purpose beyond existing as a place to hold template parameters.
 class BuiltinTemplateDecl : public TemplateDecl {
   void anchor() override;
 

Modified: cfe/trunk/include/clang/Basic/Builtins.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Builtins.h?rev=274316=274315=274316=diff
==
--- cfe/trunk/include/clang/Basic/Builtins.h (original)
+++ cfe/trunk/include/clang/Basic/Builtins.h Thu Jun 30 20:24:09 2016
@@ -219,7 +219,10 @@ private:
 /// \brief Kinds of BuiltinTemplateDecl.
 enum BuiltinTemplateKind : int {
   /// \brief This names the __make_integer_seq BuiltinTemplateDecl.
-  BTK__make_integer_seq
+  BTK__make_integer_seq,
+
+  /// \brief This names the __type_pack_element BuiltinTemplateDecl.
+  BTK__type_pack_element
 };
 
 } // end namespace clang

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=274316=274315=274316=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Thu Jun 30 20:24:09 
2016
@@ -2128,6 +2128,10 @@ def err_integer_sequence_negative_length
 def 

r274314 - [CodeCompletion] Allow system headers providing private symbols with a single underscore.

2016-06-30 Thread Argyrios Kyrtzidis via cfe-commits
Author: akirtzidis
Date: Thu Jun 30 20:17:02 2016
New Revision: 274314

URL: http://llvm.org/viewvc/llvm-project?rev=274314=rev
Log:
[CodeCompletion] Allow system headers providing private symbols with a single 
underscore.

rdar://24677150

Modified:
cfe/trunk/lib/Sema/SemaCodeComplete.cpp
cfe/trunk/test/CodeCompletion/Inputs/reserved.h
cfe/trunk/test/CodeCompletion/ordinary-name.c

Modified: cfe/trunk/lib/Sema/SemaCodeComplete.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaCodeComplete.cpp?rev=274314=274313=274314=diff
==
--- cfe/trunk/lib/Sema/SemaCodeComplete.cpp (original)
+++ cfe/trunk/lib/Sema/SemaCodeComplete.cpp Thu Jun 30 20:17:02 2016
@@ -481,12 +481,37 @@ getRequiredQualification(ASTContext 
 
 /// Determine whether \p Id is a name reserved for the implementation (C99
 /// 7.1.3, C++ [lib.global.names]).
-static bool isReservedName(const IdentifierInfo *Id) {
+static bool isReservedName(const IdentifierInfo *Id,
+   bool doubleUnderscoreOnly = false) {
   if (Id->getLength() < 2)
 return false;
   const char *Name = Id->getNameStart();
   return Name[0] == '_' &&
- (Name[1] == '_' || (Name[1] >= 'A' && Name[1] <= 'Z'));
+ (Name[1] == '_' || (Name[1] >= 'A' && Name[1] <= 'Z' &&
+ !doubleUnderscoreOnly));
+}
+
+// Some declarations have reserved names that we don't want to ever show.
+// Filter out names reserved for the implementation if they come from a
+// system header.
+static bool shouldIgnoreDueToReservedName(const NamedDecl *ND, Sema ) {
+  const IdentifierInfo *Id = ND->getIdentifier();
+  if (!Id)
+return false;
+
+  // Ignore reserved names for compiler provided decls.
+  if (isReservedName(Id) && ND->getLocation().isInvalid())
+return true;
+
+  // For system headers ignore only double-underscore names.
+  // This allows for system headers providing private symbols with a single
+  // underscore.
+  if (isReservedName(Id, /*doubleUnderscoreOnly=*/true) &&
+   SemaRef.SourceMgr.isInSystemHeader(
+   SemaRef.SourceMgr.getSpellingLoc(ND->getLocation(
+  return true;
+
+  return false;
 }
 
 bool ResultBuilder::isInterestingDecl(const NamedDecl *ND,
@@ -513,17 +538,9 @@ bool ResultBuilder::isInterestingDecl(co
   // Using declarations themselves are never added as results.
   if (isa(ND))
 return false;
-  
-  // Some declarations have reserved names that we don't want to ever show.
-  // Filter out names reserved for the implementation if they come from a
-  // system header.
-  // TODO: Add a predicate for this.
-  if (const IdentifierInfo *Id = ND->getIdentifier())
-if (isReservedName(Id) &&
-(ND->getLocation().isInvalid() ||
- SemaRef.SourceMgr.isInSystemHeader(
- SemaRef.SourceMgr.getSpellingLoc(ND->getLocation()
-return false;
+
+  if (shouldIgnoreDueToReservedName(ND, SemaRef))
+return false;
 
   if (Filter == ::IsNestedNameSpecifier ||
   (isa(ND) &&

Modified: cfe/trunk/test/CodeCompletion/Inputs/reserved.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeCompletion/Inputs/reserved.h?rev=274314=274313=274314=diff
==
--- cfe/trunk/test/CodeCompletion/Inputs/reserved.h (original)
+++ cfe/trunk/test/CodeCompletion/Inputs/reserved.h Thu Jun 30 20:17:02 2016
@@ -1,2 +1,4 @@
-typedef int _INTEGER_TYPE;
+typedef int __INTEGER_TYPE;
 typedef float FLOATING_TYPE;
+
+typedef int _MyPrivateType;

Modified: cfe/trunk/test/CodeCompletion/ordinary-name.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeCompletion/ordinary-name.c?rev=274314=274313=274314=diff
==
--- cfe/trunk/test/CodeCompletion/ordinary-name.c (original)
+++ cfe/trunk/test/CodeCompletion/ordinary-name.c Thu Jun 30 20:17:02 2016
@@ -5,8 +5,9 @@ typedef struct t _TYPEDEF;
 void foo() {
   int y;
   // RUN: %clang_cc1 -isystem %S/Inputs -fsyntax-only 
-code-completion-at=%s:6:9 %s -o - | FileCheck -check-prefix=CHECK-CC1 %s
+  // CHECK-CC1-NOT: __INTEGER_TYPE
   // CHECK-CC1: _Imaginary
-  // CHECK-CC1-NOT: _INTEGER_TYPE;
+  // CHECK-CC1: _MyPrivateType
   // CHECK-CC1: _TYPEDEF
   // CHECK-CC1: FLOATING_TYPE
   // CHECK-CC1: foo


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


Re: [PATCH] D18639: Use __builtin_isnan/isinf/isfinite in complex

2016-06-30 Thread Hal Finkel via cfe-commits
hfinkel added a comment.

ping


http://reviews.llvm.org/D18639



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


[PATCH] D21912: [CUDA] Don't assume that destructors can't be overloaded.

2016-06-30 Thread Justin Lebar via cfe-commits
jlebar created this revision.
jlebar added a reviewer: rsmith.
jlebar added subscribers: tra, cfe-commits.

You can overload a destructor in CUDA, and SemaOverload needs to be
tweaked not to crash when it sees an explicit call to an overloaded
destructor.

http://reviews.llvm.org/D21912

Files:
  lib/Sema/SemaOverload.cpp
  test/SemaCUDA/call-overloaded-destructor.cu

Index: test/SemaCUDA/call-overloaded-destructor.cu
===
--- /dev/null
+++ test/SemaCUDA/call-overloaded-destructor.cu
@@ -0,0 +1,17 @@
+// expected-no-diagnostics
+
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple nvptx64-nvidia-cuda -fsyntax-only -fcuda-is-device 
-verify %s
+
+#include "Inputs/cuda.h"
+
+struct S {
+  __host__ ~S() {}
+  __device__ ~S() {}
+};
+
+__host__ __device__ void test() {
+  S s;
+  // This should not crash clang.
+  s.~S();
+}
Index: lib/Sema/SemaOverload.cpp
===
--- lib/Sema/SemaOverload.cpp
+++ lib/Sema/SemaOverload.cpp
@@ -12407,8 +12407,7 @@
   if (CXXDestructorDecl *DD =
   dyn_cast(TheCall->getMethodDecl())) {
 // a->A::f() doesn't go through the vtable, except in AppleKext mode.
-bool CallCanBeVirtual = !cast(NakedMemExpr)->hasQualifier() ||
-getLangOpts().AppleKext;
+bool CallCanBeVirtual = !MemExpr->hasQualifier() || 
getLangOpts().AppleKext;
 CheckVirtualDtorCall(DD, MemExpr->getLocStart(), /*IsDelete=*/false,
  CallCanBeVirtual, /*WarnOnNonAbstractTypes=*/true,
  MemExpr->getMemberLoc());


Index: test/SemaCUDA/call-overloaded-destructor.cu
===
--- /dev/null
+++ test/SemaCUDA/call-overloaded-destructor.cu
@@ -0,0 +1,17 @@
+// expected-no-diagnostics
+
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple nvptx64-nvidia-cuda -fsyntax-only -fcuda-is-device -verify %s
+
+#include "Inputs/cuda.h"
+
+struct S {
+  __host__ ~S() {}
+  __device__ ~S() {}
+};
+
+__host__ __device__ void test() {
+  S s;
+  // This should not crash clang.
+  s.~S();
+}
Index: lib/Sema/SemaOverload.cpp
===
--- lib/Sema/SemaOverload.cpp
+++ lib/Sema/SemaOverload.cpp
@@ -12407,8 +12407,7 @@
   if (CXXDestructorDecl *DD =
   dyn_cast(TheCall->getMethodDecl())) {
 // a->A::f() doesn't go through the vtable, except in AppleKext mode.
-bool CallCanBeVirtual = !cast(NakedMemExpr)->hasQualifier() ||
-getLangOpts().AppleKext;
+bool CallCanBeVirtual = !MemExpr->hasQualifier() || getLangOpts().AppleKext;
 CheckVirtualDtorCall(DD, MemExpr->getLocStart(), /*IsDelete=*/false,
  CallCanBeVirtual, /*WarnOnNonAbstractTypes=*/true,
  MemExpr->getMemberLoc());
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


LLVM buildmaster will be restarted around 5 PM today

2016-06-30 Thread Galina Kistanova via cfe-commits
Hello everyone,

LLVM buildmaster will be restarted around 5 PM Pacific time today.
Thank you for understanding.

Thanks

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


Re: [PATCH] D18172: [CUDA][OpenMP] Add a generic offload action builder

2016-06-30 Thread Justin Lebar via cfe-commits
jlebar added a comment.

Alexey, it seems that you're asking for "final" on all classes that are not 
inherited from.  Forgive my ignorance, but would you mind pointing me to the 
document that talks about our position on "final" in LLVM source?  I don't see 
it in the style guide, but I may be missing something.

The style guide does talk a good bit about writing concise and generally 
not-misleading code.  My concern is that adding "final" everywhere paints an 
inaccurate picture and will mislead readers.  Specifically, "final" is useful 
as a signal to readers that a class cannot safely be inherited from.  "Don't 
even think about it, buster."  But here we're adding "final" to a lot of 
classes that, as far as I can tell, aren't distinctive except in that they have 
no subclasses today.  The problem with this is that, if we use "final" in this 
way, it dilutes the first "don't even try" meaning.  Now when I see a class 
with "final" that I want to subclass, I'm just going to rip the "final" off, 
because chances are, I can do so safely.  Now "final" does not serve as a 
warning to me that I shouldn't do this.

Sorry to focus on a superficial issue, but I think this really does matter for 
usability.


http://reviews.llvm.org/D18172



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


Re: [PATCH] D21334: Add TargetInfo for 32-bit and 64-bit RenderScript

2016-06-30 Thread Eric Christopher via cfe-commits
echristo accepted this revision.
echristo added a comment.
This revision is now accepted and ready to land.

Please reformat with clang-format and then OK.

-eric


http://reviews.llvm.org/D21334



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


Re: [PATCH] D18172: [CUDA][OpenMP] Add a generic offload action builder

2016-06-30 Thread Samuel Antao via cfe-commits
sfantao added a comment.

Hi Alexey,

Thanks for the review! Addressed your comments in the new diff.

I'll wait for your response on my question in http://reviews.llvm.org/D18172 to 
address the issue with \brief properly.

Thanks again,
Samuel


http://reviews.llvm.org/D18172



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


Re: [PATCH] D18172: [CUDA][OpenMP] Add a generic offload action builder

2016-06-30 Thread Samuel Antao via cfe-commits
sfantao updated this revision to Diff 62438.
sfantao marked 3 inline comments as done.
sfantao added a comment.

- Fix comments, annotate classes with final, and add default initializers.


http://reviews.llvm.org/D18172

Files:
  include/clang/Driver/Compilation.h
  lib/Driver/Driver.cpp

Index: lib/Driver/Driver.cpp
===
--- lib/Driver/Driver.cpp
+++ lib/Driver/Driver.cpp
@@ -1387,131 +1387,523 @@
   }
 }
 
-// For each unique --cuda-gpu-arch= argument creates a TY_CUDA_DEVICE
-// input action and then wraps each in CudaDeviceAction paired with
-// appropriate GPU arch name. In case of partial (i.e preprocessing
-// only) or device-only compilation, each device action is added to /p
-// Actions and /p Current is released. Otherwise the function creates
-// and returns a new CudaHostAction which wraps /p Current and device
-// side actions.
-static Action *buildCudaActions(Compilation , DerivedArgList ,
-const Arg *InputArg, Action *HostAction,
-ActionList ) {
-  Arg *PartialCompilationArg = Args.getLastArg(
-  options::OPT_cuda_host_only, options::OPT_cuda_device_only,
-  options::OPT_cuda_compile_host_device);
-  bool CompileHostOnly =
-  PartialCompilationArg &&
-  PartialCompilationArg->getOption().matches(options::OPT_cuda_host_only);
-  bool CompileDeviceOnly =
-  PartialCompilationArg &&
-  PartialCompilationArg->getOption().matches(options::OPT_cuda_device_only);
-
-  if (CompileHostOnly) {
+namespace {
+/// \brief Provides a convenient interface for different programming models to
+/// generate the required device actions.
+class OffloadingActionBuilder final {
+  /// \brief Flag used to trace errors in the builder.
+  bool IsValid = false;
+
+  /// \brief The compilation that is using this builder.
+  Compilation 
+
+  /// \brief The derived arguments associated with this builder.
+  DerivedArgList 
+
+  /// \brief Map between an input argument and the offload kinds used to process
+  /// it.
+  std::map InputArgToOffloadKindMap;
+
+  /// \brief Builder interface. It doesn't build anything or keep any state.
+  class DeviceActionBuilder {
+  public:
+typedef llvm::SmallVector PhasesTy;
+
+enum ActionBuilderReturnCode {
+  // The builder acted successfully on the current action.
+  ABRT_Success,
+  // The builder didn't have to act on the current action.
+  ABRT_Inactive,
+  // The builder was successful and requested the host action to not be
+  // generated.
+  ABRT_Ignore_Host,
+};
+
+  protected:
+/// \brief Compilation associated with this builder.
+Compilation 
+
+/// \brief Tool chains associated with this builder. The same programming
+/// model may have associated one or more tool chains.
+SmallVector ToolChains;
+
+/// \brief The derived arguments associated with this builder.
+DerivedArgList 
+
+/// \brief The inputs associated with this builder.
+const Driver::InputList 
+
+/// \brief The associated offload kind.
+Action::OffloadKind AssociatedOffloadKind = Action::OFK_None;
+
+  public:
+DeviceActionBuilder(Compilation , DerivedArgList ,
+const Driver::InputList ,
+Action::OffloadKind AssociatedOffloadKind)
+: C(C), Args(Args), Inputs(Inputs),
+  AssociatedOffloadKind(AssociatedOffloadKind) {}
+virtual ~DeviceActionBuilder() {}
+
+// \brief Fill up the array \a DA with all the device dependences that
+// should be added to the provided host action \a HostAction. By default it
+// is inactive.
+virtual ActionBuilderReturnCode
+getDeviceDepences(OffloadAction::DeviceDependences , phases::ID CurPhase,
+  phases::ID FinalPhase, PhasesTy ) {
+  return ABRT_Inactive;
+}
+
+// \brief Update the state to include the provided host action \a HostAction
+// as a dependency of the current device action. By default it is inactive.
+virtual ActionBuilderReturnCode addDeviceDepences(Action *HostAction) {
+  return ABRT_Inactive;
+}
+
+// \brief Append top level actions generated by the builder. Return true if
+// errors were found.
+virtual void appendTopLevelActions(ActionList ) {}
+
+// \brief Append linker actions generated by the builder. Return true if
+// errors were found.
+virtual void appendLinkDependences(OffloadAction::DeviceDependences ) {}
+
+// \brief Initialize the builder. Return true if any initialization errors
+// are found.
+virtual bool initialize() { return false; }
+
+// \brief Return true if this builder is valid. We have a valid builder if
+// we have associated device tool chains.
+bool isValid() { return !ToolChains.empty(); }
+
+// \brief Return the associated offload kind.
+Action::OffloadKind 

Re: [PATCH] D21619: [Sema] Implement C++14's DR1579: Prefer moving id-expression out of functions

2016-06-30 Thread Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL274291: [Sema] Implement C++14's DR1579: Prefer returning by 
converting move constructor (authored by epilk).

Changed prior to commit:
  http://reviews.llvm.org/D21619?vs=62405=62437#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D21619

Files:
  cfe/trunk/include/clang/Sema/Initialization.h
  cfe/trunk/include/clang/Sema/Sema.h
  cfe/trunk/lib/Sema/SemaStmt.cpp
  cfe/trunk/test/CXX/drs/dr15xx.cpp
  cfe/trunk/test/SemaCXX/rval-references.cpp

Index: cfe/trunk/test/SemaCXX/rval-references.cpp
===
--- cfe/trunk/test/SemaCXX/rval-references.cpp
+++ cfe/trunk/test/SemaCXX/rval-references.cpp
@@ -72,23 +72,17 @@
 // Test the return dance. This also tests IsReturnCopyElidable.
 struct MoveOnly {
   MoveOnly();
-  MoveOnly(const MoveOnly&) = delete;	// expected-note {{candidate constructor}} \
-  // expected-note 3{{explicitly marked deleted here}}
-  MoveOnly(MoveOnly&&);	// expected-note {{candidate constructor}}
-  MoveOnly(int&&);	// expected-note {{candidate constructor}}
+  MoveOnly(const MoveOnly&) = delete;	// expected-note 3{{explicitly marked deleted here}}
 };
 
 MoveOnly gmo;
 MoveOnly returningNonEligible() {
-  int i;
   static MoveOnly mo;
   MoveOnly  = mo;
   if (0) // Copy from global can't be elided
 return gmo; // expected-error {{call to deleted constructor}}
   else if (0) // Copy from local static can't be elided
 return mo; // expected-error {{call to deleted constructor}}
-  else if (0) // Copy from reference can't be elided
+  else // Copy from reference can't be elided
 return r; // expected-error {{call to deleted constructor}}
-  else // Construction from different type can't be elided
-return i; // expected-error {{no viable conversion from returned value of type 'int' to function return type 'MoveOnly'}}
 }
Index: cfe/trunk/test/CXX/drs/dr15xx.cpp
===
--- cfe/trunk/test/CXX/drs/dr15xx.cpp
+++ cfe/trunk/test/CXX/drs/dr15xx.cpp
@@ -87,6 +87,62 @@
 
 } // std
 
+namespace dr1579 { // dr1579: 3.9
+template
+struct GenericMoveOnly {
+  GenericMoveOnly();
+  template GenericMoveOnly(const GenericMoveOnly &) = delete; // expected-note 5 {{marked deleted here}}
+  GenericMoveOnly(const int &) = delete; // expected-note 2 {{marked deleted here}}
+  template GenericMoveOnly(GenericMoveOnly &&);
+  GenericMoveOnly(int &&);
+};
+
+GenericMoveOnly DR1579_Eligible(GenericMoveOnly CharMO) {
+  int i;
+  GenericMoveOnly GMO;
+
+  if (0)
+return i;
+  else if (0)
+return GMO;
+  else if (0)
+return ((GMO));
+  else
+return CharMO;
+}
+
+GenericMoveOnly GlobalMO;
+
+GenericMoveOnly DR1579_Ineligible(int ,
+  GenericMoveOnly ) {
+  static GenericMoveOnly StaticMove;
+  extern GenericMoveOnly ExternMove;
+
+  if (0)
+return AnInt; // expected-error{{invokes a deleted function}}
+  else if (0)
+return GlobalMO; // expected-error{{invokes a deleted function}}
+  else if (0)
+return StaticMove; // expected-error{{invokes a deleted function}}
+  else if (0)
+return ExternMove; // expected-error{{invokes a deleted function}}
+  else if (0)
+return AnInt; // expected-error{{invokes a deleted function}}
+  else
+return CharMO; // expected-error{{invokes a deleted function}}
+}
+
+auto DR1579_lambda_valid = [](GenericMoveOnly mo) ->
+  GenericMoveOnly {
+  return mo;
+};
+
+auto DR1579_lambda_invalid = []() -> GenericMoveOnly {
+  static GenericMoveOnly mo;
+  return mo; // expected-error{{invokes a deleted function}}
+};
+} // end namespace dr1579
+
 namespace dr1589 {   // dr1589: 3.7 c++11
   // Ambiguous ranking of list-initialization sequences
 
Index: cfe/trunk/lib/Sema/SemaStmt.cpp
===
--- cfe/trunk/lib/Sema/SemaStmt.cpp
+++ cfe/trunk/lib/Sema/SemaStmt.cpp
@@ -2697,16 +2697,16 @@
 /// \param E The expression being returned from the function or block, or
 /// being thrown.
 ///
-/// \param AllowFunctionParameter Whether we allow function parameters to
-/// be considered NRVO candidates. C++ prohibits this for NRVO itself, but
-/// we re-use this logic to determine whether we should try to move as part of
-/// a return or throw (which does allow function parameters).
+/// \param AllowParamOrMoveConstructible Whether we allow function parameters or
+/// id-expressions that could be moved out of the function to be considered NRVO
+/// candidates. C++ prohibits these for NRVO itself, but we re-use this logic to
+/// determine whether we should try to move as part of a return or throw (which
+/// does allow function parameters).
 ///
 /// \returns The NRVO candidate variable, if the return statement may use the
 /// NRVO, or NULL if there is no such candidate.
-VarDecl *Sema::getCopyElisionCandidate(QualType ReturnType,
-   

r274291 - [Sema] Implement C++14's DR1579: Prefer returning by converting move constructor

2016-06-30 Thread Erik Pilkington via cfe-commits
Author: epilk
Date: Thu Jun 30 18:09:13 2016
New Revision: 274291

URL: http://llvm.org/viewvc/llvm-project?rev=274291=rev
Log:
[Sema] Implement C++14's DR1579: Prefer returning by converting move constructor

Fixes PR28096.

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

Modified:
cfe/trunk/include/clang/Sema/Initialization.h
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/Sema/SemaStmt.cpp
cfe/trunk/test/CXX/drs/dr15xx.cpp
cfe/trunk/test/SemaCXX/rval-references.cpp

Modified: cfe/trunk/include/clang/Sema/Initialization.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Initialization.h?rev=274291=274290=274291=diff
==
--- cfe/trunk/include/clang/Sema/Initialization.h (original)
+++ cfe/trunk/include/clang/Sema/Initialization.h Thu Jun 30 18:09:13 2016
@@ -952,6 +952,9 @@ public:
   step_iterator step_begin() const { return Steps.begin(); }
   step_iterator step_end()   const { return Steps.end(); }
 
+  typedef llvm::iterator_range step_range;
+  step_range steps() const { return {step_begin(), step_end()}; }
+
   /// \brief Determine whether this initialization is a direct reference 
   /// binding (C++ [dcl.init.ref]).
   bool isDirectReferenceBinding() const;

Modified: cfe/trunk/include/clang/Sema/Sema.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=274291=274290=274291=diff
==
--- cfe/trunk/include/clang/Sema/Sema.h (original)
+++ cfe/trunk/include/clang/Sema/Sema.h Thu Jun 30 18:09:13 2016
@@ -3476,9 +3476,9 @@ public:
SourceLocation Loc,
unsigned NumParams);
   VarDecl *getCopyElisionCandidate(QualType ReturnType, Expr *E,
-   bool AllowFunctionParameters);
+   bool AllowParamOrMoveConstructible);
   bool isCopyElisionCandidate(QualType ReturnType, const VarDecl *VD,
-  bool AllowFunctionParameters);
+  bool AllowParamOrMoveConstructible);
 
   StmtResult ActOnReturnStmt(SourceLocation ReturnLoc, Expr *RetValExp,
  Scope *CurScope);

Modified: cfe/trunk/lib/Sema/SemaStmt.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaStmt.cpp?rev=274291=274290=274291=diff
==
--- cfe/trunk/lib/Sema/SemaStmt.cpp (original)
+++ cfe/trunk/lib/Sema/SemaStmt.cpp Thu Jun 30 18:09:13 2016
@@ -2697,16 +2697,16 @@ Sema::ActOnBreakStmt(SourceLocation Brea
 /// \param E The expression being returned from the function or block, or
 /// being thrown.
 ///
-/// \param AllowFunctionParameter Whether we allow function parameters to
-/// be considered NRVO candidates. C++ prohibits this for NRVO itself, but
-/// we re-use this logic to determine whether we should try to move as part of
-/// a return or throw (which does allow function parameters).
+/// \param AllowParamOrMoveConstructible Whether we allow function parameters 
or
+/// id-expressions that could be moved out of the function to be considered 
NRVO
+/// candidates. C++ prohibits these for NRVO itself, but we re-use this logic 
to
+/// determine whether we should try to move as part of a return or throw (which
+/// does allow function parameters).
 ///
 /// \returns The NRVO candidate variable, if the return statement may use the
 /// NRVO, or NULL if there is no such candidate.
-VarDecl *Sema::getCopyElisionCandidate(QualType ReturnType,
-   Expr *E,
-   bool AllowFunctionParameter) {
+VarDecl *Sema::getCopyElisionCandidate(QualType ReturnType, Expr *E,
+   bool AllowParamOrMoveConstructible) {
   if (!getLangOpts().CPlusPlus)
 return nullptr;
 
@@ -2719,13 +2719,13 @@ VarDecl *Sema::getCopyElisionCandidate(Q
   if (!VD)
 return nullptr;
 
-  if (isCopyElisionCandidate(ReturnType, VD, AllowFunctionParameter))
+  if (isCopyElisionCandidate(ReturnType, VD, AllowParamOrMoveConstructible))
 return VD;
   return nullptr;
 }
 
 bool Sema::isCopyElisionCandidate(QualType ReturnType, const VarDecl *VD,
-  bool AllowFunctionParameter) {
+  bool AllowParamOrMoveConstructible) {
   QualType VDType = VD->getType();
   // - in a return statement in a function with ...
   // ... a class return type ...
@@ -2733,20 +2733,24 @@ bool Sema::isCopyElisionCandidate(QualTy
 if (!ReturnType->isRecordType())
   return false;
 // ... the same cv-unqualified type as the function return type ...
-if (!VDType->isDependentType() &&
+// When considering moving this expression out, allow dissimilar types.
+if 

Re: [PATCH] D18171: [CUDA][OpenMP] Create generic offload action

2016-06-30 Thread Samuel Antao via cfe-commits
sfantao added a comment.

Hi Alexey,

Thanks for the review! I addressed your comments in the last diff.

In http://reviews.llvm.org/D18171#471044, @ABataev wrote:

> No '\brief's


When you say  "no \brief" do you mean I am using that where I shouldn't or the 
other way around. I am only adding that for member functions/vars  that I 
create, should I do that for member I am modifying too? I noticed two places 
where I was using that for static functions, I removed \brief in those cases. 
Let me know if that is what you wanted me to do.

Thanks again,
Samuel


http://reviews.llvm.org/D18171



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


Re: r274084 - Revert "[PS4] Tighten up a test (noticed in passing)"

2016-06-30 Thread Sean Silva via cfe-commits
On Thu, Jun 30, 2016 at 3:52 PM, Robinson, Paul 
wrote:

>
>
> > -Original Message-
> > From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf
> Of
> > Sean Silva via cfe-commits
> > Sent: Tuesday, June 28, 2016 5:29 PM
> > To: cfe-commits@lists.llvm.org
> > Subject: r274084 - Revert "[PS4] Tighten up a test (noticed in passing)"
> >
> > Author: silvas
> > Date: Tue Jun 28 19:29:23 2016
> > New Revision: 274084
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=274084=rev
> > Log:
> > Revert "[PS4] Tighten up a test (noticed in passing)"
> >
> > This reverts commit r269709.
> >
> > r262285 changed this deliberately so that the test would not be
> > sensitive to which binaries are in the same directory as clang.
> > See the commit message of that commit for more background.
>
> Okay, but the point of the test is to match a "file.exe" instead
> of just "file". See commentary at the top of the test.
> Also "orbis-ld" is a prefix of "orbis-ld.gold" and so matching
> just the former doesn't verify we're looking for the right one.
>
> I understand taking out the path part of the check in r262285 but
> if you named your test linker "orbis-ld.exe" instead of "orbis-ld"
> then the test would pass with r269709, right?


Unfortunately not.

-- Sean Silva


>   If that's all this
> is about, please undo this revert and use the standard Windows
> file extension for your test linkers.
> --paulr
>
> >
> > Modified:
> > cfe/trunk/test/Driver/ps4-linker-win.c
> >
> > Modified: cfe/trunk/test/Driver/ps4-linker-win.c
> > URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/ps4-linker-
> > win.c?rev=274084=274083=274084=diff
> >
> ==
> > 
> > --- cfe/trunk/test/Driver/ps4-linker-win.c (original)
> > +++ cfe/trunk/test/Driver/ps4-linker-win.c Tue Jun 28 19:29:23 2016
> > @@ -22,5 +22,5 @@
> >  // RUN: env "PATH=%T;%PATH%;" %clang -target x86_64-scei-ps4  %s -shared
> > \
> >  // RUN: -fuse-ld=ps4 -### 2>&1 | FileCheck --check-prefix=CHECK-PS4-
> > LINKER %s
> >
> > -// CHECK-PS4-GOLD: \\orbis-ld.gold.exe"
> > -// CHECK-PS4-LINKER: \\orbis-ld.exe"
> > +// CHECK-PS4-GOLD: \\orbis-ld.gold
> > +// CHECK-PS4-LINKER: \\orbis-ld
> >
> >
> > ___
> > 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] D15421: [Feature] Add a builtin for indexing into parameter packs

2016-06-30 Thread Eric Fiselier via cfe-commits
EricWF added a subscriber: EricWF.
EricWF added a comment.

Ping? Is there a reason this hasn't been committed?


http://reviews.llvm.org/D15421



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


Re: [PATCH] D18171: [CUDA][OpenMP] Create generic offload action

2016-06-30 Thread Samuel Antao via cfe-commits
sfantao updated this revision to Diff 62435.
sfantao marked 5 inline comments as done.
sfantao added a comment.

- Mark classes with final and fix comments.


http://reviews.llvm.org/D18171

Files:
  include/clang/Driver/Action.h
  include/clang/Driver/Compilation.h
  include/clang/Driver/Driver.h
  lib/Driver/Action.cpp
  lib/Driver/Driver.cpp
  lib/Driver/ToolChain.cpp
  lib/Driver/ToolChains.cpp
  lib/Driver/ToolChains.h
  lib/Driver/Tools.cpp
  lib/Driver/Tools.h
  lib/Frontend/CreateInvocationFromCommandLine.cpp

Index: lib/Frontend/CreateInvocationFromCommandLine.cpp
===
--- lib/Frontend/CreateInvocationFromCommandLine.cpp
+++ lib/Frontend/CreateInvocationFromCommandLine.cpp
@@ -60,25 +60,25 @@
   }
 
   // We expect to get back exactly one command job, if we didn't something
-  // failed. CUDA compilation is an exception as it creates multiple jobs. If
-  // that's the case, we proceed with the first job. If caller needs particular
-  // CUDA job, it should be controlled via --cuda-{host|device}-only option
-  // passed to the driver.
+  // failed. Offload compilation is an exception as it creates multiple jobs. If
+  // that's the case, we proceed with the first job. If caller needs a
+  // particular job, it should be controlled via options (e.g.
+  // --cuda-{host|device}-only for CUDA) passed to the driver.
   const driver::JobList  = C->getJobs();
-  bool CudaCompilation = false;
+  bool OffloadCompilation = false;
   if (Jobs.size() > 1) {
 for (auto  : C->getActions()){
   // On MacOSX real actions may end up being wrapped in BindArchAction
   if (isa(A))
 A = *A->input_begin();
-  if (isa(A)) {
-CudaCompilation = true;
+  if (isa(A)) {
+OffloadCompilation = true;
 break;
   }
 }
   }
   if (Jobs.size() == 0 || !isa(*Jobs.begin()) ||
-  (Jobs.size() > 1 && !CudaCompilation)) {
+  (Jobs.size() > 1 && !OffloadCompilation)) {
 SmallString<256> Msg;
 llvm::raw_svector_ostream OS(Msg);
 Jobs.Print(OS, "; ", true);
Index: lib/Driver/Tools.h
===
--- lib/Driver/Tools.h
+++ lib/Driver/Tools.h
@@ -57,8 +57,7 @@
const Driver , const llvm::opt::ArgList ,
llvm::opt::ArgStringList ,
const InputInfo ,
-   const InputInfoList ,
-   const ToolChain *AuxToolChain) const;
+   const InputInfoList ) const;
 
   void AddAArch64TargetArgs(const llvm::opt::ArgList ,
 llvm::opt::ArgStringList ) const;
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -288,12 +288,45 @@
  !O.hasFlag(options::DriverOption) && !O.hasFlag(options::LinkerInput);
 }
 
+/// Add the C++ include args of other offloading toolchains. If this is a host
+/// job, the device toolchains are added. If this is a device job, the host
+/// toolchains will be added.
+static void addExtraOffloadCXXStdlibIncludeArgs(Compilation ,
+const JobAction ,
+const ArgList ,
+ArgStringList ) {
+
+  if (JA.isHostOffloading(Action::OFK_Cuda))
+C.getSingleOffloadToolChain()
+->AddClangCXXStdlibIncludeArgs(Args, CmdArgs);
+  else if (JA.isDeviceOffloading(Action::OFK_Cuda))
+C.getSingleOffloadToolChain()
+->AddClangCXXStdlibIncludeArgs(Args, CmdArgs);
+
+  // TODO: Add support for other programming models here.
+}
+
+/// Add the include args that are specific of each offloading programming model.
+static void addExtraOffloadSpecificIncludeArgs(Compilation ,
+   const JobAction ,
+   const ArgList ,
+   ArgStringList ) {
+
+  if (JA.isHostOffloading(Action::OFK_Cuda))
+C.getSingleOffloadToolChain()->AddCudaIncludeArgs(
+Args, CmdArgs);
+  else if (JA.isDeviceOffloading(Action::OFK_Cuda))
+C.getSingleOffloadToolChain()->AddCudaIncludeArgs(
+Args, CmdArgs);
+
+  // TODO: Add support for other programming models here.
+}
+
 void Clang::AddPreprocessingOptions(Compilation , const JobAction ,
 const Driver , const ArgList ,
 ArgStringList ,
 const InputInfo ,
-const InputInfoList ,
-const ToolChain *AuxToolChain) const {
+const InputInfoList ) const {
   Arg *A;
   const bool IsIAMCU = getToolChain().getTriple().isOSIAMCU();
 
@@ 

Re: [PATCH] D21385: Adjust Registry interface to not require plugins to export a registry

2016-06-30 Thread Rudy Pons via cfe-commits
Ilod added a subscriber: Ilod.
Ilod added a comment.

Hello,

When I tried your patch and added LLVM_EXPORT_SYMBOLS_FOR_PLUGINS=ON, I had 
multiple errors on your python scripts, like:

File "utils/extract_symbols.py", line 399, in 
  calling_convention_decoration = is_32bit_windows(libs[0])
File "utils/extract_symbols.py", line 88, in dumpbin_is_32bit_windows
  match = re.match('.+machine \((\S+)\)', line)
File "C:\Program Files\Python35\lib\re.py", line 163, in match
  return _compile(pattern, flags).match(string)
  TypeError: cannot use a string pattern on a bytes-like object

And after I fixed them by passing bytes-like object literals, I had the 
following error:

File "utils/extract_symbols.py", line 488, in 
  print >>outfile, str(k)
  TypeError: unsupported operand type(s) for >>: 'builtin_function_or_method' 
and '_io.TextIOWrapper'

I gave up after this. I have Pyhton 3.5 64 bits, and was building clang 32-bits 
on Windows with Visual Studio 2015 Update 2.

Looking at the patch:

If I understand correctly, the pros/cons between your approach and the previous 
attempt are:

- Your method allows to export the various symbols of the tool from the plugin, 
allowing mainly to access/modify global variables of it, instead of having 
another instance of it in the DLL (thus probably causing many bugs)
- Previous attempt allowed to make a plugin which could be loaded by any tool, 
while yours need the plugin to be specific to a tool

If that's all, I suppose it's better to have your limitation to plugin support 
rather than a full support which will bug if you call a function that accesses 
a static member.

(By the way, the previous attempt works fine, it was reverted because of a 
mingw crash which can be fixed by the patch http://reviews.llvm.org/D18847)

However, couldn't we enable by default LLVM_EXPORT_SYMBOLS_FOR_PLUGINS on the 
platforms/compilers which doesn't currently support the plugins? Having plugins 
only work on custom builds of clang seems to be against the main use of 
plugins. (If testing is the only problem, I would gladly test it on Windows 
with mingw, and maybe Mac if needed)

Also, could you add in the documentation (cfe/trunk/docs/ClangPlugins.rst) what 
are the limitations/setup needed to make an out-of-tree plugin?


Repository:
  rL LLVM

http://reviews.llvm.org/D21385



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


[libcxx] r274286 - Replace __make_tuple_indices implementation with superior implementation.

2016-06-30 Thread Eric Fiselier via cfe-commits
Author: ericwf
Date: Thu Jun 30 17:34:43 2016
New Revision: 274286

URL: http://llvm.org/viewvc/llvm-project?rev=274286=rev
Log:
Replace __make_tuple_indices implementation with superior implementation.

The previous __make_tuple_indices implementation caused O(N) instantiations
and was pretty inefficient. The C++14 __make_integer_sequence implementation
is much better, since it either uses a builtin to generate the sequence or
a very nice Log8(N) implementation provided by richard smith.

This patch moves the __make_integer_sequence implementation into __tuple
and uses it to implement __make_tuple_indices.

Since libc++ can't expose the name 'integer_sequence' in C++11 this patch
also introduces a dummy type '__integer_sequence' which is used when generating
the sequence. One the sequence is generated '__integer_sequence' can be
converted into the required type; either '__tuple_indices' or 
'integer_sequence'.

Modified:
libcxx/trunk/include/__tuple
libcxx/trunk/include/utility

Modified: libcxx/trunk/include/__tuple
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__tuple?rev=274286=274285=274286=diff
==
--- libcxx/trunk/include/__tuple (original)
+++ libcxx/trunk/include/__tuple Thu Jun 30 17:34:43 2016
@@ -68,6 +68,80 @@ template  struct __tuple_like
 // tuple specializations
 
 #if !defined(_LIBCPP_HAS_NO_VARIADICS)
+
+template  struct __tuple_indices {};
+
+template 
+struct __integer_sequence {
+  template  class _ToIndexSeq, class 
_ToIndexType>
+  using __convert = _ToIndexSeq<_ToIndexType, _Values...>;
+
+  template 
+  using __to_tuple_indices = __tuple_indices<(_Values + _Sp)...>;
+};
+
+#if !__has_builtin(__make_integer_seq) || 
defined(_LIBCPP_TESTING_FALLBACK_MAKE_INTEGER_SEQUENCE)
+namespace __detail {
+
+template struct __repeat;
+template struct 
__repeat<__integer_sequence<_Tp, _Np...>, _Extra...> {
+  typedef __integer_sequence<_Tp,
+   _Np...,
+   sizeof...(_Np) + _Np...,
+   2 * sizeof...(_Np) + _Np...,
+   3 * sizeof...(_Np) + _Np...,
+   4 * sizeof...(_Np) + _Np...,
+   5 * sizeof...(_Np) + _Np...,
+   6 * sizeof...(_Np) + _Np...,
+   7 * sizeof...(_Np) + _Np...,
+   _Extra...> type;
+};
+
+template struct __parity;
+template struct __make : __parity<_Np % 8>::template __pmake<_Np> 
{};
+
+template<> struct __make<0> { typedef __integer_sequence type; };
+template<> struct __make<1> { typedef __integer_sequence type; };
+template<> struct __make<2> { typedef __integer_sequence type; };
+template<> struct __make<3> { typedef __integer_sequence 
type; };
+template<> struct __make<4> { typedef __integer_sequence 
type; };
+template<> struct __make<5> { typedef __integer_sequence type; };
+template<> struct __make<6> { typedef __integer_sequence type; };
+template<> struct __make<7> { typedef __integer_sequence type; };
+
+template<> struct __parity<0> { template struct __pmake : 
__repeat::type> {}; };
+template<> struct __parity<1> { template struct __pmake : 
__repeat::type, _Np - 1> {}; };
+template<> struct __parity<2> { template struct __pmake : 
__repeat::type, _Np - 2, _Np - 1> {}; };
+template<> struct __parity<3> { template struct __pmake : 
__repeat::type, _Np - 3, _Np - 2, _Np - 1> {}; };
+template<> struct __parity<4> { template struct __pmake : 
__repeat::type, _Np - 4, _Np - 3, _Np - 2, _Np - 1> 
{}; };
+template<> struct __parity<5> { template struct __pmake : 
__repeat::type, _Np - 5, _Np - 4, _Np - 3, _Np - 2, 
_Np - 1> {}; };
+template<> struct __parity<6> { template struct __pmake : 
__repeat::type, _Np - 6, _Np - 5, _Np - 4, _Np - 3, 
_Np - 2, _Np - 1> {}; };
+template<> struct __parity<7> { template struct __pmake : 
__repeat::type, _Np - 7, _Np - 6, _Np - 5, _Np - 4, 
_Np - 3, _Np - 2, _Np - 1> {}; };
+
+} // namespace detail
+
+#endif  // !__has_builtin(__make_integer_seq) || 
defined(_LIBCPP_TESTING_FALLBACK_MAKE_INTEGER_SEQUENCE)
+
+#if __has_builtin(__make_integer_seq)
+template 
+using __make_indices_imp =
+typename __make_integer_seq<__integer_sequence, size_t, _Ep - 
_Sp>::template
+__to_tuple_indices<_Sp>;
+#else
+template 
+using __make_indices_imp =
+typename __detail::__make<_Ep - _Sp>::type::template 
__to_tuple_indices<_Sp>;
+
+#endif
+
+template 
+struct __make_tuple_indices
+{
+static_assert(_Sp <= _Ep, "__make_tuple_indices input error");
+typedef __make_indices_imp<_Ep, _Sp> type;
+};
+
+
 template  class _LIBCPP_TYPE_VIS_ONLY tuple;
 
 template  struct __tuple_like > : true_type {};
@@ -149,31 +223,6 @@ get(const array<_Tp, _Size>&&) _NOEXCEPT
 
 #if 

Re: r264008 - [sema] [CUDA] Use std algorithms in EraseUnwantedCUDAMatchesImpl.

2016-06-30 Thread Justin Lebar via cfe-commits
I think this code is accidentally OK, because the list of overloads
that callers pass in in should have at most two elements.  A given
overload set may have both a __host__ and a __device__ function, or
alternatively it may have a __host__ __device__ function, but you
can't have all three.

There is, however, a substantial gap in our testing, which I
accidentally created when I refactored a test, which causes us never
to call this function with even two overload candidates during tests.
So I'm fixing that, and I'll also fix the function to call the correct
erase() so that it does the right thing in general.

Thanks again.

On Thu, Jun 30, 2016 at 1:43 PM, Justin Lebar  wrote:
> Interestingly all the clang tests pass with that whole line commented
> out.  So something *really* seems missing here.
>
> Thank you for finding this.
>
> On Thu, Jun 30, 2016 at 5:08 AM, Benjamin Kramer  wrote:
>> On Tue, Mar 22, 2016 at 1:09 AM, Justin Lebar via cfe-commits
>>  wrote:
>>> Author: jlebar
>>> Date: Mon Mar 21 19:09:25 2016
>>> New Revision: 264008
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=264008=rev
>>> Log:
>>> [sema] [CUDA] Use std algorithms in EraseUnwantedCUDAMatchesImpl.
>>>
>>> Summary: NFC
>>>
>>> Reviewers: tra
>>>
>>> Subscribers: cfe-commits
>>>
>>> Differential Revision: http://reviews.llvm.org/D18327
>>>
>>> Modified:
>>> cfe/trunk/lib/Sema/SemaCUDA.cpp
>>>
>>> Modified: cfe/trunk/lib/Sema/SemaCUDA.cpp
>>> URL: 
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaCUDA.cpp?rev=264008=264007=264008=diff
>>> ==
>>> --- cfe/trunk/lib/Sema/SemaCUDA.cpp (original)
>>> +++ cfe/trunk/lib/Sema/SemaCUDA.cpp Mon Mar 21 19:09:25 2016
>>> @@ -210,31 +210,28 @@ bool Sema::CheckCUDATarget(const Functio
>>>return false;
>>>  }
>>>
>>> -template 
>>> -static void EraseUnwantedCUDAMatchesImpl(Sema , const FunctionDecl 
>>> *Caller,
>>> - llvm::SmallVectorImpl ,
>>> - FetchDeclFn FetchDecl) {
>>> +template 
>>> +static void EraseUnwantedCUDAMatchesImpl(
>>> +Sema , const FunctionDecl *Caller, llvm::SmallVectorImpl ,
>>> +std::function FetchDecl) {
>>>assert(S.getLangOpts().CUDATargetOverloads &&
>>>   "Should not be called w/o enabled target overloads.");
>>>if (Matches.size() <= 1)
>>>  return;
>>>
>>> +  // Gets the CUDA function preference for a call from Caller to Match.
>>> +  auto GetCFP = [&](const T ) {
>>> +return S.IdentifyCUDAPreference(Caller, FetchDecl(Match));
>>> +  };
>>> +
>>>// Find the best call preference among the functions in Matches.
>>> -  Sema::CUDAFunctionPreference P, BestCFP = Sema::CFP_Never;
>>> -  for (auto const  : Matches) {
>>> -P = S.IdentifyCUDAPreference(Caller, FetchDecl(Match));
>>> -if (P > BestCFP)
>>> -  BestCFP = P;
>>> -  }
>>> +  Sema::CUDAFunctionPreference BestCFP = GetCFP(*std::max_element(
>>> +  Matches.begin(), Matches.end(),
>>> +  [&](const T , const T ) { return GetCFP(M1) < GetCFP(M2); }));
>>>
>>>// Erase all functions with lower priority.
>>> -  for (unsigned I = 0, N = Matches.size(); I != N;)
>>> -if (S.IdentifyCUDAPreference(Caller, FetchDecl(Matches[I])) < BestCFP) 
>>> {
>>> -  Matches[I] = Matches[--N];
>>> -  Matches.resize(N);
>>> -} else {
>>> -  ++I;
>>> -}
>>> +  Matches.erase(llvm::remove_if(
>>> +  Matches, [&](const T ) { return GetCFP(Match) < BestCFP; }));
>>
>> This is the single-element form of SmallVector::erase, so it won't
>> remove ALL functions with lower priority. I sense a lack of test case
>> here.
>>
>>>  }
>>>
>>>  void Sema::EraseUnwantedCUDAMatches(const FunctionDecl *Caller,
>>>
>>>
>>> ___
>>> 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] D20499: [Temporary, Lifetime] Add lifetime marks for temporaries

2016-06-30 Thread Tim Shen via cfe-commits
timshen updated this revision to Diff 62433.
timshen added a comment.

Done. Added a new testcase to ensure the correct behavior with exceptions 
turned on.


http://reviews.llvm.org/D20499

Files:
  lib/CodeGen/CGCleanup.cpp
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CGExpr.cpp
  lib/CodeGen/CodeGenFunction.h
  lib/CodeGen/EHScopeStack.h
  test/CodeGen/temporary-lifetime-exceptions.cpp
  test/CodeGen/temporary-lifetime.cpp
  test/CodeGenCXX/microsoft-abi-eh-cleanups.cpp

Index: test/CodeGenCXX/microsoft-abi-eh-cleanups.cpp
===
--- test/CodeGenCXX/microsoft-abi-eh-cleanups.cpp
+++ test/CodeGenCXX/microsoft-abi-eh-cleanups.cpp
@@ -1,5 +1,5 @@
-// RUN: %clang_cc1 -std=c++11 -emit-llvm %s -o - -triple=i386-pc-win32 -mconstructor-aliases -fexceptions -fcxx-exceptions -fno-rtti | FileCheck -check-prefix WIN32 %s
-// RUN: %clang_cc1 -std=c++11 -emit-llvm -O3 -disable-llvm-optzns %s -o - -triple=i386-pc-win32 -mconstructor-aliases -fexceptions -fcxx-exceptions -fno-rtti | FileCheck -check-prefix WIN32 -check-prefix WIN32-LIFETIME %s
+// RUN: %clang_cc1 -std=c++11 -emit-llvm %s -o - -triple=i386-pc-win32 -mconstructor-aliases -fexceptions -fcxx-exceptions -fno-rtti | FileCheck -check-prefix WIN32 -check-prefix WIN32-O0 %s
+// RUN: %clang_cc1 -std=c++11 -emit-llvm -O3 -disable-llvm-optzns %s -o - -triple=i386-pc-win32 -mconstructor-aliases -fexceptions -fcxx-exceptions -fno-rtti | FileCheck -check-prefix WIN32 -check-prefix WIN32-O3 -check-prefix WIN32-LIFETIME %s
 
 struct A {
   A();
@@ -95,40 +95,78 @@
   return (cond ? TakesTwo((TakeRef(A()), A()), (TakeRef(A()), A())) : CouldThrow());
 }
 
-// WIN32-LABEL: define i32 @"\01?HasConditionalDeactivatedCleanups@@YAH_N@Z"{{.*}} {
-// WIN32:   alloca i1
-// WIN32:   %[[arg1_cond:.*]] = alloca i1
+// WIN32-O0-LABEL: define i32 @"\01?HasConditionalDeactivatedCleanups@@YAH_N@Z"{{.*}} {
+// WIN32-O0:   alloca i1
+// WIN32-O0:   %[[arg1_cond:.*]] = alloca i1
 //Start all four cleanups as deactivated.
-// WIN32:   store i1 false
-// WIN32:   store i1 false
-// WIN32:   store i1 false
-// WIN32:   store i1 false
-// WIN32:   br i1
+// WIN32-O0:   store i1 false
+// WIN32-O0:   store i1 false
+// WIN32-O0:   store i1 false
+// WIN32-O0:   store i1 false
+// WIN32-O0:   br i1
 //True condition.
-// WIN32:   call x86_thiscallcc %struct.A* @"\01??0A@@QAE@XZ"
-// WIN32:   store i1 true
-// WIN32:   invoke void @"\01?TakeRef@@YAXABUA@@@Z"
-// WIN32:   invoke x86_thiscallcc %struct.A* @"\01??0A@@QAE@XZ"
-// WIN32:   store i1 true, i1* %[[arg1_cond]]
-// WIN32:   invoke x86_thiscallcc %struct.A* @"\01??0A@@QAE@XZ"
-// WIN32:   store i1 true
-// WIN32:   invoke void @"\01?TakeRef@@YAXABUA@@@Z"
-// WIN32:   invoke x86_thiscallcc %struct.A* @"\01??0A@@QAE@XZ"
-// WIN32:   store i1 true
-// WIN32:   store i1 false, i1* %[[arg1_cond]]
-// WIN32:   invoke i32 @"\01?TakesTwo@@YAHUA@@0@Z"
+// WIN32-O0:   call x86_thiscallcc %struct.A* @"\01??0A@@QAE@XZ"
+// WIN32-O0:   store i1 true
+// WIN32-O0:   invoke void @"\01?TakeRef@@YAXABUA@@@Z"
+// WIN32-O0:   invoke x86_thiscallcc %struct.A* @"\01??0A@@QAE@XZ"
+// WIN32-O0:   store i1 true, i1* %[[arg1_cond]]
+// WIN32-O0:   invoke x86_thiscallcc %struct.A* @"\01??0A@@QAE@XZ"
+// WIN32-O0:   store i1 true
+// WIN32-O0:   invoke void @"\01?TakeRef@@YAXABUA@@@Z"
+// WIN32-O0:   invoke x86_thiscallcc %struct.A* @"\01??0A@@QAE@XZ"
+// WIN32-O0:   store i1 true
+// WIN32-O0:   store i1 false, i1* %[[arg1_cond]]
+// WIN32-O0:   invoke i32 @"\01?TakesTwo@@YAHUA@@0@Z"
 //False condition.
-// WIN32:   invoke i32 @"\01?CouldThrow@@YAHXZ"()
+// WIN32-O0:   invoke i32 @"\01?CouldThrow@@YAHXZ"()
 //Two normal cleanups for TakeRef args.
-// WIN32:   call x86_thiscallcc void @"\01??1A@@QAE@XZ"({{.*}})
-// WIN32-NOT:   invoke x86_thiscallcc void @"\01??1A@@QAE@XZ"
-// WIN32:   ret i32
+// WIN32-O0:   call x86_thiscallcc void @"\01??1A@@QAE@XZ"({{.*}})
+// WIN32-O0-NOT:   invoke x86_thiscallcc void @"\01??1A@@QAE@XZ"
+// WIN32-O0:   ret i32
 //
 //Somewhere in the landing pad soup, we conditionally destroy arg1.
-// WIN32:   %[[isactive:.*]] = load i1, i1* %[[arg1_cond]]
-// WIN32:   br i1 %[[isactive]]
-// WIN32:   call x86_thiscallcc void @"\01??1A@@QAE@XZ"({{.*}})
-// WIN32: }
+// WIN32-O0:   %[[isactive:.*]] = load i1, i1* %[[arg1_cond]]
+// WIN32-O0:   br i1 %[[isactive]]
+// WIN32-O0:   call x86_thiscallcc void @"\01??1A@@QAE@XZ"({{.*}})
+// WIN32-O0: }
+
+// WIN32-O3-LABEL: define i32 @"\01?HasConditionalDeactivatedCleanups@@YAH_N@Z"{{.*}} {
+// WIN32-O3:   alloca i1
+// WIN32-O3:   alloca i1
+// WIN32-O3:   %[[arg1_cond:.*]] = alloca i1
+//Start all four cleanups as deactivated.
+// WIN32-O3:   store i1 false
+// WIN32-O3:   store i1 false
+// WIN32-O3:   store i1 false
+// WIN32-O3:   store i1 false
+// WIN32-O3:   store i1 false
+// WIN32-O3:   store i1 false
+// WIN32-O3:   br i1
+//True condition.
+// WIN32-O3:   call x86_thiscallcc 

[libcxx] r274285 - Fix static assert problem on gcc; remove XFAILs that I put in in r274250

2016-06-30 Thread Marshall Clow via cfe-commits
Author: marshall
Date: Thu Jun 30 17:05:45 2016
New Revision: 274285

URL: http://llvm.org/viewvc/llvm-project?rev=274285=rev
Log:
Fix static assert problem on gcc; remove XFAILs that I put in in r274250

Modified:
libcxx/trunk/include/__hash_table
libcxx/trunk/include/__tree
libcxx/trunk/test/std/containers/associative/map/incomplete_type.pass.cpp

libcxx/trunk/test/std/containers/associative/map/map.cons/default_recursive.pass.cpp

libcxx/trunk/test/std/containers/associative/multimap/incomplete_type.pass.cpp

libcxx/trunk/test/std/containers/associative/multimap/multimap.cons/default_recursive.pass.cpp
libcxx/trunk/test/std/containers/unord/unord.map/incomplete_type.pass.cpp
libcxx/trunk/test/std/containers/unord/unord.multimap/incomplete.pass.cpp

Modified: libcxx/trunk/include/__hash_table
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__hash_table?rev=274285=274284=274285=diff
==
--- libcxx/trunk/include/__hash_table (original)
+++ libcxx/trunk/include/__hash_table Thu Jun 30 17:05:45 2016
@@ -938,10 +938,6 @@ private:
 typedef allocator_traits<__node_base_allocator> __node_base_traits;
 static_assert((is_same<__node_base_pointer, typename 
__node_base_traits::pointer>::value),
  "Allocator does not rebind pointers in a sane manner.");
-static_assert((is_copy_constructible::value),
- "Predicate must be copy-constructible.");
-static_assert((is_copy_constructible::value),
- "Hasher must be copy-constructible.");
 
 private:
 
@@ -1479,6 +1475,10 @@ __hash_table<_Tp, _Hash, _Equal, _Alloc>
 template 
 __hash_table<_Tp, _Hash, _Equal, _Alloc>::~__hash_table()
 {
+static_assert((is_copy_constructible::value),
+ "Predicate must be copy-constructible.");
+static_assert((is_copy_constructible::value),
+ "Hasher must be copy-constructible.");
 __deallocate(__p1_.first().__next_);
 #if _LIBCPP_DEBUG_LEVEL >= 2
 __get_db()->__erase_c(this);

Modified: libcxx/trunk/include/__tree
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__tree?rev=274285=274284=274285=diff
==
--- libcxx/trunk/include/__tree (original)
+++ libcxx/trunk/include/__tree Thu Jun 30 17:05:45 2016
@@ -946,8 +946,6 @@ private:
 typedef allocator_traits<__node_base_allocator> __node_base_traits;
 static_assert((is_same<__node_base_pointer, typename 
__node_base_traits::pointer>::value),
  "Allocator does not rebind pointers in a sane manner.");
-static_assert((is_copy_constructible::value),
- "Comparator must be copy-constructible.");
 
 private:
 __node_pointer __begin_node_;
@@ -1707,6 +1705,8 @@ __tree<_Tp, _Compare, _Allocator>::opera
 template 
 __tree<_Tp, _Compare, _Allocator>::~__tree()
 {
+static_assert((is_copy_constructible::value),
+ "Comparator must be copy-constructible.");
 destroy(__root());
 }
 

Modified: 
libcxx/trunk/test/std/containers/associative/map/incomplete_type.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/containers/associative/map/incomplete_type.pass.cpp?rev=274285=274284=274285=diff
==
--- libcxx/trunk/test/std/containers/associative/map/incomplete_type.pass.cpp 
(original)
+++ libcxx/trunk/test/std/containers/associative/map/incomplete_type.pass.cpp 
Thu Jun 30 17:05:45 2016
@@ -12,8 +12,6 @@
 // Check that std::map and it's iterators can be instantiated with an 
incomplete
 // type.
 
-// XFAIL: gcc
-
 #include 
 
 struct A {

Modified: 
libcxx/trunk/test/std/containers/associative/map/map.cons/default_recursive.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/containers/associative/map/map.cons/default_recursive.pass.cpp?rev=274285=274284=274285=diff
==
--- 
libcxx/trunk/test/std/containers/associative/map/map.cons/default_recursive.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/containers/associative/map/map.cons/default_recursive.pass.cpp
 Thu Jun 30 17:05:45 2016
@@ -13,8 +13,6 @@
 
 // map();
 
-// XFAIL: gcc
-
 #include 
 
 struct X

Modified: 
libcxx/trunk/test/std/containers/associative/multimap/incomplete_type.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/containers/associative/multimap/incomplete_type.pass.cpp?rev=274285=274284=274285=diff
==
--- 
libcxx/trunk/test/std/containers/associative/multimap/incomplete_type.pass.cpp 
(original)
+++ 
libcxx/trunk/test/std/containers/associative/multimap/incomplete_type.pass.cpp 
Thu Jun 30 17:05:45 2016
@@ -12,8 +12,6 @@
 // Check 

[libcxx] r274274 - Fix C++03 build.

2016-06-30 Thread Eric Fiselier via cfe-commits
Author: ericwf
Date: Thu Jun 30 15:46:58 2016
New Revision: 274274

URL: http://llvm.org/viewvc/llvm-project?rev=274274=rev
Log:
Fix C++03 build.

Modified:

libcxx/trunk/test/std/containers/unord/unord.map/unord.map.cnstr/compare_copy_constructible.fail.cpp

libcxx/trunk/test/std/containers/unord/unord.map/unord.map.cnstr/hash_copy_constructible.fail.cpp

libcxx/trunk/test/std/containers/unord/unord.multimap/unord.multimap.cnstr/compare_copy_constructible.fail.cpp

libcxx/trunk/test/std/containers/unord/unord.multimap/unord.multimap.cnstr/hash_copy_constructible.fail.cpp
libcxx/trunk/test/std/thread/futures/futures.overview/future_errc.pass.cpp

Modified: 
libcxx/trunk/test/std/containers/unord/unord.map/unord.map.cnstr/compare_copy_constructible.fail.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/containers/unord/unord.map/unord.map.cnstr/compare_copy_constructible.fail.cpp?rev=274274=274273=274274=diff
==
--- 
libcxx/trunk/test/std/containers/unord/unord.map/unord.map.cnstr/compare_copy_constructible.fail.cpp
 (original)
+++ 
libcxx/trunk/test/std/containers/unord/unord.map/unord.map.cnstr/compare_copy_constructible.fail.cpp
 Thu Jun 30 15:46:58 2016
@@ -7,6 +7,9 @@
 //
 
//===--===//
 
+// UNSUPPORTED: c++98, c++03
+// The test requires access control SFINAE.
+
 // 
 
 // Check that std::unordered_map fails to instantiate if the comparison 
predicate is 

Modified: 
libcxx/trunk/test/std/containers/unord/unord.map/unord.map.cnstr/hash_copy_constructible.fail.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/containers/unord/unord.map/unord.map.cnstr/hash_copy_constructible.fail.cpp?rev=274274=274273=274274=diff
==
--- 
libcxx/trunk/test/std/containers/unord/unord.map/unord.map.cnstr/hash_copy_constructible.fail.cpp
 (original)
+++ 
libcxx/trunk/test/std/containers/unord/unord.map/unord.map.cnstr/hash_copy_constructible.fail.cpp
 Thu Jun 30 15:46:58 2016
@@ -7,6 +7,9 @@
 //
 
//===--===//
 
+// UNSUPPORTED: c++98, c++03
+// The test requires access control SFINAE.
+
 // 
 
 // Check that std::unordered_map fails to instantiate if the hash function is 
@@ -21,7 +24,7 @@ struct Hash {
Hash () {}
 private:
Hash (const Hash &); // declared but not defined
-   };
+};
 
 
 int main() {

Modified: 
libcxx/trunk/test/std/containers/unord/unord.multimap/unord.multimap.cnstr/compare_copy_constructible.fail.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/containers/unord/unord.multimap/unord.multimap.cnstr/compare_copy_constructible.fail.cpp?rev=274274=274273=274274=diff
==
--- 
libcxx/trunk/test/std/containers/unord/unord.multimap/unord.multimap.cnstr/compare_copy_constructible.fail.cpp
 (original)
+++ 
libcxx/trunk/test/std/containers/unord/unord.multimap/unord.multimap.cnstr/compare_copy_constructible.fail.cpp
 Thu Jun 30 15:46:58 2016
@@ -7,6 +7,9 @@
 //
 
//===--===//
 
+// UNSUPPORTED: c++98, c++03
+// The test requires access control SFINAE.
+
 // 
 
 // Check that std::unordered_multimap fails to instantiate if the comparison 
predicate is 

Modified: 
libcxx/trunk/test/std/containers/unord/unord.multimap/unord.multimap.cnstr/hash_copy_constructible.fail.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/containers/unord/unord.multimap/unord.multimap.cnstr/hash_copy_constructible.fail.cpp?rev=274274=274273=274274=diff
==
--- 
libcxx/trunk/test/std/containers/unord/unord.multimap/unord.multimap.cnstr/hash_copy_constructible.fail.cpp
 (original)
+++ 
libcxx/trunk/test/std/containers/unord/unord.multimap/unord.multimap.cnstr/hash_copy_constructible.fail.cpp
 Thu Jun 30 15:46:58 2016
@@ -7,6 +7,9 @@
 //
 
//===--===//
 
+// UNSUPPORTED: c++98, c++03
+// The test requires access control SFINAE.
+
 // 
 
 // Check that std::unordered_multimap fails to instantiate if the hash 
function is 

Modified: 
libcxx/trunk/test/std/thread/futures/futures.overview/future_errc.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/thread/futures/futures.overview/future_errc.pass.cpp?rev=274274=274273=274274=diff
==
--- libcxx/trunk/test/std/thread/futures/futures.overview/future_errc.pass.cpp 
(original)
+++ libcxx/trunk/test/std/thread/futures/futures.overview/future_errc.pass.cpp 
Thu Jun 30 15:46:58 2016
@@ -9,6 +9,9 @@
 //
 // UNSUPPORTED: 

Re: r274257 - Don't instantiate a full host toolchain in ASTMatchersTest.

2016-06-30 Thread Justin Lebar via cfe-commits
Thank you, fix in r274269.

On Thu, Jun 30, 2016 at 12:57 PM, Yaron Keren  wrote:
> Seems this commit broke a builder,
> http://bb.pgr.jp/builders/ninja-x64-msvc-RA-centos6
>
> http://bb.pgr.jp/builders/ninja-x64-msvc-RA-centos6/builds/26133
> http://bb.pgr.jp/builders/ninja-x64-msvc-RA-centos6/builds/26134
>
>  TEST 'Clang-Unit ::
> ASTMatchers/ASTMatchersTests/DeclarationMatcher.MatchClass' FAILED
> 
> Note: Google Test filter = DeclarationMatcher.MatchClass
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 1 test from DeclarationMatcher
> [ RUN  ] DeclarationMatcher.MatchClass
> /home/bb/ninja-x64-msvc-RA-centos6/llvm-project/clang/unittests/ASTMatchers/ASTMatchersNodeTest.cpp:91:
> Failure
> Value of: matches("", ClassMatcher)
>   Actual: false (Could not find match in "")
> Expected: true
> [  FAILED  ] DeclarationMatcher.MatchClass (20 ms)
> [--] 1 test from DeclarationMatcher (20 ms total)
>
> [--] Global test environment tear-down
> [==] 1 test from 1 test case ran. (20 ms total)
> [  PASSED  ] 0 tests.
> [  FAILED  ] 1 test, listed below:
> [  FAILED  ] DeclarationMatcher.MatchClass
>
>  1 FAILED TEST
>
> 
>
>
>
> 2016-06-30 21:12 GMT+03:00 Justin Lebar via cfe-commits
> :
>>
>> Author: jlebar
>> Date: Thu Jun 30 13:12:25 2016
>> New Revision: 274257
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=274257=rev
>> Log:
>> Don't instantiate a full host toolchain in ASTMatchersTest.
>>
>> Summary:
>> This test was stat()'ing large swaths of /usr/lib hundreds of times, as
>> every invocation of matchesConditionally*() created a new Linux
>> toolchain.
>>
>> In addition to being slow, perf indicated this was causing substantial
>> contention in the kernel.
>>
>> Something is...interesting in the kernel, as without this patch I
>> sometimes see ~11m spent in the kernel, and sometimes ~5m.  This
>> corresponds to bimodal ninja check-clang times of ~30s and ~20s.
>>
>> It's not clear to me exactly what causes the bimodality.  In any case,
>> this change makes this test run in 2.5s, down from 17s, and it seems to
>> cause us to get the 20s ninja check-clang time unconditionally.
>>
>> Reviewers: chandlerc
>>
>> Subscribers: cfe-commits, klimek
>>
>> Differential Revision: http://reviews.llvm.org/D21810
>>
>> Modified:
>> cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.h
>>
>> Modified: cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.h?rev=274257=274256=274257=diff
>>
>> ==
>> --- cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.h (original)
>> +++ cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.h Thu Jun 30 13:12:25
>> 2016
>> @@ -73,12 +73,16 @@ testing::AssertionResult matchesConditio
>>  return testing::AssertionFailure() << "Could not add dynamic
>> matcher";
>>std::unique_ptr Factory(
>>newFrontendActionFactory());
>> -  // Some tests use typeof, which is a gnu extension.
>> -  std::vector Args;
>> -  Args.push_back(CompileArg);
>> -  // Some tests need rtti/exceptions on
>> -  Args.push_back("-frtti");
>> -  Args.push_back("-fexceptions");
>> +  // Some tests need rtti/exceptions on.  Use an unknown-unknown triple
>> so we
>> +  // don't instantiate the full system toolchain.  On Linux,
>> instantiating the
>> +  // toolchain involves stat'ing large portions of /usr/lib, and this
>> slows down
>> +  // not only this test, but all other tests, via contention in the
>> kernel.
>> +  //
>> +  // FIXME: This is a hack to work around the fact that there's no way to
>> do the
>> +  // equivalent of runToolOnCodeWithArgs without instantiating a full
>> Driver.
>> +  // We should consider having a function, at least for tests, that
>> invokes cc1.
>> +  std::vector Args = {CompileArg, "-frtti", "-fexceptions",
>> +   "-target", "i386-unknown-unknown"};
>>if (!runToolOnCodeWithArgs(
>>Factory->create(), Code, Args, Filename, "clang-tool",
>>std::make_shared(),
>> VirtualMappedFiles)) {
>> @@ -180,13 +184,12 @@ testing::AssertionResult matchesConditio
>>  return testing::AssertionFailure() << "Could not add dynamic
>> matcher";
>>std::unique_ptr Factory(
>>newFrontendActionFactory());
>> -  // Some tests use typeof, which is a gnu extension.
>> -  std::vector Args;
>> -  Args.push_back("-xcuda");
>> -  Args.push_back("-fno-ms-extensions");
>> -  Args.push_back("--cuda-host-only");
>> -  Args.push_back("-nocudainc");
>> -  Args.push_back(CompileArg);
>> +  // Some tests use typeof, which is a gnu extension.  Using an explicit
>> +  // unknown-unknown triple is good for a large speedup, because it lets
>> us
>> +  // avoid constructing a full system 

Re: [PATCH] D21619: [Sema] Implement C++14's DR1579: Prefer moving id-expression out of functions

2016-06-30 Thread Richard Smith via cfe-commits
rsmith accepted this revision.
rsmith added a comment.
This revision is now accepted and ready to land.

LGTM, thank you!


http://reviews.llvm.org/D21619



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


Re: [PATCH] D21867: [CUDA] Add utility functions for dealing with CUDA versions / architectures.

2016-06-30 Thread Justin Lebar via cfe-commits
jlebar marked 4 inline comments as done.
jlebar added a comment.

http://reviews.llvm.org/D21867



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


Re: [PATCH] D21867: [CUDA] Add utility functions for dealing with CUDA versions / architectures.

2016-06-30 Thread Justin Lebar via cfe-commits
jlebar updated this revision to Diff 62409.
jlebar added a comment.

Address Art's review.


http://reviews.llvm.org/D21867

Files:
  include/clang/Basic/Cuda.h
  include/clang/Driver/Action.h
  lib/Basic/CMakeLists.txt
  lib/Basic/Cuda.cpp
  lib/Basic/Targets.cpp
  lib/Driver/Action.cpp
  lib/Driver/Driver.cpp
  lib/Driver/Tools.cpp

Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -11213,9 +11213,10 @@
 auto* A = cast(II.getAction());
 // We need to pass an Arch of the form "sm_XX" for cubin files and
 // "compute_XX" for ptx.
-const char *Arch = (II.getType() == types::TY_PP_Asm)
-   ? A->getComputeArchName()
-   : A->getGpuArchName();
+const char *Arch =
+(II.getType() == types::TY_PP_Asm)
+? CudaVirtualArchToString(VirtualArchForCudaArch(A->getGpuArch()))
+: CudaArchToString(A->getGpuArch());
 CmdArgs.push_back(Args.MakeArgString(llvm::Twine("--image=profile=") +
  Arch + ",file=" + II.getFilename()));
   }
Index: lib/Driver/Driver.cpp
===
--- lib/Driver/Driver.cpp
+++ lib/Driver/Driver.cpp
@@ -23,6 +23,7 @@
 #include "clang/Driver/ToolChain.h"
 #include "llvm/ADT/ArrayRef.h"
 #include "llvm/ADT/STLExtras.h"
+#include "llvm/ADT/SmallSet.h"
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/StringSet.h"
 #include "llvm/ADT/StringSwitch.h"
@@ -1022,9 +1023,10 @@
 os << '"' << BIA->getArchName() << '"' << ", {"
<< PrintActions1(C, *BIA->input_begin(), Ids) << "}";
   } else if (CudaDeviceAction *CDA = dyn_cast(A)) {
-os << '"'
-   << (CDA->getGpuArchName() ? CDA->getGpuArchName() : "(multiple archs)")
-   << '"' << ", {" << PrintActions1(C, *CDA->input_begin(), Ids) << "}";
+CudaArch Arch = CDA->getGpuArch();
+if (Arch != CudaArch::UNKNOWN)
+  os << "'" << CudaArchToString(Arch) << "', ";
+os << "{" << PrintActions1(C, *CDA->input_begin(), Ids) << "}";
   } else {
 const ActionList *AL;
 if (CudaHostAction *CHA = dyn_cast(A)) {
@@ -1380,24 +1382,25 @@
 return C.MakeAction(HostAction, ActionList());
 
   // Collect all cuda_gpu_arch parameters, removing duplicates.
-  SmallVector GpuArchList;
-  llvm::StringSet<> GpuArchNames;
+  SmallVector GpuArchList;
+  llvm::SmallSet GpuArchs;
   for (Arg *A : Args) {
 if (!A->getOption().matches(options::OPT_cuda_gpu_arch_EQ))
   continue;
 A->claim();
 
-const auto& Arch = A->getValue();
-if (!CudaDeviceAction::IsValidGpuArchName(Arch))
-  C.getDriver().Diag(clang::diag::err_drv_cuda_bad_gpu_arch) << Arch;
-else if (GpuArchNames.insert(Arch).second)
+const auto  = A->getValue();
+CudaArch Arch = StringToCudaArch(ArchStr);
+if (Arch == CudaArch::UNKNOWN)
+  C.getDriver().Diag(clang::diag::err_drv_cuda_bad_gpu_arch) << ArchStr;
+else if (GpuArchs.insert(Arch).second)
   GpuArchList.push_back(Arch);
   }
 
   // Default to sm_20 which is the lowest common denominator for supported GPUs.
   // sm_20 code should work correctly, if suboptimally, on all newer GPUs.
   if (GpuArchList.empty())
-GpuArchList.push_back("sm_20");
+GpuArchList.push_back(CudaArch::SM_20);
 
   // Replicate inputs for each GPU architecture.
   Driver::InputList CudaDeviceInputs;
@@ -1463,7 +1466,7 @@
   }
   auto FatbinAction = C.MakeAction(
   C.MakeAction(DeviceActions, types::TY_CUDA_FATBIN),
-  /* GpuArchName = */ nullptr,
+  CudaArch::UNKNOWN,
   /* AtTopLevel = */ false);
   // Return a new host action that incorporates original host action and all
   // device actions.
@@ -2047,8 +2050,8 @@
 // Call BuildJobsForAction() again, now with correct device parameters.
 InputInfo II = BuildJobsForAction(
 C, *CDA->input_begin(), C.getSingleOffloadToolChain(),
-CDA->getGpuArchName(), CDA->isAtTopLevel(), /*MultipleArchs=*/true,
-LinkingOutput, CachedResults);
+CudaArchToString(CDA->getGpuArch()), CDA->isAtTopLevel(),
+/*MultipleArchs=*/true, LinkingOutput, CachedResults);
 // Currently II's Action is *CDA->input_begin().  Set it to CDA instead, so
 // that one can retrieve II's GPU arch.
 II.setAction(A);
Index: lib/Driver/Action.cpp
===
--- lib/Driver/Action.cpp
+++ lib/Driver/Action.cpp
@@ -51,43 +51,11 @@
 BindArchAction::BindArchAction(Action *Input, const char *_ArchName)
 : Action(BindArchClass, Input), ArchName(_ArchName) {}
 
-// Converts CUDA GPU architecture, e.g. "sm_21", to its corresponding virtual
-// compute arch, e.g. "compute_20".  Returns null if the input arch is null or
-// doesn't match an existing arch.
-static const char* GpuArchToComputeName(const char *ArchName) {
-  if (!ArchName)
-

Re: [PATCH] D21867: [CUDA] Add utility functions for dealing with CUDA versions / architectures.

2016-06-30 Thread Artem Belevich via cfe-commits
tra added inline comments.


Comment at: lib/Driver/Driver.cpp:1026-1028
@@ -1024,4 +1025,5 @@
   } else if (CudaDeviceAction *CDA = dyn_cast(A)) {
-os << '"'
-   << (CDA->getGpuArchName() ? CDA->getGpuArchName() : "(multiple archs)")
+os << '"' << (CDA->getGpuArch() != CudaArch::UNKNOWN
+  ? CudaArchToString(CDA->getGpuArch())
+  : "(multiple archs)")
<< '"' << ", {" << PrintActions1(C, *CDA->input_begin(), Ids) << "}";

jlebar wrote:
> tra wrote:
> > jlebar wrote:
> > > tra wrote:
> > > > I think this could be collapsed to just 
> > > > CudaArchToString(CDA->getGpuArch()).
> > > > "(multiple archs)" is as informative as (and indistinguishable from) 
> > > > "unknown" here.
> > > > 
> > > > 
> > > I'm not crazy about "unknown", since it *is* actually known.  How about 
> > > we just not output anything?
> > It's a debugging output so it would be good to accurately reflect our 
> > internal state.
> > In this case if we for some reason end up with CudaArch::UNKNOWN, I'd want 
> > to know that. 
> > If we really use UNKNOWN to represent multiple archs, perhaps it needs an 
> > enum for multiple-archs.
> We really do use UNKNOWN here to represent multiple architectures.  It is 
> used for the architecture of the Action corresponding to the call to fatbin.
> 
> I think adding an enum value for multiple-archs is going to be more harmful 
> than useful, because it means that everywhere that we switch() on arch, we're 
> going to have to handle (and assert) MULTIPLE_ARCHs.
OK. No output is fine with me.


http://reviews.llvm.org/D21867



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


Re: [PATCH] D21619: [Sema] Implement C++14's DR1579: Prefer moving id-expression out of functions

2016-06-30 Thread Erik Pilkington via cfe-commits
erik.pilkington updated this revision to Diff 62405.
erik.pilkington added a comment.

This new patch addresses all of Richard's comments.


http://reviews.llvm.org/D21619

Files:
  include/clang/Sema/Initialization.h
  include/clang/Sema/Sema.h
  lib/Sema/SemaStmt.cpp
  test/CXX/drs/dr15xx.cpp
  test/SemaCXX/rval-references.cpp

Index: test/SemaCXX/rval-references.cpp
===
--- test/SemaCXX/rval-references.cpp
+++ test/SemaCXX/rval-references.cpp
@@ -72,23 +72,17 @@
 // Test the return dance. This also tests IsReturnCopyElidable.
 struct MoveOnly {
   MoveOnly();
-  MoveOnly(const MoveOnly&) = delete;	// expected-note {{candidate constructor}} \
-  // expected-note 3{{explicitly marked deleted here}}
-  MoveOnly(MoveOnly&&);	// expected-note {{candidate constructor}}
-  MoveOnly(int&&);	// expected-note {{candidate constructor}}
+  MoveOnly(const MoveOnly&) = delete;	// expected-note 3{{explicitly marked deleted here}}
 };
 
 MoveOnly gmo;
 MoveOnly returningNonEligible() {
-  int i;
   static MoveOnly mo;
   MoveOnly  = mo;
   if (0) // Copy from global can't be elided
 return gmo; // expected-error {{call to deleted constructor}}
   else if (0) // Copy from local static can't be elided
 return mo; // expected-error {{call to deleted constructor}}
-  else if (0) // Copy from reference can't be elided
+  else // Copy from reference can't be elided
 return r; // expected-error {{call to deleted constructor}}
-  else // Construction from different type can't be elided
-return i; // expected-error {{no viable conversion from returned value of type 'int' to function return type 'MoveOnly'}}
 }
Index: test/CXX/drs/dr15xx.cpp
===
--- test/CXX/drs/dr15xx.cpp
+++ test/CXX/drs/dr15xx.cpp
@@ -62,6 +62,62 @@
 
 } // std
 
+namespace dr1579 { // dr1579: 3.9
+template
+struct GenericMoveOnly {
+  GenericMoveOnly();
+  template GenericMoveOnly(const GenericMoveOnly &) = delete; // expected-note 5 {{marked deleted here}}
+  GenericMoveOnly(const int &) = delete; // expected-note 2 {{marked deleted here}}
+  template GenericMoveOnly(GenericMoveOnly &&);
+  GenericMoveOnly(int &&);
+};
+
+GenericMoveOnly DR1579_Eligible(GenericMoveOnly CharMO) {
+  int i;
+  GenericMoveOnly GMO;
+
+  if (0)
+return i;
+  else if (0)
+return GMO;
+  else if (0)
+return ((GMO));
+  else
+return CharMO;
+}
+
+GenericMoveOnly GlobalMO;
+
+GenericMoveOnly DR1579_Ineligible(int ,
+  GenericMoveOnly ) {
+  static GenericMoveOnly StaticMove;
+  extern GenericMoveOnly ExternMove;
+
+  if (0)
+return AnInt; // expected-error{{invokes a deleted function}}
+  else if (0)
+return GlobalMO; // expected-error{{invokes a deleted function}}
+  else if (0)
+return StaticMove; // expected-error{{invokes a deleted function}}
+  else if (0)
+return ExternMove; // expected-error{{invokes a deleted function}}
+  else if (0)
+return AnInt; // expected-error{{invokes a deleted function}}
+  else
+return CharMO; // expected-error{{invokes a deleted function}}
+}
+
+auto DR1579_lambda_valid = [](GenericMoveOnly mo) ->
+  GenericMoveOnly {
+  return mo;
+};
+
+auto DR1579_lambda_invalid = []() -> GenericMoveOnly {
+  static GenericMoveOnly mo;
+  return mo; // expected-error{{invokes a deleted function}}
+};
+} // end namespace dr1579
+
 namespace dr1589 {   // dr1589: 3.7 c++11
   // Ambiguous ranking of list-initialization sequences
 
Index: lib/Sema/SemaStmt.cpp
===
--- lib/Sema/SemaStmt.cpp
+++ lib/Sema/SemaStmt.cpp
@@ -2717,16 +2717,16 @@
 /// \param E The expression being returned from the function or block, or
 /// being thrown.
 ///
-/// \param AllowFunctionParameter Whether we allow function parameters to
-/// be considered NRVO candidates. C++ prohibits this for NRVO itself, but
-/// we re-use this logic to determine whether we should try to move as part of
-/// a return or throw (which does allow function parameters).
+/// \param AllowParamOrMoveConstructible Whether we allow function parameters or
+/// id-expressions that could be moved out of the function to be considered NRVO
+/// candidates. C++ prohibits these for NRVO itself, but we re-use this logic to
+/// determine whether we should try to move as part of a return or throw (which
+/// does allow function parameters).
 ///
 /// \returns The NRVO candidate variable, if the return statement may use the
 /// NRVO, or NULL if there is no such candidate.
-VarDecl *Sema::getCopyElisionCandidate(QualType ReturnType,
-   Expr *E,
-   bool AllowFunctionParameter) {
+VarDecl *Sema::getCopyElisionCandidate(QualType ReturnType, Expr *E,
+   bool AllowParamOrMoveConstructible) {
   if (!getLangOpts().CPlusPlus)
 return 

Re: r264008 - [sema] [CUDA] Use std algorithms in EraseUnwantedCUDAMatchesImpl.

2016-06-30 Thread Justin Lebar via cfe-commits
Interestingly all the clang tests pass with that whole line commented
out.  So something *really* seems missing here.

Thank you for finding this.

On Thu, Jun 30, 2016 at 5:08 AM, Benjamin Kramer  wrote:
> On Tue, Mar 22, 2016 at 1:09 AM, Justin Lebar via cfe-commits
>  wrote:
>> Author: jlebar
>> Date: Mon Mar 21 19:09:25 2016
>> New Revision: 264008
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=264008=rev
>> Log:
>> [sema] [CUDA] Use std algorithms in EraseUnwantedCUDAMatchesImpl.
>>
>> Summary: NFC
>>
>> Reviewers: tra
>>
>> Subscribers: cfe-commits
>>
>> Differential Revision: http://reviews.llvm.org/D18327
>>
>> Modified:
>> cfe/trunk/lib/Sema/SemaCUDA.cpp
>>
>> Modified: cfe/trunk/lib/Sema/SemaCUDA.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaCUDA.cpp?rev=264008=264007=264008=diff
>> ==
>> --- cfe/trunk/lib/Sema/SemaCUDA.cpp (original)
>> +++ cfe/trunk/lib/Sema/SemaCUDA.cpp Mon Mar 21 19:09:25 2016
>> @@ -210,31 +210,28 @@ bool Sema::CheckCUDATarget(const Functio
>>return false;
>>  }
>>
>> -template 
>> -static void EraseUnwantedCUDAMatchesImpl(Sema , const FunctionDecl 
>> *Caller,
>> - llvm::SmallVectorImpl ,
>> - FetchDeclFn FetchDecl) {
>> +template 
>> +static void EraseUnwantedCUDAMatchesImpl(
>> +Sema , const FunctionDecl *Caller, llvm::SmallVectorImpl ,
>> +std::function FetchDecl) {
>>assert(S.getLangOpts().CUDATargetOverloads &&
>>   "Should not be called w/o enabled target overloads.");
>>if (Matches.size() <= 1)
>>  return;
>>
>> +  // Gets the CUDA function preference for a call from Caller to Match.
>> +  auto GetCFP = [&](const T ) {
>> +return S.IdentifyCUDAPreference(Caller, FetchDecl(Match));
>> +  };
>> +
>>// Find the best call preference among the functions in Matches.
>> -  Sema::CUDAFunctionPreference P, BestCFP = Sema::CFP_Never;
>> -  for (auto const  : Matches) {
>> -P = S.IdentifyCUDAPreference(Caller, FetchDecl(Match));
>> -if (P > BestCFP)
>> -  BestCFP = P;
>> -  }
>> +  Sema::CUDAFunctionPreference BestCFP = GetCFP(*std::max_element(
>> +  Matches.begin(), Matches.end(),
>> +  [&](const T , const T ) { return GetCFP(M1) < GetCFP(M2); }));
>>
>>// Erase all functions with lower priority.
>> -  for (unsigned I = 0, N = Matches.size(); I != N;)
>> -if (S.IdentifyCUDAPreference(Caller, FetchDecl(Matches[I])) < BestCFP) {
>> -  Matches[I] = Matches[--N];
>> -  Matches.resize(N);
>> -} else {
>> -  ++I;
>> -}
>> +  Matches.erase(llvm::remove_if(
>> +  Matches, [&](const T ) { return GetCFP(Match) < BestCFP; }));
>
> This is the single-element form of SmallVector::erase, so it won't
> remove ALL functions with lower priority. I sense a lack of test case
> here.
>
>>  }
>>
>>  void Sema::EraseUnwantedCUDAMatches(const FunctionDecl *Caller,
>>
>>
>> ___
>> 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] D20499: [Temporary, Lifetime] Add lifetime marks for temporaries

2016-06-30 Thread Richard Smith via cfe-commits
rsmith added inline comments.


Comment at: lib/CodeGen/CGExpr.cpp:438
@@ -426,1 +437,3 @@
+}
 EmitAnyExprToMem(E, Object, Qualifiers(), /*IsInit*/true);
+if (Size) {

Seems like you should push the cleanup before you emit the initializer; the 
cleanup should run if the initializer throws.


http://reviews.llvm.org/D20499



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


Re: [cfe-dev] RFC: Default language standard mode policy

2016-06-30 Thread Richard Smith via cfe-commits
On Thu, Jun 30, 2016 at 2:02 AM, David Chisnall  wrote:

> On 29 Jun 2016, at 23:07, Richard Smith via cfe-dev <
> cfe-...@lists.llvm.org> wrote:
> >
> > Yes, those are real problems, but it's not reasonable for us to keep the
> default at C++98/03 forever. GCC has already taken the plunge here, so a
> lot of open-source code that doesn't work in C++11 onwards already
> explicitly specifies an appropriate -std= flag.
> >
>
> Could you clarify exactly what the issue is?  Currently, if I have some
> legacy C++98 code, the odds are that it just compiles with ${CXX}.  If I
> have new C++11 or C++14 code, then its build system likely sticks on the
> required -std= flag and it builds independent of what the compiler default
> is.
>

Why should new C++ code pay this tax to use the language that is currently
called C++, that is taught as C++, that is covered by books on C++, and so
on? C++98 is increasingly the odd one out, and it's the one where an
explicit -std= flag should be required.

What code would be broken by keeping the default at the language version
> accepted by code that didn’t know about newer standards?


Any code written for modern GCC. Any code written for modern MSVC.

As long as we’re keeping support for C++98 in the front end, keeping the
> default there doesn’t seem particularly arduous for us and will avoid
> breaking third-party code.


At some point (although probably not for at least a decade) I expect we
will want to remove C++98 support from Clang.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r274269 - Fix ASTMatchersNodeTest to work on Windows.

2016-06-30 Thread Justin Lebar via cfe-commits
Author: jlebar
Date: Thu Jun 30 15:29:29 2016
New Revision: 274269

URL: http://llvm.org/viewvc/llvm-project?rev=274269=rev
Log:
Fix ASTMatchersNodeTest to work on Windows.

It was failing because it had an explicit check for whether we're on
Windows.

There are a few other similar explicit checks in this file which I
didn't remove because they serve as reasonable documentation that the
test doesn't work with a Windows triple.

Modified:
cfe/trunk/unittests/ASTMatchers/ASTMatchersNodeTest.cpp

Modified: cfe/trunk/unittests/ASTMatchers/ASTMatchersNodeTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/ASTMatchers/ASTMatchersNodeTest.cpp?rev=274269=274268=274269=diff
==
--- cfe/trunk/unittests/ASTMatchers/ASTMatchersNodeTest.cpp (original)
+++ cfe/trunk/unittests/ASTMatchers/ASTMatchersNodeTest.cpp Thu Jun 30 15:29:29 
2016
@@ -82,13 +82,11 @@ TEST(NameableDeclaration, REMatchesVario
 
 TEST(DeclarationMatcher, MatchClass) {
   DeclarationMatcher ClassMatcher(recordDecl());
-  llvm::Triple Triple(llvm::sys::getDefaultTargetTriple());
-  if (Triple.getOS() != llvm::Triple::Win32 ||
-Triple.getEnvironment() != llvm::Triple::MSVC)
-EXPECT_FALSE(matches("", ClassMatcher));
-  else
-// Matches class type_info.
-EXPECT_TRUE(matches("", ClassMatcher));
+
+  // This passes on Windows only because we explicitly pass -target
+  // i386-unknown-unknown.  If we were to compile with the default target
+  // triple, we'd want to EXPECT_TRUE if it's Win32 or MSVC.
+  EXPECT_FALSE(matches("", ClassMatcher));
 
   DeclarationMatcher ClassX = recordDecl(recordDecl(hasName("X")));
   EXPECT_TRUE(matches("class X;", ClassX));


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


Re: [PATCH] D21867: [CUDA] Add utility functions for dealing with CUDA versions / architectures.

2016-06-30 Thread Justin Lebar via cfe-commits
jlebar marked an inline comment as done.


Comment at: lib/Driver/Driver.cpp:1026-1028
@@ -1024,4 +1025,5 @@
   } else if (CudaDeviceAction *CDA = dyn_cast(A)) {
-os << '"'
-   << (CDA->getGpuArchName() ? CDA->getGpuArchName() : "(multiple archs)")
+os << '"' << (CDA->getGpuArch() != CudaArch::UNKNOWN
+  ? CudaArchToString(CDA->getGpuArch())
+  : "(multiple archs)")
<< '"' << ", {" << PrintActions1(C, *CDA->input_begin(), Ids) << "}";

tra wrote:
> jlebar wrote:
> > tra wrote:
> > > I think this could be collapsed to just 
> > > CudaArchToString(CDA->getGpuArch()).
> > > "(multiple archs)" is as informative as (and indistinguishable from) 
> > > "unknown" here.
> > > 
> > > 
> > I'm not crazy about "unknown", since it *is* actually known.  How about we 
> > just not output anything?
> It's a debugging output so it would be good to accurately reflect our 
> internal state.
> In this case if we for some reason end up with CudaArch::UNKNOWN, I'd want to 
> know that. 
> If we really use UNKNOWN to represent multiple archs, perhaps it needs an 
> enum for multiple-archs.
We really do use UNKNOWN here to represent multiple architectures.  It is used 
for the architecture of the Action corresponding to the call to fatbin.

I think adding an enum value for multiple-archs is going to be more harmful 
than useful, because it means that everywhere that we switch() on arch, we're 
going to have to handle (and assert) MULTIPLE_ARCHs.


http://reviews.llvm.org/D21867



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


r274267 - Fix typo-correction crash if a typo occurs within the operand of a

2016-06-30 Thread Richard Smith via cfe-commits
Author: rsmith
Date: Thu Jun 30 15:24:30 2016
New Revision: 274267

URL: http://llvm.org/viewvc/llvm-project?rev=274267=rev
Log:
Fix typo-correction crash if a typo occurs within the operand of a
function-style cast to a non-dependent type which is then used in an invalid
way. We'd lose the "type dependent" bit here, and downstream Sema processing
would then discard the expression if it was used in a context where its type
rendered it invalid.

Modified:
cfe/trunk/lib/Sema/SemaExprCXX.cpp
cfe/trunk/test/Parser/cxx1z-init-statement.cpp
cfe/trunk/test/SemaCXX/return.cpp
cfe/trunk/test/SemaCXX/typo-correction-crash.cpp

Modified: cfe/trunk/lib/Sema/SemaExprCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExprCXX.cpp?rev=274267=274266=274267=diff
==
--- cfe/trunk/lib/Sema/SemaExprCXX.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExprCXX.cpp Thu Jun 30 15:24:30 2016
@@ -1222,7 +1222,14 @@ Sema::ActOnCXXTypeConstructExpr(ParsedTy
   if (!TInfo)
 TInfo = Context.getTrivialTypeSourceInfo(Ty, SourceLocation());
 
-  return BuildCXXTypeConstructExpr(TInfo, LParenLoc, exprs, RParenLoc);
+  auto Result = BuildCXXTypeConstructExpr(TInfo, LParenLoc, exprs, RParenLoc);
+  // Avoid creating a non-type-dependent expression that contains typos.
+  // Non-type-dependent expressions are liable to be discarded without
+  // checking for embedded typos.
+  if (!Result.isInvalid() && Result.get()->isInstantiationDependent() &&
+  !Result.get()->isTypeDependent())
+Result = CorrectDelayedTyposInExpr(Result.get());
+  return Result;
 }
 
 /// ActOnCXXTypeConstructExpr - Parse construction of a specified type.

Modified: cfe/trunk/test/Parser/cxx1z-init-statement.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Parser/cxx1z-init-statement.cpp?rev=274267=274266=274267=diff
==
--- cfe/trunk/test/Parser/cxx1z-init-statement.cpp (original)
+++ cfe/trunk/test/Parser/cxx1z-init-statement.cpp Thu Jun 30 15:24:30 2016
@@ -10,6 +10,7 @@ int f() {
   if (T(f()), g, h; f()) {} // expected-error {{not yet supported}}
   if (T f(); f()) {} // expected-error {{not yet supported}}
   if (T f(), g, h; f()) {} // expected-error {{not yet supported}}
+  if (T(n) = 0; n) {} // expected-error {{not yet supported}}
 
   // init-statement expressions
   if (T{f()}; f()) {} // expected-error {{not yet supported}}
@@ -20,6 +21,7 @@ int f() {
   if (T(n){g}) {}
   if (T f()) {} // expected-error {{function type}}
   if (T f(), g, h) {} // expected-error {{function type}}
+  if (T(n) = 0) {}
 
   // condition expressions
   if (T(f())) {}
@@ -27,9 +29,9 @@ int f() {
   if (T(f()), g, h) {} // expected-warning 2{{unused}}
   if (T{f()}, g, h) {} // expected-warning 2{{unused}}
 
-  // none of the above
-  // FIXME: This causes a typo-correction crash, as does "void f() { +T(n)(g); 
}"
-  //if (T(n)(g)) {} // expected-err-FIXME {{not a function}}
+  // none of the above, disambiguated as expression (can't be a declaration)
+  if (T(n)(g)) {} // expected-error {{undeclared identifier 'n'}}
+  if (T(n)(int())) {} // expected-error {{undeclared identifier 'n'}}
 
   // Likewise for 'switch'
   switch (int n; n) {} // expected-error {{not yet supported}}

Modified: cfe/trunk/test/SemaCXX/return.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/return.cpp?rev=274267=274266=274267=diff
==
--- cfe/trunk/test/SemaCXX/return.cpp (original)
+++ cfe/trunk/test/SemaCXX/return.cpp Thu Jun 30 15:24:30 2016
@@ -118,5 +118,5 @@ void cxx_unresolved_expr() {
   // CXXUnresolvedConstructExpr, and the missing ')' gives it an invalid source
   // location for its rparen.  Check that emitting a diag on the range of the
   // expr doesn't assert.
-  return int(undeclared, 4; // expected-error {{expected ')'}} 
expected-note{{to match this '('}} expected-error {{void function 
'cxx_unresolved_expr' should not return a value}} expected-error {{use of 
undeclared identifier 'undeclared'}}
+  return int(undeclared, 4; // expected-error {{expected ')'}} 
expected-note{{to match this '('}} expected-error {{use of undeclared 
identifier 'undeclared'}}
 }

Modified: cfe/trunk/test/SemaCXX/typo-correction-crash.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/typo-correction-crash.cpp?rev=274267=274266=274267=diff
==
--- cfe/trunk/test/SemaCXX/typo-correction-crash.cpp (original)
+++ cfe/trunk/test/SemaCXX/typo-correction-crash.cpp Thu Jun 30 15:24:30 2016
@@ -17,3 +17,5 @@ typedef int type;
 }
 struct FooRecord { };
 FooRecord::NestedNamespace::type x; // expected-error {{no member named 
'NestedNamespace' in 'FooRecord'; did you mean 
'BarNamespace::NestedNamespace'?}}
+
+void cast_expr(int 

Re: [PATCH] D21867: [CUDA] Add utility functions for dealing with CUDA versions / architectures.

2016-06-30 Thread Artem Belevich via cfe-commits
tra added inline comments.


Comment at: lib/Driver/Driver.cpp:1026-1028
@@ -1024,4 +1025,5 @@
   } else if (CudaDeviceAction *CDA = dyn_cast(A)) {
-os << '"'
-   << (CDA->getGpuArchName() ? CDA->getGpuArchName() : "(multiple archs)")
+os << '"' << (CDA->getGpuArch() != CudaArch::UNKNOWN
+  ? CudaArchToString(CDA->getGpuArch())
+  : "(multiple archs)")
<< '"' << ", {" << PrintActions1(C, *CDA->input_begin(), Ids) << "}";

jlebar wrote:
> tra wrote:
> > I think this could be collapsed to just CudaArchToString(CDA->getGpuArch()).
> > "(multiple archs)" is as informative as (and indistinguishable from) 
> > "unknown" here.
> > 
> > 
> I'm not crazy about "unknown", since it *is* actually known.  How about we 
> just not output anything?
It's a debugging output so it would be good to accurately reflect our internal 
state.
In this case if we for some reason end up with CudaArch::UNKNOWN, I'd want to 
know that. 
If we really use UNKNOWN to represent multiple archs, perhaps it needs an enum 
for multiple-archs.


http://reviews.llvm.org/D21867



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


Re: [PATCH] D21803: [libcxxabi] Provide a fallback __cxa_thread_atexit() implementation

2016-06-30 Thread Ben Craig via cfe-commits
bcraig added a comment.

Also, can you add test cases for a lot of these things?  I don't expect test 
cases for the DSO side of things, but a lot of the tricky atexit cases should 
be covered.


http://reviews.llvm.org/D21803



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


Re: [PATCH] D21803: [libcxxabi] Provide a fallback __cxa_thread_atexit() implementation

2016-06-30 Thread Tavian Barnes via cfe-commits
tavianator added inline comments.


Comment at: src/cxa_thread_atexit.cpp:47
@@ +46,3 @@
+  void run_dtors(void* ptr) {
+if (pthread_setspecific(dtors, ptr) != 0) {
+  abort_message("pthread_setspecific() failed during thread_local 
destruction");

bcraig wrote:
> Why are we doing this?  I can see it being a little useful when debugging / 
> developing, so that you get an early warning that something has gone wrong, 
> but it seems like this will always be setting a value to the value it already 
> has.
pthread_key destructors run after the key is set to null.  I re-set it here 
since the loop reads the key.


Comment at: src/cxa_thread_atexit.cpp:54
@@ +53,3 @@
+// __cxa_thread_atexit() is called during the loop.
+while (auto elem = static_cast(pthread_getspecific(dtors))) {
+  if (pthread_setspecific(dtors, elem->next) != 0) {

bcraig wrote:
> Maybe this concern is unfounded, but I'm not overly fond of 
> pthread_getspecific and setspecific in a loop.  I've always been under the 
> impression that those functions are rather slow.  Could we add a layer of 
> indirection so that we don't need to call getspecific and setspecific so 
> often?  Basically make the pointer that is directly stored in TLS an 
> immutable pointer to pointer.
Sure, I can do that.  Would reduce the number of setspecific() calls in 
__cxa_thread_atexit too.


http://reviews.llvm.org/D21803



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


Re: r274257 - Don't instantiate a full host toolchain in ASTMatchersTest.

2016-06-30 Thread Yaron Keren via cfe-commits
Seems this commit broke a builder,
http://bb.pgr.jp/builders/ninja-x64-msvc-RA-centos6

http://bb.pgr.jp/builders/ninja-x64-msvc-RA-centos6/builds/26133
http://bb.pgr.jp/builders/ninja-x64-msvc-RA-centos6/builds/26134

 TEST 'Clang-Unit ::
ASTMatchers/ASTMatchersTests/DeclarationMatcher.MatchClass' FAILED

Note: Google Test filter = DeclarationMatcher.MatchClass
[==] Running 1 test from 1 test case.
[--] Global test environment set-up.
[--] 1 test from DeclarationMatcher
[ RUN  ] DeclarationMatcher.MatchClass
/home/bb/ninja-x64-msvc-RA-centos6/llvm-project/clang/unittests/ASTMatchers/ASTMatchersNodeTest.cpp:91:
Failure
Value of: matches("", ClassMatcher)
  Actual: false (Could not find match in "")
Expected: true
[  FAILED  ] DeclarationMatcher.MatchClass (20 ms)
[--] 1 test from DeclarationMatcher (20 ms total)

[--] Global test environment tear-down
[==] 1 test from 1 test case ran. (20 ms total)
[  PASSED  ] 0 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] DeclarationMatcher.MatchClass

 1 FAILED TEST





2016-06-30 21:12 GMT+03:00 Justin Lebar via cfe-commits <
cfe-commits@lists.llvm.org>:

> Author: jlebar
> Date: Thu Jun 30 13:12:25 2016
> New Revision: 274257
>
> URL: http://llvm.org/viewvc/llvm-project?rev=274257=rev
> Log:
> Don't instantiate a full host toolchain in ASTMatchersTest.
>
> Summary:
> This test was stat()'ing large swaths of /usr/lib hundreds of times, as
> every invocation of matchesConditionally*() created a new Linux
> toolchain.
>
> In addition to being slow, perf indicated this was causing substantial
> contention in the kernel.
>
> Something is...interesting in the kernel, as without this patch I
> sometimes see ~11m spent in the kernel, and sometimes ~5m.  This
> corresponds to bimodal ninja check-clang times of ~30s and ~20s.
>
> It's not clear to me exactly what causes the bimodality.  In any case,
> this change makes this test run in 2.5s, down from 17s, and it seems to
> cause us to get the 20s ninja check-clang time unconditionally.
>
> Reviewers: chandlerc
>
> Subscribers: cfe-commits, klimek
>
> Differential Revision: http://reviews.llvm.org/D21810
>
> Modified:
> cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.h
>
> Modified: cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.h?rev=274257=274256=274257=diff
>
> ==
> --- cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.h (original)
> +++ cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.h Thu Jun 30 13:12:25
> 2016
> @@ -73,12 +73,16 @@ testing::AssertionResult matchesConditio
>  return testing::AssertionFailure() << "Could not add dynamic matcher";
>std::unique_ptr Factory(
>newFrontendActionFactory());
> -  // Some tests use typeof, which is a gnu extension.
> -  std::vector Args;
> -  Args.push_back(CompileArg);
> -  // Some tests need rtti/exceptions on
> -  Args.push_back("-frtti");
> -  Args.push_back("-fexceptions");
> +  // Some tests need rtti/exceptions on.  Use an unknown-unknown triple
> so we
> +  // don't instantiate the full system toolchain.  On Linux,
> instantiating the
> +  // toolchain involves stat'ing large portions of /usr/lib, and this
> slows down
> +  // not only this test, but all other tests, via contention in the
> kernel.
> +  //
> +  // FIXME: This is a hack to work around the fact that there's no way to
> do the
> +  // equivalent of runToolOnCodeWithArgs without instantiating a full
> Driver.
> +  // We should consider having a function, at least for tests, that
> invokes cc1.
> +  std::vector Args = {CompileArg, "-frtti", "-fexceptions",
> +   "-target", "i386-unknown-unknown"};
>if (!runToolOnCodeWithArgs(
>Factory->create(), Code, Args, Filename, "clang-tool",
>std::make_shared(),
> VirtualMappedFiles)) {
> @@ -180,13 +184,12 @@ testing::AssertionResult matchesConditio
>  return testing::AssertionFailure() << "Could not add dynamic matcher";
>std::unique_ptr Factory(
>newFrontendActionFactory());
> -  // Some tests use typeof, which is a gnu extension.
> -  std::vector Args;
> -  Args.push_back("-xcuda");
> -  Args.push_back("-fno-ms-extensions");
> -  Args.push_back("--cuda-host-only");
> -  Args.push_back("-nocudainc");
> -  Args.push_back(CompileArg);
> +  // Some tests use typeof, which is a gnu extension.  Using an explicit
> +  // unknown-unknown triple is good for a large speedup, because it lets
> us
> +  // avoid constructing a full system triple.
> +  std::vector Args = {
> +  "-xcuda",  "-fno-ms-extensions",  "--cuda-host-only",
> "-nocudainc",
> +  "-target", "nvptx64-unknown-unknown", CompileArg};
>if (!runToolOnCodeWithArgs(Factory->create(),
>   

Re: [PATCH] D21803: [libcxxabi] Provide a fallback __cxa_thread_atexit() implementation

2016-06-30 Thread Ben Craig via cfe-commits
bcraig added inline comments.


Comment at: src/cxa_thread_atexit.cpp:47
@@ +46,3 @@
+  void run_dtors(void* ptr) {
+if (pthread_setspecific(dtors, ptr) != 0) {
+  abort_message("pthread_setspecific() failed during thread_local 
destruction");

Why are we doing this?  I can see it being a little useful when debugging / 
developing, so that you get an early warning that something has gone wrong, but 
it seems like this will always be setting a value to the value it already has.


Comment at: src/cxa_thread_atexit.cpp:54
@@ +53,3 @@
+// __cxa_thread_atexit() is called during the loop.
+while (auto elem = static_cast(pthread_getspecific(dtors))) {
+  if (pthread_setspecific(dtors, elem->next) != 0) {

Maybe this concern is unfounded, but I'm not overly fond of pthread_getspecific 
and setspecific in a loop.  I've always been under the impression that those 
functions are rather slow.  Could we add a layer of indirection so that we 
don't need to call getspecific and setspecific so often?  Basically make the 
pointer that is directly stored in TLS an immutable pointer to pointer.


http://reviews.llvm.org/D21803



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


Re: [PATCH] D21867: [CUDA] Add utility functions for dealing with CUDA versions / architectures.

2016-06-30 Thread Justin Lebar via cfe-commits
jlebar marked an inline comment as done.


Comment at: lib/Basic/Cuda.cpp:8-19
@@ +7,14 @@
+
+const char *CudaVersionToString(CudaVersion V) {
+  switch (V) {
+  case CudaVersion::UNKNOWN:
+return "unknown";
+  case CudaVersion::CUDA_70:
+return "7.0";
+  case CudaVersion::CUDA_75:
+return "7.5";
+  case CudaVersion::CUDA_80:
+return "8.0";
+  }
+}
+

tra wrote:
> We seem to do a lot of enum->string and string->enum mapping in this file. 
> Is there something comparable to Boost.bimap in standard c++ library or in 
> LLVM?
> 
Not to my knowledge.


Comment at: lib/Driver/Driver.cpp:1026-1028
@@ -1024,4 +1025,5 @@
   } else if (CudaDeviceAction *CDA = dyn_cast(A)) {
-os << '"'
-   << (CDA->getGpuArchName() ? CDA->getGpuArchName() : "(multiple archs)")
+os << '"' << (CDA->getGpuArch() != CudaArch::UNKNOWN
+  ? CudaArchToString(CDA->getGpuArch())
+  : "(multiple archs)")
<< '"' << ", {" << PrintActions1(C, *CDA->input_begin(), Ids) << "}";

tra wrote:
> I think this could be collapsed to just CudaArchToString(CDA->getGpuArch()).
> "(multiple archs)" is as informative as (and indistinguishable from) 
> "unknown" here.
> 
> 
I'm not crazy about "unknown", since it *is* actually known.  How about we just 
not output anything?


http://reviews.llvm.org/D21867



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


Re: [PATCH] D21834: Implementing 'If statement with Initializer'

2016-06-30 Thread Richard Smith via cfe-commits
rsmith added a comment.

There are a few missing pieces here:

1. Analysis/CFG.cpp needs to be taught to build a correct CFG for these. You 
can test this with an example like 'if (bool b; b)' which should give a 
-Wuninitialized warning.
2. AST/ExprConstant.cpp needs to be taught to perform constant evaluation for 
these properly.
3. More test coverage. In addition for test cases for the above two cases, 
please also add some tests to test/CodeGenCXX to test that we emit correct code 
for the expression and declaration form of these constructs, for both `if` and 
`switch`, and add a test that checks that the extra statement round-trips 
through an AST file properly (see test/PCH for some examples).


http://reviews.llvm.org/D21834



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


Re: [PATCH] D21803: [libcxxabi] Provide a fallback __cxa_thread_atexit() implementation

2016-06-30 Thread Tavian Barnes via cfe-commits
tavianator updated this revision to Diff 62394.
tavianator added a comment.

Fix copy-pasta that result in an infinite loop.


http://reviews.llvm.org/D21803

Files:
  cmake/config-ix.cmake
  src/CMakeLists.txt
  src/cxa_thread_atexit.cpp
  test/CMakeLists.txt
  test/cxa_thread_atexit_test.pass.cpp
  test/libcxxabi/test/config.py
  test/lit.site.cfg.in

Index: test/lit.site.cfg.in
===
--- test/lit.site.cfg.in
+++ test/lit.site.cfg.in
@@ -13,7 +13,6 @@
 config.enable_32bit = "@LIBCXXABI_BUILD_32_BITS@"
 config.target_info  = "@LIBCXXABI_TARGET_INFO@"
 config.executor = "@LIBCXXABI_EXECUTOR@"
-config.thread_atexit= "@LIBCXXABI_HAS_CXA_THREAD_ATEXIT_IMPL@"
 config.libcxxabi_shared = "@LIBCXXABI_ENABLE_SHARED@"
 config.enable_shared= "@LIBCXX_ENABLE_SHARED@"
 config.enable_exceptions= "@LIBCXXABI_ENABLE_EXCEPTIONS@"
Index: test/libcxxabi/test/config.py
===
--- test/libcxxabi/test/config.py
+++ test/libcxxabi/test/config.py
@@ -37,8 +37,6 @@
 super(Configuration, self).configure_features()
 if not self.get_lit_bool('enable_exceptions', True):
 self.config.available_features.add('libcxxabi-no-exceptions')
-if self.get_lit_bool('thread_atexit', True):
-self.config.available_features.add('thread_atexit')
 
 def configure_compile_flags(self):
 self.cxx.compile_flags += ['-DLIBCXXABI_NO_TIMER']
Index: test/cxa_thread_atexit_test.pass.cpp
===
--- test/cxa_thread_atexit_test.pass.cpp
+++ test/cxa_thread_atexit_test.pass.cpp
@@ -8,7 +8,6 @@
 //===--===//
 
 // REQUIRES: linux
-// REQUIRES: thread_atexit
 
 #include 
 #include 
Index: test/CMakeLists.txt
===
--- test/CMakeLists.txt
+++ test/CMakeLists.txt
@@ -16,7 +16,6 @@
 pythonize_bool(LIBCXXABI_ENABLE_THREADS)
 pythonize_bool(LIBCXXABI_ENABLE_EXCEPTIONS)
 pythonize_bool(LIBCXXABI_USE_LLVM_UNWINDER)
-pythonize_bool(LIBCXXABI_HAS_CXA_THREAD_ATEXIT_IMPL)
 set(LIBCXXABI_TARGET_INFO "libcxx.test.target_info.LocalTI" CACHE STRING
 "TargetInfo to use when setting up test environment.")
 set(LIBCXXABI_EXECUTOR "None" CACHE STRING
Index: src/cxa_thread_atexit.cpp
===
--- src/cxa_thread_atexit.cpp
+++ src/cxa_thread_atexit.cpp
@@ -7,20 +7,137 @@
 //
 //===--===//
 
+#include "abort_message.h"
 #include "cxxabi.h"
+#include 
+#include 
 
 namespace __cxxabiv1 {
+namespace {
+  // This implementation is used if the C library does not provide
+  // __cxa_thread_atexit_impl() for us.  It has a number of limitations that are
+  // difficult to impossible to address without ..._impl():
+  //
+  // - dso_symbol is ignored.  This means that a shared library may be unloaded
+  //   (via dlclose()) before its thread_local destructors have run.
+  //
+  // - thread_local destructors for the main thread are run with __cxa_atexit().
+  //   This is later than expected; they should run before the destructors of
+  //   any objects with static storage duration.
+  //
+  // - thread_local destructors on other threads run on the first iteration
+  //   through the pthread_key destructors.  std::notify_all_at_thread_exit()
+  //   and similar functions must be careful to wait until the second iteration
+  //   to provide their indended ordering guarantees.
+
+  typedef void (*Dtor)(void*);
+
+  struct DtorList {
+Dtor dtor;
+void* obj;
+DtorList* next;
+  };
+
+  pthread_key_t dtors;
+  pthread_once_t dtors_once = PTHREAD_ONCE_INIT;
+  bool dtors_ready = false;
+  bool dtors_atexit = false;
+
+  void run_dtors(void* ptr) {
+if (pthread_setspecific(dtors, ptr) != 0) {
+  abort_message("pthread_setspecific() failed during thread_local destruction");
+}
+
+// Rather than iterate over the list directly, use the pthread_key to get
+// the head of the list every time.  This gives the correct ordering if
+// __cxa_thread_atexit() is called during the loop.
+while (auto elem = static_cast(pthread_getspecific(dtors))) {
+  if (pthread_setspecific(dtors, elem->next) != 0) {
+abort_message("pthread_setspecific() failed during thread_local destruction");
+  }
+  elem->dtor(elem->obj);
+  std::free(elem);
+}
+  }
+
+  void run_dtors_atexit(void*) {
+// Signify that we need to re-register this function if any new
+// thread_locals are created.
+dtors_atexit = false;
+
+auto ptr = pthread_getspecific(dtors);
+run_dtors(ptr);
+  }
+
+  // This is the DSO handle for libc++abi.so itself
+  extern "C" void* __dso_handle;
+
+  

r274261 - [CUDA] Give templated device functions internal linkage, templated kernels external linkage.

2016-06-30 Thread Justin Lebar via cfe-commits
Author: jlebar
Date: Thu Jun 30 13:41:33 2016
New Revision: 274261

URL: http://llvm.org/viewvc/llvm-project?rev=274261=rev
Log:
[CUDA] Give templated device functions internal linkage, templated kernels 
external linkage.

Summary:
This lets LLVM perform IPO over these functions.  In particular, it
allows LLVM to emit ld.global.nc for loads to __restrict pointers in
kernels that are never written to.

Reviewers: rsmith

Subscribers: cfe-commits, tra

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

Modified:
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/test/CodeGenCUDA/ptx-kernels.cu

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=274261=274260=274261=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Thu Jun 30 13:41:33 2016
@@ -2671,9 +2671,18 @@ llvm::GlobalValue::LinkageTypes CodeGenM
   // explicit instantiations can occur in multiple translation units
   // and must all be equivalent. However, we are not allowed to
   // throw away these explicit instantiations.
-  if (Linkage == GVA_StrongODR)
-return !Context.getLangOpts().AppleKext ? llvm::Function::WeakODRLinkage
-: llvm::Function::ExternalLinkage;
+  //
+  // We don't currently support CUDA device code spread out across multiple 
TUs,
+  // so say that CUDA templates are either external (for kernels) or internal.
+  // This lets llvm perform aggressive inter-procedural optimizations.
+  if (Linkage == GVA_StrongODR) {
+if (Context.getLangOpts().AppleKext)
+  return llvm::Function::ExternalLinkage;
+if (Context.getLangOpts().CUDA && Context.getLangOpts().CUDAIsDevice)
+  return D->hasAttr() ? llvm::Function::ExternalLinkage
+  : llvm::Function::InternalLinkage;
+return llvm::Function::WeakODRLinkage;
+  }
 
   // C++ doesn't have tentative definitions and thus cannot have common
   // linkage.

Modified: cfe/trunk/test/CodeGenCUDA/ptx-kernels.cu
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCUDA/ptx-kernels.cu?rev=274261=274260=274261=diff
==
--- cfe/trunk/test/CodeGenCUDA/ptx-kernels.cu (original)
+++ cfe/trunk/test/CodeGenCUDA/ptx-kernels.cu Thu Jun 30 13:41:33 2016
@@ -19,11 +19,11 @@ __global__ void global_function() {
 
 // Make sure host-instantiated kernels are preserved on device side.
 template  __global__ void templated_kernel(T param) {}
-// CHECK-DAG: define weak_odr void @_Z16templated_kernelIiEvT_(
+// CHECK-DAG: define void @_Z16templated_kernelIiEvT_(
 
 namespace {
 __global__ void anonymous_ns_kernel() {}
-// CHECK-DAG: define weak_odr void @_ZN12_GLOBAL__N_119anonymous_ns_kernelEv(
+// CHECK-DAG: define void @_ZN12_GLOBAL__N_119anonymous_ns_kernelEv(
 }
 
 void host_function() {


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


Re: [PATCH] D21337: [CUDA] Give templated device functions internal linkage, templated kernels external linkage.

2016-06-30 Thread Justin Lebar via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL274261: [CUDA] Give templated device functions internal 
linkage, templated kernels… (authored by jlebar).

Changed prior to commit:
  http://reviews.llvm.org/D21337?vs=60728=62391#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D21337

Files:
  cfe/trunk/lib/CodeGen/CodeGenModule.cpp
  cfe/trunk/test/CodeGenCUDA/ptx-kernels.cu

Index: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
===
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp
@@ -2671,9 +2671,18 @@
   // explicit instantiations can occur in multiple translation units
   // and must all be equivalent. However, we are not allowed to
   // throw away these explicit instantiations.
-  if (Linkage == GVA_StrongODR)
-return !Context.getLangOpts().AppleKext ? llvm::Function::WeakODRLinkage
-: llvm::Function::ExternalLinkage;
+  //
+  // We don't currently support CUDA device code spread out across multiple 
TUs,
+  // so say that CUDA templates are either external (for kernels) or internal.
+  // This lets llvm perform aggressive inter-procedural optimizations.
+  if (Linkage == GVA_StrongODR) {
+if (Context.getLangOpts().AppleKext)
+  return llvm::Function::ExternalLinkage;
+if (Context.getLangOpts().CUDA && Context.getLangOpts().CUDAIsDevice)
+  return D->hasAttr() ? llvm::Function::ExternalLinkage
+  : llvm::Function::InternalLinkage;
+return llvm::Function::WeakODRLinkage;
+  }
 
   // C++ doesn't have tentative definitions and thus cannot have common
   // linkage.
Index: cfe/trunk/test/CodeGenCUDA/ptx-kernels.cu
===
--- cfe/trunk/test/CodeGenCUDA/ptx-kernels.cu
+++ cfe/trunk/test/CodeGenCUDA/ptx-kernels.cu
@@ -19,11 +19,11 @@
 
 // Make sure host-instantiated kernels are preserved on device side.
 template  __global__ void templated_kernel(T param) {}
-// CHECK-DAG: define weak_odr void @_Z16templated_kernelIiEvT_(
+// CHECK-DAG: define void @_Z16templated_kernelIiEvT_(
 
 namespace {
 __global__ void anonymous_ns_kernel() {}
-// CHECK-DAG: define weak_odr void @_ZN12_GLOBAL__N_119anonymous_ns_kernelEv(
+// CHECK-DAG: define void @_ZN12_GLOBAL__N_119anonymous_ns_kernelEv(
 }
 
 void host_function() {


Index: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
===
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp
@@ -2671,9 +2671,18 @@
   // explicit instantiations can occur in multiple translation units
   // and must all be equivalent. However, we are not allowed to
   // throw away these explicit instantiations.
-  if (Linkage == GVA_StrongODR)
-return !Context.getLangOpts().AppleKext ? llvm::Function::WeakODRLinkage
-: llvm::Function::ExternalLinkage;
+  //
+  // We don't currently support CUDA device code spread out across multiple TUs,
+  // so say that CUDA templates are either external (for kernels) or internal.
+  // This lets llvm perform aggressive inter-procedural optimizations.
+  if (Linkage == GVA_StrongODR) {
+if (Context.getLangOpts().AppleKext)
+  return llvm::Function::ExternalLinkage;
+if (Context.getLangOpts().CUDA && Context.getLangOpts().CUDAIsDevice)
+  return D->hasAttr() ? llvm::Function::ExternalLinkage
+  : llvm::Function::InternalLinkage;
+return llvm::Function::WeakODRLinkage;
+  }
 
   // C++ doesn't have tentative definitions and thus cannot have common
   // linkage.
Index: cfe/trunk/test/CodeGenCUDA/ptx-kernels.cu
===
--- cfe/trunk/test/CodeGenCUDA/ptx-kernels.cu
+++ cfe/trunk/test/CodeGenCUDA/ptx-kernels.cu
@@ -19,11 +19,11 @@
 
 // Make sure host-instantiated kernels are preserved on device side.
 template  __global__ void templated_kernel(T param) {}
-// CHECK-DAG: define weak_odr void @_Z16templated_kernelIiEvT_(
+// CHECK-DAG: define void @_Z16templated_kernelIiEvT_(
 
 namespace {
 __global__ void anonymous_ns_kernel() {}
-// CHECK-DAG: define weak_odr void @_ZN12_GLOBAL__N_119anonymous_ns_kernelEv(
+// CHECK-DAG: define void @_ZN12_GLOBAL__N_119anonymous_ns_kernelEv(
 }
 
 void host_function() {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D21803: [libcxxabi] Provide a fallback __cxa_thread_atexit() implementation

2016-06-30 Thread Tavian Barnes via cfe-commits
tavianator updated this revision to Diff 62388.
tavianator added a comment.

Added missing __dso_handle declaration.


http://reviews.llvm.org/D21803

Files:
  cmake/config-ix.cmake
  src/CMakeLists.txt
  src/cxa_thread_atexit.cpp
  test/CMakeLists.txt
  test/cxa_thread_atexit_test.pass.cpp
  test/libcxxabi/test/config.py
  test/lit.site.cfg.in

Index: test/lit.site.cfg.in
===
--- test/lit.site.cfg.in
+++ test/lit.site.cfg.in
@@ -13,7 +13,6 @@
 config.enable_32bit = "@LIBCXXABI_BUILD_32_BITS@"
 config.target_info  = "@LIBCXXABI_TARGET_INFO@"
 config.executor = "@LIBCXXABI_EXECUTOR@"
-config.thread_atexit= "@LIBCXXABI_HAS_CXA_THREAD_ATEXIT_IMPL@"
 config.libcxxabi_shared = "@LIBCXXABI_ENABLE_SHARED@"
 config.enable_shared= "@LIBCXX_ENABLE_SHARED@"
 config.enable_exceptions= "@LIBCXXABI_ENABLE_EXCEPTIONS@"
Index: test/libcxxabi/test/config.py
===
--- test/libcxxabi/test/config.py
+++ test/libcxxabi/test/config.py
@@ -37,8 +37,6 @@
 super(Configuration, self).configure_features()
 if not self.get_lit_bool('enable_exceptions', True):
 self.config.available_features.add('libcxxabi-no-exceptions')
-if self.get_lit_bool('thread_atexit', True):
-self.config.available_features.add('thread_atexit')
 
 def configure_compile_flags(self):
 self.cxx.compile_flags += ['-DLIBCXXABI_NO_TIMER']
Index: test/cxa_thread_atexit_test.pass.cpp
===
--- test/cxa_thread_atexit_test.pass.cpp
+++ test/cxa_thread_atexit_test.pass.cpp
@@ -8,7 +8,6 @@
 //===--===//
 
 // REQUIRES: linux
-// REQUIRES: thread_atexit
 
 #include 
 #include 
Index: test/CMakeLists.txt
===
--- test/CMakeLists.txt
+++ test/CMakeLists.txt
@@ -16,7 +16,6 @@
 pythonize_bool(LIBCXXABI_ENABLE_THREADS)
 pythonize_bool(LIBCXXABI_ENABLE_EXCEPTIONS)
 pythonize_bool(LIBCXXABI_USE_LLVM_UNWINDER)
-pythonize_bool(LIBCXXABI_HAS_CXA_THREAD_ATEXIT_IMPL)
 set(LIBCXXABI_TARGET_INFO "libcxx.test.target_info.LocalTI" CACHE STRING
 "TargetInfo to use when setting up test environment.")
 set(LIBCXXABI_EXECUTOR "None" CACHE STRING
Index: src/cxa_thread_atexit.cpp
===
--- src/cxa_thread_atexit.cpp
+++ src/cxa_thread_atexit.cpp
@@ -7,20 +7,137 @@
 //
 //===--===//
 
+#include "abort_message.h"
 #include "cxxabi.h"
+#include 
+#include 
 
 namespace __cxxabiv1 {
+namespace {
+  // This implementation is used if the C library does not provide
+  // __cxa_thread_atexit_impl() for us.  It has a number of limitations that are
+  // difficult to impossible to address without ..._impl():
+  //
+  // - dso_symbol is ignored.  This means that a shared library may be unloaded
+  //   (via dlclose()) before its thread_local destructors have run.
+  //
+  // - thread_local destructors for the main thread are run with __cxa_atexit().
+  //   This is later than expected; they should run before the destructors of
+  //   any objects with static storage duration.
+  //
+  // - thread_local destructors on other threads run on the first iteration
+  //   through the pthread_key destructors.  std::notify_all_at_thread_exit()
+  //   and similar functions must be careful to wait until the second iteration
+  //   to provide their indended ordering guarantees.
+
+  typedef void (*Dtor)(void*);
+
+  struct DtorList {
+Dtor dtor;
+void* obj;
+DtorList* next;
+  };
+
+  pthread_key_t dtors;
+  pthread_once_t dtors_once = PTHREAD_ONCE_INIT;
+  bool dtors_ready = false;
+  bool dtors_atexit = false;
+
+  void run_dtors(void* ptr) {
+if (pthread_setspecific(dtors, ptr) != 0) {
+  abort_message("pthread_setspecific() failed during thread_local destruction");
+}
+
+// Rather than iterate over the list directly, use the pthread_key to get
+// the head of the list every time.  This gives the correct ordering if
+// __cxa_thread_atexit() is called during the loop.
+while (auto elem = static_cast(pthread_getspecific(dtors))) {
+  if (pthread_setspecific(dtors, ptr) != 0) {
+abort_message("pthread_setspecific() failed during thread_local destruction");
+  }
+  elem->dtor(elem->obj);
+  std::free(elem);
+}
+  }
+
+  void run_dtors_atexit(void*) {
+// Signify that we need to re-register this function if any new
+// thread_locals are created.
+dtors_atexit = false;
+
+auto ptr = pthread_getspecific(dtors);
+run_dtors(ptr);
+  }
+
+  // This is the DSO handle for libc++abi.so itself
+  extern "C" void* __dso_handle;
+
+  void 

Re: [PATCH] D21803: [libcxxabi] Provide a fallback __cxa_thread_atexit() implementation

2016-06-30 Thread Tavian Barnes via cfe-commits
tavianator marked 3 inline comments as done.
tavianator added a comment.

In http://reviews.llvm.org/D21803#470448, @bcraig wrote:

> What that means for this implementation is that I think that 
> _cxa_thread_atexit is allowed to be called during run_dtors.  If running the 
> dtor for a thread local variable 'cat', we encounter a previously unseen 
> thread_local 'dog', the compiler will call the ctor, then register the dtor 
> with _cxa_thread_atexit.  Since it is the most recently constructed thread 
> local object, I would expect the 'dog' dtor to be the next dtor to be run.  
> You may be able to support this just by moving "elem = elem->next" below the 
> dtor invocation.


It wasn't quite that easy (have to re-look at the pthread_key to get newly 
added thread_locals), but that's done in the latest patch.



Comment at: src/cxa_thread_atexit.cpp:115
@@ +114,3 @@
+if (!dtors_atexit) {
+  if (__cxa_atexit(run_dtors_atexit, NULL, __dso_handle) != 0) {
+return -1;

See http://stackoverflow.com/q/38130185/502399 for a test case that would 
trigger this.  This may not be necessary depending on the answer to that 
question.


Comment at: src/cxa_thread_atexit.cpp:122
@@ +121,3 @@
+auto head = static_cast(std::malloc(sizeof(DtorList)));
+if (!head) {
+  return -1;

This has changed somewhat in the latest patch, but the gist is similar.  If 
libc++abi.so is dlclose()d, there had better not be any still-running threads 
that expect to execute thread_local destructors (or any other C++ code, for 
that matter).  In the usual case (libc++abi.so loaded at startup, not by a 
later dlopen()), the last run_dtors() call happens as the final thread is 
exiting.


http://reviews.llvm.org/D21803



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


Re: [PATCH] D21803: [libcxxabi] Provide a fallback __cxa_thread_atexit() implementation

2016-06-30 Thread Tavian Barnes via cfe-commits
tavianator updated this revision to Diff 62386.
tavianator added a comment.

Fixed some corner cases regarding destruction order and very-late-initialized 
thread_locals.  Explicitly documented the known limitations compared to 
__cxa_thread_atexit_impl().


http://reviews.llvm.org/D21803

Files:
  cmake/config-ix.cmake
  src/CMakeLists.txt
  src/cxa_thread_atexit.cpp
  test/CMakeLists.txt
  test/cxa_thread_atexit_test.pass.cpp
  test/libcxxabi/test/config.py
  test/lit.site.cfg.in

Index: test/lit.site.cfg.in
===
--- test/lit.site.cfg.in
+++ test/lit.site.cfg.in
@@ -13,7 +13,6 @@
 config.enable_32bit = "@LIBCXXABI_BUILD_32_BITS@"
 config.target_info  = "@LIBCXXABI_TARGET_INFO@"
 config.executor = "@LIBCXXABI_EXECUTOR@"
-config.thread_atexit= "@LIBCXXABI_HAS_CXA_THREAD_ATEXIT_IMPL@"
 config.libcxxabi_shared = "@LIBCXXABI_ENABLE_SHARED@"
 config.enable_shared= "@LIBCXX_ENABLE_SHARED@"
 config.enable_exceptions= "@LIBCXXABI_ENABLE_EXCEPTIONS@"
Index: test/libcxxabi/test/config.py
===
--- test/libcxxabi/test/config.py
+++ test/libcxxabi/test/config.py
@@ -37,8 +37,6 @@
 super(Configuration, self).configure_features()
 if not self.get_lit_bool('enable_exceptions', True):
 self.config.available_features.add('libcxxabi-no-exceptions')
-if self.get_lit_bool('thread_atexit', True):
-self.config.available_features.add('thread_atexit')
 
 def configure_compile_flags(self):
 self.cxx.compile_flags += ['-DLIBCXXABI_NO_TIMER']
Index: test/cxa_thread_atexit_test.pass.cpp
===
--- test/cxa_thread_atexit_test.pass.cpp
+++ test/cxa_thread_atexit_test.pass.cpp
@@ -8,7 +8,6 @@
 //===--===//
 
 // REQUIRES: linux
-// REQUIRES: thread_atexit
 
 #include 
 #include 
Index: test/CMakeLists.txt
===
--- test/CMakeLists.txt
+++ test/CMakeLists.txt
@@ -16,7 +16,6 @@
 pythonize_bool(LIBCXXABI_ENABLE_THREADS)
 pythonize_bool(LIBCXXABI_ENABLE_EXCEPTIONS)
 pythonize_bool(LIBCXXABI_USE_LLVM_UNWINDER)
-pythonize_bool(LIBCXXABI_HAS_CXA_THREAD_ATEXIT_IMPL)
 set(LIBCXXABI_TARGET_INFO "libcxx.test.target_info.LocalTI" CACHE STRING
 "TargetInfo to use when setting up test environment.")
 set(LIBCXXABI_EXECUTOR "None" CACHE STRING
Index: src/cxa_thread_atexit.cpp
===
--- src/cxa_thread_atexit.cpp
+++ src/cxa_thread_atexit.cpp
@@ -7,20 +7,134 @@
 //
 //===--===//
 
+#include "abort_message.h"
 #include "cxxabi.h"
+#include 
+#include 
 
 namespace __cxxabiv1 {
+namespace {
+  // This implementation is used if the C library does not provide
+  // __cxa_thread_atexit_impl() for us.  It has a number of limitations that are
+  // difficult to impossible to address without ..._impl():
+  //
+  // - dso_symbol is ignored.  This means that a shared library may be unloaded
+  //   (via dlclose()) before its thread_local destructors have run.
+  //
+  // - thread_local destructors for the main thread are run with __cxa_atexit().
+  //   This is later than expected; they should run before the destructors of
+  //   any objects with static storage duration.
+  //
+  // - thread_local destructors on other threads run on the first iteration
+  //   through the pthread_key destructors.  std::notify_all_at_thread_exit()
+  //   and similar functions must be careful to wait until the second iteration
+  //   to provide their indended ordering guarantees.
+
+  typedef void (*Dtor)(void*);
+
+  struct DtorList {
+Dtor dtor;
+void* obj;
+DtorList* next;
+  };
+
+  pthread_key_t dtors;
+  pthread_once_t dtors_once = PTHREAD_ONCE_INIT;
+  bool dtors_ready = false;
+  bool dtors_atexit = false;
+
+  void run_dtors(void* ptr) {
+if (pthread_setspecific(dtors, ptr) != 0) {
+  abort_message("pthread_setspecific() failed during thread_local destruction");
+}
+
+// Rather than iterate over the list directly, use the pthread_key to get
+// the head of the list every time.  This gives the correct ordering if
+// __cxa_thread_atexit() is called during the loop.
+while (auto elem = static_cast(pthread_getspecific(dtors))) {
+  if (pthread_setspecific(dtors, ptr) != 0) {
+abort_message("pthread_setspecific() failed during thread_local destruction");
+  }
+  elem->dtor(elem->obj);
+  std::free(elem);
+}
+  }
+
+  void run_dtors_atexit(void*) {
+// Signify that we need to re-register this function if any new
+// thread_locals are created.
+dtors_atexit = false;
+
+auto ptr = 

Re: [PATCH] D21810: Don't instantiate a full host toolchain in ASTMatchersTest.

2016-06-30 Thread Justin Lebar via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL274257: Don't instantiate a full host toolchain in 
ASTMatchersTest. (authored by jlebar).

Changed prior to commit:
  http://reviews.llvm.org/D21810?vs=62132=62385#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D21810

Files:
  cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.h

Index: cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.h
===
--- cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.h
+++ cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.h
@@ -73,12 +73,16 @@
 return testing::AssertionFailure() << "Could not add dynamic matcher";
   std::unique_ptr Factory(
   newFrontendActionFactory());
-  // Some tests use typeof, which is a gnu extension.
-  std::vector Args;
-  Args.push_back(CompileArg);
-  // Some tests need rtti/exceptions on
-  Args.push_back("-frtti");
-  Args.push_back("-fexceptions");
+  // Some tests need rtti/exceptions on.  Use an unknown-unknown triple so we
+  // don't instantiate the full system toolchain.  On Linux, instantiating the
+  // toolchain involves stat'ing large portions of /usr/lib, and this slows 
down
+  // not only this test, but all other tests, via contention in the kernel.
+  //
+  // FIXME: This is a hack to work around the fact that there's no way to do 
the
+  // equivalent of runToolOnCodeWithArgs without instantiating a full Driver.
+  // We should consider having a function, at least for tests, that invokes 
cc1.
+  std::vector Args = {CompileArg, "-frtti", "-fexceptions",
+   "-target", "i386-unknown-unknown"};
   if (!runToolOnCodeWithArgs(
   Factory->create(), Code, Args, Filename, "clang-tool",
   std::make_shared(), VirtualMappedFiles)) {
@@ -180,13 +184,12 @@
 return testing::AssertionFailure() << "Could not add dynamic matcher";
   std::unique_ptr Factory(
   newFrontendActionFactory());
-  // Some tests use typeof, which is a gnu extension.
-  std::vector Args;
-  Args.push_back("-xcuda");
-  Args.push_back("-fno-ms-extensions");
-  Args.push_back("--cuda-host-only");
-  Args.push_back("-nocudainc");
-  Args.push_back(CompileArg);
+  // Some tests use typeof, which is a gnu extension.  Using an explicit
+  // unknown-unknown triple is good for a large speedup, because it lets us
+  // avoid constructing a full system triple.
+  std::vector Args = {
+  "-xcuda",  "-fno-ms-extensions",  "--cuda-host-only", "-nocudainc",
+  "-target", "nvptx64-unknown-unknown", CompileArg};
   if (!runToolOnCodeWithArgs(Factory->create(),
  CudaHeader + Code, Args)) {
 return testing::AssertionFailure() << "Parsing error in \"" << Code << 
"\"";
@@ -230,8 +233,11 @@
   Finder.addMatcher(AMatcher, );
   std::unique_ptr Factory(
   newFrontendActionFactory());
-  // Some tests use typeof, which is a gnu extension.
-  std::vector Args(1, "-std=gnu++98");
+  // Some tests use typeof, which is a gnu extension.  Using an explicit
+  // unknown-unknown triple is good for a large speedup, because it lets us
+  // avoid constructing a full system triple.
+  std::vector Args = {"-std=gnu++98", "-target",
+   "i386-unknown-unknown"};
   if (!runToolOnCodeWithArgs(Factory->create(), Code, Args)) {
 return testing::AssertionFailure() << "Parsing error in \"" << Code << 
"\"";
   }


Index: cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.h
===
--- cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.h
+++ cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.h
@@ -73,12 +73,16 @@
 return testing::AssertionFailure() << "Could not add dynamic matcher";
   std::unique_ptr Factory(
   newFrontendActionFactory());
-  // Some tests use typeof, which is a gnu extension.
-  std::vector Args;
-  Args.push_back(CompileArg);
-  // Some tests need rtti/exceptions on
-  Args.push_back("-frtti");
-  Args.push_back("-fexceptions");
+  // Some tests need rtti/exceptions on.  Use an unknown-unknown triple so we
+  // don't instantiate the full system toolchain.  On Linux, instantiating the
+  // toolchain involves stat'ing large portions of /usr/lib, and this slows down
+  // not only this test, but all other tests, via contention in the kernel.
+  //
+  // FIXME: This is a hack to work around the fact that there's no way to do the
+  // equivalent of runToolOnCodeWithArgs without instantiating a full Driver.
+  // We should consider having a function, at least for tests, that invokes cc1.
+  std::vector Args = {CompileArg, "-frtti", "-fexceptions",
+   "-target", "i386-unknown-unknown"};
   if (!runToolOnCodeWithArgs(
   Factory->create(), Code, Args, Filename, "clang-tool",
   std::make_shared(), VirtualMappedFiles)) {
@@ -180,13 +184,12 @@
 return testing::AssertionFailure() << 

r274257 - Don't instantiate a full host toolchain in ASTMatchersTest.

2016-06-30 Thread Justin Lebar via cfe-commits
Author: jlebar
Date: Thu Jun 30 13:12:25 2016
New Revision: 274257

URL: http://llvm.org/viewvc/llvm-project?rev=274257=rev
Log:
Don't instantiate a full host toolchain in ASTMatchersTest.

Summary:
This test was stat()'ing large swaths of /usr/lib hundreds of times, as
every invocation of matchesConditionally*() created a new Linux
toolchain.

In addition to being slow, perf indicated this was causing substantial
contention in the kernel.

Something is...interesting in the kernel, as without this patch I
sometimes see ~11m spent in the kernel, and sometimes ~5m.  This
corresponds to bimodal ninja check-clang times of ~30s and ~20s.

It's not clear to me exactly what causes the bimodality.  In any case,
this change makes this test run in 2.5s, down from 17s, and it seems to
cause us to get the 20s ninja check-clang time unconditionally.

Reviewers: chandlerc

Subscribers: cfe-commits, klimek

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

Modified:
cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.h

Modified: cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.h?rev=274257=274256=274257=diff
==
--- cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.h (original)
+++ cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.h Thu Jun 30 13:12:25 2016
@@ -73,12 +73,16 @@ testing::AssertionResult matchesConditio
 return testing::AssertionFailure() << "Could not add dynamic matcher";
   std::unique_ptr Factory(
   newFrontendActionFactory());
-  // Some tests use typeof, which is a gnu extension.
-  std::vector Args;
-  Args.push_back(CompileArg);
-  // Some tests need rtti/exceptions on
-  Args.push_back("-frtti");
-  Args.push_back("-fexceptions");
+  // Some tests need rtti/exceptions on.  Use an unknown-unknown triple so we
+  // don't instantiate the full system toolchain.  On Linux, instantiating the
+  // toolchain involves stat'ing large portions of /usr/lib, and this slows 
down
+  // not only this test, but all other tests, via contention in the kernel.
+  //
+  // FIXME: This is a hack to work around the fact that there's no way to do 
the
+  // equivalent of runToolOnCodeWithArgs without instantiating a full Driver.
+  // We should consider having a function, at least for tests, that invokes 
cc1.
+  std::vector Args = {CompileArg, "-frtti", "-fexceptions",
+   "-target", "i386-unknown-unknown"};
   if (!runToolOnCodeWithArgs(
   Factory->create(), Code, Args, Filename, "clang-tool",
   std::make_shared(), VirtualMappedFiles)) {
@@ -180,13 +184,12 @@ testing::AssertionResult matchesConditio
 return testing::AssertionFailure() << "Could not add dynamic matcher";
   std::unique_ptr Factory(
   newFrontendActionFactory());
-  // Some tests use typeof, which is a gnu extension.
-  std::vector Args;
-  Args.push_back("-xcuda");
-  Args.push_back("-fno-ms-extensions");
-  Args.push_back("--cuda-host-only");
-  Args.push_back("-nocudainc");
-  Args.push_back(CompileArg);
+  // Some tests use typeof, which is a gnu extension.  Using an explicit
+  // unknown-unknown triple is good for a large speedup, because it lets us
+  // avoid constructing a full system triple.
+  std::vector Args = {
+  "-xcuda",  "-fno-ms-extensions",  "--cuda-host-only", "-nocudainc",
+  "-target", "nvptx64-unknown-unknown", CompileArg};
   if (!runToolOnCodeWithArgs(Factory->create(),
  CudaHeader + Code, Args)) {
 return testing::AssertionFailure() << "Parsing error in \"" << Code << 
"\"";
@@ -230,8 +233,11 @@ matchAndVerifyResultConditionally(const
   Finder.addMatcher(AMatcher, );
   std::unique_ptr Factory(
   newFrontendActionFactory());
-  // Some tests use typeof, which is a gnu extension.
-  std::vector Args(1, "-std=gnu++98");
+  // Some tests use typeof, which is a gnu extension.  Using an explicit
+  // unknown-unknown triple is good for a large speedup, because it lets us
+  // avoid constructing a full system triple.
+  std::vector Args = {"-std=gnu++98", "-target",
+   "i386-unknown-unknown"};
   if (!runToolOnCodeWithArgs(Factory->create(), Code, Args)) {
 return testing::AssertionFailure() << "Parsing error in \"" << Code << 
"\"";
   }


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


Re: [PATCH] D21810: Don't instantiate a full host toolchain in ASTMatchersTest.

2016-06-30 Thread Chandler Carruth via cfe-commits
chandlerc accepted this revision.
chandlerc added a comment.
This revision is now accepted and ready to land.

In http://reviews.llvm.org/D21810#471486, @jlebar wrote:

> > But I think this is a reasonable workaround until such an API can be 
> > provided.
>
>
> Should I take that as an LG, or are we waiting for someone else to approve 
> this?


Lacking a more detailed response from Manuel, yea, I think you should check 
this in... I wrote most of the toolchain search logic you're turning off so I'm 
happy to provide an LGTM here. I think this is fine for now, fixes an immediate 
issue, and can be revisited and improved later easily. So yes, LG.


http://reviews.llvm.org/D21810



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


[libcxx] r274255 - Mark issues 2550, 2551, 2555, 2685, 2698 as complete. These issues are wording clarifications; no code changes required.

2016-06-30 Thread Marshall Clow via cfe-commits
Author: marshall
Date: Thu Jun 30 13:05:19 2016
New Revision: 274255

URL: http://llvm.org/viewvc/llvm-project?rev=274255=rev
Log:
Mark issues 2550, 2551, 2555, 2685, 2698 as complete. These issues are wording 
clarifications; no code changes required.

Modified:
libcxx/trunk/www/cxx1z_status.html

Modified: libcxx/trunk/www/cxx1z_status.html
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/cxx1z_status.html?rev=274255=274254=274255=diff
==
--- libcxx/trunk/www/cxx1z_status.html (original)
+++ libcxx/trunk/www/cxx1z_status.html Thu Jun 30 13:05:19 2016
@@ -275,9 +275,9 @@
http://wg21.link/LWG2516;>2516[fund.ts.v2] Public 
"exposition only" members in observer_ptrOulu
http://wg21.link/LWG2542;>2542Missing 
const requirements for associative containersOulu
http://wg21.link/LWG2549;>2549Tuple 
EXPLICIT constructor templates that take tuple parameters end up taking 
references to temporaries and will create dangling 
referencesOuluComplete
-   http://wg21.link/LWG2550;>2550Wording of 
unordered container's clear() method complexityOulu
-   http://wg21.link/LWG2551;>2551[fund.ts.v2] "Exception 
safety" cleanup in library fundamentals requiredOulu
-   http://wg21.link/LWG2555;>2555[fund.ts.v2] No handling for 
over-aligned types in optionalOulu
+   http://wg21.link/LWG2550;>2550Wording of 
unordered container's clear() method 
complexityOuluComplete
+   http://wg21.link/LWG2551;>2551[fund.ts.v2] "Exception 
safety" cleanup in library fundamentals 
requiredOuluComplete
+   http://wg21.link/LWG2555;>2555[fund.ts.v2] No handling for 
over-aligned types in optionalOuluComplete
http://wg21.link/LWG2573;>2573[fund.ts.v2] 
std::hashstd::experimental::shared_ptr does not work for 
arraysOulu
http://wg21.link/LWG2596;>2596vector::data() should use 
addressofOuluComplete
http://wg21.link/LWG2667;>2667path::root_directory() 
description is confusingOuluComplete
@@ -288,16 +288,16 @@
http://wg21.link/LWG2674;>2674Bidirectional iterator 
requirement on path::iterator is very 
expensiveOuluComplete
http://wg21.link/LWG2683;>2683filesystem::copy() says "no 
effects"Oulu
http://wg21.link/LWG2684;>2684priority_queue lacking 
comparator typedefOuluComplete
-   http://wg21.link/LWG2685;>2685shared_ptr 
deleters must not throw on move constructionOulu
+   http://wg21.link/LWG2685;>2685shared_ptr 
deleters must not throw on move 
constructionOuluComplete
http://wg21.link/LWG2687;>2687{inclusive,exclusive}_scan 
misspecifiedOulu
http://wg21.link/LWG2688;>2688clamp 
misses preconditions and has extraneous condition on 
resultOuluComplete
http://wg21.link/LWG2689;>2689Parallel 
versions of std::copy and std::move shouldn't be in 
orderOulu
-   http://wg21.link/LWG2698;>2698Effect of 
assign() on iterators/pointers/referencesOulu
+   http://wg21.link/LWG2698;>2698Effect of 
assign() on 
iterators/pointers/referencesOuluComplete
http://wg21.link/LWG2704;>2704recursive_directory_iterator's 
members should require '*this is 
dereferenceable'OuluComplete
http://wg21.link/LWG2706;>2706Error 
reporting for recursive_directory_iterator::pop() is 
under-specifiedOuluComplete
http://wg21.link/LWG2707;>2707path 
construction and assignment should have "string_type&&" 
overloadsOuluComplete
http://wg21.link/LWG2709;>2709offsetof is 
unnecessarily impreciseOulu
-   http://wg21.link/LWG2710;>2710"Effects: 
Equivalent to ..." doesn't count "Synchronization:" as determined 
semanticsOulu
+   http://wg21.link/LWG2710;>2710"Effects: 
Equivalent to ..." doesn't count "Synchronization:" as determined 
semanticsOuluComplete
http://wg21.link/LWG2711;>2711path is 
convertible from approximately everything under the 
sunOulu
http://wg21.link/LWG2716;>2716Specification of shuffle and 
sample disallows lvalue URNGsOulu
http://wg21.link/LWG2718;>2718Parallelism 
bug in [algorithms.parallel.exec] p2Oulu
@@ -317,7 +317,7 @@
 
   
 
-  Last Updated: 28-Jun-2016
+  Last Updated: 30-Jun-2016
 
 
 


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


[libcxx] r274253 - Mark issues 2667, 2669, 2670, 2671, 2673 as complete. These issues are wording clarifications; no code changes required.

2016-06-30 Thread Marshall Clow via cfe-commits
Author: marshall
Date: Thu Jun 30 12:59:01 2016
New Revision: 274253

URL: http://llvm.org/viewvc/llvm-project?rev=274253=rev
Log:
Mark issues 2667, 2669, 2670, 2671, 2673 as complete. These issues are wording 
clarifications; no code changes required.

Modified:
libcxx/trunk/www/cxx1z_status.html

Modified: libcxx/trunk/www/cxx1z_status.html
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/cxx1z_status.html?rev=274253=274252=274253=diff
==
--- libcxx/trunk/www/cxx1z_status.html (original)
+++ libcxx/trunk/www/cxx1z_status.html Thu Jun 30 12:59:01 2016
@@ -280,11 +280,11 @@
http://wg21.link/LWG2555;>2555[fund.ts.v2] No handling for 
over-aligned types in optionalOulu
http://wg21.link/LWG2573;>2573[fund.ts.v2] 
std::hashstd::experimental::shared_ptr does not work for 
arraysOulu
http://wg21.link/LWG2596;>2596vector::data() should use 
addressofOuluComplete
-   http://wg21.link/LWG2667;>2667path::root_directory() 
description is confusingOulu
-   http://wg21.link/LWG2669;>2669recursive_directory_iterator 
effects refers to non-existent functionsOulu
-   http://wg21.link/LWG2670;>2670system_complete refers to 
undefined variable 'base'Oulu
-   http://wg21.link/LWG2671;>2671Errors in 
CopyOulu
-   http://wg21.link/LWG2673;>2673status() 
effects cannot be implemented as specifiedOulu
+   http://wg21.link/LWG2667;>2667path::root_directory() 
description is confusingOuluComplete
+   http://wg21.link/LWG2669;>2669recursive_directory_iterator 
effects refers to non-existent functionsOuluComplete
+   http://wg21.link/LWG2670;>2670system_complete refers to 
undefined variable 'base'OuluComplete
+   http://wg21.link/LWG2671;>2671Errors in 
CopyOuluComplete
+   http://wg21.link/LWG2673;>2673status() 
effects cannot be implemented as 
specifiedOuluComplete
http://wg21.link/LWG2674;>2674Bidirectional iterator 
requirement on path::iterator is very 
expensiveOuluComplete
http://wg21.link/LWG2683;>2683filesystem::copy() says "no 
effects"Oulu
http://wg21.link/LWG2684;>2684priority_queue lacking 
comparator typedefOuluComplete


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


Re: r274246 - [codeview] Emit qualified display names if -gline-tables-only is on

2016-06-30 Thread Reid Kleckner via cfe-commits
David and Paul,

Do you think I should enable this behavior for DWARF as well? We only emit
a DW_TAG_subprogram when a function is inlined or contains inlined
functions, which might not be that many. IIRC Paul did something similar
with DW_AT_linkage_name, and the object file size cost wasn't that bad.

Reid

On Thu, Jun 30, 2016 at 10:41 AM, Reid Kleckner via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rnk
> Date: Thu Jun 30 12:41:31 2016
> New Revision: 274246
>
> URL: http://llvm.org/viewvc/llvm-project?rev=274246=rev
> Log:
> [codeview] Emit qualified display names if -gline-tables-only is on
>
> When -gmlt is on, we don't emit namespace or class scope information,
> and the CodeView emission code in LLVM can't compute the fully qualified
> name. If we know LLVM won't be able to get the name right, go ahead and
> emit the qualified name in the frontend.
>
> We could change our -gmlt emission strategy to include those scopes when
> emitting codeview, but that would increase memory usage and slow down
> LTO and add more complexity to debug info emission.
>
> The same problem exists when you debug a -gmlt binary with GDB, so we
> should consider removing '&& EmitCodeView' from the condition here at
> some point in the future after evaluating the impact on object file
> size.
>
> Modified:
> cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> cfe/trunk/test/CodeGenCXX/debug-info-codeview-display-name.cpp
>
> Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=274246=274245=274246=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Thu Jun 30 12:41:31 2016
> @@ -185,17 +185,27 @@ StringRef CGDebugInfo::getFunctionName(c
>FunctionTemplateSpecializationInfo *Info =
>FD->getTemplateSpecializationInfo();
>
> -  if (!Info && FII)
> +  // Emit the unqualified name in normal operation. LLVM and the debugger
> can
> +  // compute the fully qualified name from the scope chain. If we're only
> +  // emitting line table info, there won't be any scope chains, so emit
> the
> +  // fully qualified name here so that stack traces are more accurate.
> +  // FIXME: Do this when emitting DWARF as well as when emitting CodeView
> after
> +  // evaluating the size impact.
> +  bool UseQualifiedName = DebugKind ==
> codegenoptions::DebugLineTablesOnly &&
> +  CGM.getCodeGenOpts().EmitCodeView;
> +
> +  if (!Info && FII && !UseQualifiedName)
>  return FII->getName();
>
> -  // Otherwise construct human readable name for debug info.
>SmallString<128> NS;
>llvm::raw_svector_ostream OS(NS);
>PrintingPolicy Policy(CGM.getLangOpts());
>Policy.MSVCFormatting = CGM.getCodeGenOpts().EmitCodeView;
> +  if (!UseQualifiedName)
> +FD->printName(OS);
> +  else
> +FD->printQualifiedName(OS, Policy);
>
> -  // Print the unqualified name with some template arguments.
> -  FD->printName(OS);
>// Add any template specialization args.
>if (Info) {
>  const TemplateArgumentList *TArgs = Info->TemplateArguments;
>
> Modified: cfe/trunk/test/CodeGenCXX/debug-info-codeview-display-name.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-codeview-display-name.cpp?rev=274246=274245=274246=diff
>
> ==
> --- cfe/trunk/test/CodeGenCXX/debug-info-codeview-display-name.cpp
> (original)
> +++ cfe/trunk/test/CodeGenCXX/debug-info-codeview-display-name.cpp Thu Jun
> 30 12:41:31 2016
> @@ -1,14 +1,22 @@
> -// RUN: %clang_cc1 -fblocks -debug-info-kind=limited -gcodeview
> -emit-llvm %s -o - -triple=x86_64-pc-win32 -std=c++98 | \
> -// RUN:  grep 'DISubprogram' | sed -e 's/.*name: "\([^"]*\)".*/"\1"/' |
> FileCheck %s
> +// RUN: %clang_cc1 -fblocks -debug-info-kind=limited -gcodeview
> -emit-llvm %s \
> +// RUN:   -o - -triple=x86_64-pc-win32 -std=c++98 | \
> +// RUN:grep 'DISubprogram' | sed -e 's/.*name: "\([^"]*\)".*/"\1"/' |
> \
> +// RUN:FileCheck %s --check-prefix=CHECK --check-prefix=UNQUAL
> +// RUN: %clang_cc1 -fblocks -debug-info-kind=line-tables-only -gcodeview
> -emit-llvm %s \
> +// RUN:   -o - -triple=x86_64-pc-win32 -std=c++98 | \
> +// RUN:grep 'DISubprogram' | sed -e 's/.*name: "\([^"]*\)".*/"\1"/' |
> \
> +// RUN:FileCheck %s --check-prefix=CHECK --check-prefix=QUAL
>
>  void freefunc() { }
>  // CHECK-DAG: "freefunc"
>
>  namespace N {
>int b() { return 0; }
> -// CHECK-DAG: "b"
> +// UNQUAL-DAG: "b"
> +// QUAL-DAG: "N::b"
>namespace { void func() { } }
> -// CHECK-DAG: "func"
> +// UNQUAL-DAG: "func"
> +// QUAL-DAG: "N::`anonymous namespace'::func"
>  }
>
>  void _c(void) {
> @@ -19,19 +27,24 @@ void _c(void) {
>  struct foo {
>int operator+(int);
>foo(){}
> -// CHECK-DAG: "foo"
> +// UNQUAL-DAG: 

[libcxx] r274250 - Temporarily XFAIL the incomplete type tests for GCC while I figure out why adding a static_assert in r274235 broken them

2016-06-30 Thread Marshall Clow via cfe-commits
Author: marshall
Date: Thu Jun 30 12:49:36 2016
New Revision: 274250

URL: http://llvm.org/viewvc/llvm-project?rev=274250=rev
Log:
Temporarily XFAIL the incomplete type tests for GCC while I figure out why 
adding a static_assert in r274235 broken them

Modified:
libcxx/trunk/test/std/containers/associative/map/incomplete_type.pass.cpp

libcxx/trunk/test/std/containers/associative/map/map.cons/default_recursive.pass.cpp

libcxx/trunk/test/std/containers/associative/multimap/incomplete_type.pass.cpp

libcxx/trunk/test/std/containers/associative/multimap/multimap.cons/default_recursive.pass.cpp
libcxx/trunk/test/std/containers/unord/unord.map/incomplete_type.pass.cpp
libcxx/trunk/test/std/containers/unord/unord.multimap/incomplete.pass.cpp

Modified: 
libcxx/trunk/test/std/containers/associative/map/incomplete_type.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/containers/associative/map/incomplete_type.pass.cpp?rev=274250=274249=274250=diff
==
--- libcxx/trunk/test/std/containers/associative/map/incomplete_type.pass.cpp 
(original)
+++ libcxx/trunk/test/std/containers/associative/map/incomplete_type.pass.cpp 
Thu Jun 30 12:49:36 2016
@@ -12,6 +12,8 @@
 // Check that std::map and it's iterators can be instantiated with an 
incomplete
 // type.
 
+// XFAIL: gcc
+
 #include 
 
 struct A {

Modified: 
libcxx/trunk/test/std/containers/associative/map/map.cons/default_recursive.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/containers/associative/map/map.cons/default_recursive.pass.cpp?rev=274250=274249=274250=diff
==
--- 
libcxx/trunk/test/std/containers/associative/map/map.cons/default_recursive.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/containers/associative/map/map.cons/default_recursive.pass.cpp
 Thu Jun 30 12:49:36 2016
@@ -13,6 +13,8 @@
 
 // map();
 
+// XFAIL: gcc
+
 #include 
 
 struct X

Modified: 
libcxx/trunk/test/std/containers/associative/multimap/incomplete_type.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/containers/associative/multimap/incomplete_type.pass.cpp?rev=274250=274249=274250=diff
==
--- 
libcxx/trunk/test/std/containers/associative/multimap/incomplete_type.pass.cpp 
(original)
+++ 
libcxx/trunk/test/std/containers/associative/multimap/incomplete_type.pass.cpp 
Thu Jun 30 12:49:36 2016
@@ -12,6 +12,8 @@
 // Check that std::multimap and it's iterators can be instantiated with an 
incomplete
 // type.
 
+// XFAIL: gcc
+
 #include 
 
 struct A {

Modified: 
libcxx/trunk/test/std/containers/associative/multimap/multimap.cons/default_recursive.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/containers/associative/multimap/multimap.cons/default_recursive.pass.cpp?rev=274250=274249=274250=diff
==
--- 
libcxx/trunk/test/std/containers/associative/multimap/multimap.cons/default_recursive.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/containers/associative/multimap/multimap.cons/default_recursive.pass.cpp
 Thu Jun 30 12:49:36 2016
@@ -13,6 +13,8 @@
 
 // multimap();
 
+// XFAIL: gcc
+
 #include 
 
 struct X

Modified: 
libcxx/trunk/test/std/containers/unord/unord.map/incomplete_type.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/containers/unord/unord.map/incomplete_type.pass.cpp?rev=274250=274249=274250=diff
==
--- libcxx/trunk/test/std/containers/unord/unord.map/incomplete_type.pass.cpp 
(original)
+++ libcxx/trunk/test/std/containers/unord/unord.map/incomplete_type.pass.cpp 
Thu Jun 30 12:49:36 2016
@@ -13,6 +13,8 @@
 // Check that std::unordered_map and it's iterators can be instantiated with 
an incomplete
 // type.
 
+// XFAIL: gcc
+
 #include 
 
 template 

Modified: 
libcxx/trunk/test/std/containers/unord/unord.multimap/incomplete.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/containers/unord/unord.multimap/incomplete.pass.cpp?rev=274250=274249=274250=diff
==
--- libcxx/trunk/test/std/containers/unord/unord.multimap/incomplete.pass.cpp 
(original)
+++ libcxx/trunk/test/std/containers/unord/unord.multimap/incomplete.pass.cpp 
Thu Jun 30 12:49:36 2016
@@ -13,6 +13,8 @@
 // Check that std::unordered_multimap and it's iterators can be instantiated 
with an incomplete
 // type.
 
+// XFAIL: gcc
+
 #include 
 
 template 


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


Re: [PATCH] D21603: [include-fixer] Add missing namespace qualifiers after inserting a missing header.

2016-06-30 Thread Haojian Wu via cfe-commits
hokein updated this revision to Diff 62383.
hokein marked 4 inline comments as done.
hokein added a comment.

Address review comments.


http://reviews.llvm.org/D21603

Files:
  include-fixer/IncludeFixer.cpp
  include-fixer/IncludeFixerContext.h
  include-fixer/SymbolIndexManager.cpp
  include-fixer/SymbolIndexManager.h
  include-fixer/find-all-symbols/SymbolInfo.cpp
  include-fixer/find-all-symbols/SymbolInfo.h
  include-fixer/tool/ClangIncludeFixer.cpp
  unittests/include-fixer/IncludeFixerTest.cpp

Index: unittests/include-fixer/IncludeFixerTest.cpp
===
--- unittests/include-fixer/IncludeFixerTest.cpp
+++ unittests/include-fixer/IncludeFixerTest.cpp
@@ -50,7 +50,7 @@
 }
 
 static std::string runIncludeFixer(
-StringRef Code,
+StringRef Code, bool FixNamespaceQualifiers = false,
 const std::vector  = std::vector()) {
   std::vector Symbols = {
   SymbolInfo("string", SymbolInfo::SymbolKind::Class, "", 1,
@@ -82,14 +82,17 @@
   IncludeFixerContext FixerContext;
   IncludeFixerActionFactory Factory(*SymbolIndexMgr, FixerContext, "llvm");
 
-  runOnCode(, Code, "input.cc", ExtraArgs);
-  if (FixerContext.Headers.empty())
+  std::string FakeFileName = "input.cc";
+  runOnCode(, Code, FakeFileName, ExtraArgs);
+  if (FixerContext.getMatchedSymbols().empty())
 return Code;
   tooling::Replacements Replacements =
   clang::include_fixer::createInsertHeaderReplacements(
-  Code, "input.cc", FixerContext.Headers.front());
+  Code, FakeFileName, FixerContext.getHeaders().front());
   clang::RewriterTestContext Context;
-  clang::FileID ID = Context.createInMemoryFile("input.cc", Code);
+  clang::FileID ID = Context.createInMemoryFile(FakeFileName, Code);
+  if (FixNamespaceQualifiers && FixerContext.getSymbolRange().getLength() > 0)
+Replacements.insert(FixerContext.createSymbolReplacement(FakeFileName, 0));
   clang::tooling::applyAllReplacements(Replacements, Context.Rewrite);
   return Context.getRewrittenText(ID);
 }
@@ -137,19 +140,23 @@
 TEST(IncludeFixer, MinimizeInclude) {
   std::vector IncludePath = {"-Idir/"};
   EXPECT_EQ("#include \"otherdir/qux.h\"\na::b::foo bar;\n",
-runIncludeFixer("a::b::foo bar;\n", IncludePath));
+runIncludeFixer("a::b::foo bar;\n",
+/*FixNamespaceQualifiers=*/false, IncludePath));
 
   IncludePath = {"-isystemdir"};
   EXPECT_EQ("#include \na::b::foo bar;\n",
-runIncludeFixer("a::b::foo bar;\n", IncludePath));
+runIncludeFixer("a::b::foo bar;\n",
+/*FixNamespaceQualifiers=*/false, IncludePath));
 
   IncludePath = {"-iquotedir"};
   EXPECT_EQ("#include \"otherdir/qux.h\"\na::b::foo bar;\n",
-runIncludeFixer("a::b::foo bar;\n", IncludePath));
+runIncludeFixer("a::b::foo bar;\n",
+/*FixNamespaceQualifiers=*/false, IncludePath));
 
   IncludePath = {"-Idir", "-Idir/otherdir"};
   EXPECT_EQ("#include \"qux.h\"\na::b::foo bar;\n",
-runIncludeFixer("a::b::foo bar;\n", IncludePath));
+runIncludeFixer("a::b::foo bar;\n",
+/*FixNamespaceQualifiers=*/false, IncludePath));
 }
 
 TEST(IncludeFixer, NestedName) {
@@ -221,6 +228,44 @@
 runIncludeFixer("a::Vector v;"));
 }
 
+TEST(IncludeFixer, FixNamespaceQualifiers) {
+  EXPECT_EQ("#include \"bar.h\"\na::b::bar b;\n",
+runIncludeFixer("b::bar b;\n", /*FixNamespaceQualifiers=*/true));
+  EXPECT_EQ("#include \"bar.h\"\na::b::bar b;\n",
+runIncludeFixer("a::b::bar b;\n", /*FixNamespaceQualifiers=*/true));
+  EXPECT_EQ("#include \"bar.h\"\na::b::bar b;\n",
+runIncludeFixer("bar b;\n", /*FixNamespaceQualifiers=*/true));
+  EXPECT_EQ("#include \"bar.h\"\nnamespace a {\nb::bar b;\n}\n",
+runIncludeFixer("namespace a {\nb::bar b;\n}\n",
+/*FixNamespaceQualifiers==*/true));
+  EXPECT_EQ("#include \"bar.h\"\nnamespace a {\nb::bar b;\n}\n",
+runIncludeFixer("namespace a {\nbar b;\n}\n",
+/*FixNamespaceQualifiers==*/true));
+  EXPECT_EQ("#include \"bar.h\"\nnamespace a {\nnamespace b{\nbar b;\n}\n}\n",
+runIncludeFixer("namespace a {\nnamespace b{\nbar b;\n}\n}\n",
+/*FixNamespaceQualifiers==*/true));
+  EXPECT_EQ("c::b::bar b;\n",
+runIncludeFixer("c::b::bar b;\n", /*FixNamespaceQualifiers=*/true));
+  EXPECT_EQ("#include \"bar.h\"\nnamespace c {\na::b::bar b;\n}\n",
+runIncludeFixer("namespace c {\nbar b;\n}\n",
+/*FixNamespaceQualifiers=*/true));
+
+  EXPECT_EQ(
+  "#include \"color.h\"\nint test = a::b::Green;\n",
+  runIncludeFixer("int test = Green;\n", /*FixNamespaceQualifiers=*/true));
+  EXPECT_EQ("#include \"color.h\"\nnamespace d {\nint test = a::b::Green;\n}\n",
+runIncludeFixer("namespace d 

[libcxx] r274252 - Implement LWG#2688: 'clamp misses preconditions and has extraneous condition on result'. We already did this, just added tests

2016-06-30 Thread Marshall Clow via cfe-commits
Author: marshall
Date: Thu Jun 30 12:52:51 2016
New Revision: 274252

URL: http://llvm.org/viewvc/llvm-project?rev=274252=rev
Log:
Implement LWG#2688: 'clamp misses preconditions and has extraneous condition on 
result'. We already did this, just added tests

Modified:
libcxx/trunk/test/std/algorithms/alg.sorting/alg.clamp/clamp.comp.pass.cpp
libcxx/trunk/test/std/algorithms/alg.sorting/alg.clamp/clamp.pass.cpp
libcxx/trunk/www/cxx1z_status.html

Modified: 
libcxx/trunk/test/std/algorithms/alg.sorting/alg.clamp/clamp.comp.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/algorithms/alg.sorting/alg.clamp/clamp.comp.pass.cpp?rev=274252=274251=274252=diff
==
--- libcxx/trunk/test/std/algorithms/alg.sorting/alg.clamp/clamp.comp.pass.cpp 
(original)
+++ libcxx/trunk/test/std/algorithms/alg.sorting/alg.clamp/clamp.comp.pass.cpp 
Thu Jun 30 12:52:51 2016
@@ -18,6 +18,20 @@
 #include 
 #include 
 
+struct Tag {
+Tag() : val(0), tag("Default") {}
+Tag(int a, const char *b) : val(a), tag(b) {}
+~Tag() {}
+
+int val;
+const char *tag;
+};
+
+bool eq(const Tag& rhs, const Tag& lhs) { return rhs.val == lhs.val && rhs.tag 
== lhs.tag; }
+// bool operator==(const Tag& rhs, const Tag& lhs) { return rhs.val == 
lhs.val; }
+bool comp (const Tag& rhs, const Tag& lhs) { return rhs.val <  lhs.val; }
+
+
 template 
 void
 test(const T& v, const T& lo, const T& hi, C c, const T& x)
@@ -48,7 +62,60 @@ int main()
 test(x, y, z, std::greater(), y);
 test(y, x, z, std::greater(), y);
 }
-#if _LIBCPP_STD_VER > 11
+
+{
+//  If they're all the same, we should get the value back.
+Tag x{0, "Zero-x"};
+Tag y{0, "Zero-y"};
+Tag z{0, "Zero-z"};
+assert(eq(std::clamp(x, y, z, comp), x));
+assert(eq(std::clamp(y, x, z, comp), y));
+}
+
+{
+//  If it's the same as the lower bound, we get the value back.
+Tag x{0, "Zero-x"};
+Tag y{0, "Zero-y"};
+Tag z{1, "One-z"};
+assert(eq(std::clamp(x, y, z, comp), x));
+assert(eq(std::clamp(y, x, z, comp), y));
+}
+
+{
+//  If it's the same as the upper bound, we get the value back.
+Tag x{1, "One-x"};
+Tag y{0, "Zero-y"};
+Tag z{1, "One-z"};
+assert(eq(std::clamp(x, y, z, comp), x));
+assert(eq(std::clamp(z, y, x, comp), z));
+}
+
+{
+//  If the value is between, we should get the value back
+Tag x{1, "One-x"};
+Tag y{0, "Zero-y"};
+Tag z{2, "Two-z"};
+assert(eq(std::clamp(x, y, z, comp), x));
+assert(eq(std::clamp(y, x, z, comp), x));
+}
+
+{
+//  If the value is less than the 'lo', we should get the lo back.
+Tag x{0, "Zero-x"};
+Tag y{1, "One-y"};
+Tag z{2, "Two-z"};
+assert(eq(std::clamp(x, y, z, comp), y));
+assert(eq(std::clamp(y, x, z, comp), y));
+}
+{
+//  If the value is greater than 'hi', we should get hi back.
+Tag x{2, "Two-x"};
+Tag y{0, "Zero-y"};
+Tag z{1, "One-z"};
+assert(eq(std::clamp(x, y, z, comp), z));
+assert(eq(std::clamp(y, z, x, comp), z));
+}
+
 {
 typedef int T;
 constexpr T x = 1;
@@ -57,5 +124,4 @@ int main()
 static_assert(std::clamp(x, y, z, std::greater()) == y, "" );
 static_assert(std::clamp(y, x, z, std::greater()) == y, "" );
 }
-#endif
 }

Modified: libcxx/trunk/test/std/algorithms/alg.sorting/alg.clamp/clamp.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/algorithms/alg.sorting/alg.clamp/clamp.pass.cpp?rev=274252=274251=274252=diff
==
--- libcxx/trunk/test/std/algorithms/alg.sorting/alg.clamp/clamp.pass.cpp 
(original)
+++ libcxx/trunk/test/std/algorithms/alg.sorting/alg.clamp/clamp.pass.cpp Thu 
Jun 30 12:52:51 2016
@@ -17,6 +17,19 @@
 #include 
 #include 
 
+struct Tag {
+   Tag() : val(0), tag("Default") {}
+   Tag(int a, const char *b) : val(a), tag(b) {}
+   ~Tag() {}
+   
+   int val;
+   const char *tag;
+   };
+   
+bool eq(const Tag& rhs, const Tag& lhs) { return rhs.val == lhs.val && rhs.tag 
== lhs.tag; }
+// bool operator==(const Tag& rhs, const Tag& lhs) { return rhs.val == 
lhs.val; }
+bool operator< (const Tag& rhs, const Tag& lhs) { return rhs.val <  lhs.val; }
+
 template 
 void
 test(const T& a, const T& lo, const T& hi, const T& x)
@@ -47,7 +60,60 @@ int main()
 test(x, y, z, x);
 test(y, x, z, x);
 }
-#if _LIBCPP_STD_VER > 11
+
+{
+//  If they're all the same, we should get the value back.
+Tag x{0, "Zero-x"};
+Tag y{0, "Zero-y"};
+Tag z{0, "Zero-z"};
+assert(eq(std::clamp(x, y, z), x));
+assert(eq(std::clamp(y, x, z), y));
+}
+
+{
+//  If it's the same as the lower bound, we get the value back.
+Tag x{0, "Zero-x"};
+Tag y{0, "Zero-y"};
+Tag z{1, "One-z"};
+assert(eq(std::clamp(x, y, z), x));
+

r274246 - [codeview] Emit qualified display names if -gline-tables-only is on

2016-06-30 Thread Reid Kleckner via cfe-commits
Author: rnk
Date: Thu Jun 30 12:41:31 2016
New Revision: 274246

URL: http://llvm.org/viewvc/llvm-project?rev=274246=rev
Log:
[codeview] Emit qualified display names if -gline-tables-only is on

When -gmlt is on, we don't emit namespace or class scope information,
and the CodeView emission code in LLVM can't compute the fully qualified
name. If we know LLVM won't be able to get the name right, go ahead and
emit the qualified name in the frontend.

We could change our -gmlt emission strategy to include those scopes when
emitting codeview, but that would increase memory usage and slow down
LTO and add more complexity to debug info emission.

The same problem exists when you debug a -gmlt binary with GDB, so we
should consider removing '&& EmitCodeView' from the condition here at
some point in the future after evaluating the impact on object file
size.

Modified:
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/test/CodeGenCXX/debug-info-codeview-display-name.cpp

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=274246=274245=274246=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Thu Jun 30 12:41:31 2016
@@ -185,17 +185,27 @@ StringRef CGDebugInfo::getFunctionName(c
   FunctionTemplateSpecializationInfo *Info =
   FD->getTemplateSpecializationInfo();
 
-  if (!Info && FII)
+  // Emit the unqualified name in normal operation. LLVM and the debugger can
+  // compute the fully qualified name from the scope chain. If we're only
+  // emitting line table info, there won't be any scope chains, so emit the
+  // fully qualified name here so that stack traces are more accurate.
+  // FIXME: Do this when emitting DWARF as well as when emitting CodeView after
+  // evaluating the size impact.
+  bool UseQualifiedName = DebugKind == codegenoptions::DebugLineTablesOnly &&
+  CGM.getCodeGenOpts().EmitCodeView;
+
+  if (!Info && FII && !UseQualifiedName)
 return FII->getName();
 
-  // Otherwise construct human readable name for debug info.
   SmallString<128> NS;
   llvm::raw_svector_ostream OS(NS);
   PrintingPolicy Policy(CGM.getLangOpts());
   Policy.MSVCFormatting = CGM.getCodeGenOpts().EmitCodeView;
+  if (!UseQualifiedName)
+FD->printName(OS);
+  else
+FD->printQualifiedName(OS, Policy);
 
-  // Print the unqualified name with some template arguments.
-  FD->printName(OS);
   // Add any template specialization args.
   if (Info) {
 const TemplateArgumentList *TArgs = Info->TemplateArguments;

Modified: cfe/trunk/test/CodeGenCXX/debug-info-codeview-display-name.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-codeview-display-name.cpp?rev=274246=274245=274246=diff
==
--- cfe/trunk/test/CodeGenCXX/debug-info-codeview-display-name.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/debug-info-codeview-display-name.cpp Thu Jun 30 
12:41:31 2016
@@ -1,14 +1,22 @@
-// RUN: %clang_cc1 -fblocks -debug-info-kind=limited -gcodeview -emit-llvm %s 
-o - -triple=x86_64-pc-win32 -std=c++98 | \
-// RUN:  grep 'DISubprogram' | sed -e 's/.*name: "\([^"]*\)".*/"\1"/' | 
FileCheck %s
+// RUN: %clang_cc1 -fblocks -debug-info-kind=limited -gcodeview -emit-llvm %s \
+// RUN:   -o - -triple=x86_64-pc-win32 -std=c++98 | \
+// RUN:grep 'DISubprogram' | sed -e 's/.*name: "\([^"]*\)".*/"\1"/' | \
+// RUN:FileCheck %s --check-prefix=CHECK --check-prefix=UNQUAL
+// RUN: %clang_cc1 -fblocks -debug-info-kind=line-tables-only -gcodeview 
-emit-llvm %s \
+// RUN:   -o - -triple=x86_64-pc-win32 -std=c++98 | \
+// RUN:grep 'DISubprogram' | sed -e 's/.*name: "\([^"]*\)".*/"\1"/' | \
+// RUN:FileCheck %s --check-prefix=CHECK --check-prefix=QUAL
 
 void freefunc() { }
 // CHECK-DAG: "freefunc"
 
 namespace N {
   int b() { return 0; }
-// CHECK-DAG: "b"
+// UNQUAL-DAG: "b"
+// QUAL-DAG: "N::b"
   namespace { void func() { } }
-// CHECK-DAG: "func"
+// UNQUAL-DAG: "func"
+// QUAL-DAG: "N::`anonymous namespace'::func"
 }
 
 void _c(void) {
@@ -19,19 +27,24 @@ void _c(void) {
 struct foo {
   int operator+(int);
   foo(){}
-// CHECK-DAG: "foo"
+// UNQUAL-DAG: "foo"
+// QUAL-DAG: "foo::foo"
 
   ~foo(){}
-// CHECK-DAG: "~foo"
+// UNQUAL-DAG: "~foo"
+// QUAL-DAG: "foo::~foo"
 
   foo(int i){}
-// CHECK-DAG: "foo"
+// UNQUAL-DAG: "foo"
+// QUAL-DAG: "foo::foo"
 
   foo(char *q){}
-// CHECK-DAG: "foo"
+// UNQUAL-DAG: "foo"
+// QUAL-DAG: "foo::foo"
 
   static foo* static_method() { return 0; }
-// CHECK-DAG: "static_method"
+// UNQUAL-DAG: "static_method"
+// QUAL-DAG: "foo::static_method"
 
 };
 
@@ -40,7 +53,8 @@ void use_foo() {
   foo::static_method();
 }
 
-// CHECK-DAG: "operator+"
+// UNQUAL-DAG: "operator+"
+// QUAL-DAG: "foo::operator+"
 int foo::operator+(int a) { 

Re: [PATCH] D21810: Don't instantiate a full host toolchain in ASTMatchersTest.

2016-06-30 Thread Justin Lebar via cfe-commits
jlebar added a comment.

> But I think this is a reasonable workaround until such an API can be provided.


Should I take that as an LG, or are we waiting for someone else to approve this?


http://reviews.llvm.org/D21810



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


r274245 - Port some more debug info tests on Windows

2016-06-30 Thread Reid Kleckner via cfe-commits
Author: rnk
Date: Thu Jun 30 12:41:27 2016
New Revision: 274245

URL: http://llvm.org/viewvc/llvm-project?rev=274245=rev
Log:
Port some more debug info tests on Windows

Modified:
cfe/trunk/test/CodeGenCXX/debug-info-line.cpp
cfe/trunk/test/CodeGenCXX/debug-info-namespace.cpp
cfe/trunk/test/lit.cfg

Modified: cfe/trunk/test/CodeGenCXX/debug-info-line.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-line.cpp?rev=274245=274244=274245=diff
==
--- cfe/trunk/test/CodeGenCXX/debug-info-line.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/debug-info-line.cpp Thu Jun 30 12:41:27 2016
@@ -1,8 +1,6 @@
-// RUN: %clang_cc1 -w -debug-info-kind=line-tables-only -std=c++11 
-fexceptions -fcxx-exceptions -S -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -w -debug-info-kind=line-tables-only -std=c++11 
-fexceptions -fcxx-exceptions -S -emit-llvm %s -o - -triple %itanium_abi_triple 
| FileCheck %s
 // RUN: %clang_cc1 -w -debug-info-kind=line-tables-only -std=c++11 
-fexceptions -fcxx-exceptions -S -emit-llvm %s -o - -triple i686-linux-gnu | 
FileCheck %s
 
-// XFAIL: win32
-
 int ();
 int *sink();
 extern "C" __complex float complex_src();

Modified: cfe/trunk/test/CodeGenCXX/debug-info-namespace.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-namespace.cpp?rev=274245=274244=274245=diff
==
--- cfe/trunk/test/CodeGenCXX/debug-info-namespace.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/debug-info-namespace.cpp Thu Jun 30 12:41:27 2016
@@ -95,7 +95,7 @@ void B::func_fwd() {}
 // CHECK: [[M11]] = !DIImportedEntity(tag: DW_TAG_imported_declaration, name: 
"X", scope: [[FUNC]], entity: [[CTXT]]
 // CHECK: [[M12]] = !DIImportedEntity(tag: DW_TAG_imported_declaration, name: 
"Y", scope: [[FUNC]], entity: [[M11]]
 // CHECK: [[M13]] = !DIImportedEntity(tag: DW_TAG_imported_declaration, scope: 
[[FUNC]], entity: [[VAR_DECL:![0-9]+]]
-// CHECK: [[VAR_DECL]] = !DIGlobalVariable(name: "var_decl", linkageName: 
"_ZN1A1B8var_declE", scope: [[NS]],{{.*}} line: 8,
+// CHECK: [[VAR_DECL]] = !DIGlobalVariable(name: "var_decl", linkageName: 
"{{[^"]*var_decl[^"]*}}", scope: [[NS]],{{.*}} line: 8,
 // CHECK: [[M14]] = !DIImportedEntity(tag: DW_TAG_imported_declaration, scope: 
[[FUNC]], entity: [[FUNC_DECL:![0-9]+]]
 // CHECK: [[FUNC_DECL]] = !DISubprogram(name: "func_decl",
 // CHECK-SAME:  scope: [[NS]], file: [[FOOCPP]], line: 
9
@@ -111,5 +111,3 @@ void B::func_fwd() {}
 // CHECK-NOLIMIT: !DICompositeType(tag: DW_TAG_structure_type, name: 
"bar",{{.*}} line: 6,
 // CHECK-NOLIMIT-NOT:  DIFlagFwdDecl
 // CHECK-NOLIMIT-SAME: ){{$}}
-
-// REQUIRES: dw2

Modified: cfe/trunk/test/lit.cfg
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/lit.cfg?rev=274245=274244=274245=diff
==
--- cfe/trunk/test/lit.cfg (original)
+++ cfe/trunk/test/lit.cfg Thu Jun 30 12:41:27 2016
@@ -397,10 +397,6 @@ if is_filesystem_case_insensitive():
 if os.path.exists("/dev/fd/0") and sys.platform not in ['cygwin']:
 config.available_features.add('dev-fd-fs')
 
-# DW2 Target
-if not re.match(r'.*-win32$', config.target_triple):
-config.available_features.add('dw2')
-
 # Not set on native MS environment.
 if not re.match(r'.*-win32$', config.target_triple):
 config.available_features.add('non-ms-sdk')


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


Re: [PATCH] D21753: Comprehensive Static Instrumentation (2/2): Clang flag

2016-06-30 Thread Derek Bruening via cfe-commits
bruening added inline comments.


Comment at: docs/CSI.rst:75
@@ +74,3 @@
+  % clang++ -c -O3 -g -fcsi -emit-llvm bar.cpp -o bar.o
+  % clang++ foo.o bar.o my-tool.o libclang_rt.csi-x86_64.a -fuse-ld=gold -flto 
-lrt -ldl -o foo
+

See below: the sanitizers pass the -f flag (-fcsi here) to the link line and 
have the library automatically linked in, which is a simpler usage model than 
the user having to name this static library explicitly.


Comment at: docs/CSI.rst:78
@@ +77,3 @@
+Notice that in the final stage of linking, the tool user also needs to link in
+the static library of the CSI runtime to produce the final TIX.  The runtime
+archive is distributed under the ``build/lib/clang//lib/``

This should not be necessary: as mentioned above, if -fcsi is passed to the 
link line you should be able to have clang automatically add the static csi 
library, just like is done for the sanitizers.


Comment at: docs/CSI.rst:81
@@ +80,3 @@
+directory. We plan to investigate means of linking with the runtime
+automatically in the future, but for the time being, the tool user should link
+it in explicitly.

Hmm, see above comments: is this already implemented and was deliberately split 
from this one for simplicity?


Comment at: docs/CSI.rst:97
@@ +96,3 @@
+* functions,
+* function exits,
+* basic blocks,

Wouldn't the after-hook here be the same as the after-hook for the function 
category?  Generally the reason to have a post-function or function-exit hook 
would be to view or change the return value: couldn't that be done equally 
easily from a post-function hook at the instruction after the call site?  I 
guess I'm asking why this is a separate category.


Comment at: docs/CSI.rst:99
@@ +98,3 @@
+* basic blocks,
+* call sites,
+* loads, and

It seems like there is some redundancy here?  This seems very similar to the 
"functions" category: I'm curious as to why they are separate?


Comment at: docs/CSI.rst:164
@@ +163,3 @@
+library loads.
+
+

Some tools also need thread-local handling: do you plan to provide thread 
initialization and exit hooks in the future?


Comment at: docs/CSI.rst:164
@@ +163,3 @@
+library loads.
+
+

bruening wrote:
> Some tools also need thread-local handling: do you plan to provide thread 
> initialization and exit hooks in the future?
What about a fini or destructor function called at program exit?  Many 
profiling or analysis tools gather data and want to report it or dump it to a 
file at program exit.


Comment at: docs/CSI.rst:173
@@ +172,3 @@
+
+  void __csi_func_entry(const csi_id_t func_id);
+  void __csi_func_exit(const csi_id_t func_exit_id, const csi_id_t func_id);

Generally, tools that hook application functions want to examine the arguments. 
 How does a hook access (or modify) the application function's arguments?


Comment at: docs/CSI.rst:174
@@ +173,3 @@
+  void __csi_func_entry(const csi_id_t func_id);
+  void __csi_func_exit(const csi_id_t func_exit_id, const csi_id_t func_id);
+

Similarly, how does a hook access or change the return value?


Comment at: docs/CSI.rst:181
@@ +180,3 @@
+hook ``__csi_func_exit`` is invoked just before the function returns
+normally).  (We have not yet defined the API for exceptions.)
+The ``func_exit_id`` parameter allows the tool writer to distinguish the

s/normally)/normally/


Comment at: docs/CSI.rst:189
@@ +188,3 @@
+
+CSI also provide instrumentation hooks basic block entry and exit.
+A basic block consists of strands of instructions with no incoming branches

Grammar: provides, for


Comment at: docs/CSI.rst:212
@@ +211,3 @@
+
+CSI provides the following hooks for call sites:
+

See above: I'm not sure why both call sites and function entry hooks are 
needed?  Perhaps there could be some explanation of that here.


Comment at: docs/CSI.rst:221
@@ +220,3 @@
+parameter identifies the called function.  Note that it may not always be
+possible to CSI to produce the function ID corresponds to the called function
+statically --- for example, if a function is called indirectly

Grammar: s/to CSI/for CSI/; s/ID/ID that/


Comment at: docs/CSI.rst:258
@@ +257,3 @@
+plan to extend the CSI to include more property values and incorporate property
+into other types of hooks.
+

Hmm, there seems to be a missing feature in this interface design in general: 
static analysis or static operation of some kind.  Tools often want to take one 
action if a memory address is aligned, but a different one if it's not aligned 
(usually a fastpath when aligned and a slowpath when unaligned).  The compiler 

Re: [PATCH] D18286: [OPENMP] private and firstprivate clauses of teams code generation for nvptx

2016-06-30 Thread Jonas Hahnfeld via cfe-commits
Hahnfeld added a comment.

Hi Carlo,

I think these tests are not yet committed, right?

Thanks,
Jonas


Repository:
  rL LLVM

http://reviews.llvm.org/D18286



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


Re: [PATCH] D20249: [OpenCL] Hierarchical/dynamic parallelism - enqueue kernel in OpenCL 2.0

2016-06-30 Thread Anastasia Stulova via cfe-commits
Anastasia marked 12 inline comments as done.


Comment at: lib/CodeGen/CGBuiltin.cpp:2180-2181
@@ +2179,4 @@
+}
+// Could have events and/or vaargs.
+if (NumArgs >= 5) {
+  if (E->getArg(3)->getType()->isBlockPointerType()) {

bader wrote:
> [Style] Minor suggestion to consider.
> To avoid indentation of almost 100 lines of code inside if statement this can 
> be implemented as:
> if (NumArgs < 5) llvm_unreachable("Unhandled enqueue_kernel signature");
> 
> There is no else branch for that condition anyway.
Would assertion be more appropriate even?


Comment at: lib/Sema/SemaChecking.cpp:145
@@ +144,3 @@
+}
+// Potentially emit standard warnings for implicit conversions if enabled
+// using -Wconversion.

I am reusing C diagnostics functionality here now to keep consistency!


http://reviews.llvm.org/D20249



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


Re: [PATCH] D21803: [libcxxabi] Provide a fallback __cxa_thread_atexit() implementation

2016-06-30 Thread Dimitry Ivanov via cfe-commits
dimitry added inline comments.


Comment at: src/cxa_thread_atexit.cpp:46
@@ +45,3 @@
+  pthread_key_delete(key_);
+}
+

bcraig wrote:
> dimitry wrote:
> > run_dtors() is called when/if libc++.so gets unloaded... but only for the 
> > thread calling dlclose()?
> Most of the dtor magic is on the pthread_key_create side.  pthreads lets you 
> register a per-thread destructor.
> 
> This destructor is only run on process termination (I think).
I meant the call from ~DtorListHolder()


http://reviews.llvm.org/D21803



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


Re: [PATCH] D20249: [OpenCL] Hierarchical/dynamic parallelism - enqueue kernel in OpenCL 2.0

2016-06-30 Thread Anastasia Stulova via cfe-commits
Anastasia updated this revision to Diff 62376.
Anastasia added a comment.

- Fixed style issues
- Added warning diagnostics for conversions of integer types


http://reviews.llvm.org/D20249

Files:
  include/clang/AST/Type.h
  include/clang/Basic/Builtins.def
  include/clang/Basic/Builtins.h
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/Basic/Builtins.cpp
  lib/CodeGen/CGBuiltin.cpp
  lib/Headers/opencl-c.h
  lib/Sema/SemaChecking.cpp
  lib/Sema/SemaInit.cpp
  test/CodeGenOpenCL/cl20-device-side-enqueue.cl
  test/SemaOpenCL/cl20-device-side-enqueue.cl
  test/SemaOpenCL/clang-builtin-version.cl
  test/SemaOpenCL/to_addr_builtin.cl

Index: test/SemaOpenCL/to_addr_builtin.cl
===
--- test/SemaOpenCL/to_addr_builtin.cl
+++ test/SemaOpenCL/to_addr_builtin.cl
@@ -10,43 +10,44 @@
 
   glob = to_global(glob, loc);
 #if __OPENCL_C_VERSION__ < CL_VERSION_2_0
-  // expected-error@-2{{'to_global' requires OpenCL version 2.0 or above}}
+  // expected-warning@-2{{implicit declaration of function 'to_global' is invalid in C99}}
+  // expected-warning@-3{{incompatible integer to pointer conversion assigning to '__global int *' from 'int'}}
 #else
-  // expected-error@-4{{invalid number of arguments to function: 'to_global'}}
+  // expected-error@-5{{invalid number of arguments to function: 'to_global'}}
 #endif
 
   int x;
   glob = to_global(x);
 #if __OPENCL_C_VERSION__ < CL_VERSION_2_0
-  // expected-error@-2{{'to_global' requires OpenCL version 2.0 or above}}
+  // expected-warning@-2{{incompatible integer to pointer conversion assigning to '__global int *' from 'int'}}
 #else
   // expected-error@-4{{invalid argument x to function: 'to_global', expecting a generic pointer argument}}
 #endif
 
   glob = to_global(con);
 #if __OPENCL_C_VERSION__ < CL_VERSION_2_0
-  // expected-error@-2{{'to_global' requires OpenCL version 2.0 or above}}
+  // expected-warning@-2{{incompatible integer to pointer conversion assigning to '__global int *' from 'int'}}
 #else
   // expected-error@-4{{invalid argument con to function: 'to_global', expecting a generic pointer argument}}
 #endif
 
   glob = to_global(con_typedef);
 #if __OPENCL_C_VERSION__ < CL_VERSION_2_0
-  // expected-error@-2{{'to_global' requires OpenCL version 2.0 or above}}
+  // expected-warning@-2{{incompatible integer to pointer conversion assigning to '__global int *' from 'int'}}
 #else
   // expected-error@-4{{invalid argument con_typedef to function: 'to_global', expecting a generic pointer argument}}
 #endif
 
   loc = to_global(glob);
 #if __OPENCL_C_VERSION__ < CL_VERSION_2_0
-  // expected-error@-2{{'to_global' requires OpenCL version 2.0 or above}}
+  // expected-warning@-2{{incompatible integer to pointer conversion assigning to '__local int *' from 'int'}}
 #else
   // expected-error@-4{{assigning '__global int *' to '__local int *' changes address space of pointer}}
 #endif
 
   global char *glob_c = to_global(loc);
 #if __OPENCL_C_VERSION__ < CL_VERSION_2_0
-  // expected-error@-2{{'to_global' requires OpenCL version 2.0 or above}}
+  // expected-warning@-2{{incompatible integer to pointer conversion initializing '__global char *' with an expression of type 'int'}}
 #else
   // expected-warning@-4{{incompatible pointer types initializing '__global char *' with an expression of type '__global int *'}}
 #endif
Index: test/SemaOpenCL/clang-builtin-version.cl
===
--- /dev/null
+++ test/SemaOpenCL/clang-builtin-version.cl
@@ -0,0 +1,44 @@
+// RUN: %clang_cc1 %s -fblocks -verify -pedantic -fsyntax-only -ferror-limit 100
+
+// Confirm CL2.0 Clang builtins are not available in earlier versions
+
+kernel void dse_builtins() {
+  int tmp;
+  enqueue_kernel(tmp, tmp, tmp, ^(void) { // expected-warning{{implicit declaration of function 'enqueue_kernel' is invalid in C99}}
+return;
+  });
+  unsigned size = get_kernel_work_group_size(^(void) { // expected-warning{{implicit declaration of function 'get_kernel_work_group_size' is invalid in C99}}
+return;
+  });
+  size = get_kernel_preferred_work_group_size_multiple(^(void) { // expected-warning{{implicit declaration of function 'get_kernel_preferred_work_group_size_multiple' is invalid in C99}}
+return;
+  });
+}
+
+void pipe_builtins() {
+  int tmp;
+
+  read_pipe(tmp, tmp);  // expected-warning{{implicit declaration of function 'read_pipe' is invalid in C99}}
+  write_pipe(tmp, tmp); // expected-warning{{implicit declaration of function 'write_pipe' is invalid in C99}}
+
+  reserve_read_pipe(tmp, tmp);  // expected-warning{{implicit declaration of function 'reserve_read_pipe' is invalid in C99}}
+  reserve_write_pipe(tmp, tmp); // expected-warning{{implicit declaration of function 'reserve_write_pipe' is invalid in C99}}
+
+  work_group_reserve_read_pipe(tmp, tmp);  // expected-warning{{implicit declaration of function 'work_group_reserve_read_pipe' is invalid in C99}}
+  

[libcxx] r274243 - Implement LWG#2684: 'priority_queue lacking comparator typedef'. We already did this, just added tests

2016-06-30 Thread Marshall Clow via cfe-commits
Author: marshall
Date: Thu Jun 30 11:03:50 2016
New Revision: 274243

URL: http://llvm.org/viewvc/llvm-project?rev=274243=rev
Log:
Implement LWG#2684: 'priority_queue lacking comparator typedef'. We already did 
this, just added tests

Modified:

libcxx/trunk/test/std/containers/container.adaptors/priority.queue/types.pass.cpp
libcxx/trunk/www/cxx1z_status.html

Modified: 
libcxx/trunk/test/std/containers/container.adaptors/priority.queue/types.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/containers/container.adaptors/priority.queue/types.pass.cpp?rev=274243=274242=274243=diff
==
--- 
libcxx/trunk/test/std/containers/container.adaptors/priority.queue/types.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/containers/container.adaptors/priority.queue/types.pass.cpp
 Thu Jun 30 11:03:50 2016
@@ -15,6 +15,7 @@
 // {
 // public:
 // typedef Containercontainer_type;
+// typedef Compare  value_compare; // 
LWG#2684
 // typedef typename container_type::value_type  value_type;
 // typedef typename container_type::reference   reference;
 // typedef typename container_type::const_reference const_reference;
@@ -54,6 +55,9 @@ int main()
 static_assert(( std::is_same::value), "");
 static_assert(( std::is_same::value), "");
 static_assert(( std::is_same::value), "");
+static_assert(( std::is_same::value), "");
+static_assert(( std::is_same::value_compare, std::less >::value), "");
+static_assert(( std::is_same::value_compare, std::greater >::value), "");
 static_assert(( std::uses_allocator::value), "");
 static_assert((!std::uses_allocator, 
std::allocator >::value), "");
 test t;

Modified: libcxx/trunk/www/cxx1z_status.html
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/cxx1z_status.html?rev=274243=274242=274243=diff
==
--- libcxx/trunk/www/cxx1z_status.html (original)
+++ libcxx/trunk/www/cxx1z_status.html Thu Jun 30 11:03:50 2016
@@ -287,7 +287,7 @@
http://wg21.link/LWG2673;>2673status() 
effects cannot be implemented as specifiedOulu
http://wg21.link/LWG2674;>2674Bidirectional iterator 
requirement on path::iterator is very 
expensiveOuluComplete
http://wg21.link/LWG2683;>2683filesystem::copy() says "no 
effects"Oulu
-   http://wg21.link/LWG2684;>2684priority_queue lacking 
comparator typedefOulu
+   http://wg21.link/LWG2684;>2684priority_queue lacking 
comparator typedefOuluComplete
http://wg21.link/LWG2685;>2685shared_ptr 
deleters must not throw on move constructionOulu
http://wg21.link/LWG2687;>2687{inclusive,exclusive}_scan 
misspecifiedOulu
http://wg21.link/LWG2688;>2688clamp 
misses preconditions and has extraneous condition on 
resultOulu


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


[libcxx] r274241 - Implement LWG#2596: 'vector::data() should use addressof'

2016-06-30 Thread Marshall Clow via cfe-commits
Author: marshall
Date: Thu Jun 30 10:50:55 2016
New Revision: 274241

URL: http://llvm.org/viewvc/llvm-project?rev=274241=rev
Log:
Implement LWG#2596: 'vector::data() should use addressof'

Modified:
libcxx/trunk/test/std/containers/sequences/vector/vector.data/data.pass.cpp

libcxx/trunk/test/std/containers/sequences/vector/vector.data/data_const.pass.cpp
libcxx/trunk/www/cxx1z_status.html

Modified: 
libcxx/trunk/test/std/containers/sequences/vector/vector.data/data.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/containers/sequences/vector/vector.data/data.pass.cpp?rev=274241=274240=274241=diff
==
--- libcxx/trunk/test/std/containers/sequences/vector/vector.data/data.pass.cpp 
(original)
+++ libcxx/trunk/test/std/containers/sequences/vector/vector.data/data.pass.cpp 
Thu Jun 30 10:50:55 2016
@@ -17,6 +17,15 @@
 #include "min_allocator.h"
 #include "asan_testing.h"
 
+struct Nasty {
+   Nasty() : i_(0) {}
+   Nasty(int i) : i_(i) {}
+   ~Nasty() {}
+   
+   Nasty * operator&() const { assert(false); return nullptr; }
+   int i_;
+   };
+
 int main()
 {
 {
@@ -26,7 +35,12 @@ int main()
 }
 {
 std::vector v(100);
-assert(v.data() == ());
+assert(v.data() == std::addressof(v.front()));
+assert(is_contiguous_container_asan_correct(v));
+}
+{
+std::vector v(100);
+assert(v.data() == std::addressof(v.front()));
 assert(is_contiguous_container_asan_correct(v));
 }
 #if TEST_STD_VER >= 11
@@ -37,7 +51,12 @@ int main()
 }
 {
 std::vector v(100);
-assert(v.data() == ());
+assert(v.data() == std::addressof(v.front()));
+assert(is_contiguous_container_asan_correct(v));
+}
+{
+std::vector v(100);
+assert(v.data() == std::addressof(v.front()));
 assert(is_contiguous_container_asan_correct(v));
 }
 #endif

Modified: 
libcxx/trunk/test/std/containers/sequences/vector/vector.data/data_const.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/containers/sequences/vector/vector.data/data_const.pass.cpp?rev=274241=274240=274241=diff
==
--- 
libcxx/trunk/test/std/containers/sequences/vector/vector.data/data_const.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/containers/sequences/vector/vector.data/data_const.pass.cpp
 Thu Jun 30 10:50:55 2016
@@ -17,6 +17,15 @@
 #include "min_allocator.h"
 #include "asan_testing.h"
 
+struct Nasty {
+   Nasty() : i_(0) {}
+   Nasty(int i) : i_(i) {}
+   ~Nasty() {}
+   
+   Nasty * operator&() const { assert(false); return nullptr; }
+   int i_;
+   };
+
 int main()
 {
 {
@@ -26,7 +35,12 @@ int main()
 }
 {
 const std::vector v(100);
-assert(v.data() == ());
+assert(v.data() == std::addressof(v.front()));
+assert(is_contiguous_container_asan_correct(v));
+}
+{
+std::vector v(100);
+assert(v.data() == std::addressof(v.front()));
 assert(is_contiguous_container_asan_correct(v));
 }
 #if TEST_STD_VER >= 11
@@ -40,5 +54,10 @@ int main()
 assert(v.data() == ());
 assert(is_contiguous_container_asan_correct(v));
 }
+{
+std::vector v(100);
+assert(v.data() == std::addressof(v.front()));
+assert(is_contiguous_container_asan_correct(v));
+}
 #endif
 }

Modified: libcxx/trunk/www/cxx1z_status.html
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/cxx1z_status.html?rev=274241=274240=274241=diff
==
--- libcxx/trunk/www/cxx1z_status.html (original)
+++ libcxx/trunk/www/cxx1z_status.html Thu Jun 30 10:50:55 2016
@@ -279,7 +279,7 @@
http://wg21.link/LWG2551;>2551[fund.ts.v2] "Exception 
safety" cleanup in library fundamentals requiredOulu
http://wg21.link/LWG2555;>2555[fund.ts.v2] No handling for 
over-aligned types in optionalOulu
http://wg21.link/LWG2573;>2573[fund.ts.v2] 
std::hashstd::experimental::shared_ptr does not work for 
arraysOulu
-   http://wg21.link/LWG2596;>2596vector::data() should use 
addressofOulu
+   http://wg21.link/LWG2596;>2596vector::data() should use 
addressofOuluComplete
http://wg21.link/LWG2667;>2667path::root_directory() 
description is confusingOulu
http://wg21.link/LWG2669;>2669recursive_directory_iterator 
effects refers to non-existent functionsOulu
http://wg21.link/LWG2670;>2670system_complete refers to 
undefined variable 'base'Oulu


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


Re: [PATCH] D21895: CFGBuilder: Fix crash when visiting a range-based for over a dependent type

2016-06-30 Thread Martin Böhme via cfe-commits
mboehme marked an inline comment as done.
mboehme added a comment.

http://reviews.llvm.org/D21895



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


Re: [PATCH] D21895: CFGBuilder: Fix crash when visiting a range-based for over a dependent type

2016-06-30 Thread Martin Böhme via cfe-commits
mboehme updated this revision to Diff 62374.

http://reviews.llvm.org/D21895

Files:
  lib/Analysis/CFG.cpp
  unittests/Analysis/CFGTest.cpp
  unittests/Analysis/CMakeLists.txt
  unittests/CMakeLists.txt

Index: unittests/CMakeLists.txt
===
--- unittests/CMakeLists.txt
+++ unittests/CMakeLists.txt
@@ -13,6 +13,7 @@
 add_subdirectory(Lex)
 add_subdirectory(Driver)
 if(CLANG_ENABLE_STATIC_ANALYZER)
+  add_subdirectory(Analysis)
   add_subdirectory(StaticAnalyzer)
   add_subdirectory(Frontend)
 endif()
Index: unittests/Analysis/CMakeLists.txt
===
--- /dev/null
+++ unittests/Analysis/CMakeLists.txt
@@ -0,0 +1,13 @@
+set(LLVM_LINK_COMPONENTS
+  Support
+  )
+
+add_clang_unittest(CFGTests
+  CFGTest.cpp
+  )
+
+target_link_libraries(CFGTests
+  clangAnalysis
+  clangASTMatchers
+  clangTooling
+  )
Index: unittests/Analysis/CFGTest.cpp
===
--- /dev/null
+++ unittests/Analysis/CFGTest.cpp
@@ -0,0 +1,58 @@
+//===- unittests/Analysis/CFGTest.cpp - CFG tests -===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/Analysis/CFG.h"
+#include "clang/Tooling/Tooling.h"
+#include "gtest/gtest.h"
+#include 
+#include 
+
+namespace clang {
+namespace analysis {
+namespace {
+
+// Constructing a CFG for a range-based for over a dependent type fails (but
+// should not crash).
+TEST(CFG, RangeBasedForOverDependentType) {
+  const char *Code = "class Foo;\n"
+ "template \n"
+ "void f(const T ) {\n"
+ "  for (const Foo *TheFoo : Range) {\n"
+ "  }\n"
+ "}\n";
+
+  class CFGCallback : public ast_matchers::MatchFinder::MatchCallback {
+  public:
+bool SawFunctionBody = false;
+
+void run(const ast_matchers::MatchFinder::MatchResult ) override {
+  const auto *Func = Result.Nodes.getNodeAs("func");
+  Stmt *Body = Func->getBody();
+  if (!Body)
+return;
+  SawFunctionBody = true;
+  std::unique_ptr cfg =
+  CFG::buildCFG(nullptr, Body, Result.Context, CFG::BuildOptions());
+  EXPECT_EQ(nullptr, cfg);
+}
+  } Callback;
+
+  ast_matchers::MatchFinder Finder;
+  Finder.addMatcher(ast_matchers::functionDecl().bind("func"), );
+  std::unique_ptr Factory(
+  tooling::newFrontendActionFactory());
+  std::vector Args = {"-std=c++11"};
+  ASSERT_TRUE(tooling::runToolOnCodeWithArgs(Factory->create(), Code, Args));
+  EXPECT_TRUE(Callback.SawFunctionBody);
+}
+
+} // namespace
+} // namespace analysis
+} // namespace clang
Index: lib/Analysis/CFG.cpp
===
--- lib/Analysis/CFG.cpp
+++ lib/Analysis/CFG.cpp
@@ -3457,6 +3457,8 @@
 // continue statements.
 Block = nullptr;
 Succ = addStmt(S->getInc());
+if (badCFG)
+  return nullptr;
 ContinueJumpTarget = JumpTarget(Succ, ContinueScopePos);
 
 // The starting block for the loop increment is the block that should
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D21337: [CUDA] Give templated device functions internal linkage, templated kernels external linkage.

2016-06-30 Thread Reid Kleckner via cfe-commits
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.

lgtm Doing this in CodeGen seems right.


http://reviews.llvm.org/D21337



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


Re: [PATCH] D21705: Include debug info for nested structs and classes

2016-06-30 Thread Reid Kleckner via cfe-commits
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.

lgtm


http://reviews.llvm.org/D21705



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


[libcxx] r274235 - Implement LWG#2436: 'Comparators for associative containers should always be CopyConstructible'

2016-06-30 Thread Marshall Clow via cfe-commits
Author: marshall
Date: Thu Jun 30 10:11:53 2016
New Revision: 274235

URL: http://llvm.org/viewvc/llvm-project?rev=274235=rev
Log:
Implement LWG#2436: 'Comparators for associative containers should always be 
CopyConstructible'

Added:

libcxx/trunk/test/std/containers/associative/map/map.cons/compare_copy_constructible.fail.cpp

libcxx/trunk/test/std/containers/associative/multimap/multimap.cons/compare_copy_constructible.fail.cpp

libcxx/trunk/test/std/containers/associative/multiset/multiset.cons/compare_copy_constructible.fail.cpp

libcxx/trunk/test/std/containers/associative/set/set.cons/compare_copy_constructible.fail.cpp

libcxx/trunk/test/std/containers/unord/unord.map/unord.map.cnstr/compare_copy_constructible.fail.cpp

libcxx/trunk/test/std/containers/unord/unord.map/unord.map.cnstr/hash_copy_constructible.fail.cpp

libcxx/trunk/test/std/containers/unord/unord.multimap/unord.multimap.cnstr/compare_copy_constructible.fail.cpp

libcxx/trunk/test/std/containers/unord/unord.multimap/unord.multimap.cnstr/hash_copy_constructible.fail.cpp

libcxx/trunk/test/std/containers/unord/unord.multiset/unord.multiset.cnstr/compare_copy_constructible.fail.cpp

libcxx/trunk/test/std/containers/unord/unord.multiset/unord.multiset.cnstr/hash_copy_constructible.fail.cpp

libcxx/trunk/test/std/containers/unord/unord.set/unord.set.cnstr/compare_copy_constructible.fail.cpp

libcxx/trunk/test/std/containers/unord/unord.set/unord.set.cnstr/hash_copy_constructible.fail.cpp
Modified:
libcxx/trunk/include/__hash_table
libcxx/trunk/include/__tree
libcxx/trunk/www/cxx1z_status.html

Modified: libcxx/trunk/include/__hash_table
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__hash_table?rev=274235=274234=274235=diff
==
--- libcxx/trunk/include/__hash_table (original)
+++ libcxx/trunk/include/__hash_table Thu Jun 30 10:11:53 2016
@@ -938,6 +938,10 @@ private:
 typedef allocator_traits<__node_base_allocator> __node_base_traits;
 static_assert((is_same<__node_base_pointer, typename 
__node_base_traits::pointer>::value),
  "Allocator does not rebind pointers in a sane manner.");
+static_assert((is_copy_constructible::value),
+ "Predicate must be copy-constructible.");
+static_assert((is_copy_constructible::value),
+ "Hasher must be copy-constructible.");
 
 private:
 

Modified: libcxx/trunk/include/__tree
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__tree?rev=274235=274234=274235=diff
==
--- libcxx/trunk/include/__tree (original)
+++ libcxx/trunk/include/__tree Thu Jun 30 10:11:53 2016
@@ -946,6 +946,8 @@ private:
 typedef allocator_traits<__node_base_allocator> __node_base_traits;
 static_assert((is_same<__node_base_pointer, typename 
__node_base_traits::pointer>::value),
  "Allocator does not rebind pointers in a sane manner.");
+static_assert((is_copy_constructible::value),
+ "Comparator must be copy-constructible.");
 
 private:
 __node_pointer __begin_node_;

Added: 
libcxx/trunk/test/std/containers/associative/map/map.cons/compare_copy_constructible.fail.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/containers/associative/map/map.cons/compare_copy_constructible.fail.cpp?rev=274235=auto
==
--- 
libcxx/trunk/test/std/containers/associative/map/map.cons/compare_copy_constructible.fail.cpp
 (added)
+++ 
libcxx/trunk/test/std/containers/associative/map/map.cons/compare_copy_constructible.fail.cpp
 Thu Jun 30 10:11:53 2016
@@ -0,0 +1,29 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+// 
+
+// Check that std::map fails to instantiate if the comparison predicate is 
+// not copy-constructible. This is LWG issue 2436
+
+#include 
+
+template 
+struct Comp {
+   bool operator () (const T& lhs, const T& rhs) const { return lhs < rhs; 
}
+
+   Comp () {}
+private:
+   Comp (const Comp &); // declared but not defined
+   };
+
+
+int main() {
+   std::map m;
+}

Added: 
libcxx/trunk/test/std/containers/associative/multimap/multimap.cons/compare_copy_constructible.fail.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/containers/associative/multimap/multimap.cons/compare_copy_constructible.fail.cpp?rev=274235=auto

Re: [PATCH] D21895: CFGBuilder: Fix crash when visiting a range-based for over a dependent type

2016-06-30 Thread Manuel Klimek via cfe-commits
klimek added inline comments.


Comment at: unittests/Analysis/CFGTest.cpp:49
@@ +48,3 @@
+  std::vector Args = {"-std=c++11"};
+  ASSERT_TRUE(tooling::runToolOnCodeWithArgs(Factory->create(), Code, Args));
+}

I think we want to assert that we at least found func once with a body.


http://reviews.llvm.org/D21895



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


[PATCH] D21895: CFGBuilder: Fix crash when visiting a range-based for over a dependent type

2016-06-30 Thread Martin Böhme via cfe-commits
mboehme created this revision.
mboehme added a reviewer: klimek.
mboehme added a subscriber: cfe-commits.

CFG generation is expected to fail in this case, but it should not crash.

Also added a test that reproduces the crash.

http://reviews.llvm.org/D21895

Files:
  lib/Analysis/CFG.cpp
  unittests/Analysis/CFGTest.cpp
  unittests/Analysis/CMakeLists.txt
  unittests/CMakeLists.txt

Index: unittests/CMakeLists.txt
===
--- unittests/CMakeLists.txt
+++ unittests/CMakeLists.txt
@@ -13,6 +13,7 @@
 add_subdirectory(Lex)
 add_subdirectory(Driver)
 if(CLANG_ENABLE_STATIC_ANALYZER)
+  add_subdirectory(Analysis)
   add_subdirectory(StaticAnalyzer)
   add_subdirectory(Frontend)
 endif()
Index: unittests/Analysis/CMakeLists.txt
===
--- /dev/null
+++ unittests/Analysis/CMakeLists.txt
@@ -0,0 +1,13 @@
+set(LLVM_LINK_COMPONENTS
+  Support
+  )
+
+add_clang_unittest(CFGTests
+  CFGTest.cpp
+  )
+
+target_link_libraries(CFGTests
+  clangAnalysis
+  clangASTMatchers
+  clangTooling
+  )
Index: unittests/Analysis/CFGTest.cpp
===
--- /dev/null
+++ unittests/Analysis/CFGTest.cpp
@@ -0,0 +1,54 @@
+//===- unittests/Analysis/CFGTest.cpp - CFG tests -===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/Analysis/CFG.h"
+#include "clang/Tooling/Tooling.h"
+#include "gtest/gtest.h"
+#include 
+#include 
+
+namespace clang {
+namespace analysis {
+namespace {
+
+// Constructing a CFG for a range-based for over a dependent type fails (but
+// should not crash).
+TEST(CFG, RangeBasedForOverDependentType) {
+  const char *Code = "class Foo;\n"
+ "template \n"
+ "void f(const T ) {\n"
+ "  for (const Foo *TheFoo : Range) {\n"
+ "  }\n"
+ "}\n";
+
+  class CFGCallback : public ast_matchers::MatchFinder::MatchCallback {
+  public:
+void run(const ast_matchers::MatchFinder::MatchResult ) override {
+  const auto *Func = Result.Nodes.getNodeAs("func");
+  Stmt *Body = Func->getBody();
+  if (!Body)
+return;
+  std::unique_ptr cfg =
+  CFG::buildCFG(nullptr, Body, Result.Context, CFG::BuildOptions());
+  EXPECT_EQ(nullptr, cfg);
+}
+  } Callback;
+
+  ast_matchers::MatchFinder Finder;
+  Finder.addMatcher(ast_matchers::functionDecl().bind("func"), );
+  std::unique_ptr Factory(
+  tooling::newFrontendActionFactory());
+  std::vector Args = {"-std=c++11"};
+  ASSERT_TRUE(tooling::runToolOnCodeWithArgs(Factory->create(), Code, Args));
+}
+
+} // namespace
+} // namespace analysis
+} // namespace clang
Index: lib/Analysis/CFG.cpp
===
--- lib/Analysis/CFG.cpp
+++ lib/Analysis/CFG.cpp
@@ -3457,6 +3457,8 @@
 // continue statements.
 Block = nullptr;
 Succ = addStmt(S->getInc());
+if (badCFG)
+  return nullptr;
 ContinueJumpTarget = JumpTarget(Succ, ContinueScopePos);
 
 // The starting block for the loop increment is the block that should
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D21637: [libcxx] Don't use pthread initializers in constexpr constructors

2016-06-30 Thread Julien Ramseier via cfe-commits
elram updated this revision to Diff 62339.

http://reviews.llvm.org/D21637

Files:
  include/__mutex_base

Index: include/__mutex_base
===
--- include/__mutex_base
+++ include/__mutex_base
@@ -34,16 +34,20 @@
 
 class _LIBCPP_TYPE_VIS _LIBCPP_THREAD_SAFETY_ANNOTATION(capability("mutex")) 
mutex
 {
+#ifndef _LIBCPP_HAS_NO_CONSTEXPR
+__libcpp_mutex_t __m_ = _LIBCPP_MUTEX_INITIALIZER;
+#else
 __libcpp_mutex_t __m_;
+#endif
 
 public:
 _LIBCPP_INLINE_VISIBILITY
 #ifndef _LIBCPP_HAS_NO_CONSTEXPR
-constexpr mutex() _NOEXCEPT : __m_(_LIBCPP_MUTEX_INITIALIZER) {}
+constexpr mutex() _NOEXCEPT _LIBCPP_DEFAULT
 #else
 mutex() _NOEXCEPT {__m_ = (__libcpp_mutex_t)_LIBCPP_MUTEX_INITIALIZER;}
 #endif
- ~mutex();
+~mutex();
 
 private:
 mutex(const mutex&);// = delete;
@@ -287,13 +291,18 @@
 
 class _LIBCPP_TYPE_VIS condition_variable
 {
-__libcpp_condvar_t  __cv_;
+#ifndef _LIBCPP_HAS_NO_CONSTEXPR
+__libcpp_condvar_t __cv_ = _LIBCPP_CONDVAR_INITIALIZER;
+#else
+__libcpp_condvar_t __cv_;
+#endif
+
 public:
 _LIBCPP_INLINE_VISIBILITY
 #ifndef _LIBCPP_HAS_NO_CONSTEXPR
-constexpr condition_variable() : __cv_(_LIBCPP_CONDVAR_INITIALIZER) {}
+constexpr condition_variable() _NOEXCEPT _LIBCPP_DEFAULT
 #else
-condition_variable() {__cv_ = 
(__libcpp_condvar_t)_LIBCPP_CONDVAR_INITIALIZER;}
+condition_variable() _NOEXCEPT {__cv_ = 
(__libcpp_condvar_t)_LIBCPP_CONDVAR_INITIALIZER;}
 #endif
 ~condition_variable();
 


Index: include/__mutex_base
===
--- include/__mutex_base
+++ include/__mutex_base
@@ -34,16 +34,20 @@
 
 class _LIBCPP_TYPE_VIS _LIBCPP_THREAD_SAFETY_ANNOTATION(capability("mutex")) mutex
 {
+#ifndef _LIBCPP_HAS_NO_CONSTEXPR
+__libcpp_mutex_t __m_ = _LIBCPP_MUTEX_INITIALIZER;
+#else
 __libcpp_mutex_t __m_;
+#endif
 
 public:
 _LIBCPP_INLINE_VISIBILITY
 #ifndef _LIBCPP_HAS_NO_CONSTEXPR
-constexpr mutex() _NOEXCEPT : __m_(_LIBCPP_MUTEX_INITIALIZER) {}
+constexpr mutex() _NOEXCEPT _LIBCPP_DEFAULT
 #else
 mutex() _NOEXCEPT {__m_ = (__libcpp_mutex_t)_LIBCPP_MUTEX_INITIALIZER;}
 #endif
- ~mutex();
+~mutex();
 
 private:
 mutex(const mutex&);// = delete;
@@ -287,13 +291,18 @@
 
 class _LIBCPP_TYPE_VIS condition_variable
 {
-__libcpp_condvar_t  __cv_;
+#ifndef _LIBCPP_HAS_NO_CONSTEXPR
+__libcpp_condvar_t __cv_ = _LIBCPP_CONDVAR_INITIALIZER;
+#else
+__libcpp_condvar_t __cv_;
+#endif
+
 public:
 _LIBCPP_INLINE_VISIBILITY
 #ifndef _LIBCPP_HAS_NO_CONSTEXPR
-constexpr condition_variable() : __cv_(_LIBCPP_CONDVAR_INITIALIZER) {}
+constexpr condition_variable() _NOEXCEPT _LIBCPP_DEFAULT
 #else
-condition_variable() {__cv_ = (__libcpp_condvar_t)_LIBCPP_CONDVAR_INITIALIZER;}
+condition_variable() _NOEXCEPT {__cv_ = (__libcpp_condvar_t)_LIBCPP_CONDVAR_INITIALIZER;}
 #endif
 ~condition_variable();
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D18035: [GCC] PR23529 Mangler part of attrbute abi_tag support

2016-06-30 Thread Dmitry Polukhin via cfe-commits
DmitryPolukhin added a comment.

Richard, thank you for the review!

I decided to commit this patch without waiting for GCC response to 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71712 (that is last compatibility 
issues in comparison with GCC6) so more people could test Clang implementation 
of ABI tags on real apps and report issues if any. All, please let me know 
(file bug and add me in CC) if you observe any issues with abi_tag 
implementation in Clang.


Repository:
  rL LLVM

http://reviews.llvm.org/D18035



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


Re: [PATCH] D21678: Fix For pr28288 - Error message in shift of vector values

2016-06-30 Thread Vladimir Yakovlev via cfe-commits
vbyakovl updated this revision to Diff 62345.

http://reviews.llvm.org/D21678

Files:
  llvm/tools/clang/lib/Sema/SemaExpr.cpp
  llvm/tools/clang/test/Sema/shift.c

Index: llvm/tools/clang/lib/Sema/SemaExpr.cpp
===
--- llvm/tools/clang/lib/Sema/SemaExpr.cpp
+++ llvm/tools/clang/lib/Sema/SemaExpr.cpp
@@ -8592,11 +8592,10 @@
 << RHS.get()->getSourceRange();
 }
 
-/// \brief Return the resulting type when an OpenCL vector is shifted
+/// \brief Return the resulting type when an vector is shifted
 ///by a scalar or vector shift amount.
-static QualType checkOpenCLVectorShift(Sema ,
-   ExprResult , ExprResult ,
-   SourceLocation Loc, bool IsCompAssign) {
+static QualType checkVectorShift(Sema , ExprResult , ExprResult ,
+ SourceLocation Loc, bool IsCompAssign) {
   // OpenCL v1.1 s6.3.j says RHS can be a vector only if LHS is a vector.
   if (!LHS.get()->getType()->isVectorType()) {
 S.Diag(Loc, diag::err_shift_rhs_only_vector)
@@ -8636,9 +8635,8 @@
   }
 
   if (RHSVecTy) {
-// OpenCL v1.1 s6.3.j says that for vector types, the operators
-// are applied component-wise. So if RHS is a vector, then ensure
-// that the number of elements is the same as LHS...
+// For vector types, the operators are applied component-wise. So if RHS is
+// a vector, then ensure that the number of elements is the same as LHS...
 if (RHSVecTy->getNumElements() != LHSVecTy->getNumElements()) {
   S.Diag(Loc, diag::err_typecheck_vector_lengths_not_equal)
 << LHS.get()->getType() << RHS.get()->getType()
@@ -8664,23 +8662,19 @@
   // Vector shifts promote their scalar inputs to vector type.
   if (LHS.get()->getType()->isVectorType() ||
   RHS.get()->getType()->isVectorType()) {
-if (LangOpts.OpenCL)
-  return checkOpenCLVectorShift(*this, LHS, RHS, Loc, IsCompAssign);
 if (LangOpts.ZVector) {
   // The shift operators for the z vector extensions work basically
-  // like OpenCL shifts, except that neither the LHS nor the RHS is
+  // like general shifts, except that neither the LHS nor the RHS is
   // allowed to be a "vector bool".
   if (auto LHSVecType = LHS.get()->getType()->getAs())
 if (LHSVecType->getVectorKind() == VectorType::AltiVecBool)
   return InvalidOperands(Loc, LHS, RHS);
   if (auto RHSVecType = RHS.get()->getType()->getAs())
 if (RHSVecType->getVectorKind() == VectorType::AltiVecBool)
   return InvalidOperands(Loc, LHS, RHS);
-  return checkOpenCLVectorShift(*this, LHS, RHS, Loc, IsCompAssign);
+  return checkVectorShift(*this, LHS, RHS, Loc, IsCompAssign);
 }
-return CheckVectorOperands(LHS, RHS, Loc, IsCompAssign,
-   /*AllowBothBool*/true,
-   /*AllowBoolConversions*/false);
+return checkVectorShift(*this, LHS, RHS, Loc, IsCompAssign);
   }
 
   // Shifts don't perform usual arithmetic conversions, they just do integer
Index: llvm/tools/clang/test/Sema/shift.c
===
--- llvm/tools/clang/test/Sema/shift.c
+++ llvm/tools/clang/test/Sema/shift.c
@@ -67,3 +67,24 @@
 (void) (x >> 80); // no-warning
   (void) (x >> 80); // expected-warning {{shift count >= width of type}}
 }
+
+typedef unsigned vec16 __attribute__ ((vector_size (16)));
+typedef unsigned vec8 __attribute__ ((vector_size (8)));
+
+void
+vect_shift_1 (vec16 *x)
+{
+   *x = *x << 4 ;
+}
+
+void
+vect_shift_2 (vec16 *x,vec16 y)
+{
+   *x = *x << y ;
+}
+
+void
+vect_shift_3 (vec16 *x,vec8 y)
+{
+   *x = *x << y ; // expected-error {{vector operands do not have the same 
number of elements}}
+}


Index: llvm/tools/clang/lib/Sema/SemaExpr.cpp
===
--- llvm/tools/clang/lib/Sema/SemaExpr.cpp
+++ llvm/tools/clang/lib/Sema/SemaExpr.cpp
@@ -8592,11 +8592,10 @@
 << RHS.get()->getSourceRange();
 }
 
-/// \brief Return the resulting type when an OpenCL vector is shifted
+/// \brief Return the resulting type when an vector is shifted
 ///by a scalar or vector shift amount.
-static QualType checkOpenCLVectorShift(Sema ,
-   ExprResult , ExprResult ,
-   SourceLocation Loc, bool IsCompAssign) {
+static QualType checkVectorShift(Sema , ExprResult , ExprResult ,
+ SourceLocation Loc, bool IsCompAssign) {
   // OpenCL v1.1 s6.3.j says RHS can be a vector only if LHS is a vector.
   if (!LHS.get()->getType()->isVectorType()) {
 S.Diag(Loc, diag::err_shift_rhs_only_vector)
@@ -8636,9 +8635,8 @@
   }
 
   if (RHSVecTy) {
-// OpenCL v1.1 s6.3.j says that for vector types, the operators
-// are applied component-wise. So if RHS is a vector, then ensure
-// 

r274220 - AMDGPU: Set amdgpu_kernel calling convention for OpenCL kernels.

2016-06-30 Thread Nikolay Haustov via cfe-commits
Author: nhaustov
Date: Thu Jun 30 04:06:33 2016
New Revision: 274220

URL: http://llvm.org/viewvc/llvm-project?rev=274220=rev
Log:
AMDGPU: Set amdgpu_kernel calling convention for OpenCL kernels.

Summary:
Summary:
Change Clang calling convention SpirKernel to OpenCLKernel.
Set calling convention OpenCLKernel for amdgcn as well.
Add virtual method .getOpenCLKernelCallingConv() to TargetCodeGenInfo
and use it to set target calling convention for AMDGPU and SPIR.
Update tests.

Reviewers: rsmith, tstellarAMD, Anastasia, yaxunl

Subscribers: kzhuravl, cfe-commits

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

Added:
cfe/trunk/test/CodeGenOpenCL/amdgpu-call-kernel.cl   (with props)
cfe/trunk/test/CodeGenOpenCL/amdgpu-calling-conv.cl
Modified:
cfe/trunk/include/clang/Basic/Specifiers.h
cfe/trunk/lib/AST/ItaniumMangle.cpp
cfe/trunk/lib/AST/Type.cpp
cfe/trunk/lib/AST/TypePrinter.cpp
cfe/trunk/lib/Basic/Targets.cpp
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/lib/CodeGen/CodeGenTypes.h
cfe/trunk/lib/CodeGen/TargetInfo.cpp
cfe/trunk/lib/CodeGen/TargetInfo.h
cfe/trunk/lib/Sema/SemaType.cpp
cfe/trunk/test/CodeGenOpenCL/amdgpu-num-gpr-attr.cl
cfe/trunk/tools/libclang/CXType.cpp

Modified: cfe/trunk/include/clang/Basic/Specifiers.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Specifiers.h?rev=274220=274219=274220=diff
==
--- cfe/trunk/include/clang/Basic/Specifiers.h (original)
+++ cfe/trunk/include/clang/Basic/Specifiers.h Thu Jun 30 04:06:33 2016
@@ -241,7 +241,7 @@ namespace clang {
 CC_AAPCS_VFP,   // __attribute__((pcs("aapcs-vfp")))
 CC_IntelOclBicc, // __attribute__((intel_ocl_bicc))
 CC_SpirFunction, // default for OpenCL functions on SPIR target
-CC_SpirKernel,   // inferred for OpenCL kernels on SPIR target
+CC_OpenCLKernel, // inferred for OpenCL kernels
 CC_Swift,// __attribute__((swiftcall))
 CC_PreserveMost, // __attribute__((preserve_most))
 CC_PreserveAll,  // __attribute__((preserve_all))
@@ -257,7 +257,7 @@ namespace clang {
 case CC_X86Pascal:
 case CC_X86VectorCall:
 case CC_SpirFunction:
-case CC_SpirKernel:
+case CC_OpenCLKernel:
 case CC_Swift:
   return false;
 default:

Modified: cfe/trunk/lib/AST/ItaniumMangle.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ItaniumMangle.cpp?rev=274220=274219=274220=diff
==
--- cfe/trunk/lib/AST/ItaniumMangle.cpp (original)
+++ cfe/trunk/lib/AST/ItaniumMangle.cpp Thu Jun 30 04:06:33 2016
@@ -2161,7 +2161,7 @@ StringRef CXXNameMangler::getCallingConv
   case CC_AAPCS_VFP:
   case CC_IntelOclBicc:
   case CC_SpirFunction:
-  case CC_SpirKernel:
+  case CC_OpenCLKernel:
   case CC_PreserveMost:
   case CC_PreserveAll:
 // FIXME: we should be mangling all of the above.

Modified: cfe/trunk/lib/AST/Type.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Type.cpp?rev=274220=274219=274220=diff
==
--- cfe/trunk/lib/AST/Type.cpp (original)
+++ cfe/trunk/lib/AST/Type.cpp Thu Jun 30 04:06:33 2016
@@ -2642,7 +2642,7 @@ StringRef FunctionType::getNameForCallCo
   case CC_AAPCS_VFP: return "aapcs-vfp";
   case CC_IntelOclBicc: return "intel_ocl_bicc";
   case CC_SpirFunction: return "spir_function";
-  case CC_SpirKernel: return "spir_kernel";
+  case CC_OpenCLKernel: return "opencl_kernel";
   case CC_Swift: return "swiftcall";
   case CC_PreserveMost: return "preserve_most";
   case CC_PreserveAll: return "preserve_all";

Modified: cfe/trunk/lib/AST/TypePrinter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/TypePrinter.cpp?rev=274220=274219=274220=diff
==
--- cfe/trunk/lib/AST/TypePrinter.cpp (original)
+++ cfe/trunk/lib/AST/TypePrinter.cpp Thu Jun 30 04:06:33 2016
@@ -725,7 +725,7 @@ void TypePrinter::printFunctionProtoAfte
   OS << " __attribute__((sysv_abi))";
   break;
 case CC_SpirFunction:
-case CC_SpirKernel:
+case CC_OpenCLKernel:
   // Do nothing. These CCs are not available as attributes.
   break;
 case CC_Swift:

Modified: cfe/trunk/lib/Basic/Targets.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=274220=274219=274220=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Thu Jun 30 04:06:33 2016
@@ -2137,6 +2137,16 @@ public:
   Opts.cl_khr_3d_image_writes = 1;
 }
   }
+
+  CallingConvCheckResult checkCallingConvention(CallingConv CC) const override 
{
+switch (CC) {
+  default:
+return CCCR_Warning;
+  case 

Re: [PATCH] D21803: [libcxxabi] Provide a fallback __cxa_thread_atexit() implementation

2016-06-30 Thread Ben Craig via cfe-commits
bcraig added a comment.

In http://reviews.llvm.org/D21803#470564, @joerg wrote:

> On the topic of __cxa_thread_atexit, was it ever specified how it interacts 
> with things like thread cancellation?


I don't think it's officially specified anywhere.  C++ threads don't have a 
cancel method.  The POSIX spec doesn't speak about the C++ ABI.  The Itanium 
ABI could talk about this, but hasn't yet.

I think this implementation does the right thing with regards to cancellation 
though.  POSIX says that first cancellation cleanup handlers are called, then 
thread-specific data destructors are called.  pthread_cancel is still a really 
bad idea due to how it (doesn't) interact with RAII, but at least TLS data 
won't get leaked.



Comment at: src/cxa_thread_atexit.cpp:46
@@ +45,3 @@
+  pthread_key_delete(key_);
+}
+

dimitry wrote:
> run_dtors() is called when/if libc++.so gets unloaded... but only for the 
> thread calling dlclose()?
Most of the dtor magic is on the pthread_key_create side.  pthreads lets you 
register a per-thread destructor.

This destructor is only run on process termination (I think).


http://reviews.llvm.org/D21803



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


Re: [PATCH] D20857: [clang-tidy] Add modernize-explicit-operator-bool check.

2016-06-30 Thread Murray Cumming via cfe-commits
murrayc added a comment.

I'd still be perfectly happy if just the simple check for implicit operator 
bool was accepted.


http://reviews.llvm.org/D20857



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


Re: [PATCH] D20857: [clang-tidy] Add modernize-explicit-operator-bool check.

2016-06-30 Thread Murray Cumming via cfe-commits
murrayc updated this revision to Diff 62355.
murrayc marked an inline comment as done.
murrayc added a comment.

Same as previous patch, but with a tiny suggested whitespace corretion.


http://reviews.llvm.org/D20857

Files:
  clang-tidy/modernize/CMakeLists.txt
  clang-tidy/modernize/ExplicitOperatorBoolCheck.cpp
  clang-tidy/modernize/ExplicitOperatorBoolCheck.h
  clang-tidy/modernize/ModernizeTidyModule.cpp
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/modernize-explicit-operator-bool.rst
  test/clang-tidy/modernize-explicit-operator-bool-void-pointer.cpp
  test/clang-tidy/modernize-explicit-operator-bool.cpp

Index: test/clang-tidy/modernize-explicit-operator-bool.cpp
===
--- /dev/null
+++ test/clang-tidy/modernize-explicit-operator-bool.cpp
@@ -0,0 +1,19 @@
+// RUN: %check_clang_tidy %s modernize-explicit-operator-bool %t -- -- -std=c++11
+
+// This should trigger the check:
+class SomethingBad {
+  operator bool() const {
+// CHECK-MESSAGES: :[[@LINE-1]]:3: warning: operator bool declaration is not explicit [modernize-explicit-operator-bool]
+return something != 0;
+  }
+
+  int something = 0;
+};
+
+class SomethingGood {
+  explicit operator bool() const {
+return something != 0;
+  }
+
+  int something = 0;
+};
Index: test/clang-tidy/modernize-explicit-operator-bool-void-pointer.cpp
===
--- /dev/null
+++ test/clang-tidy/modernize-explicit-operator-bool-void-pointer.cpp
@@ -0,0 +1,46 @@
+// RUN: %check_clang_tidy %s modernize-explicit-operator-bool %t -- -- -std=c++11
+
+// This should trigger the check:
+class SomethingBad {
+  operator const void *() const {
+// CHECK-MESSAGES: :[[@LINE-1]]:3: warning: implicit operator const void* declaration should probably be explicit operator bool [modernize-explicit-operator-bool]
+return reinterpret_cast(something != 0);
+  }
+
+  int something = 0;
+};
+
+class SomethingGood {
+  // Note: Use modernize-explicit-operator-bool to check for implicit operator bool.
+  explicit operator bool() const {
+return something != 0;
+  }
+
+  int something = 0;
+};
+
+class SomethingGoodExplicitConstVoidPtr {
+  explicit operator const void *() const {
+return 
+  }
+
+  const int something = 0;
+};
+
+class SomethingGoodExplicitNonConstVoidPtr {
+  explicit operator void *() {
+return 
+  }
+
+  int something = 0;
+};
+
+class SomethingGoodNonConstVoidPtr {
+  // A non-const void* is unlikely to to be meant as operator bool before C++11
+  // let us use explicit.
+  operator void *() {
+return 
+  }
+
+  int something = 0;
+};
Index: docs/clang-tidy/checks/modernize-explicit-operator-bool.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/modernize-explicit-operator-bool.rst
@@ -0,0 +1,28 @@
+.. title:: clang-tidy - modernize-explicit-operator-bool
+
+modernize-explicit-operator-bool
+
+
+This check finds implicit ``operator bool`` overloads and inserts the
+``explicit`` keyword, which is available since C++11.
+
+Without the ``explicit`` keyword, the implicit ``bool`` overload can allow
+objects to be compared accidentally. For instance, even when objects `a` and
+`b` have no ``operator ==`` overloads, an implicit ``operator bool`` would allow
+`a == b` to compile because both `a` and `b` can be implictly converted to
+``bool``.
+
+This check also finds implicit ``operator const void*`` overloads. These were
+often used before C++11 to avoid implicit conversions to ``bool`` when providing
+an ``operator bool`` overload.
+
+To disable the check for ``operator const void*`` overloads, you may set
+The :option:`WarnOnOperatorVoidPointer` option to 1.
+
+.. code-block:: c++
+
+  operator bool () const;
+
+  // becomes
+
+  explicit operator bool () const;
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -93,6 +93,7 @@
misc-virtual-near-miss
modernize-avoid-bind
modernize-deprecated-headers
+   modernize-explicit-operator-bool
modernize-loop-convert
modernize-make-shared
modernize-make-unique
Index: docs/ReleaseNotes.rst
===
--- docs/ReleaseNotes.rst
+++ docs/ReleaseNotes.rst
@@ -204,6 +204,13 @@
 
   Replaces C standard library headers with their C++ alternatives.
 
+- New `modernize-explicit-operator-bool
+  `_ check
+
+  Adds the ``explicit`` keyword to ``operator bool`` overloads.
+  Also finds ``operator const void*`` overloads, which should often be
+  ``explicit operator bool`` overloads.
+
 - New `modernize-make-shared
   

Re: [PATCH] D21833: [clang-tidy] Fix more enum declaration cases in misc-unused-using-decls check.

2016-06-30 Thread Haojian Wu via cfe-commits
hokein updated this revision to Diff 62354.
hokein added a comment.

enumType is already in ASTMatcher now.


http://reviews.llvm.org/D21833

Files:
  clang-tidy/misc/UnusedUsingDeclsCheck.cpp
  test/clang-tidy/misc-unused-using-decls.cpp

Index: test/clang-tidy/misc-unused-using-decls.cpp
===
--- test/clang-tidy/misc-unused-using-decls.cpp
+++ test/clang-tidy/misc-unused-using-decls.cpp
@@ -44,11 +44,13 @@
 extern ostream cout;
 ostream (ostream );
 
-enum Color {
-  Green,
-  Red,
-  Yellow
-};
+enum Color1 { Green };
+
+enum Color2 { Red };
+
+enum Color3 { Yellow };
+
+enum Color4 { Blue };
 
 }  // namespace n
 
@@ -126,11 +128,13 @@
 using n::H;
 }
 
-using n::Color;
-// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: using decl 'Color' is unused
+using n::Color1;
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: using decl 'Color1' is unused
 using n::Green;
 // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: using decl 'Green' is unused
-using n::Red;
+using n::Color2;
+using n::Color3;
+using n::Blue;
 
 // - Usages -
 void f(B b);
@@ -144,5 +148,7 @@
   UsedFunc();
   UsedTemplateFunc();
   cout << endl;
-  int t = Red;
+  Color2 color2;
+  int t1 = Color3::Yellow;
+  int t2 = Blue;
 }
Index: clang-tidy/misc/UnusedUsingDeclsCheck.cpp
===
--- clang-tidy/misc/UnusedUsingDeclsCheck.cpp
+++ clang-tidy/misc/UnusedUsingDeclsCheck.cpp
@@ -31,6 +31,7 @@
 void UnusedUsingDeclsCheck::registerMatchers(MatchFinder *Finder) {
   Finder->addMatcher(usingDecl(isExpansionInMainFile()).bind("using"), this);
   auto DeclMatcher = hasDeclaration(namedDecl().bind("used"));
+  Finder->addMatcher(loc(enumType(DeclMatcher)), this);
   Finder->addMatcher(loc(recordType(DeclMatcher)), this);
   Finder->addMatcher(loc(templateSpecializationType(DeclMatcher)), this);
   Finder->addMatcher(declRefExpr().bind("used"), this);
@@ -94,6 +95,8 @@
   removeFromFoundDecls(VD);
 } else if (const auto *ECD = dyn_cast(DRE->getDecl())) {
   removeFromFoundDecls(ECD);
+  if (const auto *ET = ECD->getType()->getAs())
+removeFromFoundDecls(ET->getDecl());
 }
   }
   // Check the uninstantiated template function usage.


Index: test/clang-tidy/misc-unused-using-decls.cpp
===
--- test/clang-tidy/misc-unused-using-decls.cpp
+++ test/clang-tidy/misc-unused-using-decls.cpp
@@ -44,11 +44,13 @@
 extern ostream cout;
 ostream (ostream );
 
-enum Color {
-  Green,
-  Red,
-  Yellow
-};
+enum Color1 { Green };
+
+enum Color2 { Red };
+
+enum Color3 { Yellow };
+
+enum Color4 { Blue };
 
 }  // namespace n
 
@@ -126,11 +128,13 @@
 using n::H;
 }
 
-using n::Color;
-// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: using decl 'Color' is unused
+using n::Color1;
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: using decl 'Color1' is unused
 using n::Green;
 // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: using decl 'Green' is unused
-using n::Red;
+using n::Color2;
+using n::Color3;
+using n::Blue;
 
 // - Usages -
 void f(B b);
@@ -144,5 +148,7 @@
   UsedFunc();
   UsedTemplateFunc();
   cout << endl;
-  int t = Red;
+  Color2 color2;
+  int t1 = Color3::Yellow;
+  int t2 = Blue;
 }
Index: clang-tidy/misc/UnusedUsingDeclsCheck.cpp
===
--- clang-tidy/misc/UnusedUsingDeclsCheck.cpp
+++ clang-tidy/misc/UnusedUsingDeclsCheck.cpp
@@ -31,6 +31,7 @@
 void UnusedUsingDeclsCheck::registerMatchers(MatchFinder *Finder) {
   Finder->addMatcher(usingDecl(isExpansionInMainFile()).bind("using"), this);
   auto DeclMatcher = hasDeclaration(namedDecl().bind("used"));
+  Finder->addMatcher(loc(enumType(DeclMatcher)), this);
   Finder->addMatcher(loc(recordType(DeclMatcher)), this);
   Finder->addMatcher(loc(templateSpecializationType(DeclMatcher)), this);
   Finder->addMatcher(declRefExpr().bind("used"), this);
@@ -94,6 +95,8 @@
   removeFromFoundDecls(VD);
 } else if (const auto *ECD = dyn_cast(DRE->getDecl())) {
   removeFromFoundDecls(ECD);
+  if (const auto *ET = ECD->getType()->getAs())
+removeFromFoundDecls(ET->getDecl());
 }
   }
   // Check the uninstantiated template function usage.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D21637: [libcxx] Don't use pthread initializers in constexpr constructors

2016-06-30 Thread Joerg Sonnenberger via cfe-commits
On Thu, Jun 30, 2016 at 06:37:59AM +, Eric Fiselier wrote:
> EricWF requested changes to this revision.
> EricWF added a comment.
> This revision now requires changes to proceed.
> 
> C++03 does not support default member initializers but libc++ provides both 
> of these classes an extensions in C++03.
> C++03 also does not support defaulted special members.

The bigger question for me would be whether Clang (and/or GCC) supports
them in (extended) C++03 mode.

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


Re: [PATCH] D21836: [AVX512][BUILTIN][vpermilps][intrinsics] Fixing two incorrect IMM check.

2016-06-30 Thread Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL274224: [AVX512][BUILTIN][vpermilps][intrinsics] Fixing two 
incorrect IMM check. (authored by mzuckerm).

Changed prior to commit:
  http://reviews.llvm.org/D21836?vs=62212=62353#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D21836

Files:
  cfe/trunk/lib/Sema/SemaChecking.cpp

Index: cfe/trunk/lib/Sema/SemaChecking.cpp
===
--- cfe/trunk/lib/Sema/SemaChecking.cpp
+++ cfe/trunk/lib/Sema/SemaChecking.cpp
@@ -1389,7 +1389,6 @@
   case X86::BI__builtin_ia32_extractf32x4_mask:
   case X86::BI__builtin_ia32_extracti32x4_mask:
   case X86::BI__builtin_ia32_vpermilpd_mask:
-  case X86::BI__builtin_ia32_vpermilps_mask:
   case X86::BI__builtin_ia32_extractf64x2_512_mask:
   case X86::BI__builtin_ia32_extracti64x2_512_mask:
 i = 1; l = 0; u = 3;
@@ -1461,7 +1460,6 @@
   case X86::BI__builtin_ia32_roundps256:
   case X86::BI__builtin_ia32_roundpd256:
   case X86::BI__builtin_ia32_vpermilpd256_mask:
-  case X86::BI__builtin_ia32_vpermilps256_mask:
 i = 1; l = 0; u = 15;
 break;
   case X86::BI__builtin_ia32_roundss:
@@ -1541,7 +1539,6 @@
   case X86::BI__builtin_ia32_psrlwi128_mask:
   case X86::BI__builtin_ia32_psrlwi256_mask:
   case X86::BI__builtin_ia32_vpermilpd512_mask:
-  case X86::BI__builtin_ia32_vpermilps512_mask:
   case X86::BI__builtin_ia32_psradi128_mask:
   case X86::BI__builtin_ia32_psradi256_mask:
   case X86::BI__builtin_ia32_psradi512_mask:
@@ -1566,6 +1563,9 @@
   case X86::BI__builtin_ia32_fpclasspd512_mask:
   case X86::BI__builtin_ia32_fpclasssd_mask:
   case X86::BI__builtin_ia32_fpcla_mask:
+  case X86::BI__builtin_ia32_vpermilps_mask:
+  case X86::BI__builtin_ia32_vpermilps256_mask:
+  case X86::BI__builtin_ia32_vpermilps512_mask:
 i = 1; l = 0; u = 255;
 break;
   case X86::BI__builtin_ia32_palignr:


Index: cfe/trunk/lib/Sema/SemaChecking.cpp
===
--- cfe/trunk/lib/Sema/SemaChecking.cpp
+++ cfe/trunk/lib/Sema/SemaChecking.cpp
@@ -1389,7 +1389,6 @@
   case X86::BI__builtin_ia32_extractf32x4_mask:
   case X86::BI__builtin_ia32_extracti32x4_mask:
   case X86::BI__builtin_ia32_vpermilpd_mask:
-  case X86::BI__builtin_ia32_vpermilps_mask:
   case X86::BI__builtin_ia32_extractf64x2_512_mask:
   case X86::BI__builtin_ia32_extracti64x2_512_mask:
 i = 1; l = 0; u = 3;
@@ -1461,7 +1460,6 @@
   case X86::BI__builtin_ia32_roundps256:
   case X86::BI__builtin_ia32_roundpd256:
   case X86::BI__builtin_ia32_vpermilpd256_mask:
-  case X86::BI__builtin_ia32_vpermilps256_mask:
 i = 1; l = 0; u = 15;
 break;
   case X86::BI__builtin_ia32_roundss:
@@ -1541,7 +1539,6 @@
   case X86::BI__builtin_ia32_psrlwi128_mask:
   case X86::BI__builtin_ia32_psrlwi256_mask:
   case X86::BI__builtin_ia32_vpermilpd512_mask:
-  case X86::BI__builtin_ia32_vpermilps512_mask:
   case X86::BI__builtin_ia32_psradi128_mask:
   case X86::BI__builtin_ia32_psradi256_mask:
   case X86::BI__builtin_ia32_psradi512_mask:
@@ -1566,6 +1563,9 @@
   case X86::BI__builtin_ia32_fpclasspd512_mask:
   case X86::BI__builtin_ia32_fpclasssd_mask:
   case X86::BI__builtin_ia32_fpcla_mask:
+  case X86::BI__builtin_ia32_vpermilps_mask:
+  case X86::BI__builtin_ia32_vpermilps256_mask:
+  case X86::BI__builtin_ia32_vpermilps512_mask:
 i = 1; l = 0; u = 255;
 break;
   case X86::BI__builtin_ia32_palignr:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


  1   2   >