[PATCH] D27800: Add overload of TransformToPotentiallyEvaluated for TypeSourceInfo

[Paulo Matos via Phabricator via cfe-commits]

pmatos added a comment.

Apologies for the delay over the holiday season, I will look into this later on 
after office hours.


https://reviews.llvm.org/D27800



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

[PATCH] D26244: [Driver] Prefer libraries installed next to Clang over those from GCC

[Chandler Carruth via Phabricator via cfe-commits]

chandlerc requested changes to this revision.
chandlerc added a comment.
This revision now requires changes to proceed.

There are some issues with this patch currently.

At a basic level, it needs well crafted test cases. You can find out how to 
write them by looking at other Driver tests.

But at a deeper level, the change here will be an very significant and 
potentially very disruptive change. While libunwind is your motivation, it 
could well have a dramatic impact on the selected set of libraries for links. 
I'm very concerned to make this kind of change without a *lot* of careful 
testing, and a very clear rationale about why this is the right search order 
*for all libraries*, not just libunwind. Because this applies to all libraries. 
=]


https://reviews.llvm.org/D26244



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

[PATCH] D20428: Tracking exception specification source locations

[don hinton via Phabricator via cfe-commits]

hintonda added a comment.

Richard, is it okay to commit this?


https://reviews.llvm.org/D20428



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

[PATCH] D26244: [Driver] Prefer libraries installed next to Clang over those from GCC

[Jonas Hahnfeld via Phabricator via cfe-commits]

Hahnfeld added a comment.

This change doesn't break existing tests but maybe I should extend `linux-ld.c` 
and so on?

About the impact: Which libraries are there next to clang that could conflict 
with the system? When I look at my current installation dir:

- `libLLVM*`, `libclang*`, `liblld*` libraries which should be fine to use
- `libc++`, `libc++experimental`, `libc++abi` and `libunwind` which we really 
want to use IMO
- OpenMP runtime(s) which are fine to use (or even better than the system 
default)
- I'm not sure about `libLTO` but I *think* that users do not link to this 
library directly?


https://reviews.llvm.org/D26244



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

[PATCH] D28404: IRGen: Add optnone attribute on function during O0

[Chandler Carruth via Phabricator via cfe-commits]

chandlerc added a comment.

In https://reviews.llvm.org/D28404#640862, @probinson wrote:

> In https://reviews.llvm.org/D28404#640682, @mehdi_amini wrote:
>
> > > I'm now thinking along the lines of a `-foptimize-off` flag (bikesheds 
> > > welcome) which would set the default for the pragma to 'off'.  How is 
> > > that different than what you wanted for `-O0`?  It is defined in terms of 
> > > an existing pragma, which is WAY easier to explain and WAY easier to 
> > > implement.  And, it still lets us say that `-c -O0 -flto` is a mistake, 
> > > if that seems like a useful thing to say.
> >
> > Well -O0 being actually "disable optimization", I found "way easier" to 
> > handle everything the same way (pragma, command line, etc.). I kind of find 
> > it confusing for the user to differentiate `-O0` from `-foptimize=off`. 
> > What is supposed to change between the two?
>
>
> There is a pedantic difference, rooted in the still-true factoid that O0 != 
> optnone.
>  If we redefine LTO as "Link Time Operation" (rather than Optimization; see 
> my reply to Duncan)  then `-O0 -flto` is no longer an oxymoron, but using the 
> attribute to imply the optimization level is still not good fidelity to what 
> the user asked for.


I have to say, I don't understand the confusion or problem here...

For me, the arguments you're raising against -O0 and -flto don't hold up on 
closer inspection:

- O0 != optnone: correct. But this is only visible in LTO. And in LTO, Os != 
optsize, and Oz != minsize. But we use optsize and minsize to communicate 
between the compilation and the LTO step to the best of our ability the intent 
of the programmer. It appears we can use optnone exactly the same way here.

- optnone isn't *really* no optimizations: clearly this is true, but then 
neither is -O0. We run the always inliner, a couple of other passes, and we run 
several parts of the code generators optimizer. I understand why optnone 
deficiencies (ie, too many optimizations) might be frustrating, but having 
*more users* seems likely to make this *better*.

- There is no use case for -O0 + -flto: I really don't understand this. CFI and 
other whole program analysis or semantic transformations (*not* optimizations) 
require LTO but not any particular pipeline. And I *really* want the ability to 
bisect files going into an LTO build to chase miscompiles. There are large 
systems built to manipulate flags that are much more efficient and accessible 
than modifying source code. It seems an entirely reasonable (and quite low 
cost) feature. The fact that the LTO acronym stands for Link Time Optimization 
seems like a relatively unimportant thing. It is just an acronym and a name. We 
shouldn't let it preclude interesting use cases.

But all of this seems like an attempt to argue "you are wrong to have your use 
case". I personally find that an unproductive line of discussion. I would 
suggest instead we look at this differently:

For example, you might ask: could we find some other way to solve the problem 
you are trying to solve here? Suggesting an alternative approach would seem 
constructive. So far, all we've got is modify source code, but I think that 
there is a clear explanation of why that doesn't address the particular use 
case.

You might also ask: is supporting this feature a reasonable maintenance burden 
for Clang to address the use case? That seems like a productive discussion. For 
example, I *am* concerned about the increasing attribute noise at -O0. I don't 
think it is something to be dismissed. However, given the options we have 
today, it seems like the most effective way to address this use case and I 
don't have any better ideas to solve the problems Mehdi is solving here.

But I'm also not one of the most active maintainers writing patches, fixing 
bugs, and improving the IRGen layer. So ultimately, I defer on the maintenance 
issue to those maintainers.


https://reviews.llvm.org/D28404



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

[libcxx] r291550 - Mark tests as unsupported under libcpp-no-exceptions

[Roger Ferrer Ibanez via cfe-commits]

Author: rogfer01
Date: Tue Jan 10 02:48:48 2017
New Revision: 291550

URL: http://llvm.org/viewvc/llvm-project?rev=291550&view=rev
Log:
Mark tests as unsupported under libcpp-no-exceptions

The destructor of std::promise needs to construct a std::future_error
exception so it calls std::make_exception_ptr. But under
libcpp-no-exceptions this will trigger an abort.

Differential Revision: https://reviews.llvm.org/D27614


Modified:
libcxx/trunk/test/std/thread/futures/futures.shared_future/dtor.pass.cpp
libcxx/trunk/test/std/thread/futures/futures.unique_future/dtor.pass.cpp

Modified: 
libcxx/trunk/test/std/thread/futures/futures.shared_future/dtor.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/thread/futures/futures.shared_future/dtor.pass.cpp?rev=291550&r1=291549&r2=291550&view=diff
==
--- libcxx/trunk/test/std/thread/futures/futures.shared_future/dtor.pass.cpp 
(original)
+++ libcxx/trunk/test/std/thread/futures/futures.shared_future/dtor.pass.cpp 
Tue Jan 10 02:48:48 2017
@@ -7,7 +7,7 @@
 //
 
//===--===//
 //
-// XFAIL: libcpp-no-exceptions
+// UNSUPPORTED: libcpp-no-exceptions
 // UNSUPPORTED: libcpp-has-no-threads
 // UNSUPPORTED: c++98, c++03
 

Modified: 
libcxx/trunk/test/std/thread/futures/futures.unique_future/dtor.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/thread/futures/futures.unique_future/dtor.pass.cpp?rev=291550&r1=291549&r2=291550&view=diff
==
--- libcxx/trunk/test/std/thread/futures/futures.unique_future/dtor.pass.cpp 
(original)
+++ libcxx/trunk/test/std/thread/futures/futures.unique_future/dtor.pass.cpp 
Tue Jan 10 02:48:48 2017
@@ -7,7 +7,7 @@
 //
 
//===--===//
 //
-// XFAIL: libcpp-no-exceptions
+// UNSUPPORTED: libcpp-no-exceptions
 // UNSUPPORTED: libcpp-has-no-threads
 // UNSUPPORTED: c++98, c++03
 


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

[PATCH] D27614: Mark tests as unsupported under libcpp-no-exceptions

[Roger Ferrer Ibanez via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL291550: Mark tests as unsupported under libcpp-no-exceptions 
(authored by rogfer01).

Changed prior to commit:
  https://reviews.llvm.org/D27614?vs=80877&id=83782#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D27614

Files:
  libcxx/trunk/test/std/thread/futures/futures.shared_future/dtor.pass.cpp
  libcxx/trunk/test/std/thread/futures/futures.unique_future/dtor.pass.cpp


Index: libcxx/trunk/test/std/thread/futures/futures.unique_future/dtor.pass.cpp
===
--- libcxx/trunk/test/std/thread/futures/futures.unique_future/dtor.pass.cpp
+++ libcxx/trunk/test/std/thread/futures/futures.unique_future/dtor.pass.cpp
@@ -7,7 +7,7 @@
 //
 
//===--===//
 //
-// XFAIL: libcpp-no-exceptions
+// UNSUPPORTED: libcpp-no-exceptions
 // UNSUPPORTED: libcpp-has-no-threads
 // UNSUPPORTED: c++98, c++03
 
Index: libcxx/trunk/test/std/thread/futures/futures.shared_future/dtor.pass.cpp
===
--- libcxx/trunk/test/std/thread/futures/futures.shared_future/dtor.pass.cpp
+++ libcxx/trunk/test/std/thread/futures/futures.shared_future/dtor.pass.cpp
@@ -7,7 +7,7 @@
 //
 
//===--===//
 //
-// XFAIL: libcpp-no-exceptions
+// UNSUPPORTED: libcpp-no-exceptions
 // UNSUPPORTED: libcpp-has-no-threads
 // UNSUPPORTED: c++98, c++03
 


Index: libcxx/trunk/test/std/thread/futures/futures.unique_future/dtor.pass.cpp
===
--- libcxx/trunk/test/std/thread/futures/futures.unique_future/dtor.pass.cpp
+++ libcxx/trunk/test/std/thread/futures/futures.unique_future/dtor.pass.cpp
@@ -7,7 +7,7 @@
 //
 //===--===//
 //
-// XFAIL: libcpp-no-exceptions
+// UNSUPPORTED: libcpp-no-exceptions
 // UNSUPPORTED: libcpp-has-no-threads
 // UNSUPPORTED: c++98, c++03
 
Index: libcxx/trunk/test/std/thread/futures/futures.shared_future/dtor.pass.cpp
===
--- libcxx/trunk/test/std/thread/futures/futures.shared_future/dtor.pass.cpp
+++ libcxx/trunk/test/std/thread/futures/futures.shared_future/dtor.pass.cpp
@@ -7,7 +7,7 @@
 //
 //===--===//
 //
-// XFAIL: libcpp-no-exceptions
+// UNSUPPORTED: libcpp-no-exceptions
 // UNSUPPORTED: libcpp-has-no-threads
 // UNSUPPORTED: c++98, c++03
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r291551 - Fix rejects-valid with default member initializers exposed by r291318.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Tue Jan 10 02:51:46 2017
New Revision: 291551

URL: http://llvm.org/viewvc/llvm-project?rev=291551&view=rev
Log:
Fix rejects-valid with default member initializers exposed by r291318.

Don't prematurely clean up an RAII object; there's another RAII object in the
same scope that tries to save and restore the same member!

Modified:
cfe/trunk/lib/Sema/SemaTemplateInstantiate.cpp
cfe/trunk/test/SemaCXX/cxx0x-class.cpp

Modified: cfe/trunk/lib/Sema/SemaTemplateInstantiate.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaTemplateInstantiate.cpp?rev=291551&r1=291550&r2=291551&view=diff
==
--- cfe/trunk/lib/Sema/SemaTemplateInstantiate.cpp (original)
+++ cfe/trunk/lib/Sema/SemaTemplateInstantiate.cpp Tue Jan 10 02:51:46 2017
@@ -2264,9 +2264,6 @@ bool Sema::InstantiateInClassInitializer
   if (auto *L = getASTMutationListener())
 L->DefaultMemberInitializerInstantiated(Instantiation);
 
-  // Exit the scope of this instantiation.
-  SavedContext.pop();
-
   // Return true if the in-class initializer is still missing.
   return !Instantiation->getInClassInitializer();
 }

Modified: cfe/trunk/test/SemaCXX/cxx0x-class.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/cxx0x-class.cpp?rev=291551&r1=291550&r2=291551&view=diff
==
--- cfe/trunk/test/SemaCXX/cxx0x-class.cpp (original)
+++ cfe/trunk/test/SemaCXX/cxx0x-class.cpp Tue Jan 10 02:51:46 2017
@@ -37,3 +37,11 @@ namespace Foo {
 int y = x;
   };
 }
+
+// Instantiating another default member initializer while parsing one should
+// not cause us to mess up the 'this' override.
+template struct DefaultMemberTemplate { int n = 0; };
+class DefaultMemberInitSelf {
+  DefaultMemberTemplate t = {};
+  int *p = &t.n;
+};


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

Re: r253495 - [Sema] Don't work around a malformed AST

[Vassil Vassilev via cfe-commits]

On 18/11/15 20:49, David Majnemer via cfe-commits wrote:

Author: majnemer
Date: Wed Nov 18 13:49:19 2015
New Revision: 253495

URL: http://llvm.org/viewvc/llvm-project?rev=253495&view=rev
Log:
[Sema] Don't work around a malformed AST

We created a malformed TemplateSpecializationType: it was dependent but
had a RecordType as it's canonical type.  This would lead getAs to
crash.  r249090 worked around this but we should fix this for real by
providing a more appropriate template specialization type as the
canonical type.

This fixes PR24246.

Modified:
 cfe/trunk/lib/Sema/SemaLookup.cpp
 cfe/trunk/lib/Sema/SemaTemplate.cpp

Modified: cfe/trunk/lib/Sema/SemaLookup.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaLookup.cpp?rev=253495&r1=253494&r2=253495&view=diff
==
--- cfe/trunk/lib/Sema/SemaLookup.cpp (original)
+++ cfe/trunk/lib/Sema/SemaLookup.cpp Wed Nov 18 13:49:19 2015
@@ -3890,8 +3890,6 @@ void TypoCorrectionConsumer::addNamespac
auto &Types = SemaRef.getASTContext().getTypes();
for (unsigned I = 0; I != Types.size(); ++I) {
  const auto *TI = Types[I];
-if (!TI->isClassType() && isa(TI))
-  continue;
  if (CXXRecordDecl *CD = TI->getAsCXXRecordDecl()) {
CD = CD->getCanonicalDecl();
if (!CD->isDependentType() && !CD->isAnonymousStructOrUnion() &&

Modified: cfe/trunk/lib/Sema/SemaTemplate.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaTemplate.cpp?rev=253495&r1=253494&r2=253495&view=diff
==
--- cfe/trunk/lib/Sema/SemaTemplate.cpp (original)
+++ cfe/trunk/lib/Sema/SemaTemplate.cpp Wed Nov 18 13:49:19 2015
@@ -6408,7 +6408,17 @@ Sema::ActOnClassTemplateSpecialization(S
  if (!PrevDecl)
ClassTemplate->AddSpecialization(Specialization, InsertPos);
  
-CanonType = Context.getTypeDeclType(Specialization);

+if (CurContext->isDependentContext()) {
+  // -fms-extensions permits specialization of nested classes without
+  // fully specializing the outer class(es).
+  assert(getLangOpts().MicrosoftExt &&
+ "Only possible with -fms-extensions!");
+  TemplateName CanonTemplate = Context.getCanonicalTemplateName(Name);
+  CanonType = Context.getTemplateSpecializationType(
Out of curiosity, could we use getCanonicalTemplateSpecializationType 
here and produce one less type?

+  CanonTemplate, Converted.data(), Converted.size());
+} else {
+  CanonType = Context.getTypeDeclType(Specialization);
+}
}
  
// C++ [temp.expl.spec]p6:



___
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

r291552 - Remove fixme, use ASTContext::getCanonicalTemplateSpecializationType.

[Vassil Vassilev via cfe-commits]

Author: vvassilev
Date: Tue Jan 10 03:09:09 2017
New Revision: 291552

URL: http://llvm.org/viewvc/llvm-project?rev=291552&view=rev
Log:
Remove fixme, use ASTContext::getCanonicalTemplateSpecializationType.

Reviewed by Richard Smith (D28306).

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

Modified: cfe/trunk/lib/Sema/SemaTemplate.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaTemplate.cpp?rev=291552&r1=291551&r2=291552&view=diff
==
--- cfe/trunk/lib/Sema/SemaTemplate.cpp (original)
+++ cfe/trunk/lib/Sema/SemaTemplate.cpp Tue Jan 10 03:09:09 2017
@@ -2328,15 +2328,7 @@ QualType Sema::CheckTemplateIdType(Templ
 // A have identical types when A is declared as:
 //
 //   template struct A;
-TemplateName CanonName = Context.getCanonicalTemplateName(Name);
-CanonType = Context.getTemplateSpecializationType(CanonName,
-  Converted);
-
-// FIXME: CanonType is not actually the canonical type, and unfortunately
-// it is a TemplateSpecializationType that we will never use again.
-// In the future, we need to teach getTemplateSpecializationType to only
-// build the canonical type and return that to us.
-CanonType = Context.getCanonicalType(CanonType);
+CanonType = Context.getCanonicalTemplateSpecializationType(Name, 
Converted);
 
 // This might work out to be a current instantiation, in which
 // case the canonical type needs to be the InjectedClassNameType.
@@ -3444,7 +3436,7 @@ SubstDefaultTemplateArgument(Sema &SemaR
  SourceLocation TemplateLoc,
  SourceLocation RAngleLoc,
  TemplateTypeParmDecl *Param,
- SmallVectorImpl &Converted) {
+ SmallVectorImpl &Converted) {
   TypeSourceInfo *ArgType = Param->getDefaultArgumentInfo();
 
   // If the argument type is dependent, instantiate it now based


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

[PATCH] D28512: [libc++] Pair _aligned_malloc with _aligned_free

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai created this revision.
smeenai added reviewers: compnerd, EricWF, mclow.lists.
smeenai added a subscriber: cfe-commits.

Attempting to pair an `_aligned_malloc` with a regular free causes heap
corruption. Pairing with `_aligned_free` is required instead.

Makes the following libc++ tests pass on Windows:

  
std/language.support/support.dynamic/new.delete/new.delete.array/new_align_val_t.pass.cpp
  
std/language.support/support.dynamic/new.delete/new.delete.array/new_align_val_t_nothrow.pass.cpp
  
std/language.support/support.dynamic/new.delete/new.delete.single/new_align_val_t.pass.cpp
  
std/language.support/support.dynamic/new.delete/new.delete.single/new_align_val_t_nothrow.pass.cpp


https://reviews.llvm.org/D28512

Files:
  src/new.cpp


Index: src/new.cpp
===
--- src/new.cpp
+++ src/new.cpp
@@ -198,7 +198,11 @@
 operator delete(void* ptr, std::align_val_t) _NOEXCEPT
 {
 if (ptr)
+#if defined(_LIBCPP_MSVCRT)
+::_aligned_free(ptr);
+#else
 ::free(ptr);
+#endif
 }
 
 _LIBCPP_WEAK


Index: src/new.cpp
===
--- src/new.cpp
+++ src/new.cpp
@@ -198,7 +198,11 @@
 operator delete(void* ptr, std::align_val_t) _NOEXCEPT
 {
 if (ptr)
+#if defined(_LIBCPP_MSVCRT)
+::_aligned_free(ptr);
+#else
 ::free(ptr);
+#endif
 }
 
 _LIBCPP_WEAK
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D28306: Remove fixme, use ASTContext::getCanonicalTemplateSpecializationType

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev closed this revision.
v.g.vassilev added a comment.

Landed in r291552.


Repository:
  rL LLVM

https://reviews.llvm.org/D28306



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

[PATCH] D26244: [Driver] Prefer libraries installed next to Clang over those from GCC

[Jonas Hahnfeld via Phabricator via cfe-commits]

Hahnfeld updated this revision to Diff 83784.
Hahnfeld added a comment.

Add test case to check that

- `bin/../lib` is the first library path by default
- user-specified `-L` preceeds


https://reviews.llvm.org/D26244

Files:
  lib/Driver/ToolChains.cpp
  test/Driver/clang-libraries.c


Index: test/Driver/clang-libraries.c
===
--- /dev/null
+++ test/Driver/clang-libraries.c
@@ -0,0 +1,24 @@
+// Check that libraries installed next to Clang are preferred over those from 
GCC.
+
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: --target=x86_64-unknown-linux 
--gcc-toolchain=%S/Inputs/basic_linux_tree/usr \
+// RUN:   | FileCheck --check-prefix=CHECK-DEFAULT %s
+
+// CHECK-DEFAULT: "[[CLANG_BIN:[^"]+]]/clang"
+// CHECK-DEFAULT: "{{.*}}ld{{(.exe)?}}"
+// CHECK-DEFAULT-NOT: "-L
+// CHECK-DEFAULT: "-L[[CLANG_BIN]]/../lib
+
+
+// Check that manual library paths preceed the default ones.
+
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: --target=x86_64-unknown-linux 
--gcc-toolchain=%S/Inputs/basic_linux_tree/usr \
+// RUN: -L%S/Inputs/basic_linux_tree/usr/lib \
+// RUN:   | FileCheck --check-prefix=CHECK-MANUAL %s
+
+// CHECK-MANUAL: "[[CLANG_BIN:[^"]+]]/clang"
+// CHECK-MANUAL: "{{.*}}ld{{(.exe)?}}"
+// CHECK-MANUAL: "-L{{[^"]*}}Inputs/basic_linux_tree/usr/lib
+// CHECK-MANUAL-NOT: "-L
+// CHECK-MANUAL: "-L[[CLANG_BIN]]/../lib
Index: lib/Driver/ToolChains.cpp
===
--- lib/Driver/ToolChains.cpp
+++ lib/Driver/ToolChains.cpp
@@ -4161,6 +4161,17 @@
   const std::string OSLibDir = getOSLibDir(Triple, Args);
   const std::string MultiarchTriple = getMultiarchTriple(D, Triple, SysRoot);
 
+  // Similar to the logic for GCC below, if we currently running Clang inside
+  // of the requested system root, add its parent library paths to those
+  // searched.
+  // FIXME: It's not clear whether we should use the driver's installed
+  // directory ('Dir' below) or the ResourceDir.
+  if (StringRef(D.Dir).startswith(SysRoot)) {
+addPathIfExists(D, D.Dir + "/../lib/" + MultiarchTriple, Paths);
+addPathIfExists(D, D.Dir + "/../" + OSLibDir, Paths);
+addPathIfExists(D, D.Dir + "/../lib", Paths);
+  }
+
   // Add the multilib suffixed paths where they are available.
   if (GCCInstallation.isValid()) {
 const llvm::Triple &GCCTriple = GCCInstallation.getTriple();
@@ -4214,16 +4225,6 @@
 }
   }
 
-  // Similar to the logic for GCC above, if we currently running Clang inside
-  // of the requested system root, add its parent library paths to
-  // those searched.
-  // FIXME: It's not clear whether we should use the driver's installed
-  // directory ('Dir' below) or the ResourceDir.
-  if (StringRef(D.Dir).startswith(SysRoot)) {
-addPathIfExists(D, D.Dir + "/../lib/" + MultiarchTriple, Paths);
-addPathIfExists(D, D.Dir + "/../" + OSLibDir, Paths);
-  }
-
   addPathIfExists(D, SysRoot + "/lib/" + MultiarchTriple, Paths);
   addPathIfExists(D, SysRoot + "/lib/../" + OSLibDir, Paths);
   addPathIfExists(D, SysRoot + "/usr/lib/" + MultiarchTriple, Paths);
@@ -4260,14 +4261,6 @@
   addPathIfExists(D, LibPath, Paths);
   }
 
-  // Similar to the logic for GCC above, if we are currently running Clang
-  // inside of the requested system root, add its parent library path to those
-  // searched.
-  // FIXME: It's not clear whether we should use the driver's installed
-  // directory ('Dir' below) or the ResourceDir.
-  if (StringRef(D.Dir).startswith(SysRoot))
-addPathIfExists(D, D.Dir + "/../lib", Paths);
-
   addPathIfExists(D, SysRoot + "/lib", Paths);
   addPathIfExists(D, SysRoot + "/usr/lib", Paths);
 }


Index: test/Driver/clang-libraries.c
===
--- /dev/null
+++ test/Driver/clang-libraries.c
@@ -0,0 +1,24 @@
+// Check that libraries installed next to Clang are preferred over those from GCC.
+
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: --target=x86_64-unknown-linux --gcc-toolchain=%S/Inputs/basic_linux_tree/usr \
+// RUN:   | FileCheck --check-prefix=CHECK-DEFAULT %s
+
+// CHECK-DEFAULT: "[[CLANG_BIN:[^"]+]]/clang"
+// CHECK-DEFAULT: "{{.*}}ld{{(.exe)?}}"
+// CHECK-DEFAULT-NOT: "-L
+// CHECK-DEFAULT: "-L[[CLANG_BIN]]/../lib
+
+
+// Check that manual library paths preceed the default ones.
+
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: --target=x86_64-unknown-linux --gcc-toolchain=%S/Inputs/basic_linux_tree/usr \
+// RUN: -L%S/Inputs/basic_linux_tree/usr/lib \
+// RUN:   | FileCheck --check-prefix=CHECK-MANUAL %s
+
+// CHECK-MANUAL: "[[CLANG_BIN:[^"]+]]/clang"
+// CHECK-MANUAL: "{{.*}}ld{{(.exe)?}}"
+// CHECK-MANUAL: "-L{{[^"]*}}Inputs/basic_linux_tree/usr/lib
+// CHECK-MANUAL-NOT: "-L
+// CHECK-MANUAL: "-L[[CLANG_BIN]]/../lib
Index: lib/Driver/ToolChains.cpp

[PATCH] D26244: [Driver] Prefer libraries installed next to Clang over those from GCC

[Chandler Carruth via Phabricator via cfe-commits]

chandlerc added a comment.

In https://reviews.llvm.org/D26244#641076, @Hahnfeld wrote:

> This change doesn't break existing tests but maybe I should extend 
> `linux-ld.c` and so on?
>
> About the impact: Which libraries are there next to clang that could conflict 
> with the system? When I look at my current installation dir:
>
> - `libLLVM*`, `libclang*`, `liblld*` libraries which should be fine to use
> - `libc++`, `libc++experimental`, `libc++abi` and `libunwind` which we really 
> want to use IMO
> - OpenMP runtime(s) which are fine to use (or even better than the system 
> default)
> - I'm not sure about `libLTO` but I *think* that users do not link to this 
> library directly?


Those are just the libriaries LLVM is installing.

If it is installed into a prefix, say, /opt/mumble/{bin,lib,...} along with 
other libraries, then suddenly that directory is searched in a very different 
place.

I'm not arguing one way or the other here. I'm pointing out that this is a 
*huge* change to make. It will cause a large number of users to silently have a 
different library search path than they have had before, something that has 
been fairly stable for several years. So whatever we do must be considered very 
carefully.


https://reviews.llvm.org/D26244



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

[PATCH] D21279: Fix some issues in clang-format's AlignConsecutive modes

[Ben Harper via Phabricator via cfe-commits]

bmharper added a comment.

Hi @enyquist,
I'd like to guess that this patch will solve your problem, but I'm not intimate 
enough with this code to give you a definitive answer. I hope we can get this 
merged soon, so that you can just run it and see.

Ben


https://reviews.llvm.org/D21279



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

[PATCH] D28467: [Sema] Add warning for unused lambda captures

[Alex Lorenz via Phabricator via cfe-commits]

arphaman added a comment.

I think that the patch would be neater if you add "-Wno-unused-lambda-capture" 
to the options for all of the tests that are modified by this patch in the CXX/ 
directory. This would avoid redundant `(void)` uses and ensure that the 
`(void)` uses won't interfere with the original intent where things might be 
only used in the capture list.


https://reviews.llvm.org/D28467



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

[PATCH] D28503: Documentation for the newly added x86 intrinsics.

[michael zuckerman via Phabricator via cfe-commits]

m_zuckerman added a comment.

For my intrinsics ( _mm256_cvtsd_f64, _mm256_cvtsi256_si32 and 
_mm256_cvtss_f32) - ** LGTM**.


Repository:
  rL LLVM

https://reviews.llvm.org/D28503



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

[PATCH] D28278: [StaticAnalyzer] dont show wrong 'garbage value' warning when there is array index out of bounds

[Daniel Marjamäki via Phabricator via cfe-commits]

danielmarjamaki added a comment.

In https://reviews.llvm.org/D28278#639710, @xazax.hun wrote:

> Did you experience any problems with the array out of bounds check lately? In 
> case it was stable on large code-bases and did not give too many false 
> positives, I think it might be worth to move that check out of alpha at the 
> same time, so users who do not turn on alpha checks will not lose any 
> functionality. What do you think?


I don't have precise statistics. But these array-index-out-of-bounds messages 
are often false positives. Fixes are needed in the ExprEngine.


Repository:
  rL LLVM

https://reviews.llvm.org/D28278



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

[PATCH] D28467: [Sema] Add warning for unused lambda captures

[Malcolm Parsons via Phabricator via cfe-commits]

malcolm.parsons updated this revision to Diff 83792.
malcolm.parsons added a comment.

Use -Wno-unused-lambda-capture in existing tests.


https://reviews.llvm.org/D28467

Files:
  include/clang/Basic/DiagnosticGroups.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Sema/ScopeInfo.h
  lib/Parse/ParseExprCXX.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaExprCXX.cpp
  lib/Sema/SemaLambda.cpp
  test/CXX/expr/expr.prim/expr.prim.lambda/p12.cpp
  test/CXX/expr/expr.prim/expr.prim.lambda/p13.cpp
  test/CXX/expr/expr.prim/expr.prim.lambda/p16.cpp
  test/CXX/expr/expr.prim/expr.prim.lambda/p18.cpp
  test/CXX/expr/expr.prim/expr.prim.lambda/p19.cpp
  test/SemaCXX/uninitialized.cpp
  test/SemaCXX/warn-unused-lambda-capture.cpp

Index: test/SemaCXX/warn-unused-lambda-capture.cpp
===
--- /dev/null
+++ test/SemaCXX/warn-unused-lambda-capture.cpp
@@ -0,0 +1,78 @@
+// RUN: %clang_cc1 -fsyntax-only -Wunused-lambda-capture -Wused-but-marked-unused -Wno-uninitialized -verify -std=c++14 %s
+
+void test() {
+  int i = 0;
+
+  auto captures_nothing = [] {};
+
+  auto captures_nothing_by_value = [=] {};
+  auto captures_nothing_by_reference = [&] {};
+
+  auto implicit_by_value = [=]() mutable { i++; };
+  auto implicit_by_reference = [&] { i++; };
+
+  auto explicit_by_value_used = [i] { return i + 1; };
+  auto explicit_by_value_used_void = [i] { (void)i; };
+  auto explicit_by_value_unused = [i] {}; // expected-warning{{lambda capture 'i' is not used}}
+  auto explicit_by_value_unused_sizeof = [i] { return sizeof(i); }; // expected-warning{{lambda capture 'i' is not used}}
+
+  auto explicit_by_reference_used = [&i] { i++; };
+  auto explicit_by_reference_unused = [&i] {}; // expected-warning{{lambda capture 'i' is not used}}
+
+  auto explicit_initialized_reference_used = [&j = i] { return j + 1; };
+  auto explicit_initialized_reference_unused = [&j = i]{}; // expected-warning{{lambda capture 'j' is not used}}
+
+  auto explicit_initialized_value_used = [j = 1] { return j + 1; };
+  auto explicit_initialized_value_unused = [j = 1] {}; // expected-warning{{lambda capture 'j' is not used}}
+
+  auto nested = [&i] {
+auto explicit_by_value_used = [i] { return i + 1; };
+auto explicit_by_value_unused = [i] {}; // expected-warning{{lambda capture 'i' is not used}}
+  };
+}
+
+class Foo
+{
+  void test() {
+auto explicit_this_used = [this] { return i; };
+auto explicit_this_used_void = [this] { (void)this; };
+auto explicit_this_unused = [this] {}; // expected-warning{{lambda capture 'this' is not used}}
+  }
+  int i;
+};
+
+template 
+void test_templated() {
+  int i = 0;
+
+  auto captures_nothing = [] {};
+
+  auto captures_nothing_by_value = [=] {};
+  auto captures_nothing_by_reference = [&] {};
+
+  auto implicit_by_value = [=]() mutable { i++; };
+  auto implicit_by_reference = [&] { i++; };
+
+  auto explicit_by_value_used = [i] { return i + 1; };
+  auto explicit_by_value_used_void = [i] { (void)i; };
+  auto explicit_by_value_unused = [i] {}; // expected-warning{{lambda capture 'i' is not used}}
+  auto explicit_by_value_unused_sizeof = [i] { return sizeof(i); }; // expected-warning{{lambda capture 'i' is not used}}
+
+  auto explicit_by_reference_used = [&i] { i++; };
+  auto explicit_by_reference_unused = [&i] {}; // expected-warning{{lambda capture 'i' is not used}}
+
+  auto explicit_initialized_reference_used = [&j = i] { return j + 1; };
+  auto explicit_initialized_reference_unused = [&j = i]{}; // expected-warning{{lambda capture 'j' is not used}}
+
+  auto explicit_initialized_value_used = [j = 1] { return j + 1; };
+  auto explicit_initialized_value_unused = [j = 1] {}; // expected-warning{{lambda capture 'j' is not used}}
+
+  auto nested = [&i] {
+auto explicit_by_value_used = [i] { return i + 1; };
+auto explicit_by_value_unused = [i] {}; // expected-warning{{lambda capture 'i' is not used}}
+  };
+}
+
+void test_use_template() {
+  test_templated(); // expected-note{{in instantiation of function template specialization 'test_templated' requested here}}
+}
Index: test/SemaCXX/uninitialized.cpp
===
--- test/SemaCXX/uninitialized.cpp
+++ test/SemaCXX/uninitialized.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -Wall -Wuninitialized -Wno-unused-value -std=c++11 -verify %s
+// RUN: %clang_cc1 -fsyntax-only -Wall -Wuninitialized -Wno-unused-value -Wno-unused-lambda-capture -std=c++11 -verify %s
 
 // definitions for std::move
 namespace std {
Index: test/CXX/expr/expr.prim/expr.prim.lambda/p19.cpp
===
--- test/CXX/expr/expr.prim/expr.prim.lambda/p19.cpp
+++ test/CXX/expr/expr.prim/expr.prim.lambda/p19.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -std=c++11 %s -Wunused -verify
+// RUN: %clang_cc1 -std=c++11 %s -Wunused -Wno-unused-lambda-capture -verify
 
 struct MoveOnly {
   Move

[PATCH] D28467: [Sema] Add warning for unused lambda captures

[Malcolm Parsons via Phabricator via cfe-commits]

malcolm.parsons added inline comments.



Comment at: include/clang/Sema/ScopeInfo.h:457
+/// lambda.
+bool Used = false;
+

Should this be moved into one of the `PointerIntPair`s?


https://reviews.llvm.org/D28467



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

[PATCH] D28510: Reinstate CWG1607 restrictions on lambdas appearing inside certain constant-expressions

[Faisal Vali via Phabricator via cfe-commits]

faisalv added a comment.

Yes - I'll modify the patch to reflect that approach.  Any thoughts on whether 
they should also be forbidden in Lamda parameter declaration clauses?
Thanks!


Repository:
  rL LLVM

https://reviews.llvm.org/D28510



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

[PATCH] D28510: Reinstate CWG1607 restrictions on lambdas appearing inside certain constant-expressions

[Faisal Vali via Phabricator via cfe-commits]

faisalv added inline comments.



Comment at: include/clang/Sema/Sema.h:894-895
 
+/// \brief Whether lambda expressions are forbidden here.
+bool IsLambdaExprForbidden;
+

rsmith wrote:
> Rather than adding a flag, how about we have two different kinds of 
> `ExpressionEvaluationContext` for constant expressions: a generic "constant 
> expression" context and a "constant expression in signature" context?
But not all lambdas that appear in template arguments are in signatures - so 
should we split it into ConstantEvaluated, 
ConstantEvaluatedInSignatureOrTemplateArg ? 



Comment at: lib/Parse/ParseDecl.cpp:6254
+  NumElements = ParseConstantExpression(NotTypeCast,
+   /*IsLambdaExprForbidden=*/D.getContext() == D.PrototypeContext);
 } else {

I suppose we should forbid these in a lambda parameter declaration clause too?


Repository:
  rL LLVM

https://reviews.llvm.org/D28510



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

[PATCH] D26244: [Driver] Prefer libraries installed next to Clang over those from GCC

[Jonas Hahnfeld via Phabricator via cfe-commits]

Hahnfeld added a comment.

In https://reviews.llvm.org/D26244#641099, @chandlerc wrote:

> Those are just the libriaries LLVM is installing.
>
> If it is installed into a prefix, say, /opt/mumble/{bin,lib,...} along with 
> other libraries, then suddenly that directory is searched in a very different 
> place.
>
> I'm not arguing one way or the other here. I'm pointing out that this is a 
> *huge* change to make. It will cause a large number of users to silently have 
> a different library search path than they have had before, something that has 
> been fairly stable for several years. So whatever we do must be considered 
> very carefully.


Haven't thought about that! If I don't install to `/usr/lib`, I usually only 
install one software per prefix but there might be cases where that is not true.

What do you propose? Should I send an RFC to cfe-dev?


https://reviews.llvm.org/D26244



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

[PATCH] D28514: [CodeCompletion] Reset the hidden declaration obtained after lookup when caching UsingShadowDecls

[Alex Lorenz via Phabricator via cfe-commits]

arphaman created this revision.
arphaman added reviewers: manmanren, ahatanak, akyrtzi.
arphaman added a subscriber: cfe-commits.
arphaman set the repository for this revision to rL LLVM.

This patch fixes an issue where cached global code completion results for a 
`using` declaration included the namespace incorrectly. The issue arises 
because the global code completion caching performs the lookup in the entire 
translation unit, which then reports that the `UsingDecl` is being hidden by 
`UsingShadowDecl`. This leads to the nested name qualifiers being applied 
incorrectly to the completion result.


Repository:
  rL LLVM

https://reviews.llvm.org/D28514

Files:
  lib/Sema/SemaCodeComplete.cpp
  test/Index/complete-cached-globals.cpp


Index: test/Index/complete-cached-globals.cpp
===
--- /dev/null
+++ test/Index/complete-cached-globals.cpp
@@ -0,0 +1,25 @@
+// Note: the run lines follow their respective tests, since line/column
+// matter in this test.
+
+namespace SomeNamespace {
+class SomeClass {
+};
+void SomeFunction();
+}
+
+using SomeNamespace::SomeClass;
+using SomeNamespace::SomeFunction;
+
+static void foo() {
+  return;
+}
+
+// rdar://23454249
+
+// RUN: c-index-test -code-completion-at=%s:14:3 %s | FileCheck 
-check-prefix=CHECK-CC1 %s
+// RUN: env CINDEXTEST_EDITING=1 CINDEXTEST_COMPLETION_CACHING=1 c-index-test 
-code-completion-at=%s:14:3 %s | FileCheck -check-prefix=CHECK-CC1 %s
+
+// CHECK-CC1: ClassDecl:{TypedText SomeClass} (50)
+// CHECK-CC1: FunctionDecl:{ResultType void}{TypedText SomeFunction}{LeftParen 
(}{RightParen )} (50)
+// CHECK-CC1-NOT: {Text SomeNamespace::}{TypedText SomeClass}
+// CHECK-CC1-NOT: {Text SomeNamespace::}{TypedText SomeFunction}
Index: lib/Sema/SemaCodeComplete.cpp
===
--- lib/Sema/SemaCodeComplete.cpp
+++ lib/Sema/SemaCodeComplete.cpp
@@ -954,6 +954,13 @@
 
   // Look through using declarations.
   if (const UsingShadowDecl *Using = dyn_cast(R.Declaration)) 
{
+// When we are gathering global code completions for caching, the lookup
+// is performed in the translation unit context which leads to a situation
+// when a UsingShadowDecl hides a UsingDecl, and nested name specifiers are
+// then incorrectly applied to the target declaration. This can be avoided
+// by resetting the declaration that's being hidden.
+if (Hiding && isa(Hiding))
+  Hiding = nullptr;
 AddResult(Result(Using->getTargetDecl(),
  getBasePriority(Using->getTargetDecl()),
  R.Qualifier),


Index: test/Index/complete-cached-globals.cpp
===
--- /dev/null
+++ test/Index/complete-cached-globals.cpp
@@ -0,0 +1,25 @@
+// Note: the run lines follow their respective tests, since line/column
+// matter in this test.
+
+namespace SomeNamespace {
+class SomeClass {
+};
+void SomeFunction();
+}
+
+using SomeNamespace::SomeClass;
+using SomeNamespace::SomeFunction;
+
+static void foo() {
+  return;
+}
+
+// rdar://23454249
+
+// RUN: c-index-test -code-completion-at=%s:14:3 %s | FileCheck -check-prefix=CHECK-CC1 %s
+// RUN: env CINDEXTEST_EDITING=1 CINDEXTEST_COMPLETION_CACHING=1 c-index-test -code-completion-at=%s:14:3 %s | FileCheck -check-prefix=CHECK-CC1 %s
+
+// CHECK-CC1: ClassDecl:{TypedText SomeClass} (50)
+// CHECK-CC1: FunctionDecl:{ResultType void}{TypedText SomeFunction}{LeftParen (}{RightParen )} (50)
+// CHECK-CC1-NOT: {Text SomeNamespace::}{TypedText SomeClass}
+// CHECK-CC1-NOT: {Text SomeNamespace::}{TypedText SomeFunction}
Index: lib/Sema/SemaCodeComplete.cpp
===
--- lib/Sema/SemaCodeComplete.cpp
+++ lib/Sema/SemaCodeComplete.cpp
@@ -954,6 +954,13 @@
 
   // Look through using declarations.
   if (const UsingShadowDecl *Using = dyn_cast(R.Declaration)) {
+// When we are gathering global code completions for caching, the lookup
+// is performed in the translation unit context which leads to a situation
+// when a UsingShadowDecl hides a UsingDecl, and nested name specifiers are
+// then incorrectly applied to the target declaration. This can be avoided
+// by resetting the declaration that's being hidden.
+if (Hiding && isa(Hiding))
+  Hiding = nullptr;
 AddResult(Result(Using->getTargetDecl(),
  getBasePriority(Using->getTargetDecl()),
  R.Qualifier),
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D26244: [Driver] Prefer libraries installed next to Clang over those from GCC

[Michał Górny via Phabricator via cfe-commits]

mgorny added a comment.

I think the easiest solution would be for you to use a path related to clang 
runtime directory, and install the runtimes there.

However, this would require rethinking the structure a bit to cover multilib, 
different ABIs, maybe cross. We have a cheap hack for this in clang-suite (I 
can give you link when I get home) but this really requires some smart thinking.


https://reviews.llvm.org/D26244



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

[PATCH] D28033: [analyzer] Treat pointers to static member functions as function pointers

[Kirill Romanenkov via Phabricator via cfe-commits]

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

Looks good to me, apart from a very small cavil introduced in not even your 
code. Thanks for not leaving pointers to static member functions out of account!




Comment at: test/Analysis/pointer-to-member.cpp:80
 virtual int foo() { return 1; }
 int bar() { return 2;  }
+int static staticMemberFunction(int p) { return p + 1; };

This line is not affected by your patch but would you please delete the extra 
space before the second brace?


https://reviews.llvm.org/D28033



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

[PATCH] D28467: [Sema] Add warning for unused lambda captures

[Alex Lorenz via Phabricator via cfe-commits]

arphaman added inline comments.



Comment at: include/clang/Sema/ScopeInfo.h:457
+/// lambda.
+bool Used = false;
+

malcolm.parsons wrote:
> Should this be moved into one of the `PointerIntPair`s?
I'm not sure.. If we needed other capturing information in the future I would 
say that this should be its own field, but I'm not aware of anything else 
that's needed for this class. So I guess it would be better to pack it into 
`VarAndNestedAndThis`, but I wouldn't say it's a deal breaker.


https://reviews.llvm.org/D28467



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

r291564 - [Sema] Avoid -Wshadow warning when a "redefinition of " error is presented

[Alex Lorenz via cfe-commits]

Author: arphaman
Date: Tue Jan 10 08:41:13 2017
New Revision: 291564

URL: http://llvm.org/viewvc/llvm-project?rev=291564&view=rev
Log:
[Sema] Avoid -Wshadow warning when a "redefinition of " error is presented

This commit ensures that clang avoids the redundant -Wshadow warning for
variables that already get a "redefinition of " error.

rdar://29067894

Differential Revision: https://reviews.llvm.org/D28350

Modified:
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/test/SemaCXX/warn-shadow-in-lambdas.cpp
cfe/trunk/test/SemaCXX/warn-shadow.cpp

Modified: cfe/trunk/include/clang/Sema/Sema.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=291564&r1=291563&r2=291564&view=diff
==
--- cfe/trunk/include/clang/Sema/Sema.h (original)
+++ cfe/trunk/include/clang/Sema/Sema.h Tue Jan 10 08:41:13 2017
@@ -1709,7 +1709,8 @@ public:
 
   static bool adjustContextForLocalExternDecl(DeclContext *&DC);
   void DiagnoseFunctionSpecifiers(const DeclSpec &DS);
-  void CheckShadow(Scope *S, VarDecl *D, const LookupResult& R);
+  NamedDecl *getShadowedDeclaration(const VarDecl *D, const LookupResult &R);
+  void CheckShadow(VarDecl *D, NamedDecl *ShadowedDecl, const LookupResult &R);
   void CheckShadow(Scope *S, VarDecl *D);
 
   /// Warn if 'E', which is an expression that is about to be modified, refers

Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=291564&r1=291563&r2=291564&view=diff
==
--- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDecl.cpp Tue Jan 10 08:41:13 2017
@@ -6426,9 +6426,10 @@ NamedDecl *Sema::ActOnVariableDeclarator
 }
   }
 
-  // Diagnose shadowed variables before filtering for scope.
-  if (D.getCXXScopeSpec().isEmpty())
-CheckShadow(S, NewVD, Previous);
+  // Find the shadowed declaration before filtering for scope.
+  NamedDecl *ShadowedDecl = D.getCXXScopeSpec().isEmpty()
+? getShadowedDeclaration(NewVD, Previous)
+: nullptr;
 
   // Don't consider existing declarations that are in a different
   // scope and are out-of-semantic-context declarations (if the new
@@ -6523,6 +6524,10 @@ NamedDecl *Sema::ActOnVariableDeclarator
 }
   }
 
+  // Diagnose shadowed variables iff this isn't a redeclaration.
+  if (ShadowedDecl && !D.isRedeclaration())
+CheckShadow(NewVD, ShadowedDecl, Previous);
+
   ProcessPragmaWeak(S, NewVD);
 
   // If this is the first declaration of an extern C variable, update
@@ -6596,33 +6601,40 @@ static SourceLocation getCaptureLocation
   return SourceLocation();
 }
 
-/// \brief Diagnose variable or built-in function shadowing.  Implements
-/// -Wshadow.
-///
-/// This method is called whenever a VarDecl is added to a "useful"
-/// scope.
-///
-/// \param S the scope in which the shadowing name is being declared
-/// \param R the lookup of the name
-///
-void Sema::CheckShadow(Scope *S, VarDecl *D, const LookupResult& R) {
+/// \brief Return the declaration shadowed by the given variable \p D, or null
+/// if it doesn't shadow any declaration or shadowing warnings are disabled.
+NamedDecl *Sema::getShadowedDeclaration(const VarDecl *D,
+const LookupResult &R) {
   // Return if warning is ignored.
   if (Diags.isIgnored(diag::warn_decl_shadow, R.getNameLoc()))
-return;
+return nullptr;
 
   // Don't diagnose declarations at file scope.
   if (D->hasGlobalStorage())
-return;
-
-  DeclContext *NewDC = D->getDeclContext();
+return nullptr;
 
   // Only diagnose if we're shadowing an unambiguous field or variable.
   if (R.getResultKind() != LookupResult::Found)
-return;
+return nullptr;
 
-  NamedDecl* ShadowedDecl = R.getFoundDecl();
-  if (!isa(ShadowedDecl) && !isa(ShadowedDecl))
-return;
+  NamedDecl *ShadowedDecl = R.getFoundDecl();
+  return isa(ShadowedDecl) || isa(ShadowedDecl)
+ ? ShadowedDecl
+ : nullptr;
+}
+
+/// \brief Diagnose variable or built-in function shadowing.  Implements
+/// -Wshadow.
+///
+/// This method is called whenever a VarDecl is added to a "useful"
+/// scope.
+///
+/// \param ShadowedDecl the declaration that is shadowed by the given variable
+/// \param R the lookup of the name
+///
+void Sema::CheckShadow(VarDecl *D, NamedDecl *ShadowedDecl,
+   const LookupResult &R) {
+  DeclContext *NewDC = D->getDeclContext();
 
   if (FieldDecl *FD = dyn_cast(ShadowedDecl)) {
 // Fields are not shadowed by variables in C++ static methods.
@@ -6733,7 +6745,8 @@ void Sema::CheckShadow(Scope *S, VarDecl
   LookupResult R(*this, D->getDeclName(), D->getLocation(),
  Sema::LookupOrdinaryName, Sema::ForRedeclaration);
   LookupName(R, 

[PATCH] D28350: [Sema] Avoid -Wshadow warning when a "redefinition of " error is presented

[Alex Lorenz via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL291564: [Sema] Avoid -Wshadow warning when a "redefinition 
of " error is presented (authored by arphaman).

Changed prior to commit:
  https://reviews.llvm.org/D28350?vs=83214&id=83806#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D28350

Files:
  cfe/trunk/include/clang/Sema/Sema.h
  cfe/trunk/lib/Sema/SemaDecl.cpp
  cfe/trunk/test/SemaCXX/warn-shadow-in-lambdas.cpp
  cfe/trunk/test/SemaCXX/warn-shadow.cpp

Index: cfe/trunk/test/SemaCXX/warn-shadow.cpp
===
--- cfe/trunk/test/SemaCXX/warn-shadow.cpp
+++ cfe/trunk/test/SemaCXX/warn-shadow.cpp
@@ -97,3 +97,13 @@
 void test8() {
   int bob; // expected-warning {{declaration shadows a variable in the global namespace}}
 }
+
+namespace rdar29067894 {
+
+void avoidWarningWhenRedefining(int b) { // expected-note {{previous definition is here}}
+  int a = 0; // expected-note {{previous definition is here}}
+  int a = 1; // expected-error {{redefinition of 'a'}}
+  int b = 2; // expected-error {{redefinition of 'b'}}
+}
+
+}
Index: cfe/trunk/test/SemaCXX/warn-shadow-in-lambdas.cpp
===
--- cfe/trunk/test/SemaCXX/warn-shadow-in-lambdas.cpp
+++ cfe/trunk/test/SemaCXX/warn-shadow-in-lambdas.cpp
@@ -137,3 +137,11 @@
   auto g3 = [param] // expected-note {{variable 'param' is explicitly captured here}}
(auto param) { ; }; // expected-warning {{declaration shadows a local variable}}
 }
+
+void avoidWarningWhenRedefining() {
+  int a = 1;
+  auto l = [b = a] { // expected-note {{previous definition is here}}
+// Don't warn on redefinitions.
+int b = 0; // expected-error {{redefinition of 'b'}}
+  };
+}
Index: cfe/trunk/lib/Sema/SemaDecl.cpp
===
--- cfe/trunk/lib/Sema/SemaDecl.cpp
+++ cfe/trunk/lib/Sema/SemaDecl.cpp
@@ -6426,9 +6426,10 @@
 }
   }
 
-  // Diagnose shadowed variables before filtering for scope.
-  if (D.getCXXScopeSpec().isEmpty())
-CheckShadow(S, NewVD, Previous);
+  // Find the shadowed declaration before filtering for scope.
+  NamedDecl *ShadowedDecl = D.getCXXScopeSpec().isEmpty()
+? getShadowedDeclaration(NewVD, Previous)
+: nullptr;
 
   // Don't consider existing declarations that are in a different
   // scope and are out-of-semantic-context declarations (if the new
@@ -6523,6 +6524,10 @@
 }
   }
 
+  // Diagnose shadowed variables iff this isn't a redeclaration.
+  if (ShadowedDecl && !D.isRedeclaration())
+CheckShadow(NewVD, ShadowedDecl, Previous);
+
   ProcessPragmaWeak(S, NewVD);
 
   // If this is the first declaration of an extern C variable, update
@@ -6596,33 +6601,40 @@
   return SourceLocation();
 }
 
-/// \brief Diagnose variable or built-in function shadowing.  Implements
-/// -Wshadow.
-///
-/// This method is called whenever a VarDecl is added to a "useful"
-/// scope.
-///
-/// \param S the scope in which the shadowing name is being declared
-/// \param R the lookup of the name
-///
-void Sema::CheckShadow(Scope *S, VarDecl *D, const LookupResult& R) {
+/// \brief Return the declaration shadowed by the given variable \p D, or null
+/// if it doesn't shadow any declaration or shadowing warnings are disabled.
+NamedDecl *Sema::getShadowedDeclaration(const VarDecl *D,
+const LookupResult &R) {
   // Return if warning is ignored.
   if (Diags.isIgnored(diag::warn_decl_shadow, R.getNameLoc()))
-return;
+return nullptr;
 
   // Don't diagnose declarations at file scope.
   if (D->hasGlobalStorage())
-return;
-
-  DeclContext *NewDC = D->getDeclContext();
+return nullptr;
 
   // Only diagnose if we're shadowing an unambiguous field or variable.
   if (R.getResultKind() != LookupResult::Found)
-return;
+return nullptr;
 
-  NamedDecl* ShadowedDecl = R.getFoundDecl();
-  if (!isa(ShadowedDecl) && !isa(ShadowedDecl))
-return;
+  NamedDecl *ShadowedDecl = R.getFoundDecl();
+  return isa(ShadowedDecl) || isa(ShadowedDecl)
+ ? ShadowedDecl
+ : nullptr;
+}
+
+/// \brief Diagnose variable or built-in function shadowing.  Implements
+/// -Wshadow.
+///
+/// This method is called whenever a VarDecl is added to a "useful"
+/// scope.
+///
+/// \param ShadowedDecl the declaration that is shadowed by the given variable
+/// \param R the lookup of the name
+///
+void Sema::CheckShadow(VarDecl *D, NamedDecl *ShadowedDecl,
+   const LookupResult &R) {
+  DeclContext *NewDC = D->getDeclContext();
 
   if (FieldDecl *FD = dyn_cast(ShadowedDecl)) {
 // Fields are not shadowed by variables in C++ static methods.
@@ -6733,7 +6745,8 @@
   LookupResult R(*this, D->getDeclName(), D->getLocation(),
  Sema::LookupOrdinaryName, Sema::ForRedeclaration);
   Look

[PATCH] D17981: [clang-tidy] Fix clang-tidy to support parsing of assembly statements.

[Etienne Bergeron via Phabricator via cfe-commits]

etienneb added a comment.

jckooijman, this issue is still not solved on ToT.

You can apply this patch on your local repo.
It's fixing the problem, but your executable size will increase.


https://reviews.llvm.org/D17981



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

[PATCH] D28445: [Analyzer] Extend taint propagation and checking

[Vlad Tsyrklevich via Phabricator via cfe-commits]

vlad.tsyrklevich added inline comments.



Comment at: lib/StaticAnalyzer/Checkers/GenericTaintChecker.cpp:443
+  if (auto LCV = Val.getAs())
+return C.getSymbolManager().getRegionValueSymbol(LCV->getRegion());
+

zaks.anna wrote:
> This might create a new symbol. Is this what we want?
I'm not sure how to turn an LCV into a proper symbol, so without creating new 
symbols the best approach I can see is changing `getPointedToSymbol()` to 
`getPointedToSval()` and also update `addTaint()` and `isTainted()` to accept 
SVals. Then you could have separate TaintMaps that include both symbols and 
regions and check both for taintedness. Does that sound like the correct 
approach to you?


https://reviews.llvm.org/D28445



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

[PATCH] D20136: Get default -fms-compatibility-version from cl.exe's version

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

Aha, looks like this did have a `#pragma comment(lib` when it went in (for 
version.lib which is actually the correct one), but takumi removed it in 
http://llvm.org/viewvc/llvm-project?rev=269557&view=rev


Repository:
  rL LLVM

https://reviews.llvm.org/D20136



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

[PATCH] D20428: Tracking exception specification source locations

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

I think that these changes look good to me, and I noticed Richard signed off on 
the other review for the exception spec changes (thank you for working on 
that!), so I think this is ready to commit.

In https://reviews.llvm.org/D20428#641068, @hintonda wrote:

> Richard, is it okay to commit this?


If Richard does not respond today, then yes, it's fine to commit (it's had 
relatively extensive review already, and we can correct any outstanding issues 
post-commit).


https://reviews.llvm.org/D20428



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

r291565 - [OpenMP] Basic support for a parallel directive in a target region on an NVPTX device

[Arpith Chacko Jacob via cfe-commits]

Author: arpith
Date: Tue Jan 10 09:42:51 2017
New Revision: 291565

URL: http://llvm.org/viewvc/llvm-project?rev=291565&view=rev
Log:
[OpenMP] Basic support for a parallel directive in a target region on an NVPTX 
device

Summary:

This patch introduces support for the execution of parallel constructs in a 
target
region on the NVPTX device.  Parallel regions must be in the lexical scope of 
the
target directive.

The master thread in the master warp signals parallel work for worker threads 
in worker
warps on encountering a parallel region.

Note: The patch does not yet support capture of arguments in a parallel region 
so
the test cases are simple.

Reviewers: ABataev
Differential Revision: https://reviews.llvm.org/D28145

Added:
cfe/trunk/test/OpenMP/nvptx_parallel_codegen.cpp
Modified:
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h
cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.h

Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp?rev=291565&r1=291564&r2=291565&view=diff
==
--- cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp Tue Jan 10 09:42:51 2017
@@ -99,10 +99,11 @@ class CGOpenMPOutlinedRegionInfo final :
 public:
   CGOpenMPOutlinedRegionInfo(const CapturedStmt &CS, const VarDecl 
*ThreadIDVar,
  const RegionCodeGenTy &CodeGen,
- OpenMPDirectiveKind Kind, bool HasCancel)
+ OpenMPDirectiveKind Kind, bool HasCancel,
+ StringRef HelperName)
   : CGOpenMPRegionInfo(CS, ParallelOutlinedRegion, CodeGen, Kind,
HasCancel),
-ThreadIDVar(ThreadIDVar) {
+ThreadIDVar(ThreadIDVar), HelperName(HelperName) {
 assert(ThreadIDVar != nullptr && "No ThreadID in OpenMP region.");
   }
 
@@ -111,7 +112,7 @@ public:
   const VarDecl *getThreadIDVariable() const override { return ThreadIDVar; }
 
   /// \brief Get the name of the capture helper.
-  StringRef getHelperName() const override { return ".omp_outlined."; }
+  StringRef getHelperName() const override { return HelperName; }
 
   static bool classof(const CGCapturedStmtInfo *Info) {
 return CGOpenMPRegionInfo::classof(Info) &&
@@ -123,6 +124,7 @@ private:
   /// \brief A variable or parameter storing global thread id for OpenMP
   /// constructs.
   const VarDecl *ThreadIDVar;
+  StringRef HelperName;
 };
 
 /// \brief API for captured statement code generation in OpenMP constructs.
@@ -855,7 +857,7 @@ llvm::Value *CGOpenMPRuntime::emitParall
   else if (auto *OPFD = dyn_cast(&D))
 HasCancel = OPFD->hasCancel();
   CGOpenMPOutlinedRegionInfo CGInfo(*CS, ThreadIDVar, CodeGen, InnermostKind,
-HasCancel);
+HasCancel, getOutlinedHelperName());
   CodeGenFunction::CGCapturedStmtRAII CapInfoRAII(CGF, &CGInfo);
   return CGF.GenerateOpenMPCapturedStmtFunction(*CS);
 }
@@ -1892,9 +1894,9 @@ llvm::Function *CGOpenMPRuntime::emitThr
 /// } else {
 ///   ElseGen();
 /// }
-static void emitOMPIfClause(CodeGenFunction &CGF, const Expr *Cond,
-const RegionCodeGenTy &ThenGen,
-const RegionCodeGenTy &ElseGen) {
+void CGOpenMPRuntime::emitOMPIfClause(CodeGenFunction &CGF, const Expr *Cond,
+  const RegionCodeGenTy &ThenGen,
+  const RegionCodeGenTy &ElseGen) {
   CodeGenFunction::LexicalScope ConditionScope(CGF, Cond->getSourceRange());
 
   // If the condition constant folds and can be elided, try to avoid emitting

Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h?rev=291565&r1=291564&r2=291565&view=diff
==
--- cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h (original)
+++ cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h Tue Jan 10 09:42:51 2017
@@ -130,6 +130,35 @@ protected:
 bool IsOffloadEntry,
 const RegionCodeGenTy 
&CodeGen);
 
+  /// \brief Emits code for OpenMP 'if' clause using specified \a CodeGen
+  /// function. Here is the logic:
+  /// if (Cond) {
+  ///   ThenGen();
+  /// } else {
+  ///   ElseGen();
+  /// }
+  void emitOMPIfClause(CodeGenFunction &CGF, const Expr *Cond,
+   const RegionCodeGenTy &ThenGen,
+   const RegionCodeGenTy &ElseGen);
+
+  /// \brief Emits object of ident_t type with info for source location.
+  /// \param Flags Flags for OpenMP location.
+  ///
+  llvm::Value *emitUpdateLocation(CodeGenFunctio

[PATCH] D28145: [OpenMP] Basic support for a parallel directive in a target region on an NVPTX device.

[Phabricator via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL291565: [OpenMP] Basic support for a parallel directive in a 
target region on an NVPTX… (authored by arpith).

Changed prior to commit:
  https://reviews.llvm.org/D28145?vs=83641&id=83808#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D28145

Files:
  cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
  cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h
  cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
  cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.h
  cfe/trunk/test/OpenMP/nvptx_parallel_codegen.cpp

Index: cfe/trunk/test/OpenMP/nvptx_parallel_codegen.cpp
===
--- cfe/trunk/test/OpenMP/nvptx_parallel_codegen.cpp
+++ cfe/trunk/test/OpenMP/nvptx_parallel_codegen.cpp
@@ -0,0 +1,317 @@
+// Test target codegen - host bc file has to be created first.
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm-bc %s -o %t-ppc-host.bc
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple nvptx64-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o - | FileCheck %s --check-prefix CHECK --check-prefix CHECK-64
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple i386-unknown-unknown -fopenmp-targets=nvptx-nvidia-cuda -emit-llvm-bc %s -o %t-x86-host.bc
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple nvptx-unknown-unknown -fopenmp-targets=nvptx-nvidia-cuda -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-x86-host.bc -o - | FileCheck %s --check-prefix CHECK --check-prefix CHECK-32
+// RUN: %clang_cc1 -verify -fopenmp -fexceptions -fcxx-exceptions -x c++ -triple nvptx-unknown-unknown -fopenmp-targets=nvptx-nvidia-cuda -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-x86-host.bc -o - | FileCheck %s --check-prefix CHECK --check-prefix CHECK-32
+// expected-no-diagnostics
+#ifndef HEADER
+#define HEADER
+
+template
+tx ftemplate(int n) {
+  tx a = 0;
+  short aa = 0;
+  tx b[10];
+
+  #pragma omp target if(0)
+  {
+#pragma omp parallel
+{
+  int a = 41;
+}
+a += 1;
+  }
+
+  #pragma omp target
+  {
+#pragma omp parallel
+{
+  int a = 42;
+}
+#pragma omp parallel if(0)
+{
+  int a = 43;
+}
+#pragma omp parallel if(1)
+{
+  int a = 44;
+}
+a += 1;
+  }
+
+  #pragma omp target if(n>40)
+  {
+#pragma omp parallel if(n>1000)
+{
+  int a = 45;
+}
+a += 1;
+aa += 1;
+b[2] += 1;
+  }
+
+  return a;
+}
+
+int bar(int n){
+  int a = 0;
+
+  a += ftemplate(n);
+
+  return a;
+}
+
+  // CHECK-NOT: define {{.*}}void {{@__omp_offloading_.+template.+l17}}_worker()
+
+
+
+
+
+
+  // CHECK-LABEL: define {{.*}}void {{@__omp_offloading_.+template.+l26}}_worker()
+  // CHECK-DAG: [[OMP_EXEC_STATUS:%.+]] = alloca i8,
+  // CHECK-DAG: [[OMP_WORK_FN:%.+]] = alloca i8*,
+  // CHECK: store i8* null, i8** [[OMP_WORK_FN]],
+  // CHECK: store i8 0, i8* [[OMP_EXEC_STATUS]],
+  // CHECK: br label {{%?}}[[AWAIT_WORK:.+]]
+  //
+  // CHECK: [[AWAIT_WORK]]
+  // CHECK: call void @llvm.nvvm.barrier0()
+  // CHECK: [[KPR:%.+]] = call i1 @__kmpc_kernel_parallel(i8** [[OMP_WORK_FN]])
+  // CHECK: [[KPRB:%.+]] = zext i1 [[KPR]] to i8
+  // store i8 [[KPRB]], i8* [[OMP_EXEC_STATUS]], align 1
+  // CHECK: [[WORK:%.+]] = load i8*, i8** [[OMP_WORK_FN]],
+  // CHECK: [[SHOULD_EXIT:%.+]] = icmp eq i8* [[WORK]], null
+  // CHECK: br i1 [[SHOULD_EXIT]], label {{%?}}[[EXIT:.+]], label {{%?}}[[SEL_WORKERS:.+]]
+  //
+  // CHECK: [[SEL_WORKERS]]
+  // CHECK: [[ST:%.+]] = load i8, i8* [[OMP_EXEC_STATUS]]
+  // CHECK: [[IS_ACTIVE:%.+]] = icmp ne i8 [[ST]], 0
+  // CHECK: br i1 [[IS_ACTIVE]], label {{%?}}[[EXEC_PARALLEL:.+]], label {{%?}}[[BAR_PARALLEL:.+]]
+  //
+  // CHECK: [[EXEC_PARALLEL]]
+  // CHECK: [[WF1:%.+]] = load i8*, i8** [[OMP_WORK_FN]],
+  // CHECK: [[WM1:%.+]] = icmp eq i8* [[WF1]], bitcast (void (i32*, i32*)* [[PARALLEL_FN1:@.+]] to i8*)
+  // CHECK: br i1 [[WM1]], label {{%?}}[[EXEC_PFN1:.+]], label {{%?}}[[CHECK_NEXT1:.+]]
+  //
+  // CHECK: [[EXEC_PFN1]]
+  // CHECK: call void [[PARALLEL_FN1]](
+  // CHECK: br label {{%?}}[[TERM_PARALLEL:.+]]
+  //
+  // CHECK: [[CHECK_NEXT1]]
+  // CHECK: [[WF2:%.+]] = load i8*, i8** [[OMP_WORK_FN]],
+  // CHECK: [[WM2:%.+]] = icmp eq i8* [[WF2]], bitcast (void (i32*, i32*)* [[PARALLEL_FN2:@.+]] to i8*)
+  // CHECK: br i1 [[WM2]], label {{%?}}[[EXEC_PFN2:.+]], label {{%?}}[[CHECK_NEXT2:.+]]
+  //
+  // CHECK: [[EXEC_PFN2]]
+  // CHECK: call void [[PARALLEL_FN2]](
+  // CHECK: br label {{%?}}[[TERM_PARALLEL:.+]]
+  //
+  // CHECK: [[CHECK_NEXT2]]
+  // CHECK: br label {{%?}}[[TERM_PARALLEL:.+]]
+  //
+  // CHECK: [[TERM_PARALLEL]]
+  // CHECK: call void @__kmpc_kernel_end_parallel()
+  // CHECK: br label {{%?}}[[BAR_PARALLEL]]
+  //
+  // CHECK: [[BAR_PARALLEL]]
+  // CHECK: call void @llvm.nvvm.barrier0()
+  // 

[PATCH] D20428: Tracking exception specification source locations

[Malcolm Parsons via Phabricator via cfe-commits]

malcolm.parsons added inline comments.



Comment at: include/clang/AST/TypeLoc.h:1355
+  bool hasExceptionSpec() const {
+if (auto FPT = dyn_cast(getTypePtr())) {
+  return FPT->hasExceptionSpec();

`auto *`



Comment at: include/clang/AST/TypeLoc.h:1443
+if (hasExceptionSpec())
+  setExceptionSpecRange(SourceRange(Loc));
   }

`SourceRange`'s constructor from `SourceLocation` is implicit.


https://reviews.llvm.org/D20428



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

[PATCH] D28295: [libunwind] [cmake] Support overriding LLVM_CMAKE_PATH

[Michał Górny via Phabricator via cfe-commits]

mgorny abandoned this revision.
mgorny added a comment.

And the original variant landed in after all. Sorry for the noise.


https://reviews.llvm.org/D28295



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

[PATCH] D20693: [clang-tidy] New checker to replace dynamic exception specifications

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman requested changes to this revision.
aaron.ballman added inline comments.



Comment at: clang-tidy/modernize/UseNoexceptCheck.cpp:41
+void UseNoexceptCheck::registerMatchers(MatchFinder *Finder) {
+  if (!getLangOpts().CPlusPlus)
+return;

Shouldn't we require C++11 or later?



Comment at: clang-tidy/modernize/UseNoexceptCheck.cpp:64
+  Finder->addMatcher(
+  parmVarDecl(hasType(pointerType(pointee(parenType(innerType(
+  functionProtoType(hasDynamicExceptionSpec(

Will this catch pointers to member functions as well?
```
struct S {
  void f() throw();
};

void f(void (S::*)() throw()) {

}
```



Comment at: clang-tidy/modernize/UseNoexceptCheck.cpp:68
+  this);
+}
+

Also missing: typedefs and using declarations.



Comment at: docs/clang-tidy/checks/modernize-use-noexcept.rst:30
+By default this check will only replace ``throw()`` with ``noexcept``,
+and ``throw([,...])`` or ``throw(...)`` with blank except
+for operator delete and destructors, which are replaced with

I continue to object to removing the explicit exception specification entirely 
as the default behavior without strong justification. Further. there is no 
option to control this behavior.



Comment at: docs/clang-tidy/checks/modernize-use-noexcept.rst:38
+that don't support the ``noexcept`` keyword.  Users can define the
+macro to be ``noexcept`` or ``throw()`` depending on whether or not
+noexcept is supported.  Specifications that can throw, e.g.,

I'm not certain I understand the justification of calling out older compilers 
or suggesting use of `throw()`. The check will continually flag `throw()` and 
try to recommend `noexcept` in its place, won't it? At least, that's how I read 
the preceding paragraph.

I think the macro replacement is a reasonable feature, but I think the check 
only makes sense for C++11 or later, since C++98 users really have no 
alternatives to dynamic exception specifications.


https://reviews.llvm.org/D20693



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

[PATCH] D28400: [AArch64] Use generic bitreverse intrinsic, rather than AArch64 specific.

[Simon Pilgrim via Phabricator via cfe-commits]

RKSimon added inline comments.



Comment at: test/CodeGen/arm_acle.c:247
 // ARM-LABEL: test_rbit
 // AArch32: call i32 @llvm.arm.rbit
+// AArch64: call i32 @llvm.bitreverse.i32

Since you're here is it worth dealing with the AARCH32 case as well? We know it 
works on the llvm side.


https://reviews.llvm.org/D28400



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

[PATCH] D28260: Add an argumentsAre matcher

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman requested changes to this revision.
aaron.ballman added a reviewer: aaron.ballman.
aaron.ballman added a comment.
This revision now requires changes to proceed.

You should also regenerate the HTML matcher documentation as part of this patch.




Comment at: include/clang/ASTMatchers/ASTMatchers.h:3075
+///
+/// Example matches the call to f2, but not f1 or f3.
+/// (matcher = callExpr(argumentsAre(declRefExpr(), declRefExpr(

This is a neat matcher, but I'm not certain it will work with the dynamic 
matchers, which is an unfortunate divergence for clang-query.

Another concern is that this is leaking implementation details into 
ASTMatchers.h rather than keeping them in ASTMatchersInternal.h.



Comment at: unittests/ASTMatchers/ASTMatchersTraversalTest.cpp:383
+  EXPECT_TRUE(matches("void f(int x, int y) { f(x, y); }", Call));
+  EXPECT_TRUE(notMatches("void f(int x, int y, int z) { f(x, y, z); }", Call));
+}

How does this matcher work in the presence of default arguments? e.g.,
```
void f(int a, int b = 12);
f(1);
```
Will `callExpr(argumentsAre(integerLiteral()))` match?

A similar question applies for variadic functions and functions without a 
prototype (from C).

I suspect it all works fine, but some test cases would be nice.


https://reviews.llvm.org/D28260



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

[PATCH] D28260: Add an argumentsAre matcher

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

Given that this can't be expressed as a dynamic matcher, I'm wondering what the 
use case is for the matcher. Do you have a specific need for this 
functionality, or do you see this being generally useful?


https://reviews.llvm.org/D28260



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

[PATCH] D28451: [AVR] Add support for the 'interrupt' and 'naked' attributes

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman requested changes to this revision.
aaron.ballman added a comment.
This revision now requires changes to proceed.

The patch is also missing Sema tests that ensure the attributes are properly 
diagnosed when applied to something other than a function, a target other than 
AVR, arguments are present, etc.




Comment at: include/clang/Basic/Attr.td:485
+  let ParseKind = "Interrupt";
+  let Documentation = [Undocumented];
+}

No new undocumented attributes, please.



Comment at: include/clang/Basic/Attr.td:488
+
+def AVRSignal : InheritableAttr, TargetSpecificAttr {
+  let Spellings = [GNU<"signal">];

Does this attribute appertain to any specific subjects, or can you apply it to 
any declaration?



Comment at: include/clang/Basic/Attr.td:490
+  let Spellings = [GNU<"signal">];
+  let Documentation = [Undocumented];
+}

No new undocumented attributes, please.



Comment at: test/CodeGen/avr/attributes/naked.c:4
+// CHECK: define void @foo() #0
+__attribute__((naked)) void foo(void) { }
+

This test seems unrelated as you didn't modify anything about the naked 
attribute?


https://reviews.llvm.org/D28451



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

[PATCH] D20428: Tracking exception specification source locations

[don hinton via Phabricator via cfe-commits]

hintonda added a comment.

Aaron, I've got this version in a branch, so if you like, I'd be happy to apply 
Malcolm's suggestions.


https://reviews.llvm.org/D20428



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

[PATCH] D28400: [AArch64] Use generic bitreverse intrinsic, rather than AArch64 specific.

[Chad Rosier via Phabricator via cfe-commits]

mcrosier added inline comments.



Comment at: test/CodeGen/arm_acle.c:247
 // ARM-LABEL: test_rbit
 // AArch32: call i32 @llvm.arm.rbit
+// AArch64: call i32 @llvm.bitreverse.i32

RKSimon wrote:
> Since you're here is it worth dealing with the AARCH32 case as well? We know 
> it works on the llvm side.
I was thinking I would commit a separate patch once this one and D28379 were 
approved.


https://reviews.llvm.org/D28400



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

[PATCH] D20428: Tracking exception specification source locations

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In https://reviews.llvm.org/D20428#641416, @hintonda wrote:

> Aaron, I've got this version in a branch, so if you like, I'd be happy to 
> apply Malcolm's suggestions.


Please do; they're good suggestions.


https://reviews.llvm.org/D20428



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

[PATCH] D28400: [AArch64] Use generic bitreverse intrinsic, rather than AArch64 specific.

[silviu.bara...@arm.com via Phabricator via cfe-commits]

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

This looks straight-forward to me. LGTM.

-Silviu


https://reviews.llvm.org/D28400



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

[PATCH] D20428: Tracking exception specification source locations

[don hinton via Phabricator via cfe-commits]

hintonda updated this revision to Diff 83816.
hintonda added a comment.

- Address comments.


https://reviews.llvm.org/D20428

Files:
  include/clang/AST/Decl.h
  include/clang/AST/TypeLoc.h
  lib/AST/Decl.cpp
  lib/Parse/ParseDeclCXX.cpp
  lib/Sema/SemaType.cpp
  lib/Sema/TreeTransform.h
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTWriter.cpp
  unittests/AST/SourceLocationTest.cpp

Index: unittests/AST/SourceLocationTest.cpp
===
--- unittests/AST/SourceLocationTest.cpp
+++ unittests/AST/SourceLocationTest.cpp
@@ -670,5 +670,72 @@
   Language::Lang_CXX11));
 }
 
+class ExceptionSpecRangeVerifier : public RangeVerifier {
+protected:
+  SourceRange getRange(const TypeLoc &Node) override {
+auto T =
+  Node.getUnqualifiedLoc().castAs();
+assert(!T.isNull());
+return T.getExceptionSpecRange();
+  }
+};
+
+class ParmVarExceptionSpecRangeVerifier : public RangeVerifier {
+protected:
+  SourceRange getRange(const ParmVarDecl &Node) override {
+if (const TypeSourceInfo *TSI = Node.getTypeSourceInfo()) {
+  TypeLoc TL = TSI->getTypeLoc();
+  if (TL.getType()->isPointerType()) {
+TL = TL.getNextTypeLoc().IgnoreParens();
+if (auto FPTL = TL.getAs()) {
+  return FPTL.getExceptionSpecRange();
+}
+  }
+}
+return SourceRange();
+  }
+};
+
+TEST(FunctionDecl, ExceptionSpecifications) {
+  ExceptionSpecRangeVerifier Verifier;
+
+  Verifier.expectRange(1, 10, 1, 16);
+  EXPECT_TRUE(Verifier.match("void f() throw();\n", loc(functionType(;
+
+  Verifier.expectRange(1, 10, 1, 34);
+  EXPECT_TRUE(Verifier.match("void f() throw(void(void) throw());\n",
+ loc(functionType(;
+
+  Verifier.expectRange(1, 10, 1, 19);
+  std::vector Args;
+  Args.push_back("-fms-extensions");
+  EXPECT_TRUE(Verifier.match("void f() throw(...);\n", loc(functionType()),
+ Args, Language::Lang_CXX));
+
+  Verifier.expectRange(1, 10, 1, 10);
+  EXPECT_TRUE(Verifier.match("void f() noexcept;\n", loc(functionType()),
+ Language::Lang_CXX11));
+
+  Verifier.expectRange(1, 10, 1, 24);
+  EXPECT_TRUE(Verifier.match("void f() noexcept(false);\n", loc(functionType()),
+ Language::Lang_CXX11));
+
+  Verifier.expectRange(1, 10, 1, 32);
+  EXPECT_TRUE(Verifier.match("void f() noexcept(noexcept(1+1));\n",
+ loc(functionType()), Language::Lang_CXX11));
+
+  ParmVarExceptionSpecRangeVerifier Verifier2;
+  Verifier2.expectRange(1, 25, 1, 31);
+  EXPECT_TRUE(Verifier2.match("void g(void (*fp)(void) throw());\n",
+  parmVarDecl(hasType(pointerType(pointee(
+  parenType(innerType(functionType();
+
+  Verifier2.expectRange(1, 25, 1, 38);
+  EXPECT_TRUE(Verifier2.match("void g(void (*fp)(void) noexcept(true));\n",
+  parmVarDecl(hasType(pointerType(pointee(
+  parenType(innerType(functionType())),
+  Language::Lang_CXX11));
+}
+
 } // end namespace ast_matchers
 } // end namespace clang
Index: lib/Serialization/ASTWriter.cpp
===
--- lib/Serialization/ASTWriter.cpp
+++ lib/Serialization/ASTWriter.cpp
@@ -629,6 +629,7 @@
   Record.AddSourceLocation(TL.getLocalRangeBegin());
   Record.AddSourceLocation(TL.getLParenLoc());
   Record.AddSourceLocation(TL.getRParenLoc());
+  Record.AddSourceRange(TL.getExceptionSpecRange());
   Record.AddSourceLocation(TL.getLocalRangeEnd());
   for (unsigned i = 0, e = TL.getNumParams(); i != e; ++i)
 Record.AddDeclRef(TL.getParam(i));
Index: lib/Serialization/ASTReader.cpp
===
--- lib/Serialization/ASTReader.cpp
+++ lib/Serialization/ASTReader.cpp
@@ -5990,6 +5990,8 @@
   TL.setLocalRangeBegin(ReadSourceLocation());
   TL.setLParenLoc(ReadSourceLocation());
   TL.setRParenLoc(ReadSourceLocation());
+  TL.setExceptionSpecRange(SourceRange(Reader->ReadSourceLocation(*F, Record, Idx),
+   Reader->ReadSourceLocation(*F, Record, Idx)));
   TL.setLocalRangeEnd(ReadSourceLocation());
   for (unsigned i = 0, e = TL.getNumParams(); i != e; ++i) {
 TL.setParam(i, Reader->ReadDeclAs(*F, Record, Idx));
Index: lib/Sema/TreeTransform.h
===
--- lib/Sema/TreeTransform.h
+++ lib/Sema/TreeTransform.h
@@ -5023,6 +5023,7 @@
   NewTL.setLocalRangeBegin(TL.getLocalRangeBegin());
   NewTL.setLParenLoc(TL.getLParenLoc());
   NewTL.setRParenLoc(TL.getRParenLoc());
+  NewTL.setExceptionSpecRange(TL.getExceptionSpecRange());
   NewTL.setLocalRangeEnd(TL.getLocalRangeEnd());
   for (unsigned i = 0, e = NewTL.getNumParams(); i != e; ++i)
 NewTL.setParam(i, ParamDecls[i]);
Index: lib/S

[libcxx] r291572 - Fix up some mismatched SFINAE conditionsin shared_ptr; some used '_Tp*', others used 'element_type *'. Today, they're the same - but soon they won't be. No functional change.

[Marshall Clow via cfe-commits]

Author: marshall
Date: Tue Jan 10 10:59:33 2017
New Revision: 291572

URL: http://llvm.org/viewvc/llvm-project?rev=291572&view=rev
Log:
Fix up some mismatched SFINAE conditionsin shared_ptr; some used '_Tp*', others 
used 'element_type *'. Today, they're the same - but soon they won't be. No 
functional change.

Modified:
libcxx/trunk/include/memory

Modified: libcxx/trunk/include/memory
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/memory?rev=291572&r1=291571&r2=291572&view=diff
==
--- libcxx/trunk/include/memory (original)
+++ libcxx/trunk/include/memory Tue Jan 10 10:59:33 2017
@@ -3884,6 +3884,7 @@ class _LIBCPP_TEMPLATE_VIS shared_ptr
 {
 public:
 typedef _Tp element_type;
+
 #if _LIBCPP_STD_VER > 14
 typedef weak_ptr<_Tp> weak_type;
 #endif
@@ -3914,17 +3915,17 @@ public:
 template
 _LIBCPP_INLINE_VISIBILITY
 shared_ptr(const shared_ptr<_Yp>& __r,
-   typename enable_if::value, 
__nat>::type = __nat())
+   typename enable_if::value, __nat>::type = __nat())
_NOEXCEPT;
 #ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
 _LIBCPP_INLINE_VISIBILITY
 shared_ptr(shared_ptr&& __r) _NOEXCEPT;
 template _LIBCPP_INLINE_VISIBILITY  
shared_ptr(shared_ptr<_Yp>&& __r,
-   typename enable_if::value, 
__nat>::type = __nat())
+   typename enable_if::value, __nat>::type = __nat())
_NOEXCEPT;
 #endif  // _LIBCPP_HAS_NO_RVALUE_REFERENCES
 template explicit shared_ptr(const weak_ptr<_Yp>& __r,
-   typename enable_if::value, 
__nat>::type= __nat());
+   typename enable_if::value, __nat>::type= __nat());
 #ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
 template
 shared_ptr(auto_ptr<_Yp>&& __r,
@@ -4316,7 +4317,7 @@ template
 template
 inline
 shared_ptr<_Tp>::shared_ptr(const shared_ptr<_Yp>& __r,
-typename enable_if::value, __nat>::type)
+typename enable_if::value, __nat>::type)
  _NOEXCEPT
 : __ptr_(__r.__ptr_),
   __cntrl_(__r.__cntrl_)
@@ -4341,7 +4342,7 @@ template
 template
 inline
 shared_ptr<_Tp>::shared_ptr(shared_ptr<_Yp>&& __r,
-typename enable_if::value, __nat>::type)
+typename enable_if::value, __nat>::type)
  _NOEXCEPT
 : __ptr_(__r.__ptr_),
   __cntrl_(__r.__cntrl_)
@@ -4639,7 +4640,7 @@ template
 inline
 typename enable_if
 <
-is_convertible<_Yp*, _Tp*>::value,
+is_convertible<_Yp*, typename shared_ptr<_Tp>::element_type*>::value,
 shared_ptr<_Tp>&
 >::type
 shared_ptr<_Tp>::operator=(const shared_ptr<_Yp>& __r) _NOEXCEPT
@@ -4664,7 +4665,7 @@ template
 inline
 typename enable_if
 <
-is_convertible<_Yp*, _Tp*>::value,
+is_convertible<_Yp*, typename shared_ptr<_Tp>::element_type*>::value,
 shared_ptr<_Tp>&
 >::type
 shared_ptr<_Tp>::operator=(shared_ptr<_Yp>&& __r)
@@ -4679,7 +4680,7 @@ inline
 typename enable_if
 <
 !is_array<_Yp>::value &&
-is_convertible<_Yp*, _Tp*>::value,
+is_convertible<_Yp*, typename shared_ptr<_Tp>::element_type*>::value,
 shared_ptr<_Tp>
 >::type&
 shared_ptr<_Tp>::operator=(auto_ptr<_Yp>&& __r)
@@ -4694,7 +4695,8 @@ inline
 typename enable_if
 <
 !is_array<_Yp>::value &&
-is_convertible::pointer, _Tp*>::value,
+is_convertible::pointer, 
+   typename shared_ptr<_Tp>::element_type*>::value,
 shared_ptr<_Tp>&
 >::type
 shared_ptr<_Tp>::operator=(unique_ptr<_Yp, _Dp>&& __r)
@@ -4711,7 +4713,7 @@ inline _LIBCPP_INLINE_VISIBILITY
 typename enable_if
 <
 !is_array<_Yp>::value &&
-is_convertible<_Yp*, _Tp*>::value,
+is_convertible<_Yp*, element_type*>::value,
 shared_ptr<_Tp>&
 >::type
 shared_ptr<_Tp>::operator=(auto_ptr<_Yp> __r)
@@ -4726,7 +4728,7 @@ inline _LIBCPP_INLINE_VISIBILITY
 typename enable_if
 <
 !is_array<_Yp>::value &&
-is_convertible::pointer, _Tp*>::value,
+is_convertible::pointer, 
element_type*>::value,
 shared_ptr<_Tp>&
 >::type
 shared_ptr<_Tp>::operator=(unique_ptr<_Yp, _Dp> __r)
@@ -4759,7 +4761,7 @@ template
 inline
 typename enable_if
 <
-is_convertible<_Yp*, _Tp*>::value,
+is_convertible<_Yp*, typename shared_ptr<_Tp>::element_type*>::value,
 void
 >::type
 shared_ptr<_Tp>::reset(_Yp* __p)
@@ -4772,7 +4774,7 @@ template
 inline
 typename enable_if
 <
-is_convertible<_Yp*, _Tp*>::value,
+is_convertible<_Yp*, typename shared_ptr<_Tp>::element_type*>::value,
 void
 >::type
 shared_ptr<_Tp>::reset(_Yp* __p, _Dp __d)
@@ -4785,7 +4787,7 @@ template::value,
+is_convertible<_Yp*, typename shared_ptr<_Tp>::element_type*>::value,
 void
 >::type
 shared_ptr<_Tp>::reset(_Yp* __p, _Dp __d, _Alloc __a)
@@ -5350,7 +5352,7 @@ weak_ptr<_Tp>::reset() _NOEXCEPT
 template
 template
 shared_ptr<_Tp>::shared_ptr(const weak_ptr<_Yp>& _

[PATCH] D28445: [Analyzer] Extend taint propagation and checking

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

Thanks for working on the taint! I really wish the taint analysis in the 
analyzer to flourish, and the part you've digged into is particularly 
sensitive, so i'd dump some thoughts here, hopefully helpful.

**What works as it should: **

> In the second example, the SVal obtained in 
> `GenericTaintChecker::getPointedToSymbol()` is a `LazyCompoundVal` so 
> `SVal::getAsSymbol()` returns a NULL SymbolRef, meaning the symbol is not 
> tainted.

Only symbols currently can, and in my opinion ever should, directly carry taint.

We have symbols, regions, concrete values, and compound values.

A symbol //$s// denotes a particular but unknown value from a certain set 
//**S**// (say, of all integers or all pointers); we are not generally sure if 
it can denote any value from //**S**//, or only from a smaller subset 
//**S'**// within //**S**// (for example, the analyzer may be unaware that 
//$s// is always positive, because the small part of the code it's looking into 
doesn't give any hints). Analyzer also gathers constraints //**C**// when he 
picks execution paths - for instance, on a branch condition "//if ($s < 5)//", 
if we pick the true branch, //**C**// gets cropped into //[-INT_MIN, 4]//, and 
the possible values of //$s// stay within //**S'**// intersected with 
//**C**//, while the analyzer thinks that possible values of //$s// are within 
//**S**// intersected with //**C**//.

A tainted symbol merely corresponds to the special case when we know that 
//**S'** = **S**//, which we normally don't - that is, the analyzer knows that 
for some reason the symbol's value is so much chaotic that it may definitely 
take any value from //**S**// in run-time. The analyzer can know it by seeing 
that the symbol comes from an "untrusted source" such as from "outside".

We do not really talk about tainted regions - instead, we talk about tainted 
pointer values, which are symbols. In this sense, in code

  char buffer[100];

the region of variable `buffer` cannot be tainted. No matter what we do, the 
buffer region itself comes from a perfectly trusted source - it's always in the 
same well-known segment of memory (stack or in global memory). In practice this 
means that the attacker cannot affect or forge the positioning of this segment 
in any way. On the other hand, if //$i// is a tainted index symbol, then region 
//buffer[$i]// of the //$i//'th element would be "said to be tainted" - in the 
sense, its pointer is known to possibly take any value, not necessarily within 
range of the buffer. Similarly, if a pointer-symbol is tainted, the segment of 
memory (region) it points to (called `SymbolicRegion`) is "said to be tainted". 
So //whenever we're talking about a "tainted region", it's always a shorthand 
for talking about a certain tainted symbol//.

Concrete values shouldn't be tainted for the same reason - they are already 
"known", their //**S**// would consist of one element, so there's little 
interest in saying that they can take any value from this set - they're bound 
to take that only value.

Now, we have (possibly lazy) compound values. The whole point of compound 
values is that they consist of multiple other values, and therefore there's 
usually little sense in even considering them as a whole. Some sub-values of 
them may be null, over-constrained, uninitialized, irrelevant (eg. padding), or 
tainted, while other sub-values may be completely different. In your example, 
you obtain a compound value of an array, which consists of all values of all 
elements of the array. There's no point in asking if the compound value itself 
is tainted; instead, you might be interested in particular elements. For 
example, `buffer[1]` may be tainted, while `buffer[2]` was overwritten with 
`'\0'` and is no longer tainted. If you had a structure, you may ask if a 
certain field is tainted, or if all fields are tainted.

**What works but not as it should:**

> In the first example, buf has it's symbol correctly extracted (via 
> `GenericTaintChecker::getPointedToSymbol())` as a 
> `SymbolDerived{conj_$N{char}, element{buf,0 S64b,char}}`.

Nope, unfortunately, in fact this is not correctly extracted either. This 
symbol denotes the value of the first element of the buffer. The taint checker 
marks the first element as tainted, and then later reads that the first element 
is tainted, and throws the warning. However, if we pass, say, `buffer+1` to 
`execl`, it breaks.

The root cause of the problem is how the analyzer denotes casted/typed 
pointers: the `SVal` for a pointer of type `T*` is said to be the element 
region with index 0 of the region behind the pointer. You can read this as "The 
pointer points to the first `T` on this segment of memory". In this case, we 
try to say that the value behind the pointer is tainted, and we forget that the 
value behind the pointer is not only the first element of the array, but the 
whole array, even though the pointer points to the first element only.

r291574 - [AArch64] Use generic bitreverse intrinsic, rather than AArch64 specific.

[Chad Rosier via cfe-commits]

Author: mcrosier
Date: Tue Jan 10 11:20:28 2017
New Revision: 291574

URL: http://llvm.org/viewvc/llvm-project?rev=291574&view=rev
Log:
[AArch64] Use generic bitreverse intrinsic, rather than AArch64 specific.

Differential Revision: https://reviews.llvm.org/D28400

Modified:
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/test/CodeGen/arm_acle.c
cfe/trunk/test/CodeGen/builtins-arm64.c

Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=291574&r1=291573&r2=291574&view=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Tue Jan 10 11:20:28 2017
@@ -5226,14 +5226,14 @@ Value *CodeGenFunction::EmitAArch64Built
"rbit of unusual size!");
 llvm::Value *Arg = EmitScalarExpr(E->getArg(0));
 return Builder.CreateCall(
-CGM.getIntrinsic(Intrinsic::aarch64_rbit, Arg->getType()), Arg, 
"rbit");
+CGM.getIntrinsic(Intrinsic::bitreverse, Arg->getType()), Arg, "rbit");
   }
   if (BuiltinID == AArch64::BI__builtin_arm_rbit64) {
 assert((getContext().getTypeSize(E->getType()) == 64) &&
"rbit of unusual size!");
 llvm::Value *Arg = EmitScalarExpr(E->getArg(0));
 return Builder.CreateCall(
-CGM.getIntrinsic(Intrinsic::aarch64_rbit, Arg->getType()), Arg, 
"rbit");
+CGM.getIntrinsic(Intrinsic::bitreverse, Arg->getType()), Arg, "rbit");
   }
 
   if (BuiltinID == AArch64::BI__clear_cache) {

Modified: cfe/trunk/test/CodeGen/arm_acle.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/arm_acle.c?rev=291574&r1=291573&r2=291574&view=diff
==
--- cfe/trunk/test/CodeGen/arm_acle.c (original)
+++ cfe/trunk/test/CodeGen/arm_acle.c Tue Jan 10 11:20:28 2017
@@ -245,14 +245,14 @@ int16_t test_revsh(int16_t t) {
 
 // ARM-LABEL: test_rbit
 // AArch32: call i32 @llvm.arm.rbit
-// AArch64: call i32 @llvm.aarch64.rbit.i32
+// AArch64: call i32 @llvm.bitreverse.i32
 uint32_t test_rbit(uint32_t t) {
   return __rbit(t);
 }
 
 // ARM-LABEL: test_rbitl
 // AArch32: call i32 @llvm.arm.rbit
-// AArch64: call i64 @llvm.aarch64.rbit.i64
+// AArch64: call i64 @llvm.bitreverse.i64
 long test_rbitl(long t) {
   return __rbitl(t);
 }
@@ -260,7 +260,7 @@ long test_rbitl(long t) {
 // ARM-LABEL: test_rbitll
 // AArch32: call i32 @llvm.arm.rbit
 // AArch32: call i32 @llvm.arm.rbit
-// AArch64: call i64 @llvm.aarch64.rbit.i64
+// AArch64: call i64 @llvm.bitreverse.i64
 uint64_t test_rbitll(uint64_t t) {
   return __rbitll(t);
 }

Modified: cfe/trunk/test/CodeGen/builtins-arm64.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/builtins-arm64.c?rev=291574&r1=291573&r2=291574&view=diff
==
--- cfe/trunk/test/CodeGen/builtins-arm64.c (original)
+++ cfe/trunk/test/CodeGen/builtins-arm64.c Tue Jan 10 11:20:28 2017
@@ -10,12 +10,12 @@ void *tp (void) {
 // CHECK: call {{.*}} @llvm.thread.pointer()
 }
 
-// CHECK: call {{.*}} @llvm.aarch64.rbit.i32(i32 %a)
+// CHECK: call {{.*}} @llvm.bitreverse.i32(i32 %a)
 unsigned rbit(unsigned a) {
   return __builtin_arm_rbit(a);
 }
 
-// CHECK: call {{.*}} @llvm.aarch64.rbit.i64(i64 %a)
+// CHECK: call {{.*}} @llvm.bitreverse.i64(i64 %a)
 unsigned long long rbit64(unsigned long long a) {
   return __builtin_arm_rbit64(a);
 }


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

[PATCH] D28400: [AArch64] Use generic bitreverse intrinsic, rather than AArch64 specific.

[Chad Rosier via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL291574: [AArch64] Use generic bitreverse intrinsic, rather 
than AArch64 specific. (authored by mcrosier).

Changed prior to commit:
  https://reviews.llvm.org/D28400?vs=83367&id=83817#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D28400

Files:
  cfe/trunk/lib/CodeGen/CGBuiltin.cpp
  cfe/trunk/test/CodeGen/arm_acle.c
  cfe/trunk/test/CodeGen/builtins-arm64.c


Index: cfe/trunk/test/CodeGen/arm_acle.c
===
--- cfe/trunk/test/CodeGen/arm_acle.c
+++ cfe/trunk/test/CodeGen/arm_acle.c
@@ -245,22 +245,22 @@
 
 // ARM-LABEL: test_rbit
 // AArch32: call i32 @llvm.arm.rbit
-// AArch64: call i32 @llvm.aarch64.rbit.i32
+// AArch64: call i32 @llvm.bitreverse.i32
 uint32_t test_rbit(uint32_t t) {
   return __rbit(t);
 }
 
 // ARM-LABEL: test_rbitl
 // AArch32: call i32 @llvm.arm.rbit
-// AArch64: call i64 @llvm.aarch64.rbit.i64
+// AArch64: call i64 @llvm.bitreverse.i64
 long test_rbitl(long t) {
   return __rbitl(t);
 }
 
 // ARM-LABEL: test_rbitll
 // AArch32: call i32 @llvm.arm.rbit
 // AArch32: call i32 @llvm.arm.rbit
-// AArch64: call i64 @llvm.aarch64.rbit.i64
+// AArch64: call i64 @llvm.bitreverse.i64
 uint64_t test_rbitll(uint64_t t) {
   return __rbitll(t);
 }
Index: cfe/trunk/test/CodeGen/builtins-arm64.c
===
--- cfe/trunk/test/CodeGen/builtins-arm64.c
+++ cfe/trunk/test/CodeGen/builtins-arm64.c
@@ -10,12 +10,12 @@
 // CHECK: call {{.*}} @llvm.thread.pointer()
 }
 
-// CHECK: call {{.*}} @llvm.aarch64.rbit.i32(i32 %a)
+// CHECK: call {{.*}} @llvm.bitreverse.i32(i32 %a)
 unsigned rbit(unsigned a) {
   return __builtin_arm_rbit(a);
 }
 
-// CHECK: call {{.*}} @llvm.aarch64.rbit.i64(i64 %a)
+// CHECK: call {{.*}} @llvm.bitreverse.i64(i64 %a)
 unsigned long long rbit64(unsigned long long a) {
   return __builtin_arm_rbit64(a);
 }
Index: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
===
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp
@@ -5226,14 +5226,14 @@
"rbit of unusual size!");
 llvm::Value *Arg = EmitScalarExpr(E->getArg(0));
 return Builder.CreateCall(
-CGM.getIntrinsic(Intrinsic::aarch64_rbit, Arg->getType()), Arg, 
"rbit");
+CGM.getIntrinsic(Intrinsic::bitreverse, Arg->getType()), Arg, "rbit");
   }
   if (BuiltinID == AArch64::BI__builtin_arm_rbit64) {
 assert((getContext().getTypeSize(E->getType()) == 64) &&
"rbit of unusual size!");
 llvm::Value *Arg = EmitScalarExpr(E->getArg(0));
 return Builder.CreateCall(
-CGM.getIntrinsic(Intrinsic::aarch64_rbit, Arg->getType()), Arg, 
"rbit");
+CGM.getIntrinsic(Intrinsic::bitreverse, Arg->getType()), Arg, "rbit");
   }
 
   if (BuiltinID == AArch64::BI__clear_cache) {


Index: cfe/trunk/test/CodeGen/arm_acle.c
===
--- cfe/trunk/test/CodeGen/arm_acle.c
+++ cfe/trunk/test/CodeGen/arm_acle.c
@@ -245,22 +245,22 @@
 
 // ARM-LABEL: test_rbit
 // AArch32: call i32 @llvm.arm.rbit
-// AArch64: call i32 @llvm.aarch64.rbit.i32
+// AArch64: call i32 @llvm.bitreverse.i32
 uint32_t test_rbit(uint32_t t) {
   return __rbit(t);
 }
 
 // ARM-LABEL: test_rbitl
 // AArch32: call i32 @llvm.arm.rbit
-// AArch64: call i64 @llvm.aarch64.rbit.i64
+// AArch64: call i64 @llvm.bitreverse.i64
 long test_rbitl(long t) {
   return __rbitl(t);
 }
 
 // ARM-LABEL: test_rbitll
 // AArch32: call i32 @llvm.arm.rbit
 // AArch32: call i32 @llvm.arm.rbit
-// AArch64: call i64 @llvm.aarch64.rbit.i64
+// AArch64: call i64 @llvm.bitreverse.i64
 uint64_t test_rbitll(uint64_t t) {
   return __rbitll(t);
 }
Index: cfe/trunk/test/CodeGen/builtins-arm64.c
===
--- cfe/trunk/test/CodeGen/builtins-arm64.c
+++ cfe/trunk/test/CodeGen/builtins-arm64.c
@@ -10,12 +10,12 @@
 // CHECK: call {{.*}} @llvm.thread.pointer()
 }
 
-// CHECK: call {{.*}} @llvm.aarch64.rbit.i32(i32 %a)
+// CHECK: call {{.*}} @llvm.bitreverse.i32(i32 %a)
 unsigned rbit(unsigned a) {
   return __builtin_arm_rbit(a);
 }
 
-// CHECK: call {{.*}} @llvm.aarch64.rbit.i64(i64 %a)
+// CHECK: call {{.*}} @llvm.bitreverse.i64(i64 %a)
 unsigned long long rbit64(unsigned long long a) {
   return __builtin_arm_rbit64(a);
 }
Index: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
===
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp
@@ -5226,14 +5226,14 @@
"rbit of unusual size!");
 llvm::Value *Arg = EmitScalarExpr(E->getArg(0));
 return Builder.CreateCall(
-CGM.getIntrinsic(Intrinsic::aarch64_rbit, Arg->getType()), Arg, "rbit");
+CGM.getIntrinsic(Intrinsic::bitreverse, Arg->getType()), Arg, "rbit");
   }
   if (BuiltinID == AArch64

[PATCH] D28231: -Wunreachable-code: Avoid multiple diagnostics that are triggered by the same source range and fix the unary operator fixit source range

[Alex Lorenz via Phabricator via cfe-commits]

arphaman updated this revision to Diff 83819.
arphaman added a comment.

Fix more issues with FIXIT for unary operators.


Repository:
  rL LLVM

https://reviews.llvm.org/D28231

Files:
  lib/Analysis/ReachableCode.cpp
  lib/Sema/AnalysisBasedWarnings.cpp
  test/Sema/warn-unreachable.c

Index: test/Sema/warn-unreachable.c
===
--- test/Sema/warn-unreachable.c
+++ test/Sema/warn-unreachable.c
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 %s -fsyntax-only -verify -fblocks -Wunreachable-code-aggressive -Wno-unused-value -Wno-covered-switch-default -I %S/Inputs
+// RUN: %clang_cc1 -fsyntax-only -fblocks -Wunreachable-code-aggressive -Wno-unused-value -Wno-covered-switch-default -fdiagnostics-parseable-fixits -I %S/Inputs %s 2>&1 | FileCheck %s
 
 #include "warn-unreachable.h"
 
@@ -396,3 +397,57 @@
   else
 calledFun();
 }
+
+// rdar://24570531
+
+struct StructWithPointer {
+  void *p;
+};
+
+void emitJustOneWarningForOr(struct StructWithPointer *s) {
+  if (1 || !s->p) // expected-note {{silence by adding parentheses to mark code as explicitly dead}}
+return; // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:7-[[@LINE-1]]:7}:"/* DISABLES CODE */ ("
+// CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:8-[[@LINE-2]]:8}:")"
+  emitJustOneWarningForOr(s); // expected-warning {{code will never be executed}}
+}
+
+void emitJustOneWarningForOrSilenced(struct StructWithPointer *s) {
+  if ((1) || !s->p)
+return;
+
+  emitJustOneWarningForOrSilenced(s); // no warning
+}
+
+void emitJustOneWarningForOr2(struct StructWithPointer *s) {
+  if (1 || !s->p) // expected-warning {{code will never be executed}}
+return; // expected-note@-1 {{silence by adding parentheses to mark code as explicitly dead}}
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:7-[[@LINE-2]]:7}:"/* DISABLES CODE */ ("
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:8-[[@LINE-3]]:8}:")"
+}
+
+void wrapOneInFixit(struct StructWithPointer *s) {
+  if (!s->p || 1) // expected-note {{silence by adding parentheses to mark code as explicitly dead}}
+return; // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:16-[[@LINE-1]]:16}:"/* DISABLES CODE */ ("
+// CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:17-[[@LINE-2]]:17}:")"
+  wrapOneInFixit(s); // expected-warning {{code will never be executed}}
+}
+
+void unaryOpNoFixit() {
+  if (- 1)
+return; // CHECK-NOT: fix-it:"{{.*}}":{[[@LINE-1]]
+  unaryOpNoFixit(); // expected-warning {{code will never be executed}}
+}
+
+void unaryOpStrictFixit(struct StructWithPointer *s) {
+  if (!(s->p && 0)) // expected-note {{silence by adding parentheses to mark code as explicitly dead}}
+return; // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:17-[[@LINE-1]]:17}:"/* DISABLES CODE */ ("
+// CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:18-[[@LINE-2]]:18}:")"
+  unaryOpStrictFixit(s); // expected-warning {{code will never be executed}}
+}
+
+void unaryOpFixitCastSubExpr(int x) {
+  if (! (int)0) // expected-note {{silence by adding parentheses to mark code as explicitly dead}}
+return; // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:7-[[@LINE-1]]:7}:"/* DISABLES CODE */ ("
+// CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:15-[[@LINE-2]]:15}:")"
+  unaryOpFixitCastSubExpr(x); // expected-warning {{code will never be executed}}
+}
Index: lib/Sema/AnalysisBasedWarnings.cpp
===
--- lib/Sema/AnalysisBasedWarnings.cpp
+++ lib/Sema/AnalysisBasedWarnings.cpp
@@ -56,14 +56,24 @@
 namespace {
   class UnreachableCodeHandler : public reachable_code::Callback {
 Sema &S;
+SourceRange PreviousSilenceableCondVal;
+
   public:
 UnreachableCodeHandler(Sema &s) : S(s) {}
 
 void HandleUnreachable(reachable_code::UnreachableKind UK,
SourceLocation L,
SourceRange SilenceableCondVal,
SourceRange R1,
SourceRange R2) override {
+  // Avoid reporting multiple unreachable code diagnostics that are
+  // triggered by the same conditional value.
+  if (PreviousSilenceableCondVal.isValid() &&
+  SilenceableCondVal.isValid() &&
+  PreviousSilenceableCondVal == SilenceableCondVal)
+return;
+  PreviousSilenceableCondVal = SilenceableCondVal;
+
   unsigned diag = diag::warn_unreachable;
   switch (UK) {
 case reachable_code::UK_Break:
Index: lib/Analysis/ReachableCode.cpp
===
--- lib/Analysis/ReachableCode.cpp
+++ lib/Analysis/ReachableCode.cpp
@@ -218,11 +218,21 @@
 }
 case Stmt::UnaryOperatorClass: {
   const UnaryOperator *UO = cast(S);
-  if (SilenceableCondVal) 
-*SilenceableCondVal = UO->getSourceRange();  
-  return UO->getOpcode() == UO_LNot &&
- isConfigurationValue(UO->getSubExpr(), PP, SilenceableCondVal,
-  IncludeIntegers, WrappedI

r291576 - CGDecl: Skip static variable initializers in unreachable code

[Matthias Braun via cfe-commits]

Author: matze
Date: Tue Jan 10 11:43:01 2017
New Revision: 291576

URL: http://llvm.org/viewvc/llvm-project?rev=291576&view=rev
Log:
CGDecl: Skip static variable initializers in unreachable code

This fixes http://llvm.org/PR31054

Differential Revision: https://reviews.llvm.org/D28505

Added:
cfe/trunk/test/CodeGenCXX/pr31054.cpp
Modified:
cfe/trunk/lib/CodeGen/CGDecl.cpp

Modified: cfe/trunk/lib/CodeGen/CGDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDecl.cpp?rev=291576&r1=291575&r2=291576&view=diff
==
--- cfe/trunk/lib/CodeGen/CGDecl.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDecl.cpp Tue Jan 10 11:43:01 2017
@@ -311,7 +311,7 @@ CodeGenFunction::AddInitializerToStaticV
   if (!Init) {
 if (!getLangOpts().CPlusPlus)
   CGM.ErrorUnsupported(D.getInit(), "constant l-value expression");
-else if (Builder.GetInsertBlock()) {
+else if (HaveInsertPoint()) {
   // Since we have a static initializer, this global variable can't
   // be constant.
   GV->setConstant(false);
@@ -352,7 +352,7 @@ CodeGenFunction::AddInitializerToStaticV
   GV->setConstant(CGM.isTypeConstant(D.getType(), true));
   GV->setInitializer(Init);
 
-  if (hasNontrivialDestruction(D.getType())) {
+  if (hasNontrivialDestruction(D.getType()) && HaveInsertPoint()) {
 // We have a constant initializer, but a nontrivial destructor. We still
 // need to perform a guarded "initialization" in order to register the
 // destructor.

Added: cfe/trunk/test/CodeGenCXX/pr31054.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/pr31054.cpp?rev=291576&view=auto
==
--- cfe/trunk/test/CodeGenCXX/pr31054.cpp (added)
+++ cfe/trunk/test/CodeGenCXX/pr31054.cpp Tue Jan 10 11:43:01 2017
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -emit-llvm -o - %s | 
FileCheck %s
+
+struct A { ~A(); };
+void func() {
+  return;
+  static A k;
+}
+
+// Test that we did not crash, by checking whether function was created.
+// CHECK-LABEL: define void @_Z4funcv() #0 {
+// CHECK: ret void
+// CHECK: }


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

[PATCH] D28505: CGDecl: Skip static variable initializers in unreachable code

[Phabricator via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL291576: CGDecl: Skip static variable initializers in 
unreachable code (authored by matze).

Changed prior to commit:
  https://reviews.llvm.org/D28505?vs=83754&id=83820#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D28505

Files:
  cfe/trunk/lib/CodeGen/CGDecl.cpp
  cfe/trunk/test/CodeGenCXX/pr31054.cpp


Index: cfe/trunk/lib/CodeGen/CGDecl.cpp
===
--- cfe/trunk/lib/CodeGen/CGDecl.cpp
+++ cfe/trunk/lib/CodeGen/CGDecl.cpp
@@ -311,7 +311,7 @@
   if (!Init) {
 if (!getLangOpts().CPlusPlus)
   CGM.ErrorUnsupported(D.getInit(), "constant l-value expression");
-else if (Builder.GetInsertBlock()) {
+else if (HaveInsertPoint()) {
   // Since we have a static initializer, this global variable can't
   // be constant.
   GV->setConstant(false);
@@ -352,7 +352,7 @@
   GV->setConstant(CGM.isTypeConstant(D.getType(), true));
   GV->setInitializer(Init);
 
-  if (hasNontrivialDestruction(D.getType())) {
+  if (hasNontrivialDestruction(D.getType()) && HaveInsertPoint()) {
 // We have a constant initializer, but a nontrivial destructor. We still
 // need to perform a guarded "initialization" in order to register the
 // destructor.
Index: cfe/trunk/test/CodeGenCXX/pr31054.cpp
===
--- cfe/trunk/test/CodeGenCXX/pr31054.cpp
+++ cfe/trunk/test/CodeGenCXX/pr31054.cpp
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -emit-llvm -o - %s | 
FileCheck %s
+
+struct A { ~A(); };
+void func() {
+  return;
+  static A k;
+}
+
+// Test that we did not crash, by checking whether function was created.
+// CHECK-LABEL: define void @_Z4funcv() #0 {
+// CHECK: ret void
+// CHECK: }


Index: cfe/trunk/lib/CodeGen/CGDecl.cpp
===
--- cfe/trunk/lib/CodeGen/CGDecl.cpp
+++ cfe/trunk/lib/CodeGen/CGDecl.cpp
@@ -311,7 +311,7 @@
   if (!Init) {
 if (!getLangOpts().CPlusPlus)
   CGM.ErrorUnsupported(D.getInit(), "constant l-value expression");
-else if (Builder.GetInsertBlock()) {
+else if (HaveInsertPoint()) {
   // Since we have a static initializer, this global variable can't
   // be constant.
   GV->setConstant(false);
@@ -352,7 +352,7 @@
   GV->setConstant(CGM.isTypeConstant(D.getType(), true));
   GV->setInitializer(Init);
 
-  if (hasNontrivialDestruction(D.getType())) {
+  if (hasNontrivialDestruction(D.getType()) && HaveInsertPoint()) {
 // We have a constant initializer, but a nontrivial destructor. We still
 // need to perform a guarded "initialization" in order to register the
 // destructor.
Index: cfe/trunk/test/CodeGenCXX/pr31054.cpp
===
--- cfe/trunk/test/CodeGenCXX/pr31054.cpp
+++ cfe/trunk/test/CodeGenCXX/pr31054.cpp
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -emit-llvm -o - %s | FileCheck %s
+
+struct A { ~A(); };
+void func() {
+  return;
+  static A k;
+}
+
+// Test that we did not crash, by checking whether function was created.
+// CHECK-LABEL: define void @_Z4funcv() #0 {
+// CHECK: ret void
+// CHECK: }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D28231: -Wunreachable-code: Avoid multiple diagnostics that are triggered by the same source range and fix the unary operator fixit source range

[Alex Lorenz via Phabricator via cfe-commits]

arphaman added inline comments.



Comment at: lib/Analysis/ReachableCode.cpp:229
+  if (SilenceableCondValNotSet && SilenceableCondVal->getBegin().isValid())
+*SilenceableCondVal = UO->getSourceRange();
+  return UO->getOpcode() == UO_LNot && IsSubExprConfigValue;

ahatanak wrote:
> Thanks, that fixed the incorrect fixit. The patch looks good to me, but there 
> are still cases in which the suggestions clang makes are not accurate. 
> Perhaps you can leave a FIXME somewhere so that we don't forget to fix it 
> later?
> 
> For example, if we change the condition in the test case to this,
> 
> ```
> if (!(s->p && 0))
> ```
> 
> , clang suggests enclosing the entire expression with a parenthesis (caret 
> points to "!"), but the warning will not go away unless the parenthesis is 
> around "0".
> 
> The second example is in function unaryOpFixit in warn-unreachable.c. clang 
> suggests enclosing "-1" with a parenthesis, but it still warns after putting 
> the parenthesis around "-1" or "1".
Thanks for pointing out these issues, I've decided to fix them in this patch. 
Since only the '!' operator can wrap a silenced expression, the updated patch 
ensures that fixits for unary operators can only be used with '!' (this fixes 
your second example). I fixed the first example by ensuring that the unary 
operator source range can be used for fixit only if the previous fixit source 
range comes from its direct child.


Repository:
  rL LLVM

https://reviews.llvm.org/D28231



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

[PATCH] D27068: Improve string::find

[Aditya Kumar via Phabricator via cfe-commits]

hiraditya added a comment.

Just for the record, I ported the patch to gcc/libstdc++ as well: PR66414 
optimize std::string::find

https://github.com/gcc-mirror/gcc/commit/fc7ebc4b8d9ad7e2891b7f72152e8a2b7543cd65


Repository:
  rL LLVM

https://reviews.llvm.org/D27068



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

[PATCH] D25213: Fix PR28181: Prevent operator overloading related assertion failure crash that happens in C only

[Alex Lorenz via Phabricator via cfe-commits]

arphaman updated this revision to Diff 83822.
arphaman added a comment.

Ping


Repository:
  rL LLVM

https://reviews.llvm.org/D25213

Files:
  lib/Sema/SemaExpr.cpp
  test/Sema/PR28181.c


Index: test/Sema/PR28181.c
===
--- /dev/null
+++ test/Sema/PR28181.c
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+struct spinlock_t {
+  int lock;
+} audit_skb_queue;
+
+void fn1() {
+  audit_skb_queue = (lock); // expected-error {{use of undeclared identifier 
'lock'; did you mean 'long'?}}
+}   // expected-error@-1 {{assigning to 'struct 
spinlock_t' from incompatible type ''}}
+
+void fn2() {
+  audit_skb_queue + (lock); // expected-error {{use of undeclared identifier 
'lock'; did you mean 'long'?}}
+}   // expected-error@-1 {{reference to overloaded 
function could not be resolved; did you mean to call it?}}
Index: lib/Sema/SemaExpr.cpp
===
--- lib/Sema/SemaExpr.cpp
+++ lib/Sema/SemaExpr.cpp
@@ -11496,7 +11496,7 @@
   return checkPseudoObjectAssignment(S, OpLoc, Opc, LHSExpr, RHSExpr);
 
 // Don't resolve overloads if the other type is overloadable.
-if (pty->getKind() == BuiltinType::Overload) {
+if (getLangOpts().CPlusPlus && pty->getKind() == BuiltinType::Overload) {
   // We can't actually test that if we still have a placeholder,
   // though.  Fortunately, none of the exceptions we see in that
   // code below are valid when the LHS is an overload set.  Note
@@ -11521,17 +11521,18 @@
 // An overload in the RHS can potentially be resolved by the type
 // being assigned to.
 if (Opc == BO_Assign && pty->getKind() == BuiltinType::Overload) {
-  if (LHSExpr->isTypeDependent() || RHSExpr->isTypeDependent())
+  if (getLangOpts().CPlusPlus &&
+  (LHSExpr->isTypeDependent() || RHSExpr->isTypeDependent()))
 return BuildOverloadedBinOp(*this, S, OpLoc, Opc, LHSExpr, RHSExpr);
 
-  if (LHSExpr->getType()->isOverloadableType())
+  if (getLangOpts().CPlusPlus && LHSExpr->getType()->isOverloadableType())
 return BuildOverloadedBinOp(*this, S, OpLoc, Opc, LHSExpr, RHSExpr);
 
   return CreateBuiltinBinOp(OpLoc, Opc, LHSExpr, RHSExpr);
 }
 
 // Don't resolve overloads if the other type is overloadable.
-if (pty->getKind() == BuiltinType::Overload &&
+if (getLangOpts().CPlusPlus && pty->getKind() == BuiltinType::Overload &&
 LHSExpr->getType()->isOverloadableType())
   return BuildOverloadedBinOp(*this, S, OpLoc, Opc, LHSExpr, RHSExpr);
 


Index: test/Sema/PR28181.c
===
--- /dev/null
+++ test/Sema/PR28181.c
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+struct spinlock_t {
+  int lock;
+} audit_skb_queue;
+
+void fn1() {
+  audit_skb_queue = (lock); // expected-error {{use of undeclared identifier 'lock'; did you mean 'long'?}}
+}   // expected-error@-1 {{assigning to 'struct spinlock_t' from incompatible type ''}}
+
+void fn2() {
+  audit_skb_queue + (lock); // expected-error {{use of undeclared identifier 'lock'; did you mean 'long'?}}
+}   // expected-error@-1 {{reference to overloaded function could not be resolved; did you mean to call it?}}
Index: lib/Sema/SemaExpr.cpp
===
--- lib/Sema/SemaExpr.cpp
+++ lib/Sema/SemaExpr.cpp
@@ -11496,7 +11496,7 @@
   return checkPseudoObjectAssignment(S, OpLoc, Opc, LHSExpr, RHSExpr);
 
 // Don't resolve overloads if the other type is overloadable.
-if (pty->getKind() == BuiltinType::Overload) {
+if (getLangOpts().CPlusPlus && pty->getKind() == BuiltinType::Overload) {
   // We can't actually test that if we still have a placeholder,
   // though.  Fortunately, none of the exceptions we see in that
   // code below are valid when the LHS is an overload set.  Note
@@ -11521,17 +11521,18 @@
 // An overload in the RHS can potentially be resolved by the type
 // being assigned to.
 if (Opc == BO_Assign && pty->getKind() == BuiltinType::Overload) {
-  if (LHSExpr->isTypeDependent() || RHSExpr->isTypeDependent())
+  if (getLangOpts().CPlusPlus &&
+  (LHSExpr->isTypeDependent() || RHSExpr->isTypeDependent()))
 return BuildOverloadedBinOp(*this, S, OpLoc, Opc, LHSExpr, RHSExpr);
 
-  if (LHSExpr->getType()->isOverloadableType())
+  if (getLangOpts().CPlusPlus && LHSExpr->getType()->isOverloadableType())
 return BuildOverloadedBinOp(*this, S, OpLoc, Opc, LHSExpr, RHSExpr);
 
   return CreateBuiltinBinOp(OpLoc, Opc, LHSExpr, RHSExpr);
 }
 
 // Don't resolve overloads if the other type is overloadable.
-if (pty->getKind() == BuiltinType::Overload &&
+if (getLangOpts().CPlusPlus && pty->getKind() == Builti

[PATCH] D28252: [OpenMP] Sema and parsing for 'target teams distribute simd' pragma

[Kelvin Li via Phabricator via cfe-commits]

kkwli0 marked an inline comment as done.
kkwli0 added inline comments.



Comment at: lib/Sema/SemaOpenMP.cpp:6444
+
+  CapturedStmt *CS = cast(AStmt);
+  // 1.2.2 OpenMP Language Terminology

ABataev wrote:
> auto *
Will do.


https://reviews.llvm.org/D28252



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

[PATCH] D20693: [clang-tidy] New checker to replace dynamic exception specifications

[don hinton via Phabricator via cfe-commits]

hintonda marked 7 inline comments as done.
hintonda added inline comments.



Comment at: clang-tidy/modernize/UseNoexceptCheck.cpp:64
+  Finder->addMatcher(
+  parmVarDecl(hasType(pointerType(pointee(parenType(innerType(
+  functionProtoType(hasDynamicExceptionSpec(

aaron.ballman wrote:
> Will this catch pointers to member functions as well?
> ```
> struct S {
>   void f() throw();
> };
> 
> void f(void (S::*)() throw()) {
> 
> }
> ```
Added your test, but will need to change matcher to catch it.



Comment at: clang-tidy/modernize/UseNoexceptCheck.cpp:68
+  this);
+}
+

aaron.ballman wrote:
> Also missing: typedefs and using declarations.
As far as I know, it isn't legal to add dynamic exception specifications to 
typedefs and using declarations.



Comment at: clang-tidy/modernize/UseNoexceptCheck.cpp:100
+  StringRef ReplacementStr =
+  IsNoThrow ? NoexceptMacro.empty() ? "noexcept" : NoexceptMacro
+: DtorOrOperatorDel ? "noexcept(false)" : "";

malcolm.parsons wrote:
> alexfh wrote:
> > Did you consider auto-detection approach like in 
> > `getFallthroughAttrSpelling` in 
> > tools/clang/lib/Sema/AnalysisBasedWarnings.cpp?
> cpp11-migrate used to do this for -add-override - rL183001.
> clang-tidy's modernize-use-override check doesn't even have an option.
NoexceptMacro is a user option.  I'm just tested whether or not the user 
provided anything.  Perhaps I should pick a better name.  Would 
NoexceptMacroOption be better?

Did I misunderstand your comment?



Comment at: clang-tidy/modernize/UseNoexceptCheck.cpp:105
+  if (IsNoThrow || NoexceptMacro.empty())
+FixIt = FixItHint::CreateReplacement(CharSourceRange(Range, true),
+ ReplacementStr);

alexfh wrote:
> I suspect this won't work when the range is not contiguous, e.g. starts in a 
> macro definition and ends outside of it:
> 
>   #define T throw
>   void f() T(a, b) {}
> 
> Can you try this test (or construct something similar that will actually 
> break this code)? In case it doesn't work, `Lexer::makeFileCharRange` is the 
> standard way to get a contiguous file range corresponding to a  source range 
> (if possible).
As you suspected, I wasn't handling this case correctly.  I've made the change 
you suggested and will check in shortly.



Comment at: docs/clang-tidy/checks/modernize-use-noexcept.rst:30
+By default this check will only replace ``throw()`` with ``noexcept``,
+and ``throw([,...])`` or ``throw(...)`` with blank except
+for operator delete and destructors, which are replaced with

aaron.ballman wrote:
> I continue to object to removing the explicit exception specification 
> entirely as the default behavior without strong justification. Further. there 
> is no option to control this behavior.
I tried to make sure it's only applied where appropriate.  If I missed a case, 
please let me know, but I'm not sure an option "just in case" is right solution.

However, I did try to structure the code in a way to make it easy to add an 
option if that turns out the be the right thing to do.



Comment at: docs/clang-tidy/checks/modernize-use-noexcept.rst:38
+that don't support the ``noexcept`` keyword.  Users can define the
+macro to be ``noexcept`` or ``throw()`` depending on whether or not
+noexcept is supported.  Specifications that can throw, e.g.,

aaron.ballman wrote:
> I'm not certain I understand the justification of calling out older compilers 
> or suggesting use of `throw()`. The check will continually flag `throw()` and 
> try to recommend `noexcept` in its place, won't it? At least, that's how I 
> read the preceding paragraph.
> 
> I think the macro replacement is a reasonable feature, but I think the check 
> only makes sense for C++11 or later, since C++98 users really have no 
> alternatives to dynamic exception specifications.
Libraries, e.g., libc++, that need to support both multiple versions of the 
standard, use macros to switch between throw() and noexcept.

So this option was designed to be libc++ friendly.  If that's not appropriate, 
I can remove it.


https://reviews.llvm.org/D20693



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

[PATCH] D28080: [Docs][OpenCL] Added OpenCL feature description to user manual.

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia updated this revision to Diff 83824.
Anastasia added a comment.

Updated with comments from Mats!


https://reviews.llvm.org/D28080

Files:
  docs/UsersManual.rst
  www/index.html

Index: www/index.html
===
--- www/index.html
+++ www/index.html
@@ -15,10 +15,10 @@
   clang: a C language family frontend for LLVM
   
   
-  The goal of the Clang project is to create a new C, C++, Objective C and
-  Objective C++ front-end for the http://www.llvm.org/";>LLVM
-  compiler.  You can get and build the source
-  today.
+  The goal of the Clang project is to create a new C based language
+  front-end: C, C++, Objective C/C++, OpenCL and others for the
+  http://www.llvm.org/";>LLVM compiler.  You can
+  get and build the source  today.
   
   
   Features and Goals
Index: docs/UsersManual.rst
===
--- docs/UsersManual.rst
+++ docs/UsersManual.rst
@@ -41,6 +41,7 @@
variants depending on base language.
 -  :ref:`C++ Language `
 -  :ref:`Objective C++ Language `
+-  :ref:`OpenCL Language `: v1.0, v1.1, v1.2, v2.0.
 
 In addition to these base languages and their dialects, Clang supports a
 broad variety of language extensions, which are documented in the
@@ -1973,6 +1974,348 @@
  is provided or target does not support TLS, code generation for threadprivate
  variables relies on OpenMP runtime library.
 
+.. _opencl:
+
+OpenCL Features
+===
+
+Clang can be used to compile OpenCL kernels for execution on a device
+(e.g. GPU). It is possible to compile the kernel into a binary (e.g. for AMD or
+Nvidia targets) that can be uploaded to run directly on a device (e.g. using
+`clCreateProgramWithBinary
+`_) or
+into generic bitcode files loadable into other toolchains.
+
+Compiling to a binary using the default target from the installation can be done
+as follows:
+
+   .. code-block:: console
+
+ $ echo "kernel void k(){}" > test.cl
+ $ clang test.cl
+
+Compiling for a specific target can be done by specifying the triple corresponding
+to the target, for example:
+
+   .. code-block:: console
+
+ $ clang -target nvptx64-unknown-unknown test.cl
+ $ clang -target amdgcn-unknown-amdhsa test.cl
+
+Compiling to bitcode can be done as follows:
+
+   .. code-block:: console
+
+ $ clang test.cl -c -emit-llvm
+
+This will produce a generic test.bc file that can be used in vendor toolchains
+to perform machine code generation.
+
+Clang currently supports OpenCL standards up to v2.0.
+
+OpenCL Specific Options
+---
+
+Most of the OpenCL build options from `the specification v2.0 section 5.8.4
+`_ are available.
+
+Examples:
+
+   .. code-block:: console
+
+ $ clang -cl-std=CL2.0 -cl-single-precision-constant test.cl
+
+Some extra options are available to support special OpenCL features.
+
+.. option:: -finclude-default-header
+
+Loads standard includes during compilations. By default OpenCL headers are not
+loaded and therefore standard library includes are not available. To load them
+automatically a flag has been added to the frontend (see also OpenCL Header
+section):
+
+   .. code-block:: console
+
+ $ clang -Xclang -finclude-default-header test.cl
+
+Alternatively ``-include`` or ``-I`` followed by the path to the header location
+can be given manually.
+
+   .. code-block:: console
+
+ $ clang -I/lib/Headers/opencl-c.h test.cl
+
+In this case the kernel code should contain ``#include `` just as a
+regular C include.
+
+.. option:: -cl-ext
+
+Disables standard target extensions. All OpenCL targets provide a list
+of extensions that they support. Clang allows to amend this using the ``-cl-ext``
+flag with a comma-separated list of extensions prefixed with ``'+'`` or ``'-'``.
+The syntax: ``-cl-ext=<(['-'|'+'][,])+>``,  where extensions
+can be either one of `the OpenCL specification extensions
+`_
+or any known vendor extension. Alternatively, ``'all'`` can be used to enable or disable
+all known extensions.
+Example disabling double support for the 64-bit SPIR target:
+
+   .. code-block:: console
+
+ $ clang -cc1 -triple spir64-unknown-unknown -cl-ext=-cl_khr_fp64 test.cl
+
+Enabling all extensions except double support in R600 AMD GPU can be done using:
+
+   .. code-block:: console
+
+ $ clang -cc1 -triple r600-unknown-unknown -cl-ext=-all,+cl_khr_fp16 test.cl
+
+.. _opencl_fake_address_space_map:
+
+.. option:: -ffake-address-space-map
+
+Overrides the target address space map with a fake map.
+This allows adding address spaces for architectures that do not provide default
+memory segment support. Passing ``-ffake-address-space-map`` will add/override
+address spaces of the target compiled for with the following

[PATCH] D28080: [Docs][OpenCL] Added OpenCL feature description to user manual.

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia marked 4 inline comments as done.
Anastasia added a comment.

Ping! Any more comments here? It would be nice to commit this before the 4.0 
rel branch is taken (on Jan 12).


https://reviews.llvm.org/D28080



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

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

[Dimitry Andric via Phabricator via cfe-commits]

dim created this revision.
dim added reviewers: EricWF, mclow.lists.
dim added subscribers: cfe-commits, emaste, joerg.

Many thread-related libc++ test cases fail on FreeBSD, due to the following 
-Werror warnings:

  In file included from 
/share/dim/src/llvm/trunk/projects/libcxx/test/std/thread/thread.threads/thread.thread.this/sleep_until.pass.cpp:17:
  In file included from 
/share/dim/src/llvm/trunk/projects/libcxx/include/thread:97:
  In file included from 
/share/dim/src/llvm/trunk/projects/libcxx/include/__mutex_base:17:
  /share/dim/src/llvm/trunk/projects/libcxx/include/__threading_support:222:1: 
error: mutex '__m' is still held at the end of function 
[-Werror,-Wthread-safety-analysis]
  }
  ^
  /share/dim/src/llvm/trunk/projects/libcxx/include/__threading_support:221:10: 
note: mutex acquired here
return pthread_mutex_lock(__m);
   ^
  /share/dim/src/llvm/trunk/projects/libcxx/include/__threading_support:231:10: 
error: releasing mutex '__m' that was not held 
[-Werror,-Wthread-safety-analysis]
return pthread_mutex_unlock(__m);
   ^
  /share/dim/src/llvm/trunk/projects/libcxx/include/__threading_support:242:1: 
error: mutex '__m' is still held at the end of function 
[-Werror,-Wthread-safety-analysis]
  }
  ^
  /share/dim/src/llvm/trunk/projects/libcxx/include/__threading_support:241:10: 
note: mutex acquired here
return pthread_mutex_lock(__m);
   ^
  /share/dim/src/llvm/trunk/projects/libcxx/include/__threading_support:251:10: 
error: releasing mutex '__m' that was not held 
[-Werror,-Wthread-safety-analysis]
return pthread_mutex_unlock(__m);
   ^
  /share/dim/src/llvm/trunk/projects/libcxx/include/__threading_support:272:10: 
error: calling function 'pthread_cond_wait' requires holding mutex '__m' 
exclusively [-Werror,-Wthread-safety-analysis]
return pthread_cond_wait(__cv, __m);
   ^
  /share/dim/src/llvm/trunk/projects/libcxx/include/__threading_support:278:10: 
error: calling function 'pthread_cond_timedwait' requires holding mutex '__m' 
exclusively [-Werror,-Wthread-safety-analysis]
return pthread_cond_timedwait(__cv, __m, __ts);
   ^
  6 errors generated.

Obviously, these warnings are false, since the functions are exactly doing what 
they are supposed to do.

Therefore, add pragmas to ignored -Wthread-safety-analysis warnings.  These 
could also be set for the whole block of thread-related functions, but in this 
version I have added them per function.

I also considered doing this with macros, as Joerg suggested, but macros that 
expand to multi-line pragma statements are rather unwieldy, and don't make it 
much nicer, in my opinion.  Suggestions welcome, of course.


https://reviews.llvm.org/D28520

Files:
  include/__threading_support

Index: include/__threading_support
===
--- include/__threading_support
+++ include/__threading_support
@@ -216,40 +216,68 @@
   return 0;
 }
 
+#ifdef __clang__
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wthread-safety-analysis"
+#endif
 int __libcpp_recursive_mutex_lock(__libcpp_recursive_mutex_t *__m)
 {
   return pthread_mutex_lock(__m);
 }
+#ifdef __clang__
+#pragma clang diagnostic pop
+#endif
 
 int __libcpp_recursive_mutex_trylock(__libcpp_recursive_mutex_t *__m)
 {
   return pthread_mutex_trylock(__m);
 }
 
+#ifdef __clang__
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wthread-safety-analysis"
+#endif
 int __libcpp_recursive_mutex_unlock(__libcpp_mutex_t *__m)
 {
   return pthread_mutex_unlock(__m);
 }
+#ifdef __clang__
+#pragma clang diagnostic pop
+#endif
 
 int __libcpp_recursive_mutex_destroy(__libcpp_recursive_mutex_t *__m)
 {
   return pthread_mutex_destroy(__m);
 }
 
+#ifdef __clang__
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wthread-safety-analysis"
+#endif
 int __libcpp_mutex_lock(__libcpp_mutex_t *__m)
 {
   return pthread_mutex_lock(__m);
 }
+#ifdef __clang__
+#pragma clang diagnostic pop
+#endif
 
 int __libcpp_mutex_trylock(__libcpp_mutex_t *__m)
 {
   return pthread_mutex_trylock(__m);
 }
 
+#ifdef __clang__
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wthread-safety-analysis"
+#endif
 int __libcpp_mutex_unlock(__libcpp_mutex_t *__m)
 {
   return pthread_mutex_unlock(__m);
 }
+#ifdef __clang__
+#pragma clang diagnostic pop
+#endif
 
 int __libcpp_mutex_destroy(__libcpp_mutex_t *__m)
 {
@@ -267,16 +295,30 @@
   return pthread_cond_broadcast(__cv);
 }
 
+#ifdef __clang__
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wthread-safety-analysis"
+#endif
 int __libcpp_condvar_wait(__libcpp_condvar_t *__cv, __libcpp_mutex_t *__m)
 {
   return pthread_cond_wait(__cv, __m);
 }
+#ifdef __clang__
+#pragma clang diagnostic pop
+#endif
 
+#ifdef __clang__
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wthread-safety-analysis"
+#endif
 int __libcpp_condvar_timedwait(__libcpp

[PATCH] D20693: [clang-tidy] New checker to replace dynamic exception specifications

[don hinton via Phabricator via cfe-commits]

hintonda updated this revision to Diff 83827.
hintonda marked an inline comment as done.
hintonda added a comment.

- Addressed comments.


https://reviews.llvm.org/D20693

Files:
  clang-tidy/modernize/CMakeLists.txt
  clang-tidy/modernize/ModernizeTidyModule.cpp
  clang-tidy/modernize/UseNoexceptCheck.cpp
  clang-tidy/modernize/UseNoexceptCheck.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/modernize-use-noexcept.rst
  test/clang-tidy/modernize-use-noexcept-macro.cpp
  test/clang-tidy/modernize-use-noexcept.cpp

Index: test/clang-tidy/modernize-use-noexcept.cpp
===
--- /dev/null
+++ test/clang-tidy/modernize-use-noexcept.cpp
@@ -0,0 +1,83 @@
+// RUN: %check_clang_tidy %s modernize-use-noexcept %t -- \
+// RUN:   -- -std=c++11
+
+class A {};
+class B {};
+
+void foo() throw();
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: found dynamic exception specification 'throw()' [modernize-use-noexcept]
+// CHECK-FIXES: void foo() noexcept;
+
+void bar() throw(...);
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: found dynamic exception specification 'throw(...)' [modernize-use-noexcept]
+// CHECK-FIXES: void bar() ;
+
+void k() throw(int(int));
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: found dynamic exception specification 'throw(int(int))' [modernize-use-noexcept]
+// CHECK-FIXES: void k() ;
+
+void foobar() throw(A, B)
+{}
+// CHECK-MESSAGES: :[[@LINE-2]]:15: warning: found dynamic exception specification 'throw(A, B)' [modernize-use-noexcept]
+// CHECK-FIXES: void foobar()
+
+void baz(int = (throw A(), 0)) throw(A, B) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:32: warning: found dynamic exception specification 'throw(A, B)' [modernize-use-noexcept]
+// CHECK-FIXES: void baz(int = (throw A(), 0)) {}
+
+void g(void (*fp)(void) throw());
+// CHECK-MESSAGES: :[[@LINE-1]]:25: warning: found dynamic exception specification 'throw()' [modernize-use-noexcept]
+// CHECK-FIXES: void g(void (*fp)(void) noexcept);
+
+void f(void (*fp)(void) throw(int)) throw(char);
+// CHECK-MESSAGES: :[[@LINE-1]]:25: warning: found dynamic exception specification 'throw(int)' [modernize-use-noexcept]
+// CHECK-MESSAGES: :[[@LINE-2]]:37: warning: found dynamic exception specification 'throw(char)' [modernize-use-noexcept]
+// CHECK-FIXES: void f(void (*fp)(void) ) ;
+
+#define THROW throw
+void h(void (*fp)(void) THROW(int)) THROW(char);
+// CHECK-MESSAGES: :[[@LINE-1]]:25: warning: found dynamic exception specification 'THROW(int)' [modernize-use-noexcept]
+// CHECK-MESSAGES: :[[@LINE-2]]:37: warning: found dynamic exception specification 'THROW(char)' [modernize-use-noexcept]
+// CHECK-FIXES: void h(void (*fp)(void) ) ;
+
+void j() throw(int(int) throw(void(void) throw(int)));
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: found dynamic exception specification 'throw(int(int) throw(void(void) throw(int)))' [modernize-use-noexcept]
+// CHECK-FIXES: void j() ;
+
+class Y {
+  Y() throw() = default;
+};
+// CHECK-MESSAGES: :[[@LINE-2]]:7: warning: found dynamic exception specification 'throw()' [modernize-use-noexcept]
+// CHECK-FIXES: Y() noexcept = default;
+
+struct Z {
+  void operator delete(void *ptr) throw();
+  void operator delete[](void *ptr) throw(int);
+  ~Z() throw(int) {}
+};
+// CHECK-MESSAGES: :[[@LINE-4]]:35: warning: found dynamic exception specification 'throw()' [modernize-use-noexcept]
+// CHECK-MESSAGES: :[[@LINE-4]]:37: warning: found dynamic exception specification 'throw(int)' [modernize-use-noexcept]
+// CHECK-MESSAGES: :[[@LINE-4]]:8: warning: found dynamic exception specification 'throw(int)' [modernize-use-noexcept]
+// CHECK-FIXES: void operator delete(void *ptr) noexcept;
+// CHECK-FIXES: void operator delete[](void *ptr) noexcept(false);
+// CHECK-FIXES: ~Z() noexcept(false) {}
+
+struct S {
+  void f() throw();
+};
+void f(void (S::*)() throw());
+// CHECK-MESSAGES: :[[@LINE-3]]:35: warning: found dynamic exception specification 'throw()' [modernize-use-noexcept]
+// CHECK-MESSAGES: :[[@LINE-2]]:37: warning: found dynamic exception specification 'throw()' [modernize-use-noexcept]
+// CHECK-FIXES: void f() noexcept;
+// CHECK-FIXES: void f(void (S::*)() noexcept);
+
+// Should not trigger a replacement.
+void titi() noexcept {}
+void toto() noexcept(true) {}
+
+// Should not trigger a replacement.
+void bad()
+#if !__has_feature(cxx_noexcept)
+throw()
+#endif
+  ;
Index: test/clang-tidy/modernize-use-noexcept-macro.cpp
===
--- /dev/null
+++ test/clang-tidy/modernize-use-noexcept-macro.cpp
@@ -0,0 +1,36 @@
+// RUN: %check_clang_tidy %s modernize-use-noexcept %t -- \
+// RUN:   -config="{CheckOptions: [{key: modernize-use-noexcept.ReplacementString, value: 'NOEXCEPT'}]}" \
+// RUN:   -- -std=c++11
+
+// Example definition of NOEXCEPT -- simplified test to see if noexcept is supported.
+#if (__has_feature(cxx_noexcept))
+#define NOEXCEPT noexcept
+#el

[PATCH] D28365: [Driver] Updated for Visual Studio 2017

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

In https://reviews.llvm.org/D28365#640868, @hamzasood wrote:

> Ha, good point. Does that include the environment stuff in Command too or 
> just the linker?


Yes, please make the Command environment changes as part of a separate patch 
with the linker environment changes.


https://reviews.llvm.org/D28365



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

[PATCH] D28033: [analyzer] Treat pointers to static member functions as function pointers

[Devin Coughlin via Phabricator via cfe-commits]

dcoughlin updated this revision to Diff 83828.
dcoughlin added a comment.

Updating spacing, as @kromanenkov requested.


https://reviews.llvm.org/D28033

Files:
  lib/StaticAnalyzer/Core/SValBuilder.cpp
  test/Analysis/pointer-to-member.cpp


Index: test/Analysis/pointer-to-member.cpp
===
--- test/Analysis/pointer-to-member.cpp
+++ test/Analysis/pointer-to-member.cpp
@@ -77,7 +77,8 @@
 namespace testPointerToMemberFunction {
   struct A {
 virtual int foo() { return 1; }
-int bar() { return 2;  }
+int bar() { return 2; }
+int static staticMemberFunction(int p) { return p + 1; };
   };
 
   struct B : public A {
@@ -111,11 +112,19 @@
 
 clang_analyzer_eval((APtr->*AFP)() == 3); // expected-warning{{TRUE}}
   }
+
+  void testPointerToStaticMemberCall() {
+int (*fPtr)(int) = &A::staticMemberFunction;
+if (fPtr != 0) { // no-crash
+  clang_analyzer_eval(fPtr(2) == 3); // expected-warning{{TRUE}}
+}
+  }
 } // end of testPointerToMemberFunction namespace
 
 namespace testPointerToMemberData {
   struct A {
 int i;
+static int j;
   };
 
   void testPointerToMemberData() {
@@ -126,6 +135,13 @@
 a.*AMdPointer += 1;
 
 clang_analyzer_eval(a.i == 43); // expected-warning{{TRUE}}
+
+int *ptrToStaticField = &A::j;
+if (ptrToStaticField != 0) {
+  *ptrToStaticField = 7;
+  clang_analyzer_eval(*ptrToStaticField == 7); // expected-warning{{TRUE}}
+  clang_analyzer_eval(A::j == 7); // expected-warning{{TRUE}}
+}
   }
 } // end of testPointerToMemberData namespace
 
Index: lib/StaticAnalyzer/Core/SValBuilder.cpp
===
--- lib/StaticAnalyzer/Core/SValBuilder.cpp
+++ lib/StaticAnalyzer/Core/SValBuilder.cpp
@@ -218,6 +218,18 @@
 }
 
 DefinedSVal SValBuilder::getMemberPointer(const DeclaratorDecl* DD) {
+  assert(!DD || isa(DD) || isa(DD));
+
+  if (auto *MD = dyn_cast_or_null(DD)) {
+// Sema treats pointers to static member functions as have function pointer
+// type, so return a function pointer for the method.
+// We don't need to play a similar trick for static member fields
+// because these are represented as plain VarDecls and not FieldDecls
+// in the AST.
+if (MD->isStatic())
+  return getFunctionPointer(MD);
+  }
+
   return nonloc::PointerToMember(DD);
 }
 


Index: test/Analysis/pointer-to-member.cpp
===
--- test/Analysis/pointer-to-member.cpp
+++ test/Analysis/pointer-to-member.cpp
@@ -77,7 +77,8 @@
 namespace testPointerToMemberFunction {
   struct A {
 virtual int foo() { return 1; }
-int bar() { return 2;  }
+int bar() { return 2; }
+int static staticMemberFunction(int p) { return p + 1; };
   };
 
   struct B : public A {
@@ -111,11 +112,19 @@
 
 clang_analyzer_eval((APtr->*AFP)() == 3); // expected-warning{{TRUE}}
   }
+
+  void testPointerToStaticMemberCall() {
+int (*fPtr)(int) = &A::staticMemberFunction;
+if (fPtr != 0) { // no-crash
+  clang_analyzer_eval(fPtr(2) == 3); // expected-warning{{TRUE}}
+}
+  }
 } // end of testPointerToMemberFunction namespace
 
 namespace testPointerToMemberData {
   struct A {
 int i;
+static int j;
   };
 
   void testPointerToMemberData() {
@@ -126,6 +135,13 @@
 a.*AMdPointer += 1;
 
 clang_analyzer_eval(a.i == 43); // expected-warning{{TRUE}}
+
+int *ptrToStaticField = &A::j;
+if (ptrToStaticField != 0) {
+  *ptrToStaticField = 7;
+  clang_analyzer_eval(*ptrToStaticField == 7); // expected-warning{{TRUE}}
+  clang_analyzer_eval(A::j == 7); // expected-warning{{TRUE}}
+}
   }
 } // end of testPointerToMemberData namespace
 
Index: lib/StaticAnalyzer/Core/SValBuilder.cpp
===
--- lib/StaticAnalyzer/Core/SValBuilder.cpp
+++ lib/StaticAnalyzer/Core/SValBuilder.cpp
@@ -218,6 +218,18 @@
 }
 
 DefinedSVal SValBuilder::getMemberPointer(const DeclaratorDecl* DD) {
+  assert(!DD || isa(DD) || isa(DD));
+
+  if (auto *MD = dyn_cast_or_null(DD)) {
+// Sema treats pointers to static member functions as have function pointer
+// type, so return a function pointer for the method.
+// We don't need to play a similar trick for static member fields
+// because these are represented as plain VarDecls and not FieldDecls
+// in the AST.
+if (MD->isStatic())
+  return getFunctionPointer(MD);
+  }
+
   return nonloc::PointerToMember(DD);
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D21279: Fix some issues in clang-format's AlignConsecutive modes

[Erik Nyquist via Phabricator via cfe-commits]

enyquist added a comment.

Well, your patch is here for me to try, and it looks like it's been accepted. 
So I guess I should just pull my finger out and try it :)
Thanks for your response-- I'll let you know if I come across any issues.


https://reviews.llvm.org/D21279



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

[PATCH] D20693: [clang-tidy] New checker to replace dynamic exception specifications

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang-tidy/modernize/UseNoexceptCheck.cpp:68
+  this);
+}
+

hintonda wrote:
> aaron.ballman wrote:
> > Also missing: typedefs and using declarations.
> As far as I know, it isn't legal to add dynamic exception specifications to 
> typedefs and using declarations.
Hmm, I thought you could, at least in C++17, since it's now part of the 
function's type. However, I don't have a standard in front of me at the moment, 
so I'll have to double-check. It can always be added in a follow-up patch and 
need not block this one.

However, I do know the following is allowed in a typedef, and I don't think 
your existing ParmVarDecl matcher will catch it:
```
typedef void (*fp)(void (*f)(int) throw());
```



Comment at: docs/clang-tidy/checks/modernize-use-noexcept.rst:30
+By default this check will only replace ``throw()`` with ``noexcept``,
+and ``throw([,...])`` or ``throw(...)`` with blank except
+for operator delete and destructors, which are replaced with

hintonda wrote:
> aaron.ballman wrote:
> > I continue to object to removing the explicit exception specification 
> > entirely as the default behavior without strong justification. Further. 
> > there is no option to control this behavior.
> I tried to make sure it's only applied where appropriate.  If I missed a 
> case, please let me know, but I'm not sure an option "just in case" is right 
> solution.
> 
> However, I did try to structure the code in a way to make it easy to add an 
> option if that turns out the be the right thing to do.
The behavior as it's implemented now is not the behavior I would expect from 
such a check -- I think that `throw(int)` should get a FixIt to 
`noexcept(false)` rather than no `noexcept` clause whatsoever. Despite them 
being functionally equivalent in most cases, the explicit nature of the dynamic 
exception specification should be retained with an explicit noexcept exception 
specification, not discarded. If you really want `throw(int)` to be modified to 
have no explicit exception specification, I think that should be an option (off 
by default). If you would rather not make an option, then I think the explicit 
exception specification should remain.



Comment at: docs/clang-tidy/checks/modernize-use-noexcept.rst:38
+that don't support the ``noexcept`` keyword.  Users can define the
+macro to be ``noexcept`` or ``throw()`` depending on whether or not
+noexcept is supported.  Specifications that can throw, e.g.,

hintonda wrote:
> aaron.ballman wrote:
> > I'm not certain I understand the justification of calling out older 
> > compilers or suggesting use of `throw()`. The check will continually flag 
> > `throw()` and try to recommend `noexcept` in its place, won't it? At least, 
> > that's how I read the preceding paragraph.
> > 
> > I think the macro replacement is a reasonable feature, but I think the 
> > check only makes sense for C++11 or later, since C++98 users really have no 
> > alternatives to dynamic exception specifications.
> Libraries, e.g., libc++, that need to support both multiple versions of the 
> standard, use macros to switch between throw() and noexcept.
> 
> So this option was designed to be libc++ friendly.  If that's not 
> appropriate, I can remove it.
I think the *option* is fine; I think the wording is confusing. How about:
```
Alternatively, users can also use :option:`ReplacementString` to
specify a macro to use instead of ``noexcept``.  This is useful when
maintaining source code that uses custom exception specification marking
other than ``noexcept``.
```


https://reviews.llvm.org/D20693



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

[PATCH] D27651: [clang-format] Even with AlignConsecutiveDeclarations, PointerAlignment: Right should keep *s and &s to the right

[Ken-Patrick Lehrmann via Phabricator via cfe-commits]

KP updated this revision to Diff 83829.
KP added a comment.

Rename IsPointerOrReference to isPointerOrReference to comply with coding style


https://reviews.llvm.org/D27651

Files:
  lib/Format/WhitespaceManager.cpp
  unittests/Format/FormatTest.cpp

Index: unittests/Format/FormatTest.cpp
===
--- unittests/Format/FormatTest.cpp
+++ unittests/Format/FormatTest.cpp
@@ -8769,9 +8769,11 @@
   verifyFormat("int  oneTwoThree = {0}; // comment\n"
"unsigned oneTwo  = 0;   // comment",
Alignment);
+
+  // PAS_RIGHT
   EXPECT_EQ("void SomeFunction(int parameter = 0) {\n"
 "  int const i   = 1;\n"
-"  int * j   = 2;\n"
+"  int  *j   = 2;\n"
 "  int   big = 1;\n"
 "\n"
 "  unsigned oneTwoThree = 123;\n"
@@ -8792,6 +8794,141 @@
"int ll=1;\n"
"}",
Alignment));
+  EXPECT_EQ("void SomeFunction(int parameter = 0) {\n"
+"  int const i   = 1;\n"
+"  int **j   = 2, ***k;\n"
+"  int  &k   = i;\n"
+"  int &&l   = i + j;\n"
+"  int   big = 1;\n"
+"\n"
+"  unsigned oneTwoThree = 123;\n"
+"  int  oneTwo  = 12;\n"
+"  method();\n"
+"  float k  = 2;\n"
+"  int   ll = 1;\n"
+"}",
+format("void SomeFunction(int parameter= 0) {\n"
+   " int const  i= 1;\n"
+   "  int **j=2,***k;\n"
+   "int &k=i;\n"
+   "int &&l=i+j;\n"
+   " int big  =  1;\n"
+   "\n"
+   "unsigned oneTwoThree  =123;\n"
+   "int oneTwo = 12;\n"
+   "  method();\n"
+   "float k= 2;\n"
+   "int ll=1;\n"
+   "}",
+   Alignment));
+
+  // PAS_LEFT
+  FormatStyle AlignmentLeft = Alignment;
+  AlignmentLeft.PointerAlignment = FormatStyle::PAS_Left;
+  EXPECT_EQ("void SomeFunction(int parameter = 0) {\n"
+"  int const i   = 1;\n"
+"  int*  j   = 2;\n"
+"  int   big = 1;\n"
+"\n"
+"  unsigned oneTwoThree = 123;\n"
+"  int  oneTwo  = 12;\n"
+"  method();\n"
+"  float k  = 2;\n"
+"  int   ll = 1;\n"
+"}",
+format("void SomeFunction(int parameter= 0) {\n"
+   " int const  i= 1;\n"
+   "  int *j=2;\n"
+   " int big  =  1;\n"
+   "\n"
+   "unsigned oneTwoThree  =123;\n"
+   "int oneTwo = 12;\n"
+   "  method();\n"
+   "float k= 2;\n"
+   "int ll=1;\n"
+   "}",
+   AlignmentLeft));
+  EXPECT_EQ("void SomeFunction(int parameter = 0) {\n"
+"  int const i   = 1;\n"
+"  int** j   = 2;\n"
+"  int&  k   = i;\n"
+"  int&& l   = i + j;\n"
+"  int   big = 1;\n"
+"\n"
+"  unsigned oneTwoThree = 123;\n"
+"  int  oneTwo  = 12;\n"
+"  method();\n"
+"  float k  = 2;\n"
+"  int   ll = 1;\n"
+"}",
+format("void SomeFunction(int parameter= 0) {\n"
+   " int const  i= 1;\n"
+   "  int **j=2;\n"
+   "int &k=i;\n"
+   "int &&l=i+j;\n"
+   " int big  =  1;\n"
+   "\n"
+   "unsigned oneTwoThree  =123;\n"
+   "int oneTwo = 12;\n"
+   "  method();\n"
+   "float k= 2;\n"
+   "int ll=1;\n"
+   "}",
+   AlignmentLeft));
+  // PAS_MIDDLE
+  FormatStyle AlignmentMiddle = Alignment;
+  AlignmentMiddle.PointerAlignment = FormatStyle::PAS_Middle;
+  EXPECT_EQ("void SomeFunction(int parameter = 0) {\n"
+"  int const i   = 1;\n"
+"  int * j   = 2;\n"
+"  int   big = 1;\n"
+"\n"
+"  unsigned oneTwoThree = 123;\n"
+"  int  oneTwo  = 12;\n"
+"  method();\n"
+"  float k  = 2;\n"
+"  int   ll = 1;\n"
+"}",
+format("void SomeFunction(int parameter= 0) {\n"
+   " int const  i= 1;\n"
+   "  int *j=2;\n"
+   " int big  =  1;\n"
+   "\n"
+   "unsigned oneTwoThree  =123;\n"
+   "int oneTwo = 12;\n"
+   "  method();\n"
+   "float k= 2;\n"
+   "int ll

[libcxx] r291580 - Qualify some type names that I thought were fine, but some of the bots don't like.

[Marshall Clow via cfe-commits]

Author: marshall
Date: Tue Jan 10 12:40:01 2017
New Revision: 291580

URL: http://llvm.org/viewvc/llvm-project?rev=291580&view=rev
Log:
Qualify some type names that I thought were fine, but some of the bots don't 
like.

Modified:
libcxx/trunk/include/memory

Modified: libcxx/trunk/include/memory
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/memory?rev=291580&r1=291579&r2=291580&view=diff
==
--- libcxx/trunk/include/memory (original)
+++ libcxx/trunk/include/memory Tue Jan 10 12:40:01 2017
@@ -4713,7 +4713,7 @@ inline _LIBCPP_INLINE_VISIBILITY
 typename enable_if
 <
 !is_array<_Yp>::value &&
-is_convertible<_Yp*, element_type*>::value,
+is_convertible<_Yp*, typename shared_ptr<_Tp>::element_type*>::value,
 shared_ptr<_Tp>&
 >::type
 shared_ptr<_Tp>::operator=(auto_ptr<_Yp> __r)
@@ -4728,7 +4728,8 @@ inline _LIBCPP_INLINE_VISIBILITY
 typename enable_if
 <
 !is_array<_Yp>::value &&
-is_convertible::pointer, 
element_type*>::value,
+is_convertible::pointer, 
+   typename shared_ptr<_Tp>::element_type*>::value,
 shared_ptr<_Tp>&
 >::type
 shared_ptr<_Tp>::operator=(unique_ptr<_Yp, _Dp> __r)


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

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a reviewer: delesley.
aaron.ballman added a comment.

Alternatively, these functions could be given the proper thread safety 
annotations, couldn't they?


https://reviews.llvm.org/D28520



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

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

In https://reviews.llvm.org/D28520#641534, @aaron.ballman wrote:

> Alternatively, these functions could be given the proper thread safety 
> annotations, couldn't they?


Aha, I was not aware of the existence of these attributes.  I'll take a look.


https://reviews.llvm.org/D28520



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

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In https://reviews.llvm.org/D28520#641536, @dim wrote:

> In https://reviews.llvm.org/D28520#641534, @aaron.ballman wrote:
>
> > Alternatively, these functions could be given the proper thread safety 
> > annotations, couldn't they?
>
>
> Aha, I was not aware of the existence of these attributes.  I'll take a look.


This may be of some help: http://clang.llvm.org/docs/ThreadSafetyAnalysis.html


https://reviews.llvm.org/D28520



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

[PATCH] D28404: IRGen: Add optnone attribute on function during O0

[Paul Robinson via Phabricator via cfe-commits]

probinson added a comment.

In https://reviews.llvm.org/D28404#641078, @chandlerc wrote:

> For me, the arguments you're raising against -O0 and -flto don't hold up on 
> closer inspection:
>
> - O0 != optnone: correct. But this is only visible in LTO. And in LTO, Os != 
> optsize, and Oz != minsize. But we use optsize and minsize to communicate 
> between the compilation and the LTO step to the best of our ability the 
> intent of the programmer. It appears we can use optnone exactly the same way 
> here.


If the design decision is that relevant optimization controls are propagated 
into bitcode as function attributes, I grumble but concede it will do something 
similar to what was requested.

It does bother me that we keep finding things that LTO needs to know but which 
it does not know because it runs in a separate phase of the workflow.  I hope 
it is not a serious problem to ask "is there a more sensible way to fix this?"  
Maybe I'm not so good at expressing that so it comes out as a question rather 
than an objection, but that's basically what it is.

This design decision leaves -O1/-Og needing yet another attribute, when we get 
around to that, but I suppose Og would not have the 
interaction-with-other-attributes problems that optnone has.

> - optnone isn't *really* no optimizations: clearly this is true, but then 
> neither is -O0. We run the always inliner, a couple of other passes, and we 
> run several parts of the code generators optimizer. I understand why optnone 
> deficiencies (ie, too many optimizations) might be frustrating, but having 
> *more users* seems likely to make this *better*.

We have picked all the low-hanging fruit there, and probably some 
medium-hanging fruit.  Mehdi did have the misunderstanding that optnone == -O0 
and that I think was worth correcting.

> - There is no use case for -O0 + -flto:

The email thread has an exchange between Duncan and me, where I accept the use 
case.

> But all of this seems like an attempt to argue "you are wrong to have your 
> use case". I personally find that an unproductive line of discussion.

Not saying it was *wrong* just the description did not convey adequate 
justification.  Listing a few project types does not constitute a use case.  We 
did get to one, eventually, and it even involved differences in optimization 
levels.

> For example, you might ask: could we find some other way to solve the problem 
> you are trying to solve here?

There is another way to make use of the attribute, which I think will be more 
robust:

Have Sema pretend the pragma is in effect at all times, at -O0.  Then all the 
existing conflict detection/resolution logic Just Works, and there's no need to 
spend 4 lines of code hoping to replicate the correct conditions in 
CodeGenModule.

Because Sema does not have a handle on CodeGenOptions and therefore does not 
a-priori know the optimization level, probably the right thing to do is move 
the flag to LangOpts and set it under the correct conditions in 
CompilerInvocation.  It wouldn't be the first codegen-like option in LangOpts.


https://reviews.llvm.org/D28404



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

r291581 - [analyzer] Treat pointers to static member functions as function pointers

[Devin Coughlin via cfe-commits]

Author: dcoughlin
Date: Tue Jan 10 12:49:27 2017
New Revision: 291581

URL: http://llvm.org/viewvc/llvm-project?rev=291581&view=rev
Log:
[analyzer] Treat pointers to static member functions as function pointers

Sema treats pointers to static member functions as having function pointer
type, so treat treat them as function pointer values in the analyzer as well.
This prevents an assertion failure in SValBuilder::evalBinOp caused by code
that expects function pointers to be Locs (in contrast, PointerToMember values
are nonlocs).

Differential Revision: https://reviews.llvm.org/D28033

Modified:
cfe/trunk/lib/StaticAnalyzer/Core/SValBuilder.cpp
cfe/trunk/test/Analysis/pointer-to-member.cpp

Modified: cfe/trunk/lib/StaticAnalyzer/Core/SValBuilder.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/SValBuilder.cpp?rev=291581&r1=291580&r2=291581&view=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Core/SValBuilder.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Core/SValBuilder.cpp Tue Jan 10 12:49:27 2017
@@ -218,6 +218,18 @@ SValBuilder::getDerivedRegionValueSymbol
 }
 
 DefinedSVal SValBuilder::getMemberPointer(const DeclaratorDecl* DD) {
+  assert(!DD || isa(DD) || isa(DD));
+
+  if (auto *MD = dyn_cast_or_null(DD)) {
+// Sema treats pointers to static member functions as have function pointer
+// type, so return a function pointer for the method.
+// We don't need to play a similar trick for static member fields
+// because these are represented as plain VarDecls and not FieldDecls
+// in the AST.
+if (MD->isStatic())
+  return getFunctionPointer(MD);
+  }
+
   return nonloc::PointerToMember(DD);
 }
 

Modified: cfe/trunk/test/Analysis/pointer-to-member.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/pointer-to-member.cpp?rev=291581&r1=291580&r2=291581&view=diff
==
--- cfe/trunk/test/Analysis/pointer-to-member.cpp (original)
+++ cfe/trunk/test/Analysis/pointer-to-member.cpp Tue Jan 10 12:49:27 2017
@@ -77,7 +77,8 @@ bool testDereferencing() {
 namespace testPointerToMemberFunction {
   struct A {
 virtual int foo() { return 1; }
-int bar() { return 2;  }
+int bar() { return 2; }
+int static staticMemberFunction(int p) { return p + 1; };
   };
 
   struct B : public A {
@@ -111,11 +112,19 @@ namespace testPointerToMemberFunction {
 
 clang_analyzer_eval((APtr->*AFP)() == 3); // expected-warning{{TRUE}}
   }
+
+  void testPointerToStaticMemberCall() {
+int (*fPtr)(int) = &A::staticMemberFunction;
+if (fPtr != 0) { // no-crash
+  clang_analyzer_eval(fPtr(2) == 3); // expected-warning{{TRUE}}
+}
+  }
 } // end of testPointerToMemberFunction namespace
 
 namespace testPointerToMemberData {
   struct A {
 int i;
+static int j;
   };
 
   void testPointerToMemberData() {
@@ -126,6 +135,13 @@ namespace testPointerToMemberData {
 a.*AMdPointer += 1;
 
 clang_analyzer_eval(a.i == 43); // expected-warning{{TRUE}}
+
+int *ptrToStaticField = &A::j;
+if (ptrToStaticField != 0) {
+  *ptrToStaticField = 7;
+  clang_analyzer_eval(*ptrToStaticField == 7); // expected-warning{{TRUE}}
+  clang_analyzer_eval(A::j == 7); // expected-warning{{TRUE}}
+}
   }
 } // end of testPointerToMemberData namespace
 


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

[PATCH] D28033: [analyzer] Treat pointers to static member functions as function pointers

[Devin Coughlin via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL291581: [analyzer] Treat pointers to static member functions 
as function pointers (authored by dcoughlin).

Changed prior to commit:
  https://reviews.llvm.org/D28033?vs=83828&id=83830#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D28033

Files:
  cfe/trunk/lib/StaticAnalyzer/Core/SValBuilder.cpp
  cfe/trunk/test/Analysis/pointer-to-member.cpp


Index: cfe/trunk/test/Analysis/pointer-to-member.cpp
===
--- cfe/trunk/test/Analysis/pointer-to-member.cpp
+++ cfe/trunk/test/Analysis/pointer-to-member.cpp
@@ -77,7 +77,8 @@
 namespace testPointerToMemberFunction {
   struct A {
 virtual int foo() { return 1; }
-int bar() { return 2;  }
+int bar() { return 2; }
+int static staticMemberFunction(int p) { return p + 1; };
   };
 
   struct B : public A {
@@ -111,11 +112,19 @@
 
 clang_analyzer_eval((APtr->*AFP)() == 3); // expected-warning{{TRUE}}
   }
+
+  void testPointerToStaticMemberCall() {
+int (*fPtr)(int) = &A::staticMemberFunction;
+if (fPtr != 0) { // no-crash
+  clang_analyzer_eval(fPtr(2) == 3); // expected-warning{{TRUE}}
+}
+  }
 } // end of testPointerToMemberFunction namespace
 
 namespace testPointerToMemberData {
   struct A {
 int i;
+static int j;
   };
 
   void testPointerToMemberData() {
@@ -126,6 +135,13 @@
 a.*AMdPointer += 1;
 
 clang_analyzer_eval(a.i == 43); // expected-warning{{TRUE}}
+
+int *ptrToStaticField = &A::j;
+if (ptrToStaticField != 0) {
+  *ptrToStaticField = 7;
+  clang_analyzer_eval(*ptrToStaticField == 7); // expected-warning{{TRUE}}
+  clang_analyzer_eval(A::j == 7); // expected-warning{{TRUE}}
+}
   }
 } // end of testPointerToMemberData namespace
 
Index: cfe/trunk/lib/StaticAnalyzer/Core/SValBuilder.cpp
===
--- cfe/trunk/lib/StaticAnalyzer/Core/SValBuilder.cpp
+++ cfe/trunk/lib/StaticAnalyzer/Core/SValBuilder.cpp
@@ -218,6 +218,18 @@
 }
 
 DefinedSVal SValBuilder::getMemberPointer(const DeclaratorDecl* DD) {
+  assert(!DD || isa(DD) || isa(DD));
+
+  if (auto *MD = dyn_cast_or_null(DD)) {
+// Sema treats pointers to static member functions as have function pointer
+// type, so return a function pointer for the method.
+// We don't need to play a similar trick for static member fields
+// because these are represented as plain VarDecls and not FieldDecls
+// in the AST.
+if (MD->isStatic())
+  return getFunctionPointer(MD);
+  }
+
   return nonloc::PointerToMember(DD);
 }
 


Index: cfe/trunk/test/Analysis/pointer-to-member.cpp
===
--- cfe/trunk/test/Analysis/pointer-to-member.cpp
+++ cfe/trunk/test/Analysis/pointer-to-member.cpp
@@ -77,7 +77,8 @@
 namespace testPointerToMemberFunction {
   struct A {
 virtual int foo() { return 1; }
-int bar() { return 2;  }
+int bar() { return 2; }
+int static staticMemberFunction(int p) { return p + 1; };
   };
 
   struct B : public A {
@@ -111,11 +112,19 @@
 
 clang_analyzer_eval((APtr->*AFP)() == 3); // expected-warning{{TRUE}}
   }
+
+  void testPointerToStaticMemberCall() {
+int (*fPtr)(int) = &A::staticMemberFunction;
+if (fPtr != 0) { // no-crash
+  clang_analyzer_eval(fPtr(2) == 3); // expected-warning{{TRUE}}
+}
+  }
 } // end of testPointerToMemberFunction namespace
 
 namespace testPointerToMemberData {
   struct A {
 int i;
+static int j;
   };
 
   void testPointerToMemberData() {
@@ -126,6 +135,13 @@
 a.*AMdPointer += 1;
 
 clang_analyzer_eval(a.i == 43); // expected-warning{{TRUE}}
+
+int *ptrToStaticField = &A::j;
+if (ptrToStaticField != 0) {
+  *ptrToStaticField = 7;
+  clang_analyzer_eval(*ptrToStaticField == 7); // expected-warning{{TRUE}}
+  clang_analyzer_eval(A::j == 7); // expected-warning{{TRUE}}
+}
   }
 } // end of testPointerToMemberData namespace
 
Index: cfe/trunk/lib/StaticAnalyzer/Core/SValBuilder.cpp
===
--- cfe/trunk/lib/StaticAnalyzer/Core/SValBuilder.cpp
+++ cfe/trunk/lib/StaticAnalyzer/Core/SValBuilder.cpp
@@ -218,6 +218,18 @@
 }
 
 DefinedSVal SValBuilder::getMemberPointer(const DeclaratorDecl* DD) {
+  assert(!DD || isa(DD) || isa(DD));
+
+  if (auto *MD = dyn_cast_or_null(DD)) {
+// Sema treats pointers to static member functions as have function pointer
+// type, so return a function pointer for the method.
+// We don't need to play a similar trick for static member fields
+// because these are represented as plain VarDecls and not FieldDecls
+// in the AST.
+if (MD->isStatic())
+  return getFunctionPointer(MD);
+  }
+
   return nonloc::PointerToMember(DD);
 }
 
___
cfe-commits mailing list
cfe-com

r291582 - [ARM] Use generic bitreverse intrinsic, rather than ARM specific rbit.

[Chad Rosier via cfe-commits]

Author: mcrosier
Date: Tue Jan 10 12:55:11 2017
New Revision: 291582

URL: http://llvm.org/viewvc/llvm-project?rev=291582&view=rev
Log:
[ARM] Use generic bitreverse intrinsic, rather than ARM specific rbit.

The backend already supports lowering this intrinsic to a rbit instruction.

Modified:
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/test/CodeGen/arm_acle.c
cfe/trunk/test/CodeGen/builtins-arm.c

Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=291582&r1=291581&r2=291582&view=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Tue Jan 10 12:55:11 2017
@@ -4318,9 +4318,9 @@ Value *CodeGenFunction::EmitARMBuiltinEx
   }
 
   if (BuiltinID == ARM::BI__builtin_arm_rbit) {
-return Builder.CreateCall(CGM.getIntrinsic(Intrinsic::arm_rbit),
-   EmitScalarExpr(E->getArg(0)),
-  "rbit");
+llvm::Value *Arg = EmitScalarExpr(E->getArg(0));
+return Builder.CreateCall(
+CGM.getIntrinsic(Intrinsic::bitreverse, Arg->getType()), Arg, "rbit");
   }
 
   if (BuiltinID == ARM::BI__clear_cache) {

Modified: cfe/trunk/test/CodeGen/arm_acle.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/arm_acle.c?rev=291582&r1=291581&r2=291582&view=diff
==
--- cfe/trunk/test/CodeGen/arm_acle.c (original)
+++ cfe/trunk/test/CodeGen/arm_acle.c Tue Jan 10 12:55:11 2017
@@ -244,22 +244,22 @@ int16_t test_revsh(int16_t t) {
 }
 
 // ARM-LABEL: test_rbit
-// AArch32: call i32 @llvm.arm.rbit
+// AArch32: call i32 @llvm.bitreverse.i32
 // AArch64: call i32 @llvm.bitreverse.i32
 uint32_t test_rbit(uint32_t t) {
   return __rbit(t);
 }
 
 // ARM-LABEL: test_rbitl
-// AArch32: call i32 @llvm.arm.rbit
+// AArch32: call i32 @llvm.bitreverse.i32
 // AArch64: call i64 @llvm.bitreverse.i64
 long test_rbitl(long t) {
   return __rbitl(t);
 }
 
 // ARM-LABEL: test_rbitll
-// AArch32: call i32 @llvm.arm.rbit
-// AArch32: call i32 @llvm.arm.rbit
+// AArch32: call i32 @llvm.bitreverse.i32
+// AArch32: call i32 @llvm.bitreverse.i32
 // AArch64: call i64 @llvm.bitreverse.i64
 uint64_t test_rbitll(uint64_t t) {
   return __rbitll(t);

Modified: cfe/trunk/test/CodeGen/builtins-arm.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/builtins-arm.c?rev=291582&r1=291581&r2=291582&view=diff
==
--- cfe/trunk/test/CodeGen/builtins-arm.c (original)
+++ cfe/trunk/test/CodeGen/builtins-arm.c Tue Jan 10 12:55:11 2017
@@ -68,7 +68,7 @@ void test_barrier() {
   __builtin_arm_isb(3); //CHECK: call {{.*}} @llvm.arm.isb(i32 3)
 }
 
-// CHECK: call {{.*}} @llvm.arm.rbit(i32 %a)
+// CHECK: call {{.*}} @llvm.bitreverse.i32(i32 %a)
 
 unsigned rbit(unsigned a) {
   return __builtin_arm_rbit(a);


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

r291583 - [OpenMP] Remove outdated comments. NFC.

[Kelvin Li via cfe-commits]

Author: kli
Date: Tue Jan 10 12:57:07 2017
New Revision: 291583

URL: http://llvm.org/viewvc/llvm-project?rev=291583&view=rev
Log:
[OpenMP] Remove outdated comments. NFC.

Modified:
cfe/trunk/include/clang/Basic/OpenMPKinds.def

Modified: cfe/trunk/include/clang/Basic/OpenMPKinds.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/OpenMPKinds.def?rev=291583&r1=291582&r2=291583&view=diff
==
--- cfe/trunk/include/clang/Basic/OpenMPKinds.def (original)
+++ cfe/trunk/include/clang/Basic/OpenMPKinds.def Tue Jan 10 12:57:07 2017
@@ -450,7 +450,6 @@ OPENMP_TARGET_CLAUSE(firstprivate)
 OPENMP_TARGET_CLAUSE(is_device_ptr)
 
 // Clauses allowed for OpenMP directive 'target data'.
-// TODO More clauses for 'target data' directive.
 OPENMP_TARGET_DATA_CLAUSE(if)
 OPENMP_TARGET_DATA_CLAUSE(device)
 OPENMP_TARGET_DATA_CLAUSE(map)
@@ -508,7 +507,6 @@ OPENMP_TARGET_PARALLEL_FOR_CLAUSE(linear
 OPENMP_TARGET_PARALLEL_FOR_CLAUSE(is_device_ptr)
 
 // Clauses allowed for OpenMP directive 'target update'.
-// TODO More clauses for 'target update' directive.
 OPENMP_TARGET_UPDATE_CLAUSE(if)
 OPENMP_TARGET_UPDATE_CLAUSE(device)
 OPENMP_TARGET_UPDATE_CLAUSE(to)
@@ -517,7 +515,6 @@ OPENMP_TARGET_UPDATE_CLAUSE(nowait)
 OPENMP_TARGET_UPDATE_CLAUSE(depend)
 
 // Clauses allowed for OpenMP directive 'teams'.
-// TODO More clauses for 'teams' directive.
 OPENMP_TEAMS_CLAUSE(default)
 OPENMP_TEAMS_CLAUSE(private)
 OPENMP_TEAMS_CLAUSE(firstprivate)
@@ -527,7 +524,6 @@ OPENMP_TEAMS_CLAUSE(num_teams)
 OPENMP_TEAMS_CLAUSE(thread_limit)
 
 // Clauses allowed for OpenMP directive 'ordered'.
-// TODO More clauses for 'ordered' directive.
 OPENMP_ORDERED_CLAUSE(threads)
 OPENMP_ORDERED_CLAUSE(simd)
 OPENMP_ORDERED_CLAUSE(depend)


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

[PATCH] D20693: [clang-tidy] New checker to replace dynamic exception specifications

[don hinton via Phabricator via cfe-commits]

hintonda added inline comments.



Comment at: clang-tidy/modernize/UseNoexceptCheck.cpp:68
+  this);
+}
+

aaron.ballman wrote:
> hintonda wrote:
> > aaron.ballman wrote:
> > > Also missing: typedefs and using declarations.
> > As far as I know, it isn't legal to add dynamic exception specifications to 
> > typedefs and using declarations.
> Hmm, I thought you could, at least in C++17, since it's now part of the 
> function's type. However, I don't have a standard in front of me at the 
> moment, so I'll have to double-check. It can always be added in a follow-up 
> patch and need not block this one.
> 
> However, I do know the following is allowed in a typedef, and I don't think 
> your existing ParmVarDecl matcher will catch it:
> ```
> typedef void (*fp)(void (*f)(int) throw());
> ```
clang doesn't allow dynamic exception specs in typedef or using declarations 
for either c++11 or c++14, but does in c++1z since throw() is an alias for 
noexcept.  I'll try to add an appropriate test to highlight this.


I've added your typedef example -- thanks for suggesting it -- and the matcher 
does catch it and does the appropriate fixit.



Comment at: docs/clang-tidy/checks/modernize-use-noexcept.rst:30
+By default this check will only replace ``throw()`` with ``noexcept``,
+and ``throw([,...])`` or ``throw(...)`` with blank except
+for operator delete and destructors, which are replaced with

aaron.ballman wrote:
> hintonda wrote:
> > aaron.ballman wrote:
> > > I continue to object to removing the explicit exception specification 
> > > entirely as the default behavior without strong justification. Further. 
> > > there is no option to control this behavior.
> > I tried to make sure it's only applied where appropriate.  If I missed a 
> > case, please let me know, but I'm not sure an option "just in case" is 
> > right solution.
> > 
> > However, I did try to structure the code in a way to make it easy to add an 
> > option if that turns out the be the right thing to do.
> The behavior as it's implemented now is not the behavior I would expect from 
> such a check -- I think that `throw(int)` should get a FixIt to 
> `noexcept(false)` rather than no `noexcept` clause whatsoever. Despite them 
> being functionally equivalent in most cases, the explicit nature of the 
> dynamic exception specification should be retained with an explicit noexcept 
> exception specification, not discarded. If you really want `throw(int)` to be 
> modified to have no explicit exception specification, I think that should be 
> an option (off by default). If you would rather not make an option, then I 
> think the explicit exception specification should remain.
Makes sense.  Will do.



Comment at: docs/clang-tidy/checks/modernize-use-noexcept.rst:38
+that don't support the ``noexcept`` keyword.  Users can define the
+macro to be ``noexcept`` or ``throw()`` depending on whether or not
+noexcept is supported.  Specifications that can throw, e.g.,

aaron.ballman wrote:
> hintonda wrote:
> > aaron.ballman wrote:
> > > I'm not certain I understand the justification of calling out older 
> > > compilers or suggesting use of `throw()`. The check will continually flag 
> > > `throw()` and try to recommend `noexcept` in its place, won't it? At 
> > > least, that's how I read the preceding paragraph.
> > > 
> > > I think the macro replacement is a reasonable feature, but I think the 
> > > check only makes sense for C++11 or later, since C++98 users really have 
> > > no alternatives to dynamic exception specifications.
> > Libraries, e.g., libc++, that need to support both multiple versions of the 
> > standard, use macros to switch between throw() and noexcept.
> > 
> > So this option was designed to be libc++ friendly.  If that's not 
> > appropriate, I can remove it.
> I think the *option* is fine; I think the wording is confusing. How about:
> ```
> Alternatively, users can also use :option:`ReplacementString` to
> specify a macro to use instead of ``noexcept``.  This is useful when
> maintaining source code that uses custom exception specification marking
> other than ``noexcept``.
> ```
Ah, okay, that sounds much better.  I'll make this change shortly.


https://reviews.llvm.org/D20693



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

[PATCH] D28404: IRGen: Add optnone attribute on function during O0

[Mehdi AMINI via Phabricator via cfe-commits]

mehdi_amini added a comment.

In https://reviews.llvm.org/D28404#641538, @probinson wrote:

> > - optnone isn't *really* no optimizations: clearly this is true, but then 
> > neither is -O0. We run the always inliner, a couple of other passes, and we 
> > run several parts of the code generators optimizer. I understand why 
> > optnone deficiencies (ie, too many optimizations) might be frustrating, but 
> > having *more users* seems likely to make this *better*.
>
> We have picked all the low-hanging fruit there, and probably some 
> medium-hanging fruit.  Mehdi did have the misunderstanding that optnone == 
> -O0 and that I think was worth correcting.


As I stand right now, there hasn't been any correction. 
I still consider the fact that `optnone` wouldn't produce the "same" result 
(modulo corner cases around `merging global variables` for instance) as O0 a 
bug that need to be fixed.

(Disabling passes for compile time at O0 stays I compile time improvement, I 
never suggested to stop doing this...)


https://reviews.llvm.org/D28404



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

[PATCH] D28148: [Sema] Suppress warnings for C's zero initializer

[S. Gilles via Phabricator via cfe-commits]

sgilles marked an inline comment as done.
sgilles added a comment.

Ping - if there are no comments, could this be accepted?


https://reviews.llvm.org/D28148



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

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

[Eric Fiselier via Phabricator via cfe-commits]

EricWF added a comment.

Also look in `__mutex` where libc++ defines its own macros for the annotations.


https://reviews.llvm.org/D28520



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

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

In https://reviews.llvm.org/D28520#641563, @EricWF wrote:

> Also look in `__mutex` where libc++ defines its own macros for the 
> annotations.


I assume you mean `__mutex_base`.  Do we want to reuse the macros from that 
file?  If so we'd have to include it in `__thread_support`.  Maybe it is better 
to move the macros to `__config` instead, then.


https://reviews.llvm.org/D28520



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

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

[Eric Fiselier via Phabricator via cfe-commits]

EricWF added a comment.

In https://reviews.llvm.org/D28520#641569, @dim wrote:

> In https://reviews.llvm.org/D28520#641563, @EricWF wrote:
>
> > Also look in `__mutex` where libc++ defines its own macros for the 
> > annotations.
>
>
> I assume you mean `__mutex_base`.  Do we want to reuse the macros from that 
> file?  If so we'd have to include it in `__thread_support`.  Maybe it is 
> better to move the macros to `__config` instead, then.


Yes sorry `__mutex_base`. Moving them to `__config` sounds reasonable.


https://reviews.llvm.org/D28520



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

Re: [clang-tools-extra] r291446 - [include-fixer] Load symbol index asynchronously.

[Bill Seurer via cfe-commits]

On 01/09/2017 09:18 AM, Benjamin Kramer via cfe-commits wrote:

Author: d0k
Date: Mon Jan  9 09:18:28 2017
New Revision: 291446

URL: http://llvm.org/viewvc/llvm-project?rev=291446&view=rev
Log:
[include-fixer] Load symbol index asynchronously.

We don't actually need the index until parse time, so fetch it in the
background and start parsing. By the time it is actually needed it's
likely that the loading phase has completed in the background.


This update causes a linker error on ppc64le on a Release+Asserts+Shared 
build.


cmake with -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON 
-DBUILD_SHARED_LIBS=ON


http://lab.llvm.org:8011/builders/clang-ppc64le-linux-multistage/builds/754


Details:

[117/123] Linking CXX shared library 
lib/libclangIncludeFixerPlugin.so.40.0svn
FAILED: : && /home/seurer/gcc/install/gcc-5.4.0/bin/g++  -fPIC -fPIC 
-fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic 
-Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor 
-Wno-comment -Werror=date-time -std=c++11 -ffunction-sections 
-fdata-sections -fno-common -Woverloaded-virtual -fno-strict-aliasing 
-O3  -L/home/seurer/gcc/install/gcc-5.4.0/lib64 -Wl,-z,defs 
-Wl,-rpath-link,/home/seurer/llvm/build/llvm-test2/./lib  -Wl,-O3 
-Wl,--gc-sections -shared -Wl,-soname,libclangIncludeFixerPlugin.so.40 
-o lib/libclangIncludeFixerPlugin.so.40.0svn 
tools/clang/tools/extra/include-fixer/plugin/CMakeFiles/clangIncludeFixerPlugin.dir/IncludeFixerPlugin.cpp.o 
 lib/libclangAST.so.40.0svn lib/libclangBasic.so.40.0svn 
lib/libclangFrontend.so.40.0svn lib/libclangIncludeFixer.so.40.0svn 
lib/libclangParse.so.40.0svn lib/libclangSema.so.40.0svn 
lib/libclangTooling.so.40.0svn lib/libLLVMSupport.so.40.0svn 
-Wl,-rpath,"\$ORIGIN/../lib" && :
tools/clang/tools/extra/include-fixer/plugin/CMakeFiles/clangIncludeFixerPlugin.dir/IncludeFixerPlugin.cpp.o:(.toc+0xb0): 
undefined reference to `pthread_create'

collect2: error: ld returned 1 exit status
[117/123] Building CXX object 
tools/clang/tools/extra/include-fixer/tool/CMakeFiles/clang-include-fixer.dir/ClangIncludeFixer.cpp.o

ninja: build stopped: subcommand failed.
[1/7] Linking CXX shared library lib/libclangIncludeFixerPlugin.so.40.0svn
FAILED: : && /home/seurer/gcc/install/gcc-5.4.0/bin/g++  -fPIC -fPIC 
-fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic 
-Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor 
-Wno-comment -Werror=date-time -std=c++11 -ffunction-sections 
-fdata-sections -fno-common -Woverloaded-virtual -fno-strict-aliasing 
-O3  -L/home/seurer/gcc/install/gcc-5.4.0/lib64 -Wl,-z,defs 
-Wl,-rpath-link,/home/seurer/llvm/build/llvm-test2/./lib  -Wl,-O3 
-Wl,--gc-sections -shared -Wl,-soname,libclangIncludeFixerPlugin.so.40 
-o lib/libclangIncludeFixerPlugin.so.40.0svn 
tools/clang/tools/extra/include-fixer/plugin/CMakeFiles/clangIncludeFixerPlugin.dir/IncludeFixerPlugin.cpp.o 
 lib/libclangAST.so.40.0svn lib/libclangBasic.so.40.0svn 
lib/libclangFrontend.so.40.0svn lib/libclangIncludeFixer.so.40.0svn 
lib/libclangParse.so.40.0svn lib/libclangSema.so.40.0svn 
lib/libclangTooling.so.40.0svn lib/libLLVMSupport.so.40.0svn 
-Wl,-rpath,"\$ORIGIN/../lib" && :
tools/clang/tools/extra/include-fixer/plugin/CMakeFiles/clangIncludeFixerPlugin.dir/IncludeFixerPlugin.cpp.o:(.toc+0xb0): 
undefined reference to `pthread_create'

collect2: error: ld returned 1 exit status





Modified:
clang-tools-extra/trunk/include-fixer/SymbolIndexManager.cpp
clang-tools-extra/trunk/include-fixer/SymbolIndexManager.h
clang-tools-extra/trunk/include-fixer/plugin/IncludeFixerPlugin.cpp
clang-tools-extra/trunk/include-fixer/tool/ClangIncludeFixer.cpp
clang-tools-extra/trunk/unittests/include-fixer/IncludeFixerTest.cpp

Modified: clang-tools-extra/trunk/include-fixer/SymbolIndexManager.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/include-fixer/SymbolIndexManager.cpp?rev=291446&r1=291445&r2=291446&view=diff
==
--- clang-tools-extra/trunk/include-fixer/SymbolIndexManager.cpp (original)
+++ clang-tools-extra/trunk/include-fixer/SymbolIndexManager.cpp Mon Jan  9 
09:18:28 2017
@@ -64,7 +64,7 @@ SymbolIndexManager::search(llvm::StringR
   do {
 std::vector Symbols;
 for (const auto &DB : SymbolIndices) {
-  auto Res = DB->search(Names.back().str());
+  auto Res = DB.get()->search(Names.back());
   Symbols.insert(Symbols.end(), Res.begin(), Res.end());
 }


Modified: clang-tools-extra/trunk/include-fixer/SymbolIndexManager.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/include-fixer/SymbolIndexManager.h?rev=291446&r1=291445&r2=291446&view=diff
==
--- clang-tools-extra/trunk/include-fixer/Symb

[PATCH] D28404: IRGen: Add optnone attribute on function during O0

[Paul Robinson via Phabricator via cfe-commits]

probinson added a comment.

In https://reviews.llvm.org/D28404#641557, @mehdi_amini wrote:

> As I stand right now, there hasn't been any correction. 
>  I still consider the fact that `optnone` wouldn't produce the "same" result 
> (modulo corner cases around `merging global variables` for instance) as O0 a 
> bug that need to be fixed.


Why?  That's not the purpose of optnone.  You've already admitted there are 
some differences.  Why are other differences important?


https://reviews.llvm.org/D28404



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

[PATCH] D28404: IRGen: Add optnone attribute on function during O0

[Mehdi AMINI via Phabricator via cfe-commits]

mehdi_amini added a comment.

In https://reviews.llvm.org/D28404#641597, @probinson wrote:

> In https://reviews.llvm.org/D28404#641557, @mehdi_amini wrote:
>
> > As I stand right now, there hasn't been any correction. 
> >  I still consider the fact that `optnone` wouldn't produce the "same" 
> > result (modulo corner cases around `merging global variables` for instance) 
> > as O0 a bug that need to be fixed.
>
>
> Why?


Why not? What's the alternative?
If we want to support `-O0 -flto` and `optnone` it the way to convey this to 
the optimizer, I don't see the alternative.


https://reviews.llvm.org/D28404



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

[PATCH] D28419: clang-tools-extra: add gitattributes to disable EOL conversions on checkout of test source files

[Antonio Maiorano via Phabricator via cfe-commits]

amaiorano added a comment.

Last night, I realized that this problem extends to the clang/tests as well, 
not just those in clang-tools-extra. Is there someone who knows Windows, Git, 
and the testing pipeline that can weigh in more on this topic?


https://reviews.llvm.org/D28419



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

[PATCH] D28404: IRGen: Add optnone attribute on function during O0

[Paul Robinson via Phabricator via cfe-commits]

probinson added a comment.

In https://reviews.llvm.org/D28404#641606, @mehdi_amini wrote:

> If we want to support `-O0 -flto` and `optnone` it the way to convey this to 
> the optimizer, I don't see the alternative.


optsize != -Os (according to Chandler)
minsize != -Oz (according to Chandler)
optnone != -O0 (according to both me and Chandler)

optnone is not "the way to convey (-O0) to the optimizer."  Please get that 
misunderstanding out of your head.  Clang handles -O0 by creating a short, 
minimalist pipeline, and running everything through it.  Clang handles -O2 by 
creating a fuller optimization pipeline, and functions with 'optnone' skip many 
of the passes in the pipeline.

These are architecturally different processes, you are not going to be able to 
make 'optnone' behave exactly like -O0 without major redesign of how the 
pipelines work.


https://reviews.llvm.org/D28404



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

Re: [clang-tools-extra] r291446 - [include-fixer] Load symbol index asynchronously.

[Benjamin Kramer via cfe-commits]

I didn't manage to reproduce this. Does adding ${PTHREAD_LIB} to
LINK_LIBS of tools/clang/tools/extra/include-fixer/plugin/CMakeLists.txt
help?

On Tue, Jan 10, 2017 at 8:31 PM, Bill Seurer  wrote:
> On 01/09/2017 09:18 AM, Benjamin Kramer via cfe-commits wrote:
>>
>> Author: d0k
>> Date: Mon Jan  9 09:18:28 2017
>> New Revision: 291446
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=291446&view=rev
>> Log:
>> [include-fixer] Load symbol index asynchronously.
>>
>> We don't actually need the index until parse time, so fetch it in the
>> background and start parsing. By the time it is actually needed it's
>> likely that the loading phase has completed in the background.
>
>
> This update causes a linker error on ppc64le on a Release+Asserts+Shared
> build.
>
> cmake with -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON
> -DBUILD_SHARED_LIBS=ON
>
> http://lab.llvm.org:8011/builders/clang-ppc64le-linux-multistage/builds/754
>
>
> Details:
>
> [117/123] Linking CXX shared library
> lib/libclangIncludeFixerPlugin.so.40.0svn
> FAILED: : && /home/seurer/gcc/install/gcc-5.4.0/bin/g++  -fPIC -fPIC
> -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings
> -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long
> -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment
> -Werror=date-time -std=c++11 -ffunction-sections -fdata-sections -fno-common
> -Woverloaded-virtual -fno-strict-aliasing -O3
> -L/home/seurer/gcc/install/gcc-5.4.0/lib64 -Wl,-z,defs
> -Wl,-rpath-link,/home/seurer/llvm/build/llvm-test2/./lib  -Wl,-O3
> -Wl,--gc-sections -shared -Wl,-soname,libclangIncludeFixerPlugin.so.40 -o
> lib/libclangIncludeFixerPlugin.so.40.0svn
> tools/clang/tools/extra/include-fixer/plugin/CMakeFiles/clangIncludeFixerPlugin.dir/IncludeFixerPlugin.cpp.o
> lib/libclangAST.so.40.0svn lib/libclangBasic.so.40.0svn
> lib/libclangFrontend.so.40.0svn lib/libclangIncludeFixer.so.40.0svn
> lib/libclangParse.so.40.0svn lib/libclangSema.so.40.0svn
> lib/libclangTooling.so.40.0svn lib/libLLVMSupport.so.40.0svn
> -Wl,-rpath,"\$ORIGIN/../lib" && :
> tools/clang/tools/extra/include-fixer/plugin/CMakeFiles/clangIncludeFixerPlugin.dir/IncludeFixerPlugin.cpp.o:(.toc+0xb0):
> undefined reference to `pthread_create'
> collect2: error: ld returned 1 exit status
> [117/123] Building CXX object
> tools/clang/tools/extra/include-fixer/tool/CMakeFiles/clang-include-fixer.dir/ClangIncludeFixer.cpp.o
> ninja: build stopped: subcommand failed.
> [1/7] Linking CXX shared library lib/libclangIncludeFixerPlugin.so.40.0svn
> FAILED: : && /home/seurer/gcc/install/gcc-5.4.0/bin/g++  -fPIC -fPIC
> -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings
> -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long
> -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment
> -Werror=date-time -std=c++11 -ffunction-sections -fdata-sections -fno-common
> -Woverloaded-virtual -fno-strict-aliasing -O3
> -L/home/seurer/gcc/install/gcc-5.4.0/lib64 -Wl,-z,defs
> -Wl,-rpath-link,/home/seurer/llvm/build/llvm-test2/./lib  -Wl,-O3
> -Wl,--gc-sections -shared -Wl,-soname,libclangIncludeFixerPlugin.so.40 -o
> lib/libclangIncludeFixerPlugin.so.40.0svn
> tools/clang/tools/extra/include-fixer/plugin/CMakeFiles/clangIncludeFixerPlugin.dir/IncludeFixerPlugin.cpp.o
> lib/libclangAST.so.40.0svn lib/libclangBasic.so.40.0svn
> lib/libclangFrontend.so.40.0svn lib/libclangIncludeFixer.so.40.0svn
> lib/libclangParse.so.40.0svn lib/libclangSema.so.40.0svn
> lib/libclangTooling.so.40.0svn lib/libLLVMSupport.so.40.0svn
> -Wl,-rpath,"\$ORIGIN/../lib" && :
> tools/clang/tools/extra/include-fixer/plugin/CMakeFiles/clangIncludeFixerPlugin.dir/IncludeFixerPlugin.cpp.o:(.toc+0xb0):
> undefined reference to `pthread_create'
> collect2: error: ld returned 1 exit status
>
>
>
>
>
>> Modified:
>> clang-tools-extra/trunk/include-fixer/SymbolIndexManager.cpp
>> clang-tools-extra/trunk/include-fixer/SymbolIndexManager.h
>> clang-tools-extra/trunk/include-fixer/plugin/IncludeFixerPlugin.cpp
>> clang-tools-extra/trunk/include-fixer/tool/ClangIncludeFixer.cpp
>> clang-tools-extra/trunk/unittests/include-fixer/IncludeFixerTest.cpp
>>
>> Modified: clang-tools-extra/trunk/include-fixer/SymbolIndexManager.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/include-fixer/SymbolIndexManager.cpp?rev=291446&r1=291445&r2=291446&view=diff
>>
>> ==
>> --- clang-tools-extra/trunk/include-fixer/SymbolIndexManager.cpp
>> (original)
>> +++ clang-tools-extra/trunk/include-fixer/SymbolIndexManager.cpp Mon Jan
>> 9 09:18:28 2017
>> @@ -64,7 +64,7 @@ SymbolIndexManager::search(llvm::StringR
>>do {
>>  std::vector Symbols;
>>  for (const auto &DB : SymbolIndices) {
>> -  auto Res = DB->search(Names.back().str());
>> +  auto Res = DB.get()->search(Names.back());
>>Symbols.insert(Symbols.end(), Res.be

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

[Dimitry Andric via Phabricator via cfe-commits]

dim updated this revision to Diff 83843.
dim added a comment.

- Move `_LIBCPP_THREAD_SAFETY_ANNOTATION` macro definition to `__config`.
- Add `_LIBCPP_THREAD_SAFETY_ANNOTATION(no_thread_safety_analysis)` macros to 
`__threading_support` function declarations which require them.

Note that I was not able to figure out how to make the other thread safety 
annotation attributes, such as `try_acquire_capability()`, match to the 
function signatures, as these use `int` instead of `bool`, for example.


https://reviews.llvm.org/D28520

Files:
  include/__config
  include/__mutex_base
  include/__threading_support


Index: include/__threading_support
===
--- include/__threading_support
+++ include/__threading_support
@@ -98,25 +98,25 @@
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_recursive_mutex_init(__libcpp_recursive_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY 
_LIBCPP_THREAD_SAFETY_ANNOTATION(no_thread_safety_analysis)
 int __libcpp_recursive_mutex_lock(__libcpp_recursive_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY 
_LIBCPP_THREAD_SAFETY_ANNOTATION(no_thread_safety_analysis)
 int __libcpp_recursive_mutex_trylock(__libcpp_recursive_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY 
_LIBCPP_THREAD_SAFETY_ANNOTATION(no_thread_safety_analysis)
 int __libcpp_recursive_mutex_unlock(__libcpp_recursive_mutex_t *__m);
 
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_recursive_mutex_destroy(__libcpp_recursive_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY 
_LIBCPP_THREAD_SAFETY_ANNOTATION(no_thread_safety_analysis)
 int __libcpp_mutex_lock(__libcpp_mutex_t *__m);
 
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_mutex_trylock(__libcpp_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY 
_LIBCPP_THREAD_SAFETY_ANNOTATION(no_thread_safety_analysis)
 int __libcpp_mutex_unlock(__libcpp_mutex_t *__m);
 
 _LIBCPP_THREAD_ABI_VISIBILITY
@@ -129,10 +129,10 @@
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_condvar_broadcast(__libcpp_condvar_t* __cv);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY 
_LIBCPP_THREAD_SAFETY_ANNOTATION(no_thread_safety_analysis)
 int __libcpp_condvar_wait(__libcpp_condvar_t* __cv, __libcpp_mutex_t* __m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY 
_LIBCPP_THREAD_SAFETY_ANNOTATION(no_thread_safety_analysis)
 int __libcpp_condvar_timedwait(__libcpp_condvar_t *__cv, __libcpp_mutex_t *__m,
timespec *__ts);
 
Index: include/__mutex_base
===
--- include/__mutex_base
+++ include/__mutex_base
@@ -24,14 +24,6 @@
 
 #ifndef _LIBCPP_HAS_NO_THREADS
 
-#ifndef _LIBCPP_THREAD_SAFETY_ANNOTATION
-#  ifdef _LIBCPP_HAS_THREAD_SAFETY_ANNOTATIONS
-#define _LIBCPP_THREAD_SAFETY_ANNOTATION(x) __attribute__((x))
-#  else
-#define _LIBCPP_THREAD_SAFETY_ANNOTATION(x)
-#  endif
-#endif  // _LIBCPP_THREAD_SAFETY_ANNOTATION
-
 class _LIBCPP_TYPE_VIS _LIBCPP_THREAD_SAFETY_ANNOTATION(capability("mutex")) 
mutex
 {
 #ifndef _LIBCPP_HAS_NO_CONSTEXPR
Index: include/__config
===
--- include/__config
+++ include/__config
@@ -981,6 +981,16 @@
 #define _LIBCPP_HAS_THREAD_SAFETY_ANNOTATIONS
 #endif
 
+#if !defined(_LIBCPP_HAS_NO_THREADS)
+# if !defined(_LIBCPP_THREAD_SAFETY_ANNOTATION)
+#  if defined(_LIBCPP_HAS_THREAD_SAFETY_ANNOTATIONS)
+#   define _LIBCPP_THREAD_SAFETY_ANNOTATION(x) __attribute__((x))
+#  else
+#   define _LIBCPP_THREAD_SAFETY_ANNOTATION(x)
+#  endif
+# endif
+#endif
+
 #if __has_attribute(require_constant_initialization)
 #define _LIBCPP_SAFE_STATIC 
__attribute__((__require_constant_initialization__))
 #else


Index: include/__threading_support
===
--- include/__threading_support
+++ include/__threading_support
@@ -98,25 +98,25 @@
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_recursive_mutex_init(__libcpp_recursive_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_THREAD_SAFETY_ANNOTATION(no_thread_safety_analysis)
 int __libcpp_recursive_mutex_lock(__libcpp_recursive_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_THREAD_SAFETY_ANNOTATION(no_thread_safety_analysis)
 int __libcpp_recursive_mutex_trylock(__libcpp_recursive_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_THREAD_SAFETY_ANNOTATION(no_thread_safety_analysis)
 int __libcpp_recursive_mutex_unlock(__libcpp_recursive_mutex_t *__m);
 
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_recursive_mutex_destroy(__libcpp_recursive_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_THREAD_SAFETY_ANNOTATION(no_thread_safety_analysis)
 int __libcpp_m

[libcxx] r291592 - [CMake][libcxx] Move Python check to main CMake file

[Petr Hosek via cfe-commits]

Author: phosek
Date: Tue Jan 10 13:51:17 2017
New Revision: 291592

URL: http://llvm.org/viewvc/llvm-project?rev=291592&view=rev
Log:
[CMake][libcxx] Move Python check to main CMake file

This is to make sure this check is called even when building as
part of LLVM runtimes when we are doing standalone but not out of
tree build.

Differential Revision: https://reviews.llvm.org/D28392

Modified:
libcxx/trunk/CMakeLists.txt
libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=291592&r1=291591&r2=291592&view=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Tue Jan 10 13:51:17 2017
@@ -32,6 +32,15 @@ if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURR
   include(HandleOutOfTreeLLVM)
 endif()
 
+if (LIBCXX_STANDALONE_BUILD)
+  include(FindPythonInterp)
+  if( NOT PYTHONINTERP_FOUND )
+message(WARNING "Failed to find python interpreter. "
+"The libc++ test suite will be disabled.")
+set(LLVM_INCLUDE_TESTS OFF)
+  endif()
+endif()
+
 # Require out of source build.
 include(MacroEnsureOutOfSourceBuild)
 MACRO_ENSURE_OUT_OF_SOURCE_BUILD(

Modified: libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake?rev=291592&r1=291591&r2=291592&view=diff
==
--- libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake (original)
+++ libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake Tue Jan 10 13:51:17 
2017
@@ -95,13 +95,6 @@ macro(configure_out_of_tree_llvm)
   endif()
 
   # LLVM Options --
-  include(FindPythonInterp)
-  if( NOT PYTHONINTERP_FOUND )
-message(WARNING "Failed to find python interpreter. "
-"The libc++ test suite will be disabled.")
-set(LLVM_INCLUDE_TESTS OFF)
-  endif()
-
   if (NOT DEFINED LLVM_INCLUDE_TESTS)
 set(LLVM_INCLUDE_TESTS ${LLVM_FOUND})
   endif()


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

[PATCH] D28404: IRGen: Add optnone attribute on function during O0

[Mehdi AMINI via Phabricator via cfe-commits]

mehdi_amini added a comment.

In https://reviews.llvm.org/D28404#641632, @probinson wrote:

> In https://reviews.llvm.org/D28404#641606, @mehdi_amini wrote:
>
> > If we want to support `-O0 -flto` and `optnone` it the way to convey this 
> > to the optimizer, I don't see the alternative.
>
>
> optsize != -Os (according to Chandler)
>  minsize != -Oz (according to Chandler)
>  optnone != -O0 (according to both me and Chandler)


Of course, but that's just an implementation limitation, mostly for historical 
reason I believe, not by design. That does not have to be set in stone and I'm 
giving you the direction with respect to LTO in particular here: these 
attributes should be able to behave the same way as the corresponding '-O' 
command line.

> optnone is not "the way to convey (-O0) to the optimizer."  Please get that 
> misunderstanding out of your head.  Clang handles -O0 by creating a short, 
> minimalist pipeline, and running everything through it.  Clang handles -O2 by 
> creating a fuller optimization pipeline, and functions with 'optnone' skip 
> many of the passes in the pipeline.

Don't get me wrong: I believe I have a very good understanding how the 
optimizer pipeline is setup and how the passes operates with respect to the 
attributes.
And it is because I understand the deficiencies (and how it is an issue with 
LTO) that I'm aligning all of this toward a consistent/coherent expected result 
for the users.

> These are architecturally different processes, you are not going to be able 
> to make 'optnone' behave exactly like -O0 without major redesign of how the 
> pipelines work.

I'd disagree about your estimation of "major". It's not gonna be tomorrow, 
sure, but it does not have to be. The most difficult part will be the inter 
procedural ones, but there are not that many.


https://reviews.llvm.org/D28404



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

[PATCH] D28526: [ARM] Add diagnostics when initialization global variables with ropi/rwpi

[Weiming Zhao via Phabricator via cfe-commits]

weimingz created this revision.
weimingz added reviewers: olista01, jmolloy.
weimingz added a subscriber: cfe-commits.
Herald added subscribers: rengolin, aemerson.

This patch adds diagnoses when initializing a global variable using the address 
of another global variable that uses ROPI/RWPI relocation model.

For example, 
int a;
extern void foo();
int *x = &a;// we cannot statically initialize x with -frwpi 
void *y = &foo();  // we can't statically initialize y with -fropi

The above code will trigger diagnoses like:

  error: 'x' cannot be initialized using address of 'a' with 'rwpi' relocation


https://reviews.llvm.org/D28526

Files:
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CodeGenModule.cpp
  lib/CodeGen/CodeGenModule.h
  test/CodeGen/arm-ropi-rwpi.c

Index: test/CodeGen/arm-ropi-rwpi.c
===
--- /dev/null
+++ test/CodeGen/arm-ropi-rwpi.c
@@ -0,0 +1,56 @@
+// REQUIRES: arm-registered-target
+
+// OK with local initialization, rwpi with const gv and ropi with non-const gv.
+// RUN: %clang_cc1 -triple armv7 -mrelocation-model ropi-rwpi %s -S -o /dev/null
+// RUN: %clang_cc1 -triple armv7 -mrelocation-model rwpi -DTEST_RO_1 -DTEST_RO_2 -DTEST_RO_STATIC %s -S -o /dev/null
+// RUN: %clang_cc1 -triple armv7 -mrelocation-model ropi -DTEST_RW_1 -DTEST_RW_STATIC %s -S -o /dev/null
+
+// RUN: not %clang_cc1 -triple armv7 -mrelocation-model ropi -DTEST_RO_1  %s -S -o /dev/null 2>&1 | FileCheck %s -check-prefix=CHECK-RO-1
+// RUN: not %clang_cc1 -triple armv7 -mrelocation-model ropi -DTEST_RO_2  %s -S -o /dev/null 2>&1 | FileCheck %s -check-prefix=CHECK-RO-2
+// RUN: not %clang_cc1 -triple armv7 -mrelocation-model ropi -DTEST_RO_STATIC  %s -S -o /dev/null 2>&1 | FileCheck %s -check-prefix=CHECK-RO-STATIC
+
+// RUN: not %clang_cc1 -triple armv7 -mrelocation-model rwpi -DTEST_RW_1  %s -S -o /dev/null 2>&1 | FileCheck %s -check-prefix=CHECK-RW-1
+
+// RUN: not %clang_cc1 -triple armv7 -mrelocation-model ropi-rwpi -DTEST_RW_STATIC  %s -S -o /dev/null 2>&1 | FileCheck %s -check-prefix=CHECK-RW-STATIC
+
+extern int func(void);
+
+extern int gv;
+
+extern const int c_gv;
+
+#ifdef TEST_RO_1
+void *p1 = &func;
+#endif
+// CHECK-RO-1: error: 'p1' cannot be initilized using address of 'func' with 'ropi' relocation
+
+#ifdef TEST_RO_2
+const void *p2 = &c_gv;
+#endif
+// CHECK-RO-2: error: 'p2' cannot be initilized using address of 'c_gv' with 'ropi' relocation
+
+#ifdef TEST_RO_STATIC
+void bar() {
+  static void *sp = &func;
+}
+#endif
+// CHECK-RO-STATIC: error: 'bar.sp' cannot be initilized using address of 'func' with 'ropi' relocation
+
+#ifdef TEST_RW_1
+void *p3 = &gv;
+#endif
+// CHECK-RW-1: error: 'p3' cannot be initilized using address of 'gv' with 'rwpi' relocation
+
+#ifdef TEST_RW_STATIC
+void bar2() {
+  static void *sp = &gv;
+}
+#endif
+// CHECK-RW-STATIC: error: 'bar2.sp' cannot be initilized using address of 'gv' with 'ropi-rwpi' relocation
+
+unsigned test() {
+  unsigned a = (unsigned)&func;
+  unsigned b = (unsigned)&gv;
+  unsigned c = (unsigned)&c_gv;
+  return a + b + c;
+}
Index: lib/CodeGen/CodeGenModule.h
===
--- lib/CodeGen/CodeGenModule.h
+++ lib/CodeGen/CodeGenModule.h
@@ -500,6 +500,9 @@
   /// MDNodes.
   llvm::DenseMap MetadataIdMap;
 
+  /// The relocaton model for ARM.
+  bool IsROPI, IsRWPI;
+
 public:
   CodeGenModule(ASTContext &C, const HeaderSearchOptions &headersearchopts,
 const PreprocessorOptions &ppopts,
@@ -1189,6 +1192,10 @@
   /// \param QT is the clang QualType of the null pointer.
   llvm::Constant *getNullPointer(llvm::PointerType *T, QualType QT);
 
+  /// Check if a static initialization is valid for ROPI/RWPI.
+  bool isValidInitForPI(const llvm::Constant *Init, StringRef GVName,
+SourceLocation Loc);
+
 private:
   llvm::Constant *
   GetOrCreateLLVMFunction(StringRef MangledName, llvm::Type *Ty, GlobalDecl D,
Index: lib/CodeGen/CodeGenModule.cpp
===
--- lib/CodeGen/CodeGenModule.cpp
+++ lib/CodeGen/CodeGenModule.cpp
@@ -159,6 +159,9 @@
   // CoverageMappingModuleGen object.
   if (CodeGenOpts.CoverageMapping)
 CoverageMapping.reset(new CoverageMappingModuleGen(*this, *CoverageInfo));
+
+  IsROPI = StringRef(CodeGenOpts.RelocationModel).startswith("ropi");
+  IsRWPI = StringRef(CodeGenOpts.RelocationModel).endswith("rwpi");
 }
 
 CodeGenModule::~CodeGenModule() {}
@@ -2505,6 +2508,49 @@
   GO.setComdat(TheModule.getOrInsertComdat(GO.getName()));
 }
 
+/// Check if the address of a GV is used in the Init expr and the consntness
+/// matches with IsROPI. If such a GV is used, returns it.
+static const llvm::Constant *UseAddrOfGlobalVar(const llvm::Constant *Init,
+bool IsROPI) {
+  if (!Init)
+return nullptr;
+  if (isa(Init)) {
+   

[PATCH] D28528: [PowerPC] [PowerPC] Fix the wrong implementation of builtin vec_rlnm.

[Tony Jiang via Phabricator via cfe-commits]

jtony created this revision.
jtony added reviewers: nemanjai, kbarton, sfertile, lei, syzaara.
jtony added subscribers: llvm-commits, cfe-commits, hfinkel, echristo.

vec_rlnm was implemented according to the old ABI, which was wrong. The ABI 
team have fixed the issue (although not published yet). We need to re-implement 
these builtins according to the new ABI.

From (old implementation):
__builtin_altivec_vrlwnm(__a, __b) & __c;

To (new implementation):
vector unsigned int OneByte = { 0x8, 0x8, 0x8, 0x8 };
__builtin_altivec_vrlwnm(a, ((c << OneByte) | b));


https://reviews.llvm.org/D28528

Files:
  lib/Headers/altivec.h
  test/CodeGen/builtins-ppc-p9vector.c


Index: test/CodeGen/builtins-ppc-p9vector.c
===
--- test/CodeGen/builtins-ppc-p9vector.c
+++ test/CodeGen/builtins-ppc-p9vector.c
@@ -868,20 +868,24 @@
   return vec_rlmi(vula, vula, vula);
 }
 vector unsigned int test77(void) {
+// CHECK-BE: %shl.i = shl <4 x i32
+// CHECK-BE: %or.i = or <4 x i32> %shl.i
 // CHECK-BE: @llvm.ppc.altivec.vrlwnm(<4 x i32
-// CHECK-BE: and <4 x i32
 // CHECK-BE: ret <4 x i32>
+// CHECK: %shl.i = shl <4 x i32
+// CHECK: %or.i = or <4 x i32> %shl.i
 // CHECK: @llvm.ppc.altivec.vrlwnm(<4 x i32
-// CHECK: and <4 x i32
 // CHECK: ret <4 x i32>
   return vec_rlnm(vuia, vuia, vuia);
 }
 vector unsigned long long test78(void) {
+// CHECK-BE: %shl.i = shl <2 x i64
+// CHECK-BE: %or.i = or <2 x i64> %shl.i
 // CHECK-BE: @llvm.ppc.altivec.vrldnm(<2 x i64
-// CHECK-BE: and <2 x i64
 // CHECK-BE-NEXT: ret <2 x i64>
+// CHECK: %shl.i = shl <2 x i64
+// CHECK: %or.i = or <2 x i64> %shl.i
 // CHECK: @llvm.ppc.altivec.vrldnm(<2 x i64
-// CHECK: and <2 x i64
 // CHECK-NEXT: ret <2 x i64>
   return vec_rlnm(vula, vula, vula);
 }
Index: lib/Headers/altivec.h
===
--- lib/Headers/altivec.h
+++ lib/Headers/altivec.h
@@ -7664,13 +7664,15 @@
 static __inline__ vector unsigned int __ATTRS_o_ai
 vec_rlnm(vector unsigned int __a, vector unsigned int __b,
  vector unsigned int __c) {
-  return __builtin_altivec_vrlwnm(__a, __b) & __c;
+  vector unsigned int OneByte = { 0x8, 0x8, 0x8, 0x8 };
+  return __builtin_altivec_vrlwnm(__a, ((__c << OneByte) | __b));
 }
 
 static __inline__ vector unsigned long long __ATTRS_o_ai
 vec_rlnm(vector unsigned long long __a, vector unsigned long long __b,
  vector unsigned long long __c) {
-  return __builtin_altivec_vrldnm(__a, __b) & __c;
+  vector unsigned long long OneByte = { 0x8, 0x8 };
+  return __builtin_altivec_vrldnm(__a, ((__c << OneByte) | __b));
 }
 #endif
 


Index: test/CodeGen/builtins-ppc-p9vector.c
===
--- test/CodeGen/builtins-ppc-p9vector.c
+++ test/CodeGen/builtins-ppc-p9vector.c
@@ -868,20 +868,24 @@
   return vec_rlmi(vula, vula, vula);
 }
 vector unsigned int test77(void) {
+// CHECK-BE: %shl.i = shl <4 x i32
+// CHECK-BE: %or.i = or <4 x i32> %shl.i
 // CHECK-BE: @llvm.ppc.altivec.vrlwnm(<4 x i32
-// CHECK-BE: and <4 x i32
 // CHECK-BE: ret <4 x i32>
+// CHECK: %shl.i = shl <4 x i32
+// CHECK: %or.i = or <4 x i32> %shl.i
 // CHECK: @llvm.ppc.altivec.vrlwnm(<4 x i32
-// CHECK: and <4 x i32
 // CHECK: ret <4 x i32>
   return vec_rlnm(vuia, vuia, vuia);
 }
 vector unsigned long long test78(void) {
+// CHECK-BE: %shl.i = shl <2 x i64
+// CHECK-BE: %or.i = or <2 x i64> %shl.i
 // CHECK-BE: @llvm.ppc.altivec.vrldnm(<2 x i64
-// CHECK-BE: and <2 x i64
 // CHECK-BE-NEXT: ret <2 x i64>
+// CHECK: %shl.i = shl <2 x i64
+// CHECK: %or.i = or <2 x i64> %shl.i
 // CHECK: @llvm.ppc.altivec.vrldnm(<2 x i64
-// CHECK: and <2 x i64
 // CHECK-NEXT: ret <2 x i64>
   return vec_rlnm(vula, vula, vula);
 }
Index: lib/Headers/altivec.h
===
--- lib/Headers/altivec.h
+++ lib/Headers/altivec.h
@@ -7664,13 +7664,15 @@
 static __inline__ vector unsigned int __ATTRS_o_ai
 vec_rlnm(vector unsigned int __a, vector unsigned int __b,
  vector unsigned int __c) {
-  return __builtin_altivec_vrlwnm(__a, __b) & __c;
+  vector unsigned int OneByte = { 0x8, 0x8, 0x8, 0x8 };
+  return __builtin_altivec_vrlwnm(__a, ((__c << OneByte) | __b));
 }
 
 static __inline__ vector unsigned long long __ATTRS_o_ai
 vec_rlnm(vector unsigned long long __a, vector unsigned long long __b,
  vector unsigned long long __c) {
-  return __builtin_altivec_vrldnm(__a, __b) & __c;
+  vector unsigned long long OneByte = { 0x8, 0x8 };
+  return __builtin_altivec_vrldnm(__a, ((__c << OneByte) | __b));
 }
 #endif
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D28080: [Docs][OpenCL] Added OpenCL feature description to user manual.

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added inline comments.



Comment at: docs/UsersManual.rst:2003
+ $ clang -target nvptx64-unknown-unknown test.cl
+ $ clang -target amdgcn-unknown-amdhsa test.cl
+

$ clang -target amdgcn-amd-amdhsa-opencl test.cl



Comment at: docs/UsersManual.rst:2053
+
+Disables standard target extensions. All OpenCL targets provide a list
+of extensions that they support. Clang allows to amend this using the 
``-cl-ext``

Maybe rephrase as "Disables support of OpenCL extensions" instead of "Disable 
standard target extensions" since "standard target extension" is confusing and 
also to avoid confusion with the effect of disabling OpenCL extension as in 
'#pragam OPENCL EXTENSION X: disable'. Disabling support of an extension means 
that they cannot be enabled by pragmas in the OpenCL kernels since they are 
deemed as non-supported.



Comment at: docs/UsersManual.rst:2107
+
+ $ clang -target -triple amdgcn-unknown-amdhsa test.cl
+

$ clang -target amdgcn-amd-amdhsa-opencl test.cl



Comment at: docs/UsersManual.rst:2154
+and modules (:doc:`Modules`) are used internally to improve the compilation
+speed.
+

To enable modules for OpenCL, add option `-fmodules -fimplicit-module-maps 
-fmodules-cache-path=X` where X is the directory for storing the generated 
modules.


https://reviews.llvm.org/D28080



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

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

Hmm, actually this does not work.  The definition of 
`_LIBCPP_THREAD_SAFETY_ANNOTATION` I moved from `__mutex_base` to `__config` is 
only enabled if `_LIBCPP_ENABLE_THREAD_SAFETY_ANNOTATIONS` is manually defined.

There must have been some reason to do it like this in `__mutex_base`, but for 
`__thread_support` we unconditionally need such a macro.  I will try defining 
them slightly differently in `__thread_support` only instead.


https://reviews.llvm.org/D28520



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

[PATCH] D28001: [X86] Teach Clang about -mfentry flag

[Nirav Dave via Phabricator via cfe-commits]

niravd updated this revision to Diff 83850.
niravd marked 2 inline comments as done.
niravd added a comment.

Address comments


https://reviews.llvm.org/D28001

Files:
  include/clang/Driver/Options.td
  include/clang/Frontend/CodeGenOptions.def
  lib/CodeGen/CodeGenFunction.cpp
  lib/Driver/Tools.cpp
  lib/Frontend/CompilerInvocation.cpp
  test/CodeGen/fentry.c


Index: test/CodeGen/fentry.c
===
--- /dev/null
+++ test/CodeGen/fentry.c
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -pg -mfentry -triple i386-unknown-unknown -emit-llvm -o - 
%s | FileCheck  %s
+// RUN: %clang_cc1 -pg -mfentry -triple x86_64-unknown-linux-gnu -emit-llvm -o 
- %s | FileCheck %s
+// RUN: %clang_cc1 -mfentry -triple i386-unknown-unknown -emit-llvm -o - %s | 
FileCheck -check-prefix=NOPG %s
+// RUN: %clang_cc1 -mfentry -triple x86_64-unknown-linux-gnu -emit-llvm -o - 
%s | FileCheck -check-prefix=NOPG %s
+
+int foo(void) {
+  return 0;
+}
+
+//CHECK: attributes #{{[0-9]+}} = { {{.*}}"fentry-call"="true"{{.*}} }
+//NOPG-NOT: attributes #{{[0-9]+}} = { {{.*}}"fentry-call"{{.*}} }
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -714,6 +714,7 @@
   Opts.XRayInstructionThreshold =
   getLastArgIntValue(Args, OPT_fxray_instruction_threshold_, 200, Diags);
   Opts.InstrumentForProfiling = Args.hasArg(OPT_pg);
+  Opts.CallFEntry = Args.hasArg(OPT_mfentry);
   Opts.EmitOpenCLArgMetadata = Args.hasArg(OPT_cl_kernel_arg_info);
   Opts.CompressDebugSections = Args.hasArg(OPT_compress_debug_sections);
   Opts.RelaxELFRelocations = Args.hasArg(OPT_mrelax_relocations);
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -5423,6 +5423,9 @@
   if (getToolChain().SupportsProfiling())
 Args.AddLastArg(CmdArgs, options::OPT_pg);
 
+  if (getToolChain().SupportsProfiling())
+Args.AddLastArg(CmdArgs, options::OPT_mfentry);
+
   // -flax-vector-conversions is default.
   if (!Args.hasFlag(options::OPT_flax_vector_conversions,
 options::OPT_fno_lax_vector_conversions))
Index: lib/CodeGen/CodeGenFunction.cpp
===
--- lib/CodeGen/CodeGenFunction.cpp
+++ lib/CodeGen/CodeGenFunction.cpp
@@ -852,8 +852,12 @@
   // inlining, we just add an attribute to insert a mcount call in backend.
   // The attribute "counting-function" is set to mcount function name which is
   // architecture dependent.
-  if (CGM.getCodeGenOpts().InstrumentForProfiling)
-Fn->addFnAttr("counting-function", getTarget().getMCountName());
+  if (CGM.getCodeGenOpts().InstrumentForProfiling) {
+if (CGM.getCodeGenOpts().CallFEntry)
+  Fn->addFnAttr("fentry-call", "true");
+else
+  Fn->addFnAttr("counting-function", getTarget().getMCountName());
+  }
 
   if (RetTy->isVoidType()) {
 // Void type; nothing to return.
Index: include/clang/Frontend/CodeGenOptions.def
===
--- include/clang/Frontend/CodeGenOptions.def
+++ include/clang/Frontend/CodeGenOptions.def
@@ -83,6 +83,7 @@
 VALUE_CODEGENOPT(XRayInstructionThreshold , 32, 200)
 
 CODEGENOPT(InstrumentForProfiling , 1, 0) ///< Set when -pg is enabled.
+CODEGENOPT(CallFEntry , 1, 0) ///< Set when -mfentry is enabled.
 CODEGENOPT(LessPreciseFPMAD  , 1, 0) ///< Enable less precise MAD instructions 
to
  ///< be generated.
 CODEGENOPT(PrepareForLTO , 1, 0) ///< Set when -flto is enabled on the
Index: include/clang/Driver/Options.td
===
--- include/clang/Driver/Options.td
+++ include/clang/Driver/Options.td
@@ -1746,6 +1746,8 @@
   Flags<[CC1Option]>,
   HelpText<"Use copy relocations support for PIE builds">;
 def mno_pie_copy_relocations : Flag<["-"], "mno-pie-copy-relocations">, 
Group;
+def mfentry : Flag<["-"], "mfentry">, HelpText<"insert calls to fentry at 
function entry">,
+  Flags<[CC1Option]>, Group;
 def mx87 : Flag<["-"], "mx87">, Group;
 def m80387 : Flag<["-"], "m80387">, Alias;
 def msse2 : Flag<["-"], "msse2">, Group;


Index: test/CodeGen/fentry.c
===
--- /dev/null
+++ test/CodeGen/fentry.c
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -pg -mfentry -triple i386-unknown-unknown -emit-llvm -o - %s | FileCheck  %s
+// RUN: %clang_cc1 -pg -mfentry -triple x86_64-unknown-linux-gnu -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -mfentry -triple i386-unknown-unknown -emit-llvm -o - %s | FileCheck -check-prefix=NOPG %s
+// RUN: %clang_cc1 -mfentry -triple x86_64-unknown-linux-gnu -emit-llvm -o - %s | FileCheck -check-prefix=NOPG %s
+
+int foo(void) {
+  return 0;
+}
+
+//CHECK: attributes #{{[0-9]+}} = {

[PATCH] D28001: [X86] Teach Clang about -mfentry flag

[Nirav Dave via Phabricator via cfe-commits]

niravd added inline comments.



Comment at: include/clang/Driver/Options.td:1731
 def mno_pie_copy_relocations : Flag<["-"], "mno-pie-copy-relocations">, 
Group;
+def mfentry : Flag<["-"], "mfentry">, HelpText<"insert calls to fentry at 
function entry">, Flags<[CC1Option]>, Group;
 def mx87 : Flag<["-"], "mx87">, Group;

mcrosier wrote:
> Should this not be in the m_x86_Features_Group since this is an x86 specific 
> flag?
Done. -mfentry should eventually defined for at least aarch64 but until that 
point we should have the flag match clang's actual capabilities.



Comment at: test/CodeGen/fentry.c:1
+// RUN: %clang_cc1 -pg -mfentry -triple i386-unknown-unknown -emit-llvm -o - 
%s | FileCheck -check-prefix=HAS %s
+// RUN: %clang_cc1 -pg -mfentry -triple x86_64-unknown-linux-gnu -emit-llvm -o 
- %s | FileCheck -check-prefix=HAS %s

mcrosier wrote:
> I want to say this test should be in test/Frontend directory since you're 
> testing a new CC1 option.
That seems reasonable, but I wanted to match with the mcount test. 


https://reviews.llvm.org/D28001



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

r291596 - Fix conversion index / argument index mismatch when diagnosing overload resolution failure.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Tue Jan 10 14:19:21 2017
New Revision: 291596

URL: http://llvm.org/viewvc/llvm-project?rev=291596&view=rev
Log:
Fix conversion index / argument index mismatch when diagnosing overload 
resolution failure.

Modified:
cfe/trunk/lib/Sema/SemaOverload.cpp
cfe/trunk/test/SemaTemplate/deduction.cpp

Modified: cfe/trunk/lib/Sema/SemaOverload.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaOverload.cpp?rev=291596&r1=291595&r2=291596&view=diff
==
--- cfe/trunk/lib/Sema/SemaOverload.cpp (original)
+++ cfe/trunk/lib/Sema/SemaOverload.cpp Tue Jan 10 14:19:21 2017
@@ -10490,56 +10490,42 @@ static void CompleteNonViableCandidate(S
   // operation somehow.
   bool SuppressUserConversions = false;
 
-  const FunctionProtoType *Proto;
-  unsigned ArgIdx = 0;
+  unsigned ConvIdx = 0;
+  ArrayRef ParamTypes;
 
   if (Cand->IsSurrogate) {
 QualType ConvType
   = Cand->Surrogate->getConversionType().getNonReferenceType();
 if (const PointerType *ConvPtrType = ConvType->getAs())
   ConvType = ConvPtrType->getPointeeType();
-Proto = ConvType->getAs();
-ArgIdx = 1;
+ParamTypes = ConvType->getAs()->getParamTypes();
+// Conversion 0 is 'this', which doesn't have a corresponding argument.
+ConvIdx = 1;
   } else if (Cand->Function) {
-Proto = Cand->Function->getType()->getAs();
+ParamTypes =
+Cand->Function->getType()->getAs()->getParamTypes();
 if (isa(Cand->Function) &&
-!isa(Cand->Function))
-  ArgIdx = 1;
+!isa(Cand->Function)) {
+  // Conversion 0 is 'this', which doesn't have a corresponding argument.
+  ConvIdx = 1;
+}
   } else {
-// Builtin binary operator with a bad first conversion.
+// Builtin operator.
 assert(ConvCount <= 3);
-for (unsigned ConvIdx = (Cand->IgnoreObjectArgument ? 1 : 0);
- ConvIdx != ConvCount; ++ConvIdx) {
-  if (Cand->Conversions[ConvIdx].isInitialized())
-continue;
-  if (Cand->BuiltinTypes.ParamTypes[ConvIdx]->isDependentType())
-Cand->Conversions[ConvIdx].setAsIdentityConversion(
-Args[ConvIdx]->getType());
-  else
-Cand->Conversions[ConvIdx] = TryCopyInitialization(
-S, Args[ConvIdx], Cand->BuiltinTypes.ParamTypes[ConvIdx],
-SuppressUserConversions,
-/*InOverloadResolution*/ true,
-/*AllowObjCWritebackConversion=*/
-S.getLangOpts().ObjCAutoRefCount);
-  // FIXME: If the conversion is bad, try to fix it.
-}
-return;
+ParamTypes = Cand->BuiltinTypes.ParamTypes;
   }
 
   // Fill in the rest of the conversions.
-  unsigned NumParams = Proto->getNumParams();
-  for (unsigned ConvIdx = (Cand->IgnoreObjectArgument ? 1 : 0);
-   ConvIdx != ConvCount; ++ConvIdx, ++ArgIdx) {
+  for (unsigned ArgIdx = 0; ConvIdx != ConvCount; ++ConvIdx, ++ArgIdx) {
 if (Cand->Conversions[ConvIdx].isInitialized()) {
-  // Found the bad conversion.
-} else if (ArgIdx < NumParams) {
-  if (Proto->getParamType(ArgIdx)->isDependentType())
+  // We've already checked this conversion.
+} else if (ArgIdx < ParamTypes.size()) {
+  if (ParamTypes[ArgIdx]->isDependentType())
 Cand->Conversions[ConvIdx].setAsIdentityConversion(
 Args[ArgIdx]->getType());
   else {
 Cand->Conversions[ConvIdx] =
-TryCopyInitialization(S, Args[ArgIdx], Proto->getParamType(ArgIdx),
+TryCopyInitialization(S, Args[ArgIdx], ParamTypes[ArgIdx],
   SuppressUserConversions,
   /*InOverloadResolution=*/true,
   /*AllowObjCWritebackConversion=*/

Modified: cfe/trunk/test/SemaTemplate/deduction.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaTemplate/deduction.cpp?rev=291596&r1=291595&r2=291596&view=diff
==
--- cfe/trunk/test/SemaTemplate/deduction.cpp (original)
+++ cfe/trunk/test/SemaTemplate/deduction.cpp Tue Jan 10 14:19:21 2017
@@ -383,6 +383,12 @@ namespace deduction_after_explicit_pack
   template struct X { X(int); operator int(); };
   template void p(T..., X, ...); // expected-note 
{{deduced conflicting}}
   void q() { p(X(0), 0); } // expected-error {{no match}}
+
+  struct A {
+template  void f(T, void *, int = 0); // expected-note {{no 
known conversion from 'double' to 'void *' for 2nd argument}}
+void f(); // expected-note {{requires 0}}
+  };
+  void f(A a) { a.f(1.0, 2.0); } // expected-error {{no match}}
 }
 
 namespace overload_vs_pack {


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

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

[Dimitry Andric via Phabricator via cfe-commits]

dim updated this revision to Diff 83851.
dim added a comment.

Let's try this simpler version instead.


https://reviews.llvm.org/D28520

Files:
  include/__threading_support


Index: include/__threading_support
===
--- include/__threading_support
+++ include/__threading_support
@@ -40,6 +40,12 @@
 #define _LIBCPP_THREAD_ABI_VISIBILITY inline _LIBCPP_INLINE_VISIBILITY
 #endif
 
+#if defined(__clang__) && __has_attribute(no_thread_safety_analysis)
+#define _LIBCPP_NO_THREAD_SAFETY_ANALYSIS 
__attribute__((no_thread_safety_analysis))
+#else
+#define _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
+#endif
+
 _LIBCPP_BEGIN_NAMESPACE_STD
 
 #if defined(_LIBCPP_HAS_THREAD_API_PTHREAD)
@@ -98,25 +104,25 @@
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_recursive_mutex_init(__libcpp_recursive_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 int __libcpp_recursive_mutex_lock(__libcpp_recursive_mutex_t *__m);
 
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_recursive_mutex_trylock(__libcpp_recursive_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 int __libcpp_recursive_mutex_unlock(__libcpp_recursive_mutex_t *__m);
 
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_recursive_mutex_destroy(__libcpp_recursive_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 int __libcpp_mutex_lock(__libcpp_mutex_t *__m);
 
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_mutex_trylock(__libcpp_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 int __libcpp_mutex_unlock(__libcpp_mutex_t *__m);
 
 _LIBCPP_THREAD_ABI_VISIBILITY
@@ -129,10 +135,10 @@
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_condvar_broadcast(__libcpp_condvar_t* __cv);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 int __libcpp_condvar_wait(__libcpp_condvar_t* __cv, __libcpp_mutex_t* __m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 int __libcpp_condvar_timedwait(__libcpp_condvar_t *__cv, __libcpp_mutex_t *__m,
timespec *__ts);
 


Index: include/__threading_support
===
--- include/__threading_support
+++ include/__threading_support
@@ -40,6 +40,12 @@
 #define _LIBCPP_THREAD_ABI_VISIBILITY inline _LIBCPP_INLINE_VISIBILITY
 #endif
 
+#if defined(__clang__) && __has_attribute(no_thread_safety_analysis)
+#define _LIBCPP_NO_THREAD_SAFETY_ANALYSIS __attribute__((no_thread_safety_analysis))
+#else
+#define _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
+#endif
+
 _LIBCPP_BEGIN_NAMESPACE_STD
 
 #if defined(_LIBCPP_HAS_THREAD_API_PTHREAD)
@@ -98,25 +104,25 @@
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_recursive_mutex_init(__libcpp_recursive_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 int __libcpp_recursive_mutex_lock(__libcpp_recursive_mutex_t *__m);
 
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_recursive_mutex_trylock(__libcpp_recursive_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 int __libcpp_recursive_mutex_unlock(__libcpp_recursive_mutex_t *__m);
 
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_recursive_mutex_destroy(__libcpp_recursive_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 int __libcpp_mutex_lock(__libcpp_mutex_t *__m);
 
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_mutex_trylock(__libcpp_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 int __libcpp_mutex_unlock(__libcpp_mutex_t *__m);
 
 _LIBCPP_THREAD_ABI_VISIBILITY
@@ -129,10 +135,10 @@
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_condvar_broadcast(__libcpp_condvar_t* __cv);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 int __libcpp_condvar_wait(__libcpp_condvar_t* __cv, __libcpp_mutex_t* __m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 int __libcpp_condvar_timedwait(__libcpp_condvar_t *__cv, __libcpp_mutex_t *__m,
timespec *__ts);
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits