Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain

[Todd Fiala via cfe-commits]

tfiala added a comment.

Ah nice. Thanks!

-Todd


Repository:
  rL LLVM

http://reviews.llvm.org/D13482



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

Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain

[Todd Fiala via cfe-commits]

Ah nice. Thanks!

-Todd

> On Oct 13, 2015, at 5:28 PM, Ed Maste  wrote:
> 
> emaste added a comment.
> 
>> Can we get this fixed or reversed out? Thanks!
> 
> 
> It's already reverted.
> 
> 
> Repository:
>  rL LLVM
> 
> http://reviews.llvm.org/D13482
> 
> 
> 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain

[Todd Fiala via cfe-commits]

tfiala added a subscriber: tfiala.
tfiala added a comment.

This change appears to have broken quite a few builders.

Can we get this fixed or reversed out?  Thanks!

http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA_build/7935/
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/7334
+ others.


Repository:
  rL LLVM

http://reviews.llvm.org/D13482



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

Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain

[Todd Fiala via cfe-commits]

tfiala added a comment.

Oh no worries, just wanted to make sure wasn't missed, that's all.

-Todd


Repository:
  rL LLVM

http://reviews.llvm.org/D13482



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

Re: [libcxx] r249738 - Split out of .

[Richard Smith via cfe-commits]

On Tue, Oct 13, 2015 at 6:54 PM, Sean Silva  wrote:

> On Tue, Oct 13, 2015 at 6:14 PM, Richard Smith 
> wrote:
>
>> On Tue, Oct 13, 2015 at 5:31 PM, Sean Silva 
>> wrote:
>>
>>> On Tue, Oct 13, 2015 at 3:17 PM, Richard Smith via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 On Tue, Oct 13, 2015 at 2:10 PM, Adrian Prantl via cfe-commits <
 cfe-commits@lists.llvm.org> wrote:

> Hi Richard,
>
> this commit appears to break the module self-host on Darwin.
>
> When compiling the following program generated by clang’s own cmake
> script:
>
> > #undef NDEBUG
> > #include 
> > #define NDEBUG
> > #include 
> > int main() { assert(this code is not compiled); }
>
> with clang++ -std=c++11 -fmodules -fcxx-modules test.cpp
>

 (You don't need -fcxx-modules here.)


> I get
>
> > While building module 'std' imported from /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:
> > While building module 'Darwin' imported from
> /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:
> > In file included from :98:
> > In file included from
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/wchar.h:92:
> > In file included from
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/_wctype.h:57:

 > /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/ctype.h:33:10:
> fatal error: cyclic dependency in module 'std': std -> Darwin -> std
> > #include <__config>
> >  ^
> > While building module 'std' imported from /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:
> > In file included from :1:
> > In file included from /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/algorithm:624:
> > In file included from /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/initializer_list:47
> :
> > /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:10:
> fatal error: could not build module 'Darwin'
> > #include 
> >  ^
> > In file included from test.cpp:2:
> > /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:10:
> fatal error: could not build module 'std'
> > #include <__config>
> >  ^
> > 3 errors generated.
>
> Let me know how I can help in diagnosing what’s going on here.
>

 OK, I see what's wrong. Is this working any better for you in r250236?

>>>
>>> We're still seeing:
>>>
>>> While building module 'Darwin' imported from /usr/include/assert.h:42:
>>> While building module 'std' imported from
>>> /path/to/build_cmake/stage1/bin/../include/c++/v1/math.h:309:
>>>
>>
>> Argh, this is including , which is in the std module. Can
>> you try removing the header "type_traits" line from the libc++ module map
>> and see if that helps?
>>
>
> I've run into this issue in the past, and I don't think that will fix it
> (see below). Just to be sure, here is the output with type_traits removed
> from the module map::
>
> While building module 'Darwin' imported from /usr/include/assert.h:42:
> While building module 'std' imported from
> /path/to/build_cmake/stage1/bin/../include/c++/v1/type_traits:211:
>

That's an include of . We'd need to apply this workaround to that
header too (but I think the buck stops there).

In file included from :1:
> In file included from
> /path/to/build_cmake/stage1/bin/../include/c++/v1/algorithm:624:
> In file included from
> /path/to/build_cmake/stage1/bin/../include/c++/v1/initializer_list:47:
> In file included from
> /path/to/build_cmake/stage1/bin/../include/c++/v1/cstddef:43:
> /path/to/build_cmake/stage1/bin/../include/c++/v1/stddef.h:46:15: fatal
> error: cyclic dependency in module 'Darwin': Darwin -> std -> Darwin
> #include_next 
>   ^
> While building module 'Darwin' imported from /usr/include/assert.h:42:
> In file included from :80:
> In file included from
> /path/to/build_cmake/stage1/bin/../lib/clang/3.8.0/include/tgmath.h:29:
> In file included from
> /path/to/build_cmake/stage1/bin/../include/c++/v1/math.h:309:
> /path/to/build_cmake/stage1/bin/../include/c++/v1/type_traits:211:10:
> fatal error: could not build module 'std'
> #include 
>  ^
> In file included from modules.cpp:2:
> In file included from
> /path/to/build_cmake/stage1/bin/../include/c++/v1/cassert:21:
> /usr/include/assert.h:42:10: fatal error: could not build module 'Darwin'
> #include 
>  ^
> 3 errors generated.
>
>
>
>> What we really need here 

Re: [PATCH] D10677: Allow deque to handle incomplete types

[Eric Fiselier via cfe-commits]

EricWF added a comment.

For the most part this looks good. I'm a touch concerned though about the 
changes to the static initialization. The initializer is moved from within the 
function body to outside it. Could you have somebody confirm this won't affect 
the existing ABI?



Comment at: include/__config:32
@@ -31,2 +31,3 @@
 #define _LIBCPP_ABI_ALTERNATE_STRING_LAYOUT
+#define _LIBCPP_ABI_INCOMPLETE_TYPES_IN_DEQUE
 #endif

I think we need a short explanation of ever option added here. In this case 
could you just link to the bug report and a short explanaition?

ex.
```
// Fix deques iterator type in order to support incomplete types. See 
http://llvm.org/bugs/...
#define _LIBCPP_ABI_INCOMPLETE_TYPES_IN_DEQUE
```



Comment at: include/deque:270
@@ -264,2 +269,3 @@
 template 
+  class _DiffType, _DiffType _BS =
+#ifdef _LIBCPP_ABI_INCOMPLETE_TYPES_IN_DEQUE

Please leave a note here explaining why the template parameter was kept even 
though its unused. 


Comment at: test/std/containers/sequences/deque/deque.cons/incomplete.pass.cpp:9
@@ +8,3 @@
+//===--===//
+
+// 

This test needs to go into `test/libcxx` not `test/std` because it's testing 
libc++ implementation details and not standard specified behavior. 




Repository:
  rL LLVM

http://reviews.llvm.org/D10677



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

r250270 - Remove the optimization option from this test as it is unnecessary

[Eric Christopher via cfe-commits]

Author: echristo
Date: Wed Oct 14 00:40:11 2015
New Revision: 250270

URL: http://llvm.org/viewvc/llvm-project?rev=250270=rev
Log:
Remove the optimization option from this test as it is unnecessary
and front end tests should avoid this if possible.

Modified:
cfe/trunk/test/CodeGen/fma-builtins.c

Modified: cfe/trunk/test/CodeGen/fma-builtins.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/fma-builtins.c?rev=250270=250269=250270=diff
==
--- cfe/trunk/test/CodeGen/fma-builtins.c (original)
+++ cfe/trunk/test/CodeGen/fma-builtins.c Wed Oct 14 00:40:11 2015
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 %s -O3 -triple=x86_64-apple-darwin -target-feature +fma 
-emit-llvm -o - | FileCheck %s
+// RUN: %clang_cc1 %s -triple=x86_64-apple-darwin -target-feature +fma 
-emit-llvm -o - | FileCheck %s
 
 // Don't include mm_malloc.h, it's system specific.
 #define __MM_MALLOC_H


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

r250265 - [MSVC] Fix for http://llvm.org/PR24132: __declspec(property): double invocations of foo() when compiling foo()->propertyName

[Alexey Bataev via cfe-commits]

Author: abataev
Date: Tue Oct 13 23:05:42 2015
New Revision: 250265

URL: http://llvm.org/viewvc/llvm-project?rev=250265=rev
Log:
[MSVC] Fix for http://llvm.org/PR24132: __declspec(property): double 
invocations of foo() when compiling foo()->propertyName
Removes extra codegen for base expression of MS property call
Differential Revision: http://reviews.llvm.org/D13375

Added:
cfe/trunk/test/CodeGenCXX/ms-property.cpp   (with props)
Modified:
cfe/trunk/lib/Sema/SemaPseudoObject.cpp

Modified: cfe/trunk/lib/Sema/SemaPseudoObject.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaPseudoObject.cpp?rev=250265=250264=250265=diff
==
--- cfe/trunk/lib/Sema/SemaPseudoObject.cpp (original)
+++ cfe/trunk/lib/Sema/SemaPseudoObject.cpp Tue Oct 13 23:05:42 2015
@@ -328,11 +328,12 @@ namespace {
 
  class MSPropertyOpBuilder : public PseudoOpBuilder {
MSPropertyRefExpr *RefExpr;
+   OpaqueValueExpr *InstanceBase;
 
  public:
MSPropertyOpBuilder(Sema , MSPropertyRefExpr *refExpr) :
  PseudoOpBuilder(S, refExpr->getSourceRange().getBegin()),
- RefExpr(refExpr) {}
+ RefExpr(refExpr), InstanceBase(nullptr) {}
 
Expr *rebuildAndCaptureObject(Expr *) override;
ExprResult buildGet() override;
@@ -1400,10 +1401,10 @@ ExprResult ObjCSubscriptOpBuilder::build
 
//===--===//
 
 Expr *MSPropertyOpBuilder::rebuildAndCaptureObject(Expr *syntacticBase) {
-  Expr *NewBase = capture(RefExpr->getBaseExpr());
+  InstanceBase = capture(RefExpr->getBaseExpr());
 
   syntacticBase =
-MSPropertyRefRebuilder(S, NewBase).rebuild(syntacticBase);
+MSPropertyRefRebuilder(S, InstanceBase).rebuild(syntacticBase);
 
   return syntacticBase;
 }
@@ -1420,10 +1421,10 @@ ExprResult MSPropertyOpBuilder::buildGet
   GetterName.setIdentifier(II, RefExpr->getMemberLoc());
   CXXScopeSpec SS;
   SS.Adopt(RefExpr->getQualifierLoc());
-  ExprResult GetterExpr = S.ActOnMemberAccessExpr(
-S.getCurScope(), RefExpr->getBaseExpr(), SourceLocation(),
-RefExpr->isArrow() ? tok::arrow : tok::period, SS, SourceLocation(),
-GetterName, nullptr);
+  ExprResult GetterExpr =
+  S.ActOnMemberAccessExpr(S.getCurScope(), InstanceBase, SourceLocation(),
+  RefExpr->isArrow() ? tok::arrow : tok::period, 
SS,
+  SourceLocation(), GetterName, nullptr);
   if (GetterExpr.isInvalid()) {
 S.Diag(RefExpr->getMemberLoc(),
diag::error_cannot_find_suitable_accessor) << 0 /* getter */
@@ -1450,10 +1451,10 @@ ExprResult MSPropertyOpBuilder::buildSet
   SetterName.setIdentifier(II, RefExpr->getMemberLoc());
   CXXScopeSpec SS;
   SS.Adopt(RefExpr->getQualifierLoc());
-  ExprResult SetterExpr = S.ActOnMemberAccessExpr(
-S.getCurScope(), RefExpr->getBaseExpr(), SourceLocation(),
-RefExpr->isArrow() ? tok::arrow : tok::period, SS, SourceLocation(),
-SetterName, nullptr);
+  ExprResult SetterExpr =
+  S.ActOnMemberAccessExpr(S.getCurScope(), InstanceBase, SourceLocation(),
+  RefExpr->isArrow() ? tok::arrow : tok::period, 
SS,
+  SourceLocation(), SetterName, nullptr);
   if (SetterExpr.isInvalid()) {
 S.Diag(RefExpr->getMemberLoc(),
diag::error_cannot_find_suitable_accessor) << 1 /* setter */

Added: cfe/trunk/test/CodeGenCXX/ms-property.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/ms-property.cpp?rev=250265=auto
==
--- cfe/trunk/test/CodeGenCXX/ms-property.cpp (added)
+++ cfe/trunk/test/CodeGenCXX/ms-property.cpp Tue Oct 13 23:05:42 2015
@@ -0,0 +1,19 @@
+// RUN: %clang_cc1 -emit-llvm -triple=x86_64-pc-win32 -fms-compatibility %s -o 
- | FileCheck %s
+
+class Test1 {
+private:
+  int x_;
+
+public:
+  Test1(int x) : x_(x) {}
+  __declspec(property(get = get_x)) int X;
+  int get_x() const { return x_; }
+  static Test1 *GetTest1() { return new Test1(10); }
+};
+
+// CHECK-LABEL: main
+int main(int argc, char **argv) {
+  // CHECK: [[CALL:%.+]] = call %class.Test1* 
@"\01?GetTest1@Test1@@SAPEAV1@XZ"()
+  // CHECK-NEXT: call i32 @"\01?get_x@Test1@@QEBAHXZ"(%class.Test1* [[CALL]])
+  return Test1::GetTest1()->X;
+}

Propchange: cfe/trunk/test/CodeGenCXX/ms-property.cpp
--
svn:eol-style = native

Propchange: cfe/trunk/test/CodeGenCXX/ms-property.cpp
--
svn:keywords = Author Date Id Rev URL

Propchange: cfe/trunk/test/CodeGenCXX/ms-property.cpp
--
svn:mime-type = text/plain


___
cfe-commits mailing list
cfe-commits@lists.llvm.org

Re: r250262 - I took care of the build problem in the commit 250252.

[Sean Silva via cfe-commits]

This is breaking llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast:
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/1358/steps/test/logs/stdio

On Tue, Oct 13, 2015 at 6:09 PM, Ekaterina Romanova via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: kromanova
> Date: Tue Oct 13 20:09:02 2015
> New Revision: 250262
>
> URL: http://llvm.org/viewvc/llvm-project?rev=250262=rev
> Log:
> I took care of the build problem in the commit 250252.
> Resubmitting the patch.
>
> This patch adds missing pieces to clang, including the PS4 toolchain
> definition, added warnings, PS4 defaults, and Driver changes needed for
> our compiler.
>
> A patch by Filipe Cabecinhas, Pierre Gousseau and Katya Romanova!
>
> Differential Revision: http://reviews.llvm.org/D13482
>
>
> Added:
> cfe/trunk/test/Driver/Inputs/scei-ps4_tree/target/include/.keep
>   - copied unchanged from r250256,
> cfe/trunk/test/Driver/Inputs/scei-ps4_tree/target/include/.keep
> cfe/trunk/test/Driver/Inputs/scei-ps4_tree/target/include_common/.keep
>   - copied unchanged from r250256,
> cfe/trunk/test/Driver/Inputs/scei-ps4_tree/target/include_common/.keep
> cfe/trunk/test/Driver/no-integrated-as.s
>   - copied unchanged from r250256,
> cfe/trunk/test/Driver/no-integrated-as.s
> cfe/trunk/test/Driver/ps4-header-search.c
>   - copied unchanged from r250256,
> cfe/trunk/test/Driver/ps4-header-search.c
> cfe/trunk/test/Driver/ps4-linker-non-win.c
>   - copied unchanged from r250256,
> cfe/trunk/test/Driver/ps4-linker-non-win.c
> cfe/trunk/test/Driver/ps4-linker-win.c
>   - copied unchanged from r250256,
> cfe/trunk/test/Driver/ps4-linker-win.c
> cfe/trunk/test/Driver/ps4-pic.c
>   - copied unchanged from r250256, cfe/trunk/test/Driver/ps4-pic.c
> cfe/trunk/test/Driver/ps4-sdk-root.c
>   - copied unchanged from r250256, cfe/trunk/test/Driver/ps4-sdk-root.c
> Modified:
> cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
> cfe/trunk/include/clang/Basic/DiagnosticGroups.td
> cfe/trunk/lib/Driver/Driver.cpp
> cfe/trunk/lib/Driver/ToolChains.cpp
> cfe/trunk/lib/Driver/ToolChains.h
> cfe/trunk/lib/Driver/Tools.cpp
> cfe/trunk/lib/Driver/Tools.h
> cfe/trunk/lib/Frontend/InitHeaderSearch.cpp
> cfe/trunk/test/Driver/debug-options.c
> cfe/trunk/test/Driver/stack-protector.c
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td?rev=250262=250261=250262=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td Tue Oct 13
> 20:09:02 2015
> @@ -196,4 +196,18 @@ def warn_target_unsupported_nan2008 : Wa
>  def warn_target_unsupported_nanlegacy : Warning<
>"ignoring '-mnan=legacy' option because the '%0' architecture does not
> support it">,
>InGroup;
> +
> +def warn_drv_unable_to_find_directory_expected : Warning<
> +  "unable to find %0 directory, expected to be in '%1'">,
> +  InGroup, DefaultIgnore;
> +
> +def warn_drv_ps4_force_pic : Warning<
> +  "option '%0' was ignored by the PS4 toolchain, using '-fPIC'">,
> +  InGroup;
> +
> +def warn_drv_ps4_sdk_dir : Warning<
> +  "environment variable SCE_PS4_SDK_DIR is set, but points to invalid or
> nonexistent directory '%0'">,
> +  InGroup;
> +
> +def err_drv_unsupported_linker : Error<"unsupported value '%0' for
> -linker option">;
>  }
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticGroups.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticGroups.td?rev=250262=250261=250262=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticGroups.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticGroups.td Tue Oct 13 20:09:02
> 2015
> @@ -823,3 +823,7 @@ def CudaCompat : DiagGroup<"cuda-compat"
>
>  // A warning group for things that will change semantics in the future.
>  def FutureCompat : DiagGroup<"future-compat">;
> +
> +def InvalidOrNonExistentDirectory :
> DiagGroup<"invalid-or-nonexistent-directory">;
> +
> +def OptionIgnored : DiagGroup<"option-ignored">;
>
> Modified: cfe/trunk/lib/Driver/Driver.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Driver.cpp?rev=250262=250261=250262=diff
>
> ==
> --- cfe/trunk/lib/Driver/Driver.cpp (original)
> +++ cfe/trunk/lib/Driver/Driver.cpp Tue Oct 13 20:09:02 2015
> @@ -2261,6 +2261,9 @@ const ToolChain ::getToolChain(co
>  case llvm::Triple::CUDA:
>TC = new toolchains::CudaToolChain(*this, Target, Args);
>break;
> +case llvm::Triple::PS4:
> +  TC = new toolchains::PS4CPU(*this, Target, Args);
> +  break;
> 

Re: [PATCH] D13375: [MSVC] Fix for http://llvm.org/PR24132: __declspec(property): double invocations of foo() when compiling foo()->propertyName

[Alexey Bataev via cfe-commits]

ABataev added a comment.

I see, no problems, thanks!

Best regards,

Alexey Bataev
=

Software Engineer
Intel Compiler Team
Intel Corp.


http://reviews.llvm.org/D13375



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

Re: [PATCH] D13336: [MSVC] 'property' with an empty array in array subscript expression.

[Alexey Bataev via cfe-commits]

ABataev added a comment.

In http://reviews.llvm.org/D13336#257628, @rnk wrote:

> I think fundamentally we are doing too much declspec property lowering in 
> Sema. We might want to back up and figure out how to do it in IRGen. Right 
> now we have bugs like this, which are probably more important than new 
> functionality:
>  https://llvm.org/bugs/show_bug.cgi?id=24132


Currently declspec property is represented as a member function call and does 
not keep info about property itself. Array subscripts exprs add arguments to 
this member function call and it must be built in Sema, so we could use an 
existing codegen for CallExprs.


http://reviews.llvm.org/D13336



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

r250271 - Canonicalize some of the x86 builtin tests and either remove or comment

[Eric Christopher via cfe-commits]

Author: echristo
Date: Wed Oct 14 00:40:21 2015
New Revision: 250271

URL: http://llvm.org/viewvc/llvm-project?rev=250271=rev
Log:
Canonicalize some of the x86 builtin tests and either remove or comment
about optimization options.

Modified:
cfe/trunk/test/CodeGen/3dnow-builtins.c
cfe/trunk/test/CodeGen/avx-builtins.c
cfe/trunk/test/CodeGen/avx-cmp-builtins.c
cfe/trunk/test/CodeGen/avx-shuffle-builtins.c
cfe/trunk/test/CodeGen/avx2-builtins.c
cfe/trunk/test/CodeGen/avx512bw-builtins.c
cfe/trunk/test/CodeGen/avx512cdintrin.c
cfe/trunk/test/CodeGen/avx512dq-builtins.c
cfe/trunk/test/CodeGen/avx512er-builtins.c
cfe/trunk/test/CodeGen/avx512f-builtins.c
cfe/trunk/test/CodeGen/avx512vl-builtins.c
cfe/trunk/test/CodeGen/avx512vlbw-builtins.c
cfe/trunk/test/CodeGen/avx512vldq-builtins.c
cfe/trunk/test/CodeGen/bmi2-builtins.c
cfe/trunk/test/CodeGen/f16c-builtins.c
cfe/trunk/test/CodeGen/fma4-builtins.c
cfe/trunk/test/CodeGen/fsgsbase-builtins.c
cfe/trunk/test/CodeGen/lzcnt-builtins.c
cfe/trunk/test/CodeGen/mmx-builtins.c
cfe/trunk/test/CodeGen/pclmul-builtins.c
cfe/trunk/test/CodeGen/popcnt-builtins.c
cfe/trunk/test/CodeGen/rtm-builtins.c
cfe/trunk/test/CodeGen/sha-builtins.c
cfe/trunk/test/CodeGen/sse.c
cfe/trunk/test/CodeGen/sse3-builtins.c
cfe/trunk/test/CodeGen/sse41-builtins.c
cfe/trunk/test/CodeGen/sse42-builtins.c
cfe/trunk/test/CodeGen/sse4a-builtins.c
cfe/trunk/test/CodeGen/ssse3-builtins.c
cfe/trunk/test/CodeGen/tbm-builtins.c
cfe/trunk/test/CodeGen/xop-builtins.c

Modified: cfe/trunk/test/CodeGen/3dnow-builtins.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/3dnow-builtins.c?rev=250271=250270=250271=diff
==
--- cfe/trunk/test/CodeGen/3dnow-builtins.c (original)
+++ cfe/trunk/test/CodeGen/3dnow-builtins.c Wed Oct 14 00:40:21 2015
@@ -1,6 +1,6 @@
 // REQUIRES: x86-registered-target
-// RUN: %clang_cc1 %s -O0 -triple=x86_64-unknown-unknown -target-feature 
+3dnow -emit-llvm -o - -Werror | FileCheck %s
-// RUN: %clang_cc1 %s -O0 -triple=x86_64-unknown-unknown -target-feature 
+3dnow -S -o - -Werror | FileCheck %s --check-prefix=CHECK-ASM
+// RUN: %clang_cc1 %s -triple=x86_64-unknown-unknown -target-feature +3dnow 
-emit-llvm -o - -Werror | FileCheck %s
+// RUN: %clang_cc1 %s -triple=x86_64-unknown-unknown -target-feature +3dnow -S 
-o - -Werror | FileCheck %s --check-prefix=CHECK-ASM
 
 // Don't include mm_malloc.h, it's system specific.
 #define __MM_MALLOC_H

Modified: cfe/trunk/test/CodeGen/avx-builtins.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/avx-builtins.c?rev=250271=250270=250271=diff
==
--- cfe/trunk/test/CodeGen/avx-builtins.c (original)
+++ cfe/trunk/test/CodeGen/avx-builtins.c Wed Oct 14 00:40:21 2015
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 %s -O3 -triple=x86_64-apple-darwin -target-feature +avx 
-emit-llvm -o - | FileCheck %s
+// RUN: %clang_cc1 %s -triple=x86_64-apple-darwin -target-feature +avx 
-emit-llvm -o - | FileCheck %s
 
 // Don't include mm_malloc.h, it's system specific.
 #define __MM_MALLOC_H
@@ -96,19 +96,22 @@ int test_mm_cmpistrz(__m128i A, __m128i
 
 int test_extract_epi32(__m256i __a) {
   // CHECK-LABEL: @test_extract_epi32
-  // CHECK: extractelement <8 x i32> %{{.*}}, i32 0
+  // CHECK: [[SHIFT1:%[^ ]+]] = and i32 %{{.*}}, 7
+  // CHECK: extractelement <8 x i32> %{{.*}}, i32 [[SHIFT1]]
   return _mm256_extract_epi32(__a, 8);
 }
 
 int test_extract_epi16(__m256i __a) {
   // CHECK-LABEL: @test_extract_epi16
-  // CHECK: extractelement <16 x i16> %{{.*}}, i32 0
+  // CHECK: [[SHIFT2:%[^ ]+]] = and i32 %{{.*}}, 15
+  // CHECK: extractelement <16 x i16> %{{.*}}, i32 [[SHIFT2]]
   return _mm256_extract_epi16(__a, 16);
 }
 
 int test_extract_epi8(__m256i __a) {
   // CHECK-LABEL: @test_extract_epi8
-  // CHECK: extractelement <32 x i8> %{{.*}}, i32 0
+  // CHECK: [[SHIFT3:%[^ ]+]] = and i32 %{{.*}}, 31
+  // CHECK: extractelement <32 x i8> %{{.*}}, i32 [[SHIFT3]]
   return _mm256_extract_epi8(__a, 32);
 }
 

Modified: cfe/trunk/test/CodeGen/avx-cmp-builtins.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/avx-cmp-builtins.c?rev=250271=250270=250271=diff
==
--- cfe/trunk/test/CodeGen/avx-cmp-builtins.c (original)
+++ cfe/trunk/test/CodeGen/avx-cmp-builtins.c Wed Oct 14 00:40:21 2015
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 %s -O3 -triple=x86_64-apple-darwin -target-feature +avx 
-emit-llvm -o - | FileCheck %s
+// FIXME: The shufflevector instructions in test_cmpgt_sd are relying on O3 
here.
 
 // Don't include mm_malloc.h, it's system specific.
 #define __MM_MALLOC_H

Modified: cfe/trunk/test/CodeGen/avx-shuffle-builtins.c
URL: 

Re: [PATCH] D13014: [X86] Add XSAVE intrinsics (Clang part)

[Elena Demikhovsky via cfe-commits]

delena added a comment.

You should add the "xsave" features to all appropriate CPUs. It can be done in 
a separate patch.
LGTM.


Repository:
  rL LLVM

http://reviews.llvm.org/D13014



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

Re: [PATCH] D13590: Support every kind of initialization.

[Manuel Klimek via cfe-commits]

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

lg



Comment at: clang-tidy/modernize/MakeUniqueCheck.cpp:125-128
@@ +124,6 @@
+  // Direct initialization with initialization list.
+  // \code
+  //   struct S { S(int x) {} };
+  //   std::unique_ptr(new S{5});
+  // \endcode
+  // The arguments in the initialization list are going to be forwarded to

Nit: this is not a doxygen comment, so \code \endcode doesn't make too much 
sense; just leave them out. (here and elsewhere)


http://reviews.llvm.org/D13590



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

Re: [PATCH] D13640: [clang-tidy] Add new check cppcoreguidelines-pro-bounds-array-to-pointer-decay

[Manuel Klimek via cfe-commits]

klimek added a subscriber: klimek.


Comment at: 
clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.cpp:40
@@ +39,3 @@
+
+  diag(MatchedCast->getExprLoc(), "do not (implicitly) convert an array to a 
pointer");
+}

Can't we provide a fixit?


http://reviews.llvm.org/D13640



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

Re: [PATCH] D10599: [OPENMP 4.0] Initial support for '#pragma omp declare simd' directive.

[Alexey Bataev via cfe-commits]

ABataev updated this revision to Diff 37218.
ABataev marked 3 inline comments as done.
ABataev added a comment.

Update after review


http://reviews.llvm.org/D10599

Files:
  include/clang/Basic/Attr.td
  include/clang/Basic/AttrDocs.td
  include/clang/Basic/DiagnosticParseKinds.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/OpenMPKinds.def
  include/clang/Parse/Parser.h
  include/clang/Sema/Sema.h
  lib/Basic/OpenMPKinds.cpp
  lib/Parse/ParseDecl.cpp
  lib/Parse/ParseDeclCXX.cpp
  lib/Parse/ParseOpenMP.cpp
  lib/Parse/Parser.cpp
  lib/Sema/SemaOpenMP.cpp
  test/OpenMP/declare_simd_ast_print.c
  test/OpenMP/declare_simd_ast_print.cpp
  test/OpenMP/declare_simd_messages.cpp

Index: lib/Parse/Parser.cpp
===
--- lib/Parse/Parser.cpp
+++ lib/Parse/Parser.cpp
@@ -656,8 +656,10 @@
   case tok::annot_pragma_opencl_extension:
 HandlePragmaOpenCLExtension();
 return DeclGroupPtrTy();
-  case tok::annot_pragma_openmp:
-return ParseOpenMPDeclarativeDirective();
+  case tok::annot_pragma_openmp: {
+AccessSpecifier AS = AS_none;
+return ParseOpenMPDeclarativeDirectiveWithExtDecl(AS, attrs);
+  }
   case tok::annot_pragma_ms_pointers_to_members:
 HandlePragmaMSPointersToMembers();
 return DeclGroupPtrTy();
Index: lib/Parse/ParseOpenMP.cpp
===
--- lib/Parse/ParseOpenMP.cpp
+++ lib/Parse/ParseOpenMP.cpp
@@ -31,6 +31,7 @@
   // E.g.: OMPD_for OMPD_simd ===> OMPD_for_simd
   // TODO: add other combined directives in topological order.
   const OpenMPDirectiveKind F[][3] = {
+  {OMPD_unknown /*declare*/, OMPD_simd, OMPD_declare_simd},
   {OMPD_unknown /*cancellation*/, OMPD_unknown /*point*/,
OMPD_cancellation_point},
   {OMPD_target, OMPD_unknown /*data*/, OMPD_target_data},
@@ -48,11 +49,12 @@
   for (unsigned i = 0; i < llvm::array_lengthof(F); ++i) {
 if (!Tok.isAnnotation() && DKind == OMPD_unknown) {
   TokenMatched =
-  (i == 0) &&
-  !P.getPreprocessor().getSpelling(Tok).compare("cancellation");
-} else {
+  ((i == 0) &&
+   !P.getPreprocessor().getSpelling(Tok).compare("declare")) ||
+  ((i == 1) &&
+   !P.getPreprocessor().getSpelling(Tok).compare("cancellation"));
+} else
   TokenMatched = DKind == F[i][0] && DKind != OMPD_unknown;
-}
 
 if (TokenMatched) {
   Tok = P.getPreprocessor().LookAhead(0);
@@ -64,12 +66,11 @@
 
   if (!TokenIsAnnotation && SDKind == OMPD_unknown) {
 TokenMatched =
-((i == 0) &&
+((i == 1) &&
  !P.getPreprocessor().getSpelling(Tok).compare("point")) ||
-((i == 1) && !P.getPreprocessor().getSpelling(Tok).compare("data"));
-  } else {
+((i == 2) && !P.getPreprocessor().getSpelling(Tok).compare("data"));
+  } else
 TokenMatched = SDKind == F[i][1] && SDKind != OMPD_unknown;
-  }
 
   if (TokenMatched) {
 P.ConsumeToken();
@@ -84,8 +85,16 @@
 ///
 ///   threadprivate-directive:
 /// annot_pragma_openmp 'threadprivate' simple-variable-list
+/// annot_pragma_omp_end
 ///
-Parser::DeclGroupPtrTy Parser::ParseOpenMPDeclarativeDirective() {
+///   declare-simd-directive:
+/// annot_pragma_openmp 'declare simd' { [,]}
+/// annot_pragma_omp_end
+/// 
+///
+Parser::DeclGroupPtrTy Parser::ParseOpenMPDeclarativeDirectiveWithExtDecl(
+AccessSpecifier , ParsedAttributesWithRange ,
+DeclSpec::TST TagType, Decl *TagDecl) {
   assert(Tok.is(tok::annot_pragma_openmp) && "Not an OpenMP directive!");
   ParenBraceBracketBalancer BalancerRAIIObj(*this);
 
@@ -109,6 +118,48 @@
   return Actions.ActOnOpenMPThreadprivateDirective(Loc, Identifiers);
 }
 break;
+  case OMPD_declare_simd: {
+// The syntax is:
+// { #pragma omp declare simd }
+// 
+//
+
+ConsumeToken();
+// The last seen token is annot_pragma_openmp_end - need to check for
+// extra tokens.
+if (Tok.isNot(tok::annot_pragma_openmp_end)) {
+  Diag(Tok, diag::warn_omp_extra_tokens_at_eol)
+  << getOpenMPDirectiveName(OMPD_declare_simd);
+  while (Tok.isNot(tok::annot_pragma_openmp_end))
+ConsumeAnyToken();
+}
+// Skip the last annot_pragma_openmp_end.
+ConsumeToken();
+
+DeclGroupPtrTy Ptr;
+if (Tok.is(tok::annot_pragma_openmp)) {
+  Ptr = ParseOpenMPDeclarativeDirectiveWithExtDecl(AS, Attrs, TagType,
+   TagDecl);
+} else if (Tok.isNot(tok::r_brace) && !isEofOrEom()) {
+  // Here we expect to see some function declaration.
+  if (AS == AS_none) {
+assert(TagType == DeclSpec::TST_unspecified);
+MaybeParseCXX11Attributes(Attrs);
+MaybeParseMicrosoftAttributes(Attrs);
+ParsingDeclSpec PDS(*this);
+Ptr = 

Re: [PATCH] D10833: Retrieve BinaryOperator::getOpcode and BinaryOperator::getOpcodeStr via libclang and its python interface

[Manuel Klimek via cfe-commits]

klimek added a reviewer: milianw.
klimek added a comment.

+milian - can you take a look at this patch (or do you know somebody who might 
be in a good position to review)


http://reviews.llvm.org/D10833



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

Re: [PATCH] D12686: Add support for GCC's '__auto_type' extension.

[Nicholas Allegra via cfe-commits]

comex added inline comments.


Comment at: lib/Sema/SemaType.cpp:2654-2655
@@ -2648,4 +2653,4 @@
 case Declarator::ConversionIdContext:
   if (!SemaRef.getLangOpts().CPlusPlus14)
-Error = 12; // conversion-type-id
+Error = 14; // conversion-type-id
   break;

rsmith wrote:
> Do you really want to allow `__auto_type` here? This is inconsistent with 
> what you do for return types.
Also a mistake.


Comment at: test/SemaCXX/auto-type-from-cxx.cpp:14
@@ +13,3 @@
+  auto _ = [](__auto_type f) {}; // expected-error {{'__auto_type' not allowed 
in lambda parameter}}
+  __auto_type g = 2;
+  struct BitField { int field:2; };

thakis wrote:
> Shouldn't this say "warning: __auto_type is a gnu extension" (since this uses 
> -std=c++14, not -std=gnu++14)?
Hmm... when I added `ext_auto_type` to the .td, I didn't notice the difference 
between Extension and ExtWarn.  Since the patch currently uses Extension, it 
won't warn by default, but will with `-pedantic`, `-Wgnu`, or 
`-Wgnu-auto-type`.  The C test uses `-pedantic` so it gets the warning.

Is there an explicit policy on which extensions should be ExtWarn?  Looking at 
the rest of that file, ExtWarns seem to be mostly either (a) standardized 
extensions (which will warn if `-std` is too early) and (b) 'extensions' that 
are more like "Clang will accept your buggy code" than features.  Most GNU 
extensions are just Extension, so I think it makes sense to do the same for 
`__auto_type`.

I could update the C++ test to add `-pedantic`, but arguably it makes more 
sense to test the fact that the warning is not emitted by default.


http://reviews.llvm.org/D12686



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

Re: [PATCH] D12359: New warning -Wnonconst-parameter when a pointer parameter can be const

[Daniel Marjamäki via cfe-commits]

danielmarjamaki updated this revision to Diff 37223.
danielmarjamaki added a comment.

Minor cleanups and refactorings


http://reviews.llvm.org/D12359

Files:
  include/clang/AST/Decl.h
  include/clang/Basic/DiagnosticGroups.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Parse/Parser.h
  include/clang/Sema/Sema.h
  lib/AST/Decl.cpp
  lib/Parse/ParseExpr.cpp
  lib/Parse/ParseStmt.cpp
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaLambda.cpp
  lib/Sema/SemaOpenMP.cpp
  lib/Sema/SemaTemplateInstantiateDecl.cpp
  lib/Serialization/ASTReaderDecl.cpp
  test/Sema/warn-nonconst-parameter.c
  test/SemaCXX/warn-nonconst-parameter.cpp

Index: test/SemaCXX/warn-nonconst-parameter.cpp
===
--- test/SemaCXX/warn-nonconst-parameter.cpp
+++ test/SemaCXX/warn-nonconst-parameter.cpp
@@ -0,0 +1,44 @@
+// RUN: %clang_cc1 -fsyntax-only -Wnonconst-parameter -verify %s
+//
+// Test that -Wnonconst-parameter does not warn for virtual functions.
+//
+
+// expected-no-diagnostics
+
+class Base {
+public:
+  virtual int f(int*p);
+};
+
+class Derived : public Base {
+public:
+  // Don't warn on inherited virtual function
+  virtual int f(int *p) { return 0; }
+
+  // Don't warn on non-inherited virtual function
+  virtual int g(int *p) { return 0; }
+};
+
+class Fred {
+private:
+  void *X;
+public:
+  Fred(void *X) : X(X) {}
+  void dostuff();
+};
+
+static Fred& dontwarn1(void *P) {
+  return *static_cast(P);
+}
+
+static void dontwarn2(void *P) {
+  ((Fred*)P)->dostuff();
+}
+
+
+// Don't warn when data is passed to nonconst reference parameter
+void dostuff(int );
+void dontwarn19(int *p) {
+  dostuff(*p);
+}
+
Index: test/Sema/warn-nonconst-parameter.c
===
--- test/Sema/warn-nonconst-parameter.c
+++ test/Sema/warn-nonconst-parameter.c
@@ -0,0 +1,125 @@
+// RUN: %clang_cc1 -fsyntax-only -Wnonconst-parameter -verify %s
+
+// Currently the -Wnonconst-parameter only warns about pointer arguments.
+//
+// It can be defined both that the data is const and that the pointer is const,
+// the -Wnonconst-parameter only checks if the data can be const-specified.
+//
+// It does not warn about pointers to records or function pointers.
+
+// Some external function where first argument is nonconst and second is const.
+char* strcpy1(char *dest, const char *src);
+unsigned my_strcpy(char *buf, const char *s);
+unsigned my_strlen(const char *buf);
+
+
+int warn1(int *p) { // expected-warning {{parameter 'p' can be const}}
+  return *p;
+}
+
+void warn2(int *first, int *last) { // expected-warning {{parameter 'last' can be const}}
+  *first = 0;
+  if (first < last) {} // <- last can be const
+}
+
+void warn3(char *p) { // expected-warning {{parameter 'p' can be const}}
+  char buf[10];
+  strcpy1(buf, p);
+}
+
+int dontwarn1(const int *p) {
+  return *p;
+}
+
+void dontwarn2(int *p) {
+  *p = 0;
+}
+
+void dontwarn3(char *p) {
+  p[0] = 0;
+}
+
+void dontwarn4(int *p) {
+  int *q = p;
+  *q = 0;
+}
+
+void dontwarn5(float *p) {
+  int *q = (int *)p;
+}
+
+void dontwarn6(char *p) {
+  char *a, *b;
+  a = b = p;
+}
+
+void dontwarn7(int *p) {
+  int *i = p ? p : 0;
+}
+
+void dontwarn8(char *p) {
+  char *x;
+  x = (p ? p : "");
+}
+
+char *dontwarn9(char *p) {
+  char *x;
+  return p ? p : "";
+}
+
+void dontwarn10(int *p) {
+  ++(*p);
+}
+
+char dontwarn11(int *p) {
+  return ++(*p);
+}
+
+char *dontwarn12(char *s) {
+  return s;
+}
+
+void dontwarn13(unsigned char *str, const unsigned int i) {
+unsigned char *p;
+for (p = str + i; *p; ) {}
+}
+
+void dontwarn14(int *buf) {
+  int i, *p;
+  for (i=0, p=buf; i<10; i++, p++) {
+*p = 1;
+  }
+}
+
+void dontwarn15(int *p, int x) {
+for (int *q = p+x-1; 0; q++);
+}
+
+void dontwarn16(char *p) {
+  strcpy1(p, "abc");
+}
+
+void dontwarn17(char *p) {
+  strcpy1(p+2, "abc");
+}
+
+
+char *dontwarn18(char *p) {
+  return strcpy1(p, "abc");
+}
+
+unsigned dontwarn19(char *buf) {
+  unsigned len = my_strlen(buf);
+  return len + my_strcpy(buf, "abc");
+}
+
+// Don't warn about nonconst function pointers that can be const.
+void functionpointer(double f(double), int x) {
+  f(x);
+}
+
+// Don't warn about nonconst record pointers that can be const.
+struct XY { int x; int y; };
+int recordpointer(struct XY *xy) {
+  return xy->x;
+}
Index: lib/Serialization/ASTReaderDecl.cpp
===
--- lib/Serialization/ASTReaderDecl.cpp
+++ lib/Serialization/ASTReaderDecl.cpp
@@ -501,6 +501,8 @@
   D->setImplicit(Record[Idx++]);
   D->Used = Record[Idx++];
   D->setReferenced(Record[Idx++]);
+  if (auto *VD = dyn_cast(D))
+VD->setNonConstUse();
   D->setTopLevelDeclInObjCContainer(Record[Idx++]);
   D->setAccess((AccessSpecifier)Record[Idx++]);
   D->FromASTFile = true;
Index: lib/Sema/SemaTemplateInstantiateDecl.cpp

Re: [PATCH] D12686: Add support for GCC's '__auto_type' extension.

[Nicholas Allegra via cfe-commits]

comex added inline comments.


Comment at: lib/Sema/SemaType.cpp:2675-2678
@@ -2671,5 +2674,6 @@
   break;
 case Declarator::ConversionIdContext:
-  if (!SemaRef.getLangOpts().CPlusPlus14)
-Error = 12; // conversion-type-id
+  if (!SemaRef.getLangOpts().CPlusPlus14 ||
+  D.getDeclSpec().getTypeSpecType() == DeclSpec::TST_auto_type)
+Error = 14; // conversion-type-id
   break;

(Clarification: The "also a mistake" comment was meant to be submitted earlier, 
but was left in the Phabricator draft state; I already fixed this.)


http://reviews.llvm.org/D12686



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

Re: [PATCH] D10599: [OPENMP 4.0] Initial support for '#pragma omp declare simd' directive.

[Alexey Bataev via cfe-commits]

ABataev marked 3 inline comments as done.


Comment at: include/clang/Basic/Attr.td:2098-2102
@@ +2097,7 @@
+  let Documentation = [OMPDeclareSimdDocs];
+  let AdditionalMembers = [{
+  void printPrettyPragma(raw_ostream , const PrintingPolicy ) const {
+OS << "\n";
+  }
+  }];
+}

rsmith wrote:
> Can we instead handle this in the generated code? Presumably we'd get this 
> wrong in the same way for all attributes with pragma spelling?
Done.


Comment at: lib/Parse/ParseOpenMP.cpp:133
@@ +132,3 @@
+  << getOpenMPDirectiveName(OMPD_declare_simd);
+  if (!SkipUntil(tok::annot_pragma_openmp_end, StopBeforeMatch))
+return DeclGroupPtrTy();

rsmith wrote:
> Hmm, on reflection it would be better to use:
> 
>   while (Tok.isNot(tok::annot_pragma_openmp_end))
> ConsumeAnyToken();
> 
> We know that there is an `annot_pragma_openmp_end` token coming, but 
> `SkipUntil` might stop early if there's (say) a stray right-paren in the 
> token stream.
Done, thanks.


Comment at: lib/Parse/ParseOpenMP.cpp:144-145
@@ +143,4 @@
+} else {
+  // Here we expect to see some function declaration.
+  while (Tok.isNot(tok::r_brace) && !isEofOrEom() && !Ptr) {
+if (AS == AS_none) {

rsmith wrote:
> I don't think your example is reasonable to accept. Right now (prior to your 
> patch), we have two fundamentally different kinds of pragmas:
> 
> 1) Lexer-level pragmas. These can appear anywhere in the token stream, and 
> take effect immediately. These are handled entirely by the lexer.
> 
> 2) Declaration-like pragmas. These can only appear where a declaration is 
> permitted, and act as if they declare ... something. We transform these into 
> tokens and handle them in the parser.
> 
> You're adding a third kind of pragma, an attribute-like pragma, that can only 
> appear before declarations. As such, if your pragma appears before a pragma 
> of kind 2 (such as `#pragma GCC visibility`), it should act as an attribute 
> applying to *that* declaration-like entity.
> 
> So I think the only thing you should allow between your pragma and the 
> declaration to which it applies is more attribute-like pragmas.
Reworked.


http://reviews.llvm.org/D10599



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

Re: [PATCH] D13516: Fix overlapping replacements in clang-tidy.

[Manuel Klimek via cfe-commits]

klimek added inline comments.


Comment at: clang-tidy/ClangTidyDiagnosticConsumer.cpp:418-419
@@ +417,4 @@
+unsigned Pos;
+int Type;
+int ErrorId;
+  };

These need to be documented.


Comment at: clang-tidy/ClangTidyDiagnosticConsumer.cpp:421
@@ +420,3 @@
+  };
+  std::priority_queue Pq;
+  for (const auto  : First) {

I'd name this Queue instead (reading later I had no idea what this was).


Comment at: clang-tidy/ClangTidyDiagnosticConsumer.cpp:433-436
@@ +432,6 @@
+  int Count[2] = {0, 0};
+  // Sit[1][0] will tell if there exists any range that is covered by the
+  // first set but not by the second one, Sit[1][1] will tell if there is a
+  // range covered by both sets, etc.
+  bool Sit[2][2] = {{false, false}, {false, false}};
+

Why are you calling this "Sit"?


Comment at: clang-tidy/ClangTidyDiagnosticConsumer.cpp:475
@@ +474,3 @@
+}
+std::sort(Intervals.begin(), Intervals.end());
+IntervalsList.push_back(std::move(Intervals));

Why do we need to sort?



http://reviews.llvm.org/D13516



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

Re: [PATCH] D13388: Add support for querying the visibility of a cursor

[Manuel Klimek via cfe-commits]

klimek added a subscriber: klimek.
klimek added a reviewer: milianw.
klimek added a comment.

This LG, looping in Milian for a second opinion / to find more reviewers :)


http://reviews.llvm.org/D13388



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

Re: [PATCH] D12407: [clang-format-vs] Add an option to reformat source code when file is saved to disk

[Manuel Klimek via cfe-commits]

klimek added reviewers: aaron.ballman, rnk.
klimek added a comment.

+aaron for windows specific knowledge
+rnk to see whether we can get a reviewer with more MS VS experience (perhaps 
somebody from MS :)

My main concern is that this adds a lot of things that I have no idea whether 
they are needed or whether there are simpler variants.


http://reviews.llvm.org/D12407



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

Re: [PATCH] D13643: [Sema] Warn on ternary comparison

[Aaron Ballman via cfe-commits]

aaron.ballman added a comment.

Should there be an exception to this diagnostic for code involving Boolean 
values? e.g.,

void f(bool a, bool b, bool c) {

  if (a == b == c)
;

}

At the very least, it seems like this should also follow GCC's behavior and 
suggest parenthesis directly.



Comment at: include/clang/Basic/DiagnosticSemaKinds.td:5865
@@ -5864,1 +5864,3 @@
 
+def warn_ternary_comparison : Warning<"ternary comparisons do not work "
+  "as expected">,

This diagnostic somewhat implies that ?: does not work as expected. I prefer 
GCC's wording for this:

"comparisons like 'X<=Y<=Z' do not have their mathematical meaning"

However, I would love it if we could do one step better and use the same 
operators the user wrote, if reasonable. ;-)


http://reviews.llvm.org/D13643



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

Re: [PATCH] D13014: [X86] Add XSAVE intrinsics (Clang part)

[Amjad Aboud via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL250158: [X86] Add XSAVE intrinsic family (authored by 
aaboud).

Changed prior to commit:
  http://reviews.llvm.org/D13014?vs=37108=37238#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D13014

Files:
  cfe/trunk/include/clang/Basic/BuiltinsX86.def
  cfe/trunk/lib/CodeGen/CGBuiltin.cpp
  cfe/trunk/lib/Headers/CMakeLists.txt
  cfe/trunk/lib/Headers/Intrin.h
  cfe/trunk/lib/Headers/immintrin.h
  cfe/trunk/lib/Headers/xsavecintrin.h
  cfe/trunk/lib/Headers/xsaveintrin.h
  cfe/trunk/lib/Headers/xsaveoptintrin.h
  cfe/trunk/lib/Headers/xsavesintrin.h
  cfe/trunk/test/CodeGen/builtins-x86.c
  cfe/trunk/test/CodeGen/x86_32-xsave.c
  cfe/trunk/test/CodeGen/x86_64-xsave.c

Index: cfe/trunk/test/CodeGen/x86_32-xsave.c
===
--- cfe/trunk/test/CodeGen/x86_32-xsave.c
+++ cfe/trunk/test/CodeGen/x86_32-xsave.c
@@ -0,0 +1,72 @@
+// RUN: %clang_cc1 %s -DTEST_XSAVE -O0 -triple=i686-unknown-unknown -target-feature +xsave -emit-llvm -o - -Werror | FileCheck %s --check-prefix=XSAVE
+// RUN: %clang_cc1 %s -DTEST_XSAVE -O0 -triple=i686-unknown-unknown -target-feature +xsave -fno-signed-char -emit-llvm -o - -Werror | FileCheck %s --check-prefix=XSAVE
+
+// RUN: %clang_cc1 %s -DTEST_XSAVEOPT -O0 -triple=i686-unknown-unknown -target-feature +xsave,+xsaveopt -emit-llvm -o - -Werror | FileCheck %s --check-prefix=XSAVEOPT
+// RUN: %clang_cc1 %s -DTEST_XSAVEOPT -O0 -triple=i686-unknown-unknown -target-feature +xsave,+xsaveopt -fno-signed-char -emit-llvm -o - -Werror | FileCheck %s --check-prefix=XSAVEOPT
+
+// RUN: %clang_cc1 %s -DTEST_XSAVEC -O0 -triple=i686-unknown-unknown -target-feature +xsave,+xsavec -emit-llvm -o - -Werror | FileCheck %s --check-prefix=XSAVEC
+// RUN: %clang_cc1 %s -DTEST_XSAVEC -O0 -triple=i686-unknown-unknown -target-feature +xsave,+xsavec -fno-signed-char -emit-llvm -o - -Werror | FileCheck %s --check-prefix=XSAVEC
+
+// RUN: %clang_cc1 %s -DTEST_XSAVES -O0 -triple=i686-unknown-unknown -target-feature +xsave,+xsaves -emit-llvm -o - -Werror | FileCheck %s --check-prefix=XSAVES
+// RUN: %clang_cc1 %s -DTEST_XSAVES -O0 -triple=i686-unknown-unknown -target-feature +xsave,+xsaves -fno-signed-char -emit-llvm -o - -Werror | FileCheck %s --check-prefix=XSAVES
+
+void test() {
+  unsigned long long tmp_ULLi;
+  void*  tmp_vp;
+
+#ifdef TEST_XSAVE
+// XSAVE: [[tmp_vp_1:%[0-9a-zA-z]+]] = load i8*, i8** %tmp_vp, align 4
+// XSAVE: [[tmp_ULLi_1:%[0-9a-zA-z]+]] = load i64, i64* %tmp_ULLi, align 8
+// XSAVE: [[high64_1:%[0-9a-zA-z]+]] = lshr i64 [[tmp_ULLi_1]], 32
+// XSAVE: [[high32_1:%[0-9a-zA-z]+]] = trunc i64 [[high64_1]] to i32
+// XSAVE: [[low32_1:%[0-9a-zA-z]+]] = trunc i64 [[tmp_ULLi_1]] to i32
+// XSAVE: call void @llvm.x86.xsave(i8* [[tmp_vp_1]], i32 [[high32_1]], i32 [[low32_1]])
+  (void)__builtin_ia32_xsave(tmp_vp, tmp_ULLi);
+
+// XSAVE: [[tmp_vp_3:%[0-9a-zA-z]+]] = load i8*, i8** %tmp_vp, align 4
+// XSAVE: [[tmp_ULLi_3:%[0-9a-zA-z]+]] = load i64, i64* %tmp_ULLi, align 8
+// XSAVE: [[high64_3:%[0-9a-zA-z]+]] = lshr i64 [[tmp_ULLi_3]], 32
+// XSAVE: [[high32_3:%[0-9a-zA-z]+]] = trunc i64 [[high64_3]] to i32
+// XSAVE: [[low32_3:%[0-9a-zA-z]+]] = trunc i64 [[tmp_ULLi_3]] to i32
+// XSAVE: call void @llvm.x86.xrstor(i8* [[tmp_vp_3]], i32 [[high32_3]], i32 [[low32_3]])
+  (void)__builtin_ia32_xrstor(tmp_vp, tmp_ULLi);
+#endif
+
+#ifdef TEST_XSAVEOPT
+// XSAVEOPT: [[tmp_vp_1:%[0-9a-zA-z]+]] = load i8*, i8** %tmp_vp, align 4
+// XSAVEOPT: [[tmp_ULLi_1:%[0-9a-zA-z]+]] = load i64, i64* %tmp_ULLi, align 8
+// XSAVEOPT: [[high64_1:%[0-9a-zA-z]+]] = lshr i64 [[tmp_ULLi_1]], 32
+// XSAVEOPT: [[high32_1:%[0-9a-zA-z]+]] = trunc i64 [[high64_1]] to i32
+// XSAVEOPT: [[low32_1:%[0-9a-zA-z]+]] = trunc i64 [[tmp_ULLi_1]] to i32
+// XSAVEOPT: call void @llvm.x86.xsaveopt(i8* [[tmp_vp_1]], i32 [[high32_1]], i32 [[low32_1]])
+  (void)__builtin_ia32_xsaveopt(tmp_vp, tmp_ULLi);
+#endif
+
+#ifdef TEST_XSAVEC
+// XSAVEC: [[tmp_vp_1:%[0-9a-zA-z]+]] = load i8*, i8** %tmp_vp, align 4
+// XSAVEC: [[tmp_ULLi_1:%[0-9a-zA-z]+]] = load i64, i64* %tmp_ULLi, align 8
+// XSAVEC: [[high64_1:%[0-9a-zA-z]+]] = lshr i64 [[tmp_ULLi_1]], 32
+// XSAVEC: [[high32_1:%[0-9a-zA-z]+]] = trunc i64 [[high64_1]] to i32
+// XSAVEC: [[low32_1:%[0-9a-zA-z]+]] = trunc i64 [[tmp_ULLi_1]] to i32
+// XSAVEC: call void @llvm.x86.xsavec(i8* [[tmp_vp_1]], i32 [[high32_1]], i32 [[low32_1]])
+  (void)__builtin_ia32_xsavec(tmp_vp, tmp_ULLi);
+#endif
+
+#ifdef TEST_XSAVES
+// XSAVES: [[tmp_vp_1:%[0-9a-zA-z]+]] = load i8*, i8** %tmp_vp, align 4
+// XSAVES: [[tmp_ULLi_1:%[0-9a-zA-z]+]] = load i64, i64* %tmp_ULLi, align 8
+// XSAVES: [[high64_1:%[0-9a-zA-z]+]] = lshr i64 [[tmp_ULLi_1]], 32
+// XSAVES: [[high32_1:%[0-9a-zA-z]+]] = trunc i64 [[high64_1]] to i32
+// XSAVES: [[low32_1:%[0-9a-zA-z]+]] = trunc i64 [[tmp_ULLi_1]] to i32
+// XSAVES: call void @llvm.x86.xsaves(i8* [[tmp_vp_1]], i32 [[high32_1]], i32 

r250158 - [X86] Add XSAVE intrinsic family

[Amjad Aboud via cfe-commits]

Author: aaboud
Date: Tue Oct 13 07:29:35 2015
New Revision: 250158

URL: http://llvm.org/viewvc/llvm-project?rev=250158=rev
Log:
[X86] Add XSAVE intrinsic family

Add intrinsics for the
  XSAVE instructions (XSAVE/XSAVE64/XRSTOR/XRSTOR64)
  XSAVEOPT instructions (XSAVEOPT/XSAVEOPT64)
  XSAVEC instructions (XSAVEC/XSAVEC64)
  XSAVES instructions (XSAVES/XSAVES64/XRSTORS/XRSTORS64)

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

Added:
cfe/trunk/lib/Headers/xsavecintrin.h
cfe/trunk/lib/Headers/xsaveintrin.h
cfe/trunk/lib/Headers/xsaveoptintrin.h
cfe/trunk/lib/Headers/xsavesintrin.h
cfe/trunk/test/CodeGen/x86_32-xsave.c
cfe/trunk/test/CodeGen/x86_64-xsave.c
Modified:
cfe/trunk/include/clang/Basic/BuiltinsX86.def
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/lib/Headers/CMakeLists.txt
cfe/trunk/lib/Headers/Intrin.h
cfe/trunk/lib/Headers/immintrin.h
cfe/trunk/test/CodeGen/builtins-x86.c

Modified: cfe/trunk/include/clang/Basic/BuiltinsX86.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsX86.def?rev=250158=250157=250158=diff
==
--- cfe/trunk/include/clang/Basic/BuiltinsX86.def (original)
+++ cfe/trunk/include/clang/Basic/BuiltinsX86.def Tue Oct 13 07:29:35 2015
@@ -665,6 +665,20 @@ BUILTIN(__builtin_ia32_fxrstor64, "vv*",
 BUILTIN(__builtin_ia32_fxsave, "vv*", "")
 BUILTIN(__builtin_ia32_fxsave64, "vv*", "")
 
+// XSAVE
+BUILTIN(__builtin_ia32_xsave, "vv*ULLi", "")
+BUILTIN(__builtin_ia32_xsave64, "vv*ULLi", "")
+BUILTIN(__builtin_ia32_xrstor, "vv*ULLi", "")
+BUILTIN(__builtin_ia32_xrstor64, "vv*ULLi", "")
+BUILTIN(__builtin_ia32_xsaveopt, "vv*ULLi", "")
+BUILTIN(__builtin_ia32_xsaveopt64, "vv*ULLi", "")
+BUILTIN(__builtin_ia32_xrstors, "vv*ULLi", "")
+BUILTIN(__builtin_ia32_xrstors64, "vv*ULLi", "")
+BUILTIN(__builtin_ia32_xsavec, "vv*ULLi", "")
+BUILTIN(__builtin_ia32_xsavec64, "vv*ULLi", "")
+BUILTIN(__builtin_ia32_xsaves, "vv*ULLi", "")
+BUILTIN(__builtin_ia32_xsaves64, "vv*ULLi", "")
+
 // ADX
 TARGET_BUILTIN(__builtin_ia32_addcarryx_u32, "UcUcUiUiUi*", "", "adx")
 TARGET_BUILTIN(__builtin_ia32_addcarryx_u64, "UcUcULLiULLiULLi*", "", "adx")

Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=250158=250157=250158=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Tue Oct 13 07:29:35 2015
@@ -6083,6 +6083,46 @@ Value *CodeGenFunction::EmitX86BuiltinEx
Builder.CreateBitCast(Tmp.getPointer(), Int8PtrTy));
 return Builder.CreateLoad(Tmp, "stmxcsr");
   }
+  case X86::BI__builtin_ia32_xsave:
+  case X86::BI__builtin_ia32_xsave64:
+  case X86::BI__builtin_ia32_xrstor:
+  case X86::BI__builtin_ia32_xrstor64:
+  case X86::BI__builtin_ia32_xsaveopt:
+  case X86::BI__builtin_ia32_xsaveopt64:
+  case X86::BI__builtin_ia32_xrstors:
+  case X86::BI__builtin_ia32_xrstors64:
+  case X86::BI__builtin_ia32_xsavec:
+  case X86::BI__builtin_ia32_xsavec64:
+  case X86::BI__builtin_ia32_xsaves:
+  case X86::BI__builtin_ia32_xsaves64: {
+Intrinsic::ID ID;
+#define INTRINSIC_X86_XSAVE_ID(NAME) \
+case X86::BI__builtin_ia32_##NAME: \
+  ID = Intrinsic::x86_##NAME; \
+  break
+switch (BuiltinID) {
+default: llvm_unreachable("Unsupported intrinsic!");
+INTRINSIC_X86_XSAVE_ID(xsave);
+INTRINSIC_X86_XSAVE_ID(xsave64);
+INTRINSIC_X86_XSAVE_ID(xrstor);
+INTRINSIC_X86_XSAVE_ID(xrstor64);
+INTRINSIC_X86_XSAVE_ID(xsaveopt);
+INTRINSIC_X86_XSAVE_ID(xsaveopt64);
+INTRINSIC_X86_XSAVE_ID(xrstors);
+INTRINSIC_X86_XSAVE_ID(xrstors64);
+INTRINSIC_X86_XSAVE_ID(xsavec);
+INTRINSIC_X86_XSAVE_ID(xsavec64);
+INTRINSIC_X86_XSAVE_ID(xsaves);
+INTRINSIC_X86_XSAVE_ID(xsaves64);
+}
+#undef INTRINSIC_X86_XSAVE_ID
+Value *Mhi = Builder.CreateTrunc(
+  Builder.CreateLShr(Ops[1], ConstantInt::get(Int64Ty, 32)), Int32Ty);
+Value *Mlo = Builder.CreateTrunc(Ops[1], Int32Ty);
+Ops[1] = Mhi;
+Ops.push_back(Mlo);
+return Builder.CreateCall(CGM.getIntrinsic(ID), Ops);
+  }
   case X86::BI__builtin_ia32_storehps:
   case X86::BI__builtin_ia32_storelps: {
 llvm::Type *PtrTy = llvm::PointerType::getUnqual(Int64Ty);

Modified: cfe/trunk/lib/Headers/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/CMakeLists.txt?rev=250158=250157=250158=diff
==
--- cfe/trunk/lib/Headers/CMakeLists.txt (original)
+++ cfe/trunk/lib/Headers/CMakeLists.txt Tue Oct 13 07:29:35 2015
@@ -66,6 +66,10 @@ set(files
   x86intrin.h
   xmmintrin.h
   xopintrin.h
+  xsaveintrin.h
+  xsaveoptintrin.h
+  xsavecintrin.h
+  xsavesintrin.h
   xtestintrin.h
   )
 

Modified: cfe/trunk/lib/Headers/Intrin.h
URL: 

Re: [PATCH] D10833: Retrieve BinaryOperator::getOpcode and BinaryOperator::getOpcodeStr via libclang and its python interface

[Milian Wolff via cfe-commits]

milianw added a comment.

This looks good to me, but it's missing a unit test. Take a look at 
http://reviews.llvm.org/D13388 for how to do that in principle.


http://reviews.llvm.org/D10833



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

Re: [PATCH] D13388: Add support for querying the visibility of a cursor

[Milian Wolff via cfe-commits]

milianw added a comment.

Yep, looks good to me as well - thanks!


http://reviews.llvm.org/D13388



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

Re: [PATCH] D13640: [clang-tidy] Add new check cppcoreguidelines-pro-bounds-array-to-pointer-decay

[Aaron Ballman via cfe-commits]

aaron.ballman added inline comments.


Comment at: 
clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.cpp:40
@@ +39,3 @@
+
+  diag(MatchedCast->getExprLoc(), "do not (implicitly) convert an array to a 
pointer");
+}

klimek wrote:
> aaron.ballman wrote:
> > klimek wrote:
> > > Can't we provide a fixit?
> > I think the fixit that the C++ Core Guidelines wants is to use array_view, 
> > which isn't available to everyone and can't be applied locally (for 
> > instance, it may require changing a function parameter instead of the 
> > argument passed to the function).
> https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#-bounds3-no-array-to-pointer-decay
> says that [0] is an OK work around (makes the thing visible)
Hmm, I missed that part, but you're right. I wonder if they intended that to be 
used as a workaround or not, however. It's not an array decay because it's an 
explicit subscript of the array, and a unary op. It's certainly a functional 
workaround, though. I would worry about more complex cases:
```
size_t g();
void h(int *);

void f() {
  int a[5];
  h(a + g() - 10); // Convert to [g() - 10];
}
```


http://reviews.llvm.org/D13640



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

Re: [PATCH] D13549: Added new options to ClangFormat VSIX package.

[Aaron Ballman via cfe-commits]

aaron.ballman added inline comments.


Comment at: tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs:82
@@ -42,1 +81,3 @@
+ "  - Predefined styles ('LLVM', 'Google', 'Chromium', 
'Mozilla', 'WebKit').\n" +
+ "  - 'file' to search for a YAML .clang-format or 
_clang-format\n" +
  "configuration file.\n" +

curdeius wrote:
> aaron.ballman wrote:
> > Why is 'file' now lowercased?
> I wanted to be consistent with clang-format --help. Besides, lowercase styles 
> (file, none) are somewhat special and it's nice to have them stand out, IMO.
That seems reasonable to me. Just making sure it wasn't a drive-by unintended 
change, or had some weird semantic meaning in MSVC.


http://reviews.llvm.org/D13549



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

r250164 - [Driver] Use the parent_path of the clang executable as the default InstalledDir

[Benjamin Kramer via cfe-commits]

Author: d0k
Date: Tue Oct 13 10:19:32 2015
New Revision: 250164

URL: http://llvm.org/viewvc/llvm-project?rev=250164=rev
Log:
[Driver] Use the parent_path of the clang executable as the default InstalledDir

This is what most people want anyways. Clang -cc1's main() will override
this but for other tools this is the most sensible default and avoids
some work.

Modified:
cfe/trunk/lib/Driver/Driver.cpp
cfe/trunk/unittests/Driver/ToolChainTest.cpp

Modified: cfe/trunk/lib/Driver/Driver.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Driver.cpp?rev=250164=250163=250164=diff
==
--- cfe/trunk/lib/Driver/Driver.cpp (original)
+++ cfe/trunk/lib/Driver/Driver.cpp Tue Oct 13 10:19:32 2015
@@ -65,6 +65,7 @@ Driver::Driver(StringRef ClangExecutable
 
   Name = llvm::sys::path::filename(ClangExecutable);
   Dir = llvm::sys::path::parent_path(ClangExecutable);
+  InstalledDir = Dir; // Provide a sensible default installed dir.
 
   // Compute the path to the resource directory.
   StringRef ClangResourceDir(CLANG_RESOURCE_DIR);

Modified: cfe/trunk/unittests/Driver/ToolChainTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Driver/ToolChainTest.cpp?rev=250164=250163=250164=diff
==
--- cfe/trunk/unittests/Driver/ToolChainTest.cpp (original)
+++ cfe/trunk/unittests/Driver/ToolChainTest.cpp Tue Oct 13 10:19:32 2015
@@ -33,12 +33,12 @@ TEST(ToolChainTest, VFSGCCInstallation)
   DiagnosticsEngine Diags(DiagID, &*DiagOpts, new TestDiagnosticConsumer);
   IntrusiveRefCntPtr InMemoryFileSystem(
   new vfs::InMemoryFileSystem);
-  Driver TheDriver("/usr/bin/clang", "arm-linux-gnueabihf", Diags,
+  Driver TheDriver("/bin/clang", "arm-linux-gnueabihf", Diags,
InMemoryFileSystem);
 
   const char *EmptyFiles[] = {
   "foo.cpp",
-  "/usr/bin/clang",
+  "/bin/clang",
   "/usr/lib/gcc/arm-linux-gnueabi/4.6.1/crtbegin.o",
   "/usr/lib/gcc/arm-linux-gnueabi/4.6.1/crtend.o",
   "/usr/lib/gcc/arm-linux-gnueabihf/4.6.3/crtbegin.o",
@@ -78,4 +78,43 @@ TEST(ToolChainTest, VFSGCCInstallation)
   S);
 }
 
+TEST(ToolChainTest, VFSGCCInstallationRelativeDir) {
+  IntrusiveRefCntPtr DiagOpts = new DiagnosticOptions();
+
+  IntrusiveRefCntPtr DiagID(new DiagnosticIDs());
+  struct TestDiagnosticConsumer : public DiagnosticConsumer {};
+  DiagnosticsEngine Diags(DiagID, &*DiagOpts, new TestDiagnosticConsumer);
+  IntrusiveRefCntPtr InMemoryFileSystem(
+  new vfs::InMemoryFileSystem);
+  Driver TheDriver("/home/test/bin/clang", "arm-linux-gnueabi", Diags,
+   InMemoryFileSystem);
+
+  const char *EmptyFiles[] = {
+  "foo.cpp", "/home/test/lib/gcc/arm-linux-gnueabi/4.6.1/crtbegin.o",
+  "/home/test/include/arm-linux-gnueabi/.keep"};
+
+  for (const char *Path : EmptyFiles)
+InMemoryFileSystem->addFile(Path, 0,
+llvm::MemoryBuffer::getMemBuffer("\n"));
+
+  std::unique_ptr C(
+  TheDriver.BuildCompilation({"-fsyntax-only", "foo.cpp"}));
+
+  std::string S;
+  {
+llvm::raw_string_ostream OS(S);
+C->getDefaultToolChain().printVerboseInfo(OS);
+  }
+#if LLVM_ON_WIN32
+  std::replace(S.begin(), S.end(), '\\', '/');
+#endif
+  EXPECT_EQ("Found candidate GCC installation: "
+"/home/test/lib/gcc/arm-linux-gnueabi/4.6.1\n"
+"Selected GCC installation: "
+"/home/test/bin/../lib/gcc/arm-linux-gnueabi/4.6.1\n"
+"Candidate multilib: .;@m32\n"
+"Selected multilib: .;@m32\n",
+S);
+}
+
 } // end anonymous namespace


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

[clang-tools-extra] r250165 - Expose the clang-tidy misc-assign-operator-signature checker as cppcoreguidelines-c-copy-assignment-signature.

[Aaron Ballman via cfe-commits]

Author: aaronballman
Date: Tue Oct 13 10:24:33 2015
New Revision: 250165

URL: http://llvm.org/viewvc/llvm-project?rev=250165=rev
Log:
Expose the clang-tidy misc-assign-operator-signature checker as 
cppcoreguidelines-c-copy-assignment-signature.

Modified:

clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
clang-tools-extra/trunk/clang-tidy/misc/AssignOperatorSignatureCheck.cpp
clang-tools-extra/trunk/test/clang-tidy/misc-assign-operator-signature.cpp

Modified: 
clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp?rev=250165=250164=250165=diff
==
--- 
clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
 (original)
+++ 
clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
 Tue Oct 13 10:24:33 2015
@@ -10,6 +10,7 @@
 #include "../ClangTidy.h"
 #include "../ClangTidyModule.h"
 #include "../ClangTidyModuleRegistry.h"
+#include "../misc/AssignOperatorSignatureCheck.h"
 #include "ProBoundsPointerArithmeticCheck.h"
 #include "ProTypeConstCastCheck.h"
 #include "ProTypeReinterpretCastCheck.h"
@@ -31,6 +32,8 @@ public:
 "cppcoreguidelines-pro-type-reinterpret-cast");
 CheckFactories.registerCheck(
 "cppcoreguidelines-pro-type-static-cast-downcast");
+CheckFactories.registerCheck(
+"cppcoreguidelines-c-copy-assignment-signature");
   }
 };
 

Modified: 
clang-tools-extra/trunk/clang-tidy/misc/AssignOperatorSignatureCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/AssignOperatorSignatureCheck.cpp?rev=250165=250164=250165=diff
==
--- clang-tools-extra/trunk/clang-tidy/misc/AssignOperatorSignatureCheck.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/misc/AssignOperatorSignatureCheck.cpp 
Tue Oct 13 10:24:33 2015
@@ -51,11 +51,11 @@ void AssignOperatorSignatureCheck::regis
   .bind("ArgumentType"),
   this);
 
-  Finder->addMatcher(cxxMethodDecl(IsSelfAssign, isConst()).bind("Const"),
- this);
+  Finder->addMatcher(
+  cxxMethodDecl(IsSelfAssign, anyOf(isConst(), isVirtual())).bind("cv"),
+  this);
 }
 
-
 void AssignOperatorSignatureCheck::check(
 const MatchFinder::MatchResult ) {
   const auto* Method = Result.Nodes.getNodeAs("method");
@@ -64,12 +64,13 @@ void AssignOperatorSignatureCheck::check
   static const char *Messages[][2] = {
   {"ReturnType", "operator=() should return '%0&'"},
   {"ArgumentType", "operator=() should take '%0 const&', '%0&&' or '%0'"},
-  {"Const", "operator=() should not be marked 'const'"},
+  {"cv", "operator=() should not be marked '%1'"}
   };
 
-  for (const auto& Message : Messages) {
+  for (const auto  : Messages) {
 if (Result.Nodes.getNodeAs(Message[0]))
-  diag(Method->getLocStart(), Message[1]) << Name;
+  diag(Method->getLocStart(), Message[1])
+  << Name << (Method->isConst() ? "const" : "virtual");
   }
 }
 

Modified: 
clang-tools-extra/trunk/test/clang-tidy/misc-assign-operator-signature.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/misc-assign-operator-signature.cpp?rev=250165=250164=250165=diff
==
--- clang-tools-extra/trunk/test/clang-tidy/misc-assign-operator-signature.cpp 
(original)
+++ clang-tools-extra/trunk/test/clang-tidy/misc-assign-operator-signature.cpp 
Tue Oct 13 10:24:33 2015
@@ -49,3 +49,8 @@ class Private {
   // Pre-C++11 way of disabling assignment.
   void operator=(const Private &);
 };
+
+struct Virtual {
+  virtual Virtual& operator=(const Virtual &);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: operator=() should not be marked 
'virtual'
+};


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

Re: [PATCH] D13465: Add SafeStack support for test-suite.

[Valérian Rousset via cfe-commits]

tharvik added a comment.

In http://reviews.llvm.org/D13465#260846, @jroelofs wrote:

> In http://reviews.llvm.org/D13465#260628, @tharvik wrote:
>
> > When running the test suite, it gives a bunch of `undefined reference to 
> > '__safestack_unsafe_stack_ptr'`.
> >  See regression results .
>
>
> Sounds like it's missing the safestack runtime, which should be provided by 
> building compiler-rt.


If you try to build compiler-rt, with safestack forced, you end up with some 
"already define" error, because safestack use interception which is needed by 
some tests. We can make these tests as excepted failure though.


http://reviews.llvm.org/D13465



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

Re: [PATCH] D13640: [clang-tidy] Add new check cppcoreguidelines-pro-bounds-array-to-pointer-decay

[Aaron Ballman via cfe-commits]

aaron.ballman added inline comments.


Comment at: 
clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.cpp:29
@@ +28,3 @@
+  implicitCastExpr(unless(hasParent(arraySubscriptExpr())),
+   
unless(hasSourceExpression(declRefExpr(to(varDecl(hasName("__range")),
+   unless(hasSourceExpression(stringLiteral()))

mgehre wrote:
> sbenza wrote:
> > __range is an implementation detail and should not be used here.
> > Check that this is the range init of a cxxForRangeStmt parent node or 
> > something like that.
> That was my first attempt, but I couldn't quite figure it out.
> 
> I tried
>   
> unless(hasAncestor(cxxForRangeStmt(hasRangeInit(hasDescendant(equalsBoundNode("cast"))
> but that does not compile.
> 
> Any ideas?
I'm not certain that you'll be able to do that. Looking at the AST dump:

```
TranslationUnitDecl 0xa40168 <> 
|-TypedefDecl 0xa40458 <>  implicit 
__builtin_va_list 'char *'
`-FunctionDecl 0xa404c0  line:1:6 f 'void 
(void)'
  `-CompoundStmt 0xa40b88 
|-DeclStmt 0xa40600 
| `-VarDecl 0xa405c8  col:7 used a 'int [5]'
`-CXXForRangeStmt 0xa40b50 
  |-DeclStmt 0xa40828 
  | `-VarDecl 0xa406b8  col:16 implicit used __range 'int (&&)[5]' 
cinit
  |   `-DeclRefExpr 0xa40610  'int [5]' lvalue Var 0xa405c8 'a' 
'int [5]'
  |-DeclStmt 0xa40a00 
  | |-VarDecl 0xa40870  col:14 implicit used __begin 'int *':'int 
*' cinit
  | | `-ImplicitCastExpr 0xa40960  'int *' 
  | |   `-DeclRefExpr 0xa40838  'int [5]' lvalue Var 0xa406b8 
'__range' 'int (&&)[5]'
  | `-VarDecl 0xa408b0  col:14 implicit used __end 'int 
*':'int *' cinit
  |   `-BinaryOperator 0xa409a0  'int *' '+'
  | |-ImplicitCastExpr 0xa40990  'int *' 
  | | `-DeclRefExpr 0xa40850  'int [5]' lvalue Var 0xa406b8 
'__range' 'int (&&)[5]'
  | `-IntegerLiteral 0xa40970  'int' 5
  |-BinaryOperator 0xa40a60  '_Bool' '!='
  | |-ImplicitCastExpr 0xa40a40  'int *':'int *' 
  | | `-DeclRefExpr 0xa40a10  'int *':'int *' lvalue Var 0xa40870 
'__begin' 'int *':'int *'
  | `-ImplicitCastExpr 0xa40a50  'int *':'int *' 
  |   `-DeclRefExpr 0xa40a28  'int *':'int *' lvalue Var 0xa408b0 
'__end' 'int *':'int *'
  |-UnaryOperator 0xa40a90  'int *':'int *' lvalue prefix '++'
  | `-DeclRefExpr 0xa40a78  'int *':'int *' lvalue Var 0xa40870 
'__begin' 'int *':'int *'
  |-DeclStmt 0xa40680 
  | `-VarDecl 0xa40648  col:12 e 'int':'int' cinit
  |   `-ImplicitCastExpr 0xa40b40  'int' 
  | `-UnaryOperator 0xa40ad0  'int' lvalue prefix '*'
  |   `-ImplicitCastExpr 0xa40ac0  'int *':'int *' 

  | `-DeclRefExpr 0xa40aa8  'int *':'int *' lvalue Var 
0xa40870 '__begin' 'int *':'int *'
  `-NullStmt 0xa40b78 
```
There is no range init in the AST. I'm not certain if that is an issue we want 
to rectify in the AST or not.


Comment at: 
clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.cpp:40
@@ +39,3 @@
+
+  diag(MatchedCast->getExprLoc(), "do not (implicitly) convert an array to a 
pointer");
+}

klimek wrote:
> Can't we provide a fixit?
I think the fixit that the C++ Core Guidelines wants is to use array_view, 
which isn't available to everyone and can't be applied locally (for instance, 
it may require changing a function parameter instead of the argument passed to 
the function).


Comment at: 
test/clang-tidy/cppcoreguidelines-pro-bounds-array-to-pointer-decay.cpp:26
@@ +25,2 @@
+return "clang"; // OK, decay string literal to pointer
+}

I would like to see a test case demonstrating that this does not trigger a 
diagnostic when creating an array_view object. We don't need to pull in all of 
the array_view machinery from GSL, but it would be good to have a skeleton of 
the implementation to ensure we aren't diagnosing there.


http://reviews.llvm.org/D13640



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

Re: [PATCH] D13549: Added new options to ClangFormat VSIX package.

[Aaron Ballman via cfe-commits]

aaron.ballman added a comment.

Generally looks good to me, with a few small nits.



Comment at: tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs:57
@@ +56,3 @@
+{
+StandardValuesCollection svc = new 
StandardValuesCollection(values);
+return svc;

Can we just return directly here instead of storing in a local?


Comment at: tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs:82
@@ -42,1 +81,3 @@
+ "  - Predefined styles ('LLVM', 'Google', 'Chromium', 
'Mozilla', 'WebKit').\n" +
+ "  - 'file' to search for a YAML .clang-format or 
_clang-format\n" +
  "configuration file.\n" +

Why is 'file' now lowercased?


Comment at: tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs:116
@@ +115,3 @@
+// Check if string contains quotes.
+if (s.IndexOf('\"') != -1)
+throw new NotSupportedException("Filename cannot contain 
quotes");

I see now why this is being used, but it took a lot of context from review 
comments to understand. Can you please put in a more descriptive comment about 
why we're checking for quotes, despite them being invalid filename characters 
on Windows?


http://reviews.llvm.org/D13549



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

Re: [PATCH] D12407: [clang-format-vs] Add an option to reformat source code when file is saved to disk

[Aaron Ballman via cfe-commits]

aaron.ballman added a comment.

LGTM, but someone who understands VS plugins better should give the final 
sign-off.



Comment at: tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs:309
@@ +308,3 @@
+uint _;
+IVsHierarchy __;
+string filename;

Cute. :-P


http://reviews.llvm.org/D12407



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

Re: [PATCH] D13640: [clang-tidy] Add new check cppcoreguidelines-pro-bounds-array-to-pointer-decay

[Manuel Klimek via cfe-commits]

klimek added inline comments.


Comment at: 
clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.cpp:40
@@ +39,3 @@
+
+  diag(MatchedCast->getExprLoc(), "do not (implicitly) convert an array to a 
pointer");
+}

aaron.ballman wrote:
> klimek wrote:
> > Can't we provide a fixit?
> I think the fixit that the C++ Core Guidelines wants is to use array_view, 
> which isn't available to everyone and can't be applied locally (for instance, 
> it may require changing a function parameter instead of the argument passed 
> to the function).
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#-bounds3-no-array-to-pointer-decay
says that [0] is an OK work around (makes the thing visible)


http://reviews.llvm.org/D13640



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

Re: [PATCH] D13549: Added new options to ClangFormat VSIX package.

[Marek Kurdej via cfe-commits]

curdeius added inline comments.


Comment at: tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs:57
@@ +56,3 @@
+{
+StandardValuesCollection svc = new 
StandardValuesCollection(values);
+return svc;

aaron.ballman wrote:
> Can we just return directly here instead of storing in a local?
Hmm, yes, we can.


Comment at: tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs:82
@@ -42,1 +81,3 @@
+ "  - Predefined styles ('LLVM', 'Google', 'Chromium', 
'Mozilla', 'WebKit').\n" +
+ "  - 'file' to search for a YAML .clang-format or 
_clang-format\n" +
  "configuration file.\n" +

aaron.ballman wrote:
> Why is 'file' now lowercased?
I wanted to be consistent with clang-format --help. Besides, lowercase styles 
(file, none) are somewhat special and it's nice to have them stand out, IMO.


Comment at: tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs:116
@@ +115,3 @@
+// Check if string contains quotes.
+if (s.IndexOf('\"') != -1)
+throw new NotSupportedException("Filename cannot contain 
quotes");

aaron.ballman wrote:
> I see now why this is being used, but it took a lot of context from review 
> comments to understand. Can you please put in a more descriptive comment 
> about why we're checking for quotes, despite them being invalid filename 
> characters on Windows?
OK, will do.


http://reviews.llvm.org/D13549



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

Re: [PATCH] D13549: Added new options to ClangFormat VSIX package.

[Marek Kurdej via cfe-commits]

curdeius updated this revision to Diff 37253.
curdeius added a comment.

Applied Aaron's comments. Removed unused using.


http://reviews.llvm.org/D13549

Files:
  tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs
  tools/clang-format-vs/ClangFormat/Properties/AssemblyInfo.cs
  tools/clang-format/ClangFormat.cpp

Index: tools/clang-format/ClangFormat.cpp
===
--- tools/clang-format/ClangFormat.cpp
+++ tools/clang-format/ClangFormat.cpp
@@ -199,17 +199,25 @@
 }
 
 static void outputReplacementXML(StringRef Text) {
+  // FIXME: When we sort includes, we need to make sure the stream is correct
+  // utf-8.
   size_t From = 0;
   size_t Index;
-  while ((Index = Text.find_first_of("\n\r", From)) != StringRef::npos) {
+  while ((Index = Text.find_first_of("\n\r<&", From)) != StringRef::npos) {
 llvm::outs() << Text.substr(From, Index - From);
 switch (Text[Index]) {
 case '\n':
   llvm::outs() << "";
   break;
 case '\r':
   llvm::outs() << "";
   break;
+case '<':
+  llvm::outs() << "";
+  break;
+case '&':
+  llvm::outs() << "";
+  break;
 default:
   llvm_unreachable("Unexpected character encountered!");
 }
Index: tools/clang-format-vs/ClangFormat/Properties/AssemblyInfo.cs
===
--- tools/clang-format-vs/ClangFormat/Properties/AssemblyInfo.cs
+++ tools/clang-format-vs/ClangFormat/Properties/AssemblyInfo.cs
@@ -29,5 +29,5 @@
 // You can specify all the values or you can default the Revision and Build Numbers 
 // by using the '*' as shown below:
 
-[assembly: AssemblyVersion("1.0.0.0")]
-[assembly: AssemblyFileVersion("1.0.0.0")]
+[assembly: AssemblyVersion("1.1.0.0")]
+[assembly: AssemblyFileVersion("1.1.0.0")]
Index: tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs
===
--- tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs
+++ tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs
@@ -19,10 +19,10 @@
 using Microsoft.VisualStudio.Text.Editor;
 using Microsoft.VisualStudio.TextManager.Interop;
 using System;
+using System.Collections;
 using System.ComponentModel;
 using System.ComponentModel.Design;
 using System.IO;
-using System.Reflection;
 using System.Runtime.InteropServices;
 using System.Xml.Linq;
 
@@ -32,13 +32,53 @@
 [CLSCompliant(false), ComVisible(true)]
 public class OptionPageGrid : DialogPage
 {
-private string style = "File";
+private string assumeFilename = "";
+private string fallbackStyle = "LLVM";
+private bool sortIncludes = false;
+private string style = "file";
+
+public class StyleConverter : TypeConverter
+{
+protected ArrayList values;
+public StyleConverter()
+{
+// Initializes the standard values list with defaults.
+values = new ArrayList(new string[] { "file", "Chromium", "Google", "LLVM", "Mozilla", "WebKit" });
+}
+
+public override bool GetStandardValuesSupported(ITypeDescriptorContext context)
+{
+return true;
+}
+
+public override StandardValuesCollection GetStandardValues(ITypeDescriptorContext context)
+{
+return new StandardValuesCollection(values);
+}
+
+public override bool CanConvertFrom(ITypeDescriptorContext context, Type sourceType)
+{
+if (sourceType == typeof(string))
+return true;
+
+return base.CanConvertFrom(context, sourceType);
+}
+
+public override object ConvertFrom(ITypeDescriptorContext context, System.Globalization.CultureInfo culture, object value)
+{
+string s = value as string;
+if (s == null)
+return base.ConvertFrom(context, culture, value);
+
+return value;
+}
+}
 
 [Category("LLVM/Clang")]
 [DisplayName("Style")]
 [Description("Coding style, currently supports:\n" +
- "  - Predefined styles ('LLVM', 'Google', 'Chromium', 'Mozilla').\n" +
- "  - 'File' to search for a YAML .clang-format or _clang-format\n" +
+ "  - Predefined styles ('LLVM', 'Google', 'Chromium', 'Mozilla', 'WebKit').\n" +
+ "  - 'file' to search for a YAML .clang-format or _clang-format\n" +
  "configuration file.\n" +
  "  - A YAML configuration snippet.\n\n" +
  "'File':\n" +
@@ -48,11 +88,81 @@
  "  The content of a .clang-format configuration file, as string.\n" +
  "  Example: '{BasedOnStyle: \"LLVM\", IndentWidth: 8}'\n\n" +
  "See 

Re: [PATCH] D13549: Added new options to ClangFormat VSIX package.

[Marek Kurdej via cfe-commits]

curdeius marked 7 inline comments as done.
curdeius added a comment.

Applied comments and done some minor clean up.


http://reviews.llvm.org/D13549



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

Re: [PATCH] D12686: Add support for GCC's '__auto_type' extension.

[Nico Weber via cfe-commits]

thakis added inline comments.


Comment at: test/SemaCXX/auto-type-from-cxx.cpp:14
@@ +13,3 @@
+  auto _ = [](__auto_type f) {}; // expected-error {{'__auto_type' not allowed 
in lambda parameter}}
+  __auto_type g = 2;
+  struct BitField { int field:2; };

comex wrote:
> thakis wrote:
> > Shouldn't this say "warning: __auto_type is a gnu extension" (since this 
> > uses -std=c++14, not -std=gnu++14)?
> Hmm... when I added `ext_auto_type` to the .td, I didn't notice the 
> difference between Extension and ExtWarn.  Since the patch currently uses 
> Extension, it won't warn by default, but will with `-pedantic`, `-Wgnu`, or 
> `-Wgnu-auto-type`.  The C test uses `-pedantic` so it gets the warning.
> 
> Is there an explicit policy on which extensions should be ExtWarn?  Looking 
> at the rest of that file, ExtWarns seem to be mostly either (a) standardized 
> extensions (which will warn if `-std` is too early) and (b) 'extensions' that 
> are more like "Clang will accept your buggy code" than features.  Most GNU 
> extensions are just Extension, so I think it makes sense to do the same for 
> `__auto_type`.
> 
> I could update the C++ test to add `-pedantic`, but arguably it makes more 
> sense to test the fact that the warning is not emitted by default.
I'm not sure either. `typeof` warns with -std=c++14 but not with -std=gnu++14. 
From a user perspective, this makes sense to me: I want to write standard c++ 
and I want the compiler to help me with that, but I don't want to get all the 
pedantic warnings that -pedantic entails. For example, consider using clang-cl 
to build Windows code, and wanting MSVC to be able to build said Windows code 
too. (This can of course go wrong with standard C++ too, but in that case I'm 
running into MSVC bugs which will eventually be fixed.) So if it's possible to 
match how typeof works, I think that'd be good. If it's not possible, this 
wouldn't be the only GNU extension allowed in -std=c++14 mode though, so it's 
not a big thing.


http://reviews.llvm.org/D12686



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

[clang-tools-extra] r250166 - Appeasing build bots by linking in the proper libraries.

[Aaron Ballman via cfe-commits]

Author: aaronballman
Date: Tue Oct 13 10:42:06 2015
New Revision: 250166

URL: http://llvm.org/viewvc/llvm-project?rev=250166=rev
Log:
Appeasing build bots by linking in the proper libraries.

Modified:
clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CMakeLists.txt

Modified: clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CMakeLists.txt?rev=250166=250165=250166=diff
==
--- clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CMakeLists.txt 
(original)
+++ clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CMakeLists.txt Tue Oct 
13 10:42:06 2015
@@ -13,6 +13,7 @@ add_clang_library(clangTidyCppCoreGuidel
   clangBasic
   clangLex
   clangTidy
+  clangTidyMiscModule
   clangTidyUtils
   clangTooling
   )


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

Re: [PATCH] D12359: New warning -Wnonconst-parameter when a pointer parameter can be const

[Aaron Ballman via cfe-commits]

aaron.ballman added inline comments.


Comment at: include/clang/Basic/DiagnosticSemaKinds.td:201
@@ -200,1 +200,3 @@
+def warn_nonconst_parameter : Warning<"parameter %0 can be const">,
+  InGroup, DefaultIgnore;
 def warn_unused_variable : Warning<"unused variable %0">,

> I disagree about this. Normal usage is to enable as much warnings as you can.
> 
> Is it possible for you to show a document, discussion or something that backs 
> your claim?

Searching through the Clang email archives yields:

http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20150504/128373.html
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20140922/115379.html

and others as well. This has been the de facto bar for as long as I've been 
contributing.


Comment at: lib/Parse/ParseExpr.cpp:176
@@ +175,3 @@
+  if (auto *B = dyn_cast(ER.get())) {
+if (B->isAssignmentOp() || B->isAdditiveOp()) {
+  MarkNonConstUse(B->getLHS());

> basic idea is that p can't be const here:
```
void f(int *p) {
int *q = p + 1;
// ...
}
```
But it could be const here:
```
void f(int *p) {
  const *q = p + 1;
}
```
I am not certain that addition, by itself, is sufficient to say the use is 
non-const. At the least, this could have some comments explaining the rationale 
with a FIXME.


Comment at: lib/Parse/ParseExpr.cpp:181
@@ +180,3 @@
+  } else if (isa(ER.get()) ||
+ isa(ER.get()) ||
+ isa(ER.get())) {

>This "conditional expression" check ensures that dontwarn9 does not generate 
>FP:
```
char *dontwarn9(char *p) {
  char *x;
  return p ? p : "";
}
```
This *should* diagnose in C++ because "" is a const char *. ;-) But that's 
neither here nor there; I think both of your examples suffer from the same 
analysis issues as mentioned above. Consider:
```
const char *f(char *p) {
  return p ? p : "";
}

char g(char *p) {
  return *p;
}
```


Comment at: lib/Parse/ParseStmt.cpp:376
@@ +375,3 @@
+// Mark symbols in r-value expression as written.
+void Parser::MarkNonConstUse(Expr *E) {
+  E = E->IgnoreParenCasts();

> This is called from the Parser only.

So will this still properly diagnose the same cases from a serialized AST?


http://reviews.llvm.org/D12359



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

Re: [PATCH] D12726: [analyzer] A fix for symbolic element region index lifetime.

[Artem Dergachev via cfe-commits]

NoQ updated this revision to Diff 37267.
NoQ added a comment.

A, another mis-submit. Sorry for the noise.


http://reviews.llvm.org/D12726

Files:
  docs/analyzer/DebugChecks.rst
  include/clang/StaticAnalyzer/Core/PathSensitive/SymbolManager.h
  lib/StaticAnalyzer/Checkers/ExprInspectionChecker.cpp
  lib/StaticAnalyzer/Core/Environment.cpp
  lib/StaticAnalyzer/Core/RegionStore.cpp
  lib/StaticAnalyzer/Core/SymbolManager.cpp
  test/Analysis/return-ptr-range.cpp
  test/Analysis/symbol-reaper.c

Index: test/Analysis/symbol-reaper.c
===
--- test/Analysis/symbol-reaper.c
+++ test/Analysis/symbol-reaper.c
@@ -0,0 +1,76 @@
+// RUN: %clang_cc1 -analyze -analyzer-checker=debug.ExprInspection -verify %s
+
+void clang_analyzer_eval(int);
+void clang_analyzer_warnOnDeadSymbol(int);
+
+int conjure_index();
+
+void test_that_expr_inspection_works() {
+  do {
+int x = conjure_index();
+clang_analyzer_warnOnDeadSymbol(x);
+  } while(0); // expected-warning{{SYMBOL DEAD}}
+}
+
+// These tests verify the reaping of symbols that are only referenced as
+// index values in element regions. Most of the time, depending on where
+// the element region, as Loc value, is stored, it is possible to
+// recover the index symbol in checker code, which is also demonstrated
+// in the return_ptr_range.c test file.
+
+int arr[3];
+
+int *test_element_index_lifetime_in_environment_values() {
+  int *ptr;
+  do {
+int x = conjure_index();
+clang_analyzer_warnOnDeadSymbol(x);
+ptr = arr + x;
+  } while (0);
+  return ptr;
+}
+
+void test_element_index_lifetime_in_store_keys() {
+  do {
+int x = conjure_index();
+clang_analyzer_warnOnDeadSymbol(x);
+arr[x] = 1;
+if (x) {}
+  } while (0); // no-warning
+}
+
+int *ptr;
+void test_element_index_lifetime_in_store_values() {
+  do {
+int x = conjure_index();
+clang_analyzer_warnOnDeadSymbol(x);
+ptr = arr + x;
+  } while (0); // no-warning
+}
+
+struct S1 {
+  int field;
+};
+struct S2 {
+  struct S1 array[5];
+} s2;
+
+void test_element_index_lifetime_with_complicated_hierarchy_of_regions() {
+  do {
+int x = conjure_index();
+clang_analyzer_warnOnDeadSymbol(x);
+s2.array[x].field = 1;
+if (x) {}
+  } while (0); // no-warning
+}
+
+// Test below checks lifetime of SymbolRegionValue in certain conditions.
+
+int **ptrptr;
+void test_region_lifetime_as_store_value(int *x) {
+  clang_analyzer_warnOnDeadSymbol((int) x);
+  *x = 1;
+  ptrptr = 
+  (void)0; // No-op; make sure the environment forgets things and the GC runs.
+  clang_analyzer_eval(**ptrptr); // expected-warning{{TRUE}}
+} // no-warning
Index: test/Analysis/return-ptr-range.cpp
===
--- test/Analysis/return-ptr-range.cpp
+++ test/Analysis/return-ptr-range.cpp
@@ -0,0 +1,27 @@
+// RUN: %clang_cc1 -analyze -analyzer-checker=alpha.security.ReturnPtrRange -verify %s
+
+int arr[10];
+int *ptr;
+
+int conjure_index();
+
+int *test_element_index_lifetime() {
+  do {
+int x = conjure_index();
+ptr = arr + x;
+if (x != 20)
+  return arr; // no-warning
+  } while (0);
+  return ptr; // expected-warning{{Returned pointer value points outside the original object (potential buffer overflow)}}
+}
+
+int *test_element_index_lifetime_with_local_ptr() {
+  int *local_ptr;
+  do {
+int x = conjure_index();
+local_ptr = arr + x;
+if (x != 20)
+  return arr; // no-warning
+  } while (0);
+  return local_ptr; // expected-warning{{Returned pointer value points outside the original object (potential buffer overflow)}}
+}
Index: lib/StaticAnalyzer/Core/SymbolManager.cpp
===
--- lib/StaticAnalyzer/Core/SymbolManager.cpp
+++ lib/StaticAnalyzer/Core/SymbolManager.cpp
@@ -391,6 +391,18 @@
 
 void SymbolReaper::markLive(const MemRegion *region) {
   RegionRoots.insert(region);
+  markElementIndicesLive(region);
+}
+
+void SymbolReaper::markElementIndicesLive(const MemRegion *region) {
+  for (auto SR = dyn_cast(region); SR;
+   SR = dyn_cast(SR->getSuperRegion())) {
+if (auto ER = dyn_cast(SR)) {
+  SVal Idx = ER->getIndex();
+  for (auto SI = Idx.symbol_begin(), SE = Idx.symbol_end(); SI != SE; ++SI)
+markLive(*SI);
+}
+  }
 }
 
 void SymbolReaper::markInUse(SymbolRef sym) {
Index: lib/StaticAnalyzer/Core/RegionStore.cpp
===
--- lib/StaticAnalyzer/Core/RegionStore.cpp
+++ lib/StaticAnalyzer/Core/RegionStore.cpp
@@ -2344,8 +2344,12 @@
   if (const SymbolicRegion *SymR = dyn_cast(baseR))
 SymReaper.markLive(SymR->getSymbol());
 
-  for (ClusterBindings::iterator I = C->begin(), E = C->end(); I != E; ++I)
+  for (ClusterBindings::iterator I = C->begin(), E = C->end(); I != E; ++I) {
+// Element index of a binding key is live.
+

Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain

[Jonathan Roelofs via cfe-commits]

jroelofs added a comment.

Other than that, LGTM too.



Comment at: lib/Driver/ToolChains.cpp:4081
@@ +4080,3 @@
+
+  std::string PS4SDKDir = (EnvValue ? EnvValue : getDriver().Dir + "/../..");
+

Use `llvm::sys::path::append` instead of `std::string::operator+` for path 
concatenation here,


Comment at: lib/Driver/ToolChains.cpp:4095
@@ +4094,3 @@
+
+  std::string PS4SDKIncludeDir = PrefixDir + "/target/include";
+  if (!Args.hasArg(options::OPT_nostdinc) &&

and here,


Comment at: lib/Driver/ToolChains.cpp:4105
@@ +4104,3 @@
+
+  std::string PS4SDKLibDir = PS4SDKDir + "/target/lib";
+  if (!Args.hasArg(options::OPT_nostdlib) &&

and here.


Repository:
  rL LLVM

http://reviews.llvm.org/D13482



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

Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain

[Eric Christopher via cfe-commits]

(Jonathan's review here is fine, don't wait on me. Thanks! :)

-eric

On Tue, Oct 13, 2015 at 10:32 AM Jonathan Roelofs 
wrote:

> jroelofs added a comment.
>
> Other than that, LGTM too.
>
>
> 
> Comment at: lib/Driver/ToolChains.cpp:4081
> @@ +4080,3 @@
> +
> +  std::string PS4SDKDir = (EnvValue ? EnvValue : getDriver().Dir +
> "/../..");
> +
> 
> Use `llvm::sys::path::append` instead of `std::string::operator+` for path
> concatenation here,
>
> 
> Comment at: lib/Driver/ToolChains.cpp:4095
> @@ +4094,3 @@
> +
> +  std::string PS4SDKIncludeDir = PrefixDir + "/target/include";
> +  if (!Args.hasArg(options::OPT_nostdinc) &&
> 
> and here,
>
> 
> Comment at: lib/Driver/ToolChains.cpp:4105
> @@ +4104,3 @@
> +
> +  std::string PS4SDKLibDir = PS4SDKDir + "/target/lib";
> +  if (!Args.hasArg(options::OPT_nostdlib) &&
> 
> and here.
>
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D13482
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D12922: Add support for function attribute "notail"

[Aaron Ballman via cfe-commits]

aaron.ballman added a comment.

In http://reviews.llvm.org/D12922#265452, @ahatanak wrote:

> I think there are a couple of things that have to be discussed:
>
> 1. Name of the attribute: Should it be "notail" or "notailcall"? Perhaps it 
> should be named something like "nodirecttail" to indicate it is used to block 
> direct calls, but not indirect calls?


The attribute prevents tail calls from the call site, not for the function 
itself. "notail", at least to me, implies that the function definition itself 
will not have TCO; it does not imply that callers will be affected. Perhaps 
"not_tail_called" or "disable_tail_calls"? It's a hard concept to get across in 
a small identifier.

Also, I would like to see a test that shows always_inline, notail also gets 
diagnosed as mutually exclusive, and a test that the right thing happens with a 
C++ spelling on a member function.

~Aaron



Comment at: include/clang/Basic/AttrDocs.td:1619
@@ +1618,3 @@
+  let Content = [{
+Tail call optimization is not performed on direct calls to a function marked 
``notail``.
+  }];

It would be good to clarify what you mean by direct calls, as not all of the 
readers are going to understand that easily. Perhaps a simple code example 
showing a call to the function, and a call to the same function through a 
function pointer, with comments showing which one has TCO.

You should also call out that it is mutually exclusive with always_inline.


Comment at: lib/Sema/SemaDeclAttr.cpp:1705
@@ +1704,3 @@
+static void handleNoTailAttr(Sema , Decl *D, const AttributeList ) {
+  if (checkAttrMutualExclusion(S, D, Attr))
+return;

Missing the same check in the always_inline attribute handler.


http://reviews.llvm.org/D12922



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

Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain

[Eric Christopher via cfe-commits]

echristo added a subscriber: echristo.
echristo added a comment.

(Jonathan's review here is fine, don't wait on me. Thanks! :)

-eric


Repository:
  rL LLVM

http://reviews.llvm.org/D13482



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

Re: [PATCH] D5104: [analyzer] [proposal] Fix for PR20653

[Artem Dergachev via cfe-commits]

NoQ added a subscriber: NoQ.
NoQ added a comment.

While investigating http://reviews.llvm.org/D12726 , i accidentally came up 
with a way to test this patch; with the extension of `ExprInspectionChecker` in 
the aforementioned review, which allows testing SymbolReaper directly, the 
following test passes as soon as the old (accepted) version of this diff is 
applied:

  void clang_analyzer_warnOnDeadSymbol(int);
  void clang_analyzer_warnIfReached(void);
  
  // SymbolRegionValue should live as long as its region is live but has no
  // direct bindings that override its value.
  void test_region_value_lifetime_after_binding(int x) {
clang_analyzer_warnOnDeadSymbol(x);
if (x) {}
x = 0;
(void)0; // expected-warning{{SYMBOL DEAD}}
if (x) {
  clang_analyzer_warnIfReached(); // no-warning
}
  } // no-warning


http://reviews.llvm.org/D5104



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

Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain

[Katya Romanova via cfe-commits]

kromanova added a comment.

Thank you! I will rebase and commit shortly

Katya.


Repository:
  rL LLVM

http://reviews.llvm.org/D13482



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

r250173 - Always pass a -dwarf-version argument to integrated as.

[Douglas Katzman via cfe-commits]

Author: dougk
Date: Tue Oct 13 11:22:51 2015
New Revision: 250173

URL: http://llvm.org/viewvc/llvm-project?rev=250173=rev
Log:
Always pass a -dwarf-version argument to integrated as.

This removes the default of 3 hidden in the assembler previously.

Fixes breakage caused by r249655, reported by vsukharev.

Added:
cfe/trunk/test/Driver/as-default-dwarf.s
Modified:
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/tools/driver/cc1as_main.cpp

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=250173=250172=250173=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Tue Oct 13 11:22:51 2015
@@ -5632,10 +5632,11 @@ void ClangAs::ConstructJob(Compilation &
 if (Arg *A = Args.getLastArg(options::OPT_g_Group)) {
   WantDebug = !A->getOption().matches(options::OPT_g0);
   if (WantDebug) {
-if ((DwarfVersion = DwarfVersionNum(A->getSpelling())) == 0)
-  DwarfVersion = getToolChain().GetDefaultDwarfVersion();
+DwarfVersion = DwarfVersionNum(A->getSpelling());
   }
 }
+if (DwarfVersion == 0)
+  DwarfVersion = getToolChain().GetDefaultDwarfVersion();
 RenderDebugEnablingArgs(Args, CmdArgs,
 (WantDebug ? CodeGenOptions::LimitedDebugInfo
: CodeGenOptions::NoDebugInfo),

Added: cfe/trunk/test/Driver/as-default-dwarf.s
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/as-default-dwarf.s?rev=250173=auto
==
--- cfe/trunk/test/Driver/as-default-dwarf.s (added)
+++ cfe/trunk/test/Driver/as-default-dwarf.s Tue Oct 13 11:22:51 2015
@@ -0,0 +1,15 @@
+@ REQUIRES: arm-registered-target
+@ RUN: %clang --target=armv8a--linux-gnueabi -c %s -o %t
+@ RUN: llvm-objdump -t %t | FileCheck %s
+.text
+.type   foo,%function
+foo:
+.fnstart
+.cfi_startproc
+
+.Ltmp2:
+.size   foo, .Ltmp2-foo
+.cfi_endproc
+.fnend
+.cfi_sections .debug_frame
+@ CHECK: foo

Modified: cfe/trunk/tools/driver/cc1as_main.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/driver/cc1as_main.cpp?rev=250173=250172=250173=diff
==
--- cfe/trunk/tools/driver/cc1as_main.cpp (original)
+++ cfe/trunk/tools/driver/cc1as_main.cpp Tue Oct 13 11:22:51 2015
@@ -144,7 +144,7 @@ public:
 RelaxAll = 0;
 NoExecStack = 0;
 FatalWarnings = 0;
-DwarfVersion = 3;
+DwarfVersion = 0;
   }
 
   static bool CreateFromArgs(AssemblerInvocation ,


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

Re: [PATCH] D13375: [MSVC] Fix for http://llvm.org/PR24132: __declspec(property): double invocations of foo() when compiling foo()->propertyName

[Reid Kleckner via cfe-commits]

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

lgtm

Thanks, sorry for the delay, EH was keeping me busy. =/


http://reviews.llvm.org/D13375



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

Re: [PATCH] D6700: Diagnose UnresolvedLookupExprs that resolve to instance members in static methods

[Reid Kleckner via cfe-commits]

rnk added inline comments.


Comment at: lib/Sema/TreeTransform.h:9138
@@ +9137,3 @@
+  isa(D))
+return getSema().BuildPossibleImplicitMemberExpr(
+SS, SourceLocation(), R, /*TemplateArgs=*/nullptr,

I believe this will always fail, so one alternative way to do this would be to 
add a stripped down entry point into Sema just for template instantiation that 
diagnoses UnresolvedLookupExprs finding instance members.


http://reviews.llvm.org/D6700



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

[PATCH] D13705: [libcxxabi] Set correct libc++ version in tests.

[Evgeniy Stepanov via cfe-commits]

eugenis created this revision.
eugenis added reviewers: mclow.lists, EricWF.
eugenis added a subscriber: cfe-commits.
eugenis set the repository for this revision to rL LLVM.

Libcxxabi tests are built against non-installed libc++ headers, and they need 
to know the ABI version libc++ is configured for.

This needs to go in at the same time as D11740.

Repository:
  rL LLVM

http://reviews.llvm.org/D13705

Files:
  CMakeLists.txt
  test/CMakeLists.txt
  test/lit.site.cfg.in

Index: test/lit.site.cfg.in
===
--- test/lit.site.cfg.in
+++ test/lit.site.cfg.in
@@ -12,6 +12,8 @@
 config.enable_32bit = "@LLVM_BUILD_32_BITS@"
 config.target_info  = "@LIBCXXABI_TARGET_INFO@"
 config.executor = "@LIBCXXABI_EXECUTOR@"
+config.abi_version  = "@LIBCXX_ABI_VERSION@"
+config.abi_unstable = "@LIBCXX_ABI_UNSTABLE@"
 
 # Let the main config do the real work.
 lit_config.load_config(config, "@LIBCXXABI_SOURCE_DIR@/test/lit.cfg")
Index: test/CMakeLists.txt
===
--- test/CMakeLists.txt
+++ test/CMakeLists.txt
@@ -10,6 +10,7 @@
 pythonize_bool(LIBCXXABI_ENABLE_SHARED)
 pythonize_bool(LIBCXXABI_ENABLE_THREADS)
 pythonize_bool(LIBCXXABI_USE_LLVM_UNWINDER)
+pythonize_bool(LIBCXX_ABI_UNSTABLE)
 set(LIBCXXABI_TARGET_INFO "libcxx.test.target_info.LocalTI" CACHE STRING
 "TargetInfo to use when setting up test environment.")
 set(LIBCXXABI_EXECUTOR "None" CACHE STRING
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -129,6 +129,10 @@
 option(LIBCXXABI_ENABLE_SHARED "Build libc++abi as a shared library." ON)
 option(LIBCXXABI_ENABLE_STATIC "Build libc++abi as a static library." ON)
 
+# Libcxx version options.
+set(LIBCXX_ABI_VERSION 1 CACHE STRING "ABI version of libc++.")
+option(LIBCXX_ABI_UNSTABLE "Unstable ABI of libc++." OFF)
+
 if (NOT LIBCXXABI_ENABLE_SHARED AND NOT LIBCXXABI_ENABLE_STATIC)
   message(FATAL_ERROR "libc++abi must be built as either a shared or static 
library.")
 endif()


Index: test/lit.site.cfg.in
===
--- test/lit.site.cfg.in
+++ test/lit.site.cfg.in
@@ -12,6 +12,8 @@
 config.enable_32bit = "@LLVM_BUILD_32_BITS@"
 config.target_info  = "@LIBCXXABI_TARGET_INFO@"
 config.executor = "@LIBCXXABI_EXECUTOR@"
+config.abi_version  = "@LIBCXX_ABI_VERSION@"
+config.abi_unstable = "@LIBCXX_ABI_UNSTABLE@"
 
 # Let the main config do the real work.
 lit_config.load_config(config, "@LIBCXXABI_SOURCE_DIR@/test/lit.cfg")
Index: test/CMakeLists.txt
===
--- test/CMakeLists.txt
+++ test/CMakeLists.txt
@@ -10,6 +10,7 @@
 pythonize_bool(LIBCXXABI_ENABLE_SHARED)
 pythonize_bool(LIBCXXABI_ENABLE_THREADS)
 pythonize_bool(LIBCXXABI_USE_LLVM_UNWINDER)
+pythonize_bool(LIBCXX_ABI_UNSTABLE)
 set(LIBCXXABI_TARGET_INFO "libcxx.test.target_info.LocalTI" CACHE STRING
 "TargetInfo to use when setting up test environment.")
 set(LIBCXXABI_EXECUTOR "None" CACHE STRING
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -129,6 +129,10 @@
 option(LIBCXXABI_ENABLE_SHARED "Build libc++abi as a shared library." ON)
 option(LIBCXXABI_ENABLE_STATIC "Build libc++abi as a static library." ON)
 
+# Libcxx version options.
+set(LIBCXX_ABI_VERSION 1 CACHE STRING "ABI version of libc++.")
+option(LIBCXX_ABI_UNSTABLE "Unstable ABI of libc++." OFF)
+
 if (NOT LIBCXXABI_ENABLE_SHARED AND NOT LIBCXXABI_ENABLE_STATIC)
   message(FATAL_ERROR "libc++abi must be built as either a shared or static library.")
 endif()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D12686: Add support for GCC's '__auto_type' extension.

[Nicholas Allegra via cfe-commits]

comex added inline comments.


Comment at: test/SemaCXX/auto-type-from-cxx.cpp:14
@@ +13,3 @@
+  auto _ = [](__auto_type f) {}; // expected-error {{'__auto_type' not allowed 
in lambda parameter}}
+  __auto_type g = 2;
+  struct BitField { int field:2; };

thakis wrote:
> comex wrote:
> > thakis wrote:
> > > Shouldn't this say "warning: __auto_type is a gnu extension" (since this 
> > > uses -std=c++14, not -std=gnu++14)?
> > Hmm... when I added `ext_auto_type` to the .td, I didn't notice the 
> > difference between Extension and ExtWarn.  Since the patch currently uses 
> > Extension, it won't warn by default, but will with `-pedantic`, `-Wgnu`, or 
> > `-Wgnu-auto-type`.  The C test uses `-pedantic` so it gets the warning.
> > 
> > Is there an explicit policy on which extensions should be ExtWarn?  Looking 
> > at the rest of that file, ExtWarns seem to be mostly either (a) 
> > standardized extensions (which will warn if `-std` is too early) and (b) 
> > 'extensions' that are more like "Clang will accept your buggy code" than 
> > features.  Most GNU extensions are just Extension, so I think it makes 
> > sense to do the same for `__auto_type`.
> > 
> > I could update the C++ test to add `-pedantic`, but arguably it makes more 
> > sense to test the fact that the warning is not emitted by default.
> I'm not sure either. `typeof` warns with -std=c++14 but not with 
> -std=gnu++14. From a user perspective, this makes sense to me: I want to 
> write standard c++ and I want the compiler to help me with that, but I don't 
> want to get all the pedantic warnings that -pedantic entails. For example, 
> consider using clang-cl to build Windows code, and wanting MSVC to be able to 
> build said Windows code too. (This can of course go wrong with standard C++ 
> too, but in that case I'm running into MSVC bugs which will eventually be 
> fixed.) So if it's possible to match how typeof works, I think that'd be 
> good. If it's not possible, this wouldn't be the only GNU extension allowed 
> in -std=c++14 mode though, so it's not a big thing.
As far as I can tell, `typeof` doesn't warn at all.  In standard mode it's an 
*error* because `typeof` is treated as a normal identifier (so that code that 
uses it as such doesn't break), but if you use the reserved-namespace keyword 
`__typeof`, there is no warning even with `-Weverything`.


http://reviews.llvm.org/D12686



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

Re: [PATCH] D12686: Add support for GCC's '__auto_type' extension.

[Nico Weber via cfe-commits]

thakis added inline comments.


Comment at: test/SemaCXX/auto-type-from-cxx.cpp:14
@@ +13,3 @@
+  auto _ = [](__auto_type f) {}; // expected-error {{'__auto_type' not allowed 
in lambda parameter}}
+  __auto_type g = 2;
+  struct BitField { int field:2; };

comex wrote:
> thakis wrote:
> > comex wrote:
> > > thakis wrote:
> > > > Shouldn't this say "warning: __auto_type is a gnu extension" (since 
> > > > this uses -std=c++14, not -std=gnu++14)?
> > > Hmm... when I added `ext_auto_type` to the .td, I didn't notice the 
> > > difference between Extension and ExtWarn.  Since the patch currently uses 
> > > Extension, it won't warn by default, but will with `-pedantic`, `-Wgnu`, 
> > > or `-Wgnu-auto-type`.  The C test uses `-pedantic` so it gets the warning.
> > > 
> > > Is there an explicit policy on which extensions should be ExtWarn?  
> > > Looking at the rest of that file, ExtWarns seem to be mostly either (a) 
> > > standardized extensions (which will warn if `-std` is too early) and (b) 
> > > 'extensions' that are more like "Clang will accept your buggy code" than 
> > > features.  Most GNU extensions are just Extension, so I think it makes 
> > > sense to do the same for `__auto_type`.
> > > 
> > > I could update the C++ test to add `-pedantic`, but arguably it makes 
> > > more sense to test the fact that the warning is not emitted by default.
> > I'm not sure either. `typeof` warns with -std=c++14 but not with 
> > -std=gnu++14. From a user perspective, this makes sense to me: I want to 
> > write standard c++ and I want the compiler to help me with that, but I 
> > don't want to get all the pedantic warnings that -pedantic entails. For 
> > example, consider using clang-cl to build Windows code, and wanting MSVC to 
> > be able to build said Windows code too. (This can of course go wrong with 
> > standard C++ too, but in that case I'm running into MSVC bugs which will 
> > eventually be fixed.) So if it's possible to match how typeof works, I 
> > think that'd be good. If it's not possible, this wouldn't be the only GNU 
> > extension allowed in -std=c++14 mode though, so it's not a big thing.
> As far as I can tell, `typeof` doesn't warn at all.  In standard mode it's an 
> *error* because `typeof` is treated as a normal identifier (so that code that 
> uses it as such doesn't break), but if you use the reserved-namespace keyword 
> `__typeof`, there is no warning even with `-Weverything`.
Ah, ok. That's ok as-is then. It'd be nice if there was something that warning 
on GNU extensions, but that's independent of this patch :-)


http://reviews.llvm.org/D12686



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

Re: [PATCH] D6700: Instantiate UnresolvedLookupExpr to MemberExpr when appropriate

[Reid Kleckner via cfe-commits]

rnk added a comment.

Richard suggested that maybe we formed the wrong AST while parsing the 
template. I'm not sure that's the case. We have this very explicit logic that 
controls what AST nodes we form in SemaExprMember.cpp 
ClassifyImplicitMemberAccess:

  bool isStaticContext = SemaRef.CXXThisTypeOverride.isNull() &&
(!isa(DC) || cast(DC)->isStatic());
  if (R.isUnresolvableResult())
return isStaticContext ? IMA_Unresolved_StaticContext : IMA_Unresolved;

John wrote this code in r90266. The behavior seems pretty intentional, so think 
we're forming the right AST for the template. Our AST just anticipates that 
it's going to be instantiated with a base class where the member in question is 
static.

I think we just need some extra diagnostics during instantiation, which this 
change implements as-is. What do you think? I'll reupload without the other 
changes.


http://reviews.llvm.org/D6700



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

Re: [PATCH] D7639: Add readability-redundant-void-arg check to clang-tidy

[Eugene Zelenko via cfe-commits]

Eugene.Zelenko added a subscriber: Eugene.Zelenko.
Eugene.Zelenko added a comment.

What is preventing to add this check to Clang-tidy? Just found another piece of 
fresh C++ code in LLDB with (void) as argument list...


http://reviews.llvm.org/D7639



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

Re: [PATCH] D13326: [PGO]: Eliminate __llvm_profile_register calls for Linux (clang changes)

[David Li via cfe-commits]

davidxl abandoned this revision.
davidxl added a comment.

The refactoring is done by a previous patch already.


http://reviews.llvm.org/D13326



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

Re: [PATCH] D6700: Instantiate UnresolvedLookupExpr to MemberExpr when appropriate

[Reid Kleckner via cfe-commits]

rnk updated this revision to Diff 37283.
rnk added a comment.

- Rebase


http://reviews.llvm.org/D6700

Files:
  lib/Sema/TreeTransform.h
  test/SemaTemplate/instantiate-using-decl.cpp

Index: test/SemaTemplate/instantiate-using-decl.cpp
===
--- test/SemaTemplate/instantiate-using-decl.cpp
+++ test/SemaTemplate/instantiate-using-decl.cpp
@@ -104,3 +104,26 @@
 x.f();
   }
 }
+
+namespace PR21923 {
+struct A {
+  int member;
+  void method();
+};
+template 
+struct B : public T {
+  using T::member;
+  using T::method;
+  static void StaticFun() {
+(void)member; // expected-error {{invalid use of member 'member' in static 
member function}}
+(void)B::member; // expected-error {{invalid use of member 'member' in 
static member function}}
+method(); // expected-error {{call to non-static member function without 
an object argument}}
+  }
+  void InstanceFun() {
+(void)member;
+(void)B::member;
+method();
+  }
+};
+template class B; // expected-note 1 {{requested here}}
+}
Index: lib/Sema/TreeTransform.h
===
--- lib/Sema/TreeTransform.h
+++ lib/Sema/TreeTransform.h
@@ -9128,8 +9128,19 @@
 
   // If we have neither explicit template arguments, nor the template keyword,
   // it's a normal declaration name.
-  if (!Old->hasExplicitTemplateArgs() && !TemplateKWLoc.isValid())
+  if (!Old->hasExplicitTemplateArgs() && !TemplateKWLoc.isValid()) {
+// If this resolved to a data member, do member reference semantic analysis
+// and possibly form a MemberExpr.
+if (NamedDecl *D = R.getAsSingle()) {
+  D = D->getUnderlyingDecl();
+  if (isa(D) || isa(D) ||
+  isa(D))
+return getSema().BuildPossibleImplicitMemberExpr(
+SS, SourceLocation(), R, /*TemplateArgs=*/nullptr,
+/*Scope=*/nullptr);
+}
 return getDerived().RebuildDeclarationNameExpr(SS, R, Old->requiresADL());
+  }
 
   // If we have template arguments, rebuild them, then rebuild the
   // templateid expression.


Index: test/SemaTemplate/instantiate-using-decl.cpp
===
--- test/SemaTemplate/instantiate-using-decl.cpp
+++ test/SemaTemplate/instantiate-using-decl.cpp
@@ -104,3 +104,26 @@
 x.f();
   }
 }
+
+namespace PR21923 {
+struct A {
+  int member;
+  void method();
+};
+template 
+struct B : public T {
+  using T::member;
+  using T::method;
+  static void StaticFun() {
+(void)member; // expected-error {{invalid use of member 'member' in static member function}}
+(void)B::member; // expected-error {{invalid use of member 'member' in static member function}}
+method(); // expected-error {{call to non-static member function without an object argument}}
+  }
+  void InstanceFun() {
+(void)member;
+(void)B::member;
+method();
+  }
+};
+template class B; // expected-note 1 {{requested here}}
+}
Index: lib/Sema/TreeTransform.h
===
--- lib/Sema/TreeTransform.h
+++ lib/Sema/TreeTransform.h
@@ -9128,8 +9128,19 @@
 
   // If we have neither explicit template arguments, nor the template keyword,
   // it's a normal declaration name.
-  if (!Old->hasExplicitTemplateArgs() && !TemplateKWLoc.isValid())
+  if (!Old->hasExplicitTemplateArgs() && !TemplateKWLoc.isValid()) {
+// If this resolved to a data member, do member reference semantic analysis
+// and possibly form a MemberExpr.
+if (NamedDecl *D = R.getAsSingle()) {
+  D = D->getUnderlyingDecl();
+  if (isa(D) || isa(D) ||
+  isa(D))
+return getSema().BuildPossibleImplicitMemberExpr(
+SS, SourceLocation(), R, /*TemplateArgs=*/nullptr,
+/*Scope=*/nullptr);
+}
 return getDerived().RebuildDeclarationNameExpr(SS, R, Old->requiresADL());
+  }
 
   // If we have template arguments, rebuild them, then rebuild the
   // templateid expression.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D12726: [analyzer] A fix for symbolic element region index lifetime.

[Artem Dergachev via cfe-commits]

NoQ updated this revision to Diff 37263.
NoQ added a comment.

Hmm, i think i'm ready to explain most of the stuff.

- First of all, the piece of code in `EnvironmentManager::removeDeadBindings()` 
i mentioned above is truly useless; everything would be marked as live anyway 
on the next line.

- Then, in `RegionStore`, in `VisitBinding()`, `markLive()` of the whole region 
value inside the binding is indeed correct, and i provide a pretty 
straightforward test;

- Finally, in `VisitCluster()`, it's a bit more complicated, and i suggest that 
`markLive()` is unnecessary here, and in fact does very little if anything, so 
it's hard to test even with stuff we have now:
  - i guess we shouldn't think of a region as live, simply because it has 
bindings, in a procedure designed for removing bindings;
  - however, marking the region as live here wouldn't save the bindings; they 
would later be removed simply because they weren't visited;
  - liveness of the region would also extend lifetime of a few symbols that 
depend on it, such as its `SymbolRegionValue`, `SymbolExtent`, and 
`SymbolMetadata`, however because the binding would be dead anyway, these 
symbols would die on the next pass;
- note that `SymbolRegionValue` should explicitly be dead when the region 
has other bindings, so we certainly shouldn't try to preserve the region only 
to save `SymbolRegionValue`;
  - see also http://reviews.llvm.org/D5104 ; i also think i accidentally 
wrote the missing test for this ticket, will put it there;
  - another place that relies on region liveness information collected on these 
passes is Dynamic Type Propagation, however the same arguments apply; it would 
only delay the inevitable.

So the real question is whether (or rather how) the `Store` should maintain 
correct region liveness information after completing its internal garbage 
collection pass, because there are, in fact, other users of this information 
later in the chain, but this seems to be a larger problem without instantly 
noticeable effects.

The new diff removes dead code in `Environment` and tests and fixes the 
separate bug in the `Store` that caused reaping of constraints on 
`SymbolRegionValue` (and a few other kinds of `SymbolData`) too early when the 
only place where the related region is stored is a store value.


http://reviews.llvm.org/D12726

Files:
  docs/analyzer/DebugChecks.rst
  include/clang/StaticAnalyzer/Core/PathSensitive/SymbolManager.h
  lib/StaticAnalyzer/Checkers/ExprInspectionChecker.cpp
  lib/StaticAnalyzer/Core/Environment.cpp
  lib/StaticAnalyzer/Core/RegionStore.cpp
  lib/StaticAnalyzer/Core/SymbolManager.cpp
  test/Analysis/return-ptr-range.cpp
  test/Analysis/symbol-reaper.c

Index: test/Analysis/symbol-reaper.c
===
--- test/Analysis/symbol-reaper.c
+++ test/Analysis/symbol-reaper.c
@@ -0,0 +1,77 @@
+// RUN: %clang_cc1 -analyze -analyzer-checker=debug.ExprInspection -verify %s
+
+void clang_analyzer_eval(int);
+void clang_analyzer_warnOnDeadSymbol(int);
+void clang_analyzer_warnIfReached();
+
+int conjure_index();
+
+void test_that_expr_inspection_works() {
+  do {
+int x = conjure_index();
+clang_analyzer_warnOnDeadSymbol(x);
+  } while(0); // expected-warning{{SYMBOL DEAD}}
+}
+
+// These tests verify the reaping of symbols that are only referenced as
+// index values in element regions. Most of the time, depending on where
+// the element region, as Loc value, is stored, it is possible to
+// recover the index symbol in checker code, which is also demonstrated
+// in the return_ptr_range.c test file.
+
+int arr[3];
+
+int *test_element_index_lifetime_in_environment_values() {
+  int *ptr;
+  do {
+int x = conjure_index();
+clang_analyzer_warnOnDeadSymbol(x);
+ptr = arr + x;
+  } while (0);
+  return ptr;
+}
+
+void test_element_index_lifetime_in_store_keys() {
+  do {
+int x = conjure_index();
+clang_analyzer_warnOnDeadSymbol(x);
+arr[x] = 1;
+if (x) {}
+  } while (0); // no-warning
+}
+
+int *ptr;
+void test_element_index_lifetime_in_store_values() {
+  do {
+int x = conjure_index();
+clang_analyzer_warnOnDeadSymbol(x);
+ptr = arr + x;
+  } while (0); // no-warning
+}
+
+struct S1 {
+  int field;
+};
+struct S2 {
+  struct S1 array[5];
+} s2;
+
+void test_element_index_lifetime_with_complicated_hierarchy_of_regions() {
+  do {
+int x = conjure_index();
+clang_analyzer_warnOnDeadSymbol(x);
+s2.array[x].field = 1;
+if (x) {}
+  } while (0); // no-warning
+}
+
+// Test below checks lifetime of SymbolRegionValue in certain conditions.
+
+int **ptrptr;
+void test_region_lifetime_as_store_value(int *x) {
+  clang_analyzer_warnOnDeadSymbol((int) x);
+  *x = 1;
+  ptrptr = 
+  (void)0; // No-op; make sure the environment forgets things and the GC runs.
+  clang_analyzer_eval(**ptrptr); // expected-warning{{TRUE}}
+} // no-warning
Index: test/Analysis/return-ptr-range.cpp

Re: [PATCH] D12726: [analyzer] A fix for symbolic element region index lifetime.

[Artem Dergachev via cfe-commits]

NoQ updated this revision to Diff 37266.
NoQ added a comment.

Whoops accidentally left out a dead code line in tests.


http://reviews.llvm.org/D12726

Files:
  docs/analyzer/DebugChecks.rst
  include/clang/StaticAnalyzer/Core/PathSensitive/SymbolManager.h
  lib/StaticAnalyzer/Checkers/ExprInspectionChecker.cpp
  lib/StaticAnalyzer/Core/Environment.cpp
  lib/StaticAnalyzer/Core/RegionStore.cpp
  lib/StaticAnalyzer/Core/SymbolManager.cpp
  test/Analysis/return-ptr-range.cpp
  test/Analysis/symbol-reaper.c

Index: test/Analysis/symbol-reaper.c
===
--- test/Analysis/symbol-reaper.c
+++ test/Analysis/symbol-reaper.c
@@ -0,0 +1,78 @@
+// RUN: %clang_cc1 -analyze -analyzer-checker=debug.ExprInspection -verify %s
+
+void clang_analyzer_eval(int);
+void clang_analyzer_warnOnDeadSymbol(int);
+
+int conjure_index();
+
+void test_that_expr_inspection_works() {
+  do {
+int x = conjure_index();
+clang_analyzer_warnOnDeadSymbol(x);
+  } while(0); // expected-warning{{SYMBOL DEAD}}
+}
+
+// These tests verify the reaping of symbols that are only referenced as
+// index values in element regions. Most of the time, depending on where
+// the element region, as Loc value, is stored, it is possible to
+// recover the index symbol in checker code, which is also demonstrated
+// in the return_ptr_range.c test file.
+
+int arr[3];
+
+int *test_element_index_lifetime_in_environment_values() {
+  int *ptr;
+  do {
+int x = conjure_index();
+clang_analyzer_warnOnDeadSymbol(x);
+ptr = arr + x;
+  } while (0);
+  return ptr;
+}
+
+void test_element_index_lifetime_in_store_keys() {
+  do {
+int x = conjure_index();
+clang_analyzer_warnOnDeadSymbol(x);
+arr[x] = 1;
+if (x) {}
+  } while (0); // no-warning
+}
+
+int *ptr;
+void test_element_index_lifetime_in_store_values() {
+  do {
+int x = conjure_index();
+clang_analyzer_warnOnDeadSymbol(x);
+ptr = arr + x;
+  } while (0); // no-warning
+}
+
+struct S1 {
+  int field, other_field;
+};
+struct S2 {
+  struct S1 array[5];
+} s2;
+
+void test_element_index_lifetime_with_complicated_hierarchy_of_regions() {
+  do {
+int x = conjure_index();
+clang_analyzer_warnOnDeadSymbol(x);
+s2.array[x].field = 1;
+if (x) {}
+  } while (0); // no-warning
+}
+
+// Test below checks lifetime of SymbolRegionValue in certain conditions.
+// SymbolRegionValue should live as long as its region is live but has no
+// direct bindings that override its value.
+
+int **ptrptr;
+void test_region_lifetime_as_store_value(int *x) {
+  clang_analyzer_warnOnDeadSymbol((int) x);
+  *x = 1;
+  ptrptr = 
+  (void)0; // No-op; make sure the environment forgets things and the GC runs.
+  clang_analyzer_eval(**ptrptr); // expected-warning{{TRUE}}
+} // no-warning
Index: test/Analysis/return-ptr-range.cpp
===
--- test/Analysis/return-ptr-range.cpp
+++ test/Analysis/return-ptr-range.cpp
@@ -0,0 +1,27 @@
+// RUN: %clang_cc1 -analyze -analyzer-checker=alpha.security.ReturnPtrRange -verify %s
+
+int arr[10];
+int *ptr;
+
+int conjure_index();
+
+int *test_element_index_lifetime() {
+  do {
+int x = conjure_index();
+ptr = arr + x;
+if (x != 20)
+  return arr; // no-warning
+  } while (0);
+  return ptr; // expected-warning{{Returned pointer value points outside the original object (potential buffer overflow)}}
+}
+
+int *test_element_index_lifetime_with_local_ptr() {
+  int *local_ptr;
+  do {
+int x = conjure_index();
+local_ptr = arr + x;
+if (x != 20)
+  return arr; // no-warning
+  } while (0);
+  return local_ptr; // expected-warning{{Returned pointer value points outside the original object (potential buffer overflow)}}
+}
Index: lib/StaticAnalyzer/Core/SymbolManager.cpp
===
--- lib/StaticAnalyzer/Core/SymbolManager.cpp
+++ lib/StaticAnalyzer/Core/SymbolManager.cpp
@@ -391,6 +391,18 @@
 
 void SymbolReaper::markLive(const MemRegion *region) {
   RegionRoots.insert(region);
+  markElementIndicesLive(region);
+}
+
+void SymbolReaper::markElementIndicesLive(const MemRegion *region) {
+  for (auto SR = dyn_cast(region); SR;
+   SR = dyn_cast(SR->getSuperRegion())) {
+if (auto ER = dyn_cast(SR)) {
+  SVal Idx = ER->getIndex();
+  for (auto SI = Idx.symbol_begin(), SE = Idx.symbol_end(); SI != SE; ++SI)
+markLive(*SI);
+}
+  }
 }
 
 void SymbolReaper::markInUse(SymbolRef sym) {
Index: lib/StaticAnalyzer/Core/RegionStore.cpp
===
--- lib/StaticAnalyzer/Core/RegionStore.cpp
+++ lib/StaticAnalyzer/Core/RegionStore.cpp
@@ -2344,8 +2344,12 @@
   if (const SymbolicRegion *SymR = dyn_cast(baseR))
 SymReaper.markLive(SymR->getSymbol());
 
-  for (ClusterBindings::iterator I = C->begin(), E = C->end(); I != E; ++I)
+  for (ClusterBindings::iterator I = 

[PATCH] D13704: [Fix] Allow implicit conversions of the address of overloadable functions in C + docs update

[George Burgess IV via cfe-commits]

george.burgess.iv created this revision.
george.burgess.iv added a reviewer: rsmith.
george.burgess.iv added a subscriber: cfe-commits.

Two smallish patches in one. Happy to split into two (for review and/or commit) 
if that's preferred.

In C, we allow (as an extension) incompatible pointer conversions, like so:

```
int foo(int *);
int (*p)(void *) = foo; // Compiles; warns if -Wincompatible-pointer-types is 
specified
```

So, we should provide primitive support for this with overloadable functions. 
Specifically, this patch is trying to fix cases like this:

```
int foo(void *) __attribute__((overloadable));
int foo(double *d) __attribute__((overloadable, enable_if(d != nullptr, "")));

int (*p)(int *) = foo; // Before patch, error because we couldn't match the 
function type exactly. After patch, we see that 'int foo(void *)' is the only 
option, and choose it. A warning is emitted if -Wincompatible-pointer-types is 
given
```

Which means that explicit casts are necessary if there's more than one overload 
that isn't disabled by enable_if attrs. The updated docs have an example of 
this, but here's another:

```
int foo(void *) __attribute__((overloadable));
int foo(double *d) __attribute__((overloadable));

int (*p)(int *) = foo; // 0 candidates before patch, 2 after. Won't compile 
either way.
int (*p2)(int *) = (int (*)(void *))foo; // OK. Issues warning if 
-Wincompatible-pointer-types is given
```

http://reviews.llvm.org/D13704

Files:
  include/clang/Basic/AttrDocs.td
  lib/Sema/SemaOverload.cpp
  test/CodeGen/overloadable.c
  test/Sema/overloadable.c

Index: test/Sema/overloadable.c
===
--- test/Sema/overloadable.c
+++ test/Sema/overloadable.c
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s
+// RUN: %clang_cc1 -fsyntax-only -verify %s -Wincompatible-pointer-types
 
 int var __attribute__((overloadable)); // expected-error{{'overloadable' attribute only applies to functions}}
 void params(void) __attribute__((overloadable(12))); // expected-error {{'overloadable' attribute takes no arguments}}
@@ -99,3 +99,24 @@
   unsigned char *c;
   multi_type(c);
 }
+
+// Ensure that we allow C-specific type conversions in C
+void fn_type_conversions() {
+  void foo(void *c) __attribute__((overloadable));
+  void foo(char *c) __attribute__((overloadable));
+  void (*ptr1)(void *) = 
+  void (*ptr2)(char *) = 
+  void (*ambiguous)(int *) =  // expected-error{{initializing 'void (*)(int *)' with an expression of incompatible type ''}} expected-note@105{{candidate function}} expected-note@106{{candidate function}}
+  void *vp_ambiguous =  // expected-error{{initializing 'void *' with an expression of incompatible type ''}} expected-note@105{{candidate function}} expected-note@106{{candidate function}}
+
+  void (*specific1)(int *) = (void (*)(void *)) // expected-warning{{incompatible pointer types initializing 'void (*)(int *)' with an expression of type 'void (*)(void *)'}}
+  void *specific2 = (void (*)(void *))
+
+  void disabled(void *c) __attribute__((overloadable, enable_if(0, "")));
+  void disabled(int *c) __attribute__((overloadable, enable_if(0, "")));
+  void disabled(char *c) __attribute__((overloadable, enable_if(1, "The function name lies.")));
+  // To be clear, these should all point to the last overload of 'disabled'
+  void (*dptr1)(char *c) = 
+  void (*dptr2)(void *c) =  // expected-warning{{incompatible pointer types initializing 'void (*)(void *)' with an expression of type ''}} expected-note@115{{candidate function made ineligible by enable_if}} expected-note@116{{candidate function made ineligible by enable_if}} expected-note@117{{candidate function has type mismatch at 1st parameter (expected 'void *' but has 'char *')}} 
+  void *specific_disabled = 
+}
Index: test/CodeGen/overloadable.c
===
--- test/CodeGen/overloadable.c
+++ test/CodeGen/overloadable.c
@@ -29,3 +29,33 @@
   cdv = f(cdv);
   vv = f(vv);
 }
+
+// Ensuring that we pick the correct function for taking the address of an
+// overload when conversions are involved.
+
+void addrof_many(int *a) __attribute__((overloadable, enable_if(0, "")));
+void addrof_many(void *a) __attribute__((overloadable));
+void addrof_many(char *a) __attribute__((overloadable));
+
+void addrof_single(int *a) __attribute__((overloadable, enable_if(0, "")));
+void addrof_single(char *a) __attribute__((overloadable, enable_if(0, "")));
+void addrof_single(char *a) __attribute__((overloadable));
+
+// CHECK-LABEL: define void @foo
+void foo() {
+  // CHECK: store void (i8*)* @_Z11addrof_manyPc
+  void (*p1)(char *) = _many;
+  // CHECK: store void (i8*)* @_Z11addrof_manyPv
+  void (*p2)(void *) = _many;
+  // CHECK: void (i8*)* @_Z11addrof_manyPc
+  void *vp1 = (void (*)(char *)) & addrof_many;
+  // CHECK: void (i8*)* @_Z11addrof_manyPv
+  void *vp2 = (void (*)(void *)) & addrof_many;
+
+  // CHECK: store 

[clang-tools-extra] r250194 - Updating the documentation for the readability-inconsistent-declaration-parameter-name checker.

[Aaron Ballman via cfe-commits]

Author: aaronballman
Date: Tue Oct 13 13:13:10 2015
New Revision: 250194

URL: http://llvm.org/viewvc/llvm-project?rev=250194=rev
Log:
Updating the documentation for the 
readability-inconsistent-declaration-parameter-name checker.

Patch by Piotr Dziwinski.

Modified:

clang-tools-extra/trunk/docs/clang-tidy/checks/readability-inconsistent-declaration-parameter-name.rst

Modified: 
clang-tools-extra/trunk/docs/clang-tidy/checks/readability-inconsistent-declaration-parameter-name.rst
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/docs/clang-tidy/checks/readability-inconsistent-declaration-parameter-name.rst?rev=250194=250193=250194=diff
==
--- 
clang-tools-extra/trunk/docs/clang-tidy/checks/readability-inconsistent-declaration-parameter-name.rst
 (original)
+++ 
clang-tools-extra/trunk/docs/clang-tidy/checks/readability-inconsistent-declaration-parameter-name.rst
 Tue Oct 13 13:13:10 2015
@@ -28,5 +28,16 @@ function declarations, for example:
void foo(int a);
void foo(int); // no warning
 
-If there are multiple declarations of same function, only one warning will be
-generated.
+To help with refactoring, in some cases FixIt hints are generated to align
+parameter names to a single naming convention. This works with the assumption
+that the function definition is the most up-to-date version, as it directly
+references parameter names in its body. Example:
+
+.. code:: c++
+
+   void foo(int a); // warning and FixIt hint (replace "a" to "b")
+   int foo(int b) { return b + 2; } // definition with use of "b"
+
+In the case of multiple redeclarations or function template specializations,
+a warning is issued for every redeclaration or specialization inconsistent with
+the definition or the first declaration seen in a translation unit.


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

r250196 - [CMake] When building clang as an external project we should pass through all variables that start with COMPILER_RT

[Chris Bieneman via cfe-commits]

Author: cbieneman
Date: Tue Oct 13 13:17:30 2015
New Revision: 250196

URL: http://llvm.org/viewvc/llvm-project?rev=250196=rev
Log:
[CMake] When building clang as an external project we should pass through all 
variables that start with COMPILER_RT

Modified:
cfe/trunk/runtime/CMakeLists.txt

Modified: cfe/trunk/runtime/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/runtime/CMakeLists.txt?rev=250196=250195=250196=diff
==
--- cfe/trunk/runtime/CMakeLists.txt (original)
+++ cfe/trunk/runtime/CMakeLists.txt Tue Oct 13 13:17:30 2015
@@ -44,6 +44,16 @@ if(LLVM_BUILD_EXTERNAL_COMPILER_RT AND E
 COMMENT "Clobberring compiler-rt build and stamp directories"
 )
 
+  # Find all variables that start with COMPILER_RT and populate a variable with
+  # them.
+  get_cmake_property(variableNames VARIABLES)
+  foreach(varaibleName ${variableNames})
+if(${varaibleName} MATCHES "^COMPILER_RT")
+  list(APPEND COMPILER_RT_PASSTHROUGH_VARIABLES
+-D${varaibleName}=${${varaibleName}})
+endif()
+  endforeach()
+
   ExternalProject_Add(compiler-rt
 PREFIX ${COMPILER_RT_PREFIX}
 SOURCE_DIR ${COMPILER_RT_SRC_ROOT}
@@ -59,6 +69,7 @@ if(LLVM_BUILD_EXTERNAL_COMPILER_RT AND E

-DCOMPILER_RT_INSTALL_PATH=${CMAKE_INSTALL_PREFIX}/lib${LLVM_LIBDIR_SUFFIX}/clang/${CLANG_VERSION}
-DCOMPILER_RT_INCLUDE_TESTS=${LLVM_INCLUDE_TESTS}
-DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}
+   ${COMPILER_RT_PASSTHROUGH_VARIABLES}
 INSTALL_COMMAND ""
 STEP_TARGETS configure build
 ${cmake_3_4_USES_TERMINAL_OPTIONS}


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

r250203 - Move the adc-builtins test to the pattern of the other builtins

[Eric Christopher via cfe-commits]

Author: echristo
Date: Tue Oct 13 13:40:21 2015
New Revision: 250203

URL: http://llvm.org/viewvc/llvm-project?rev=250203=rev
Log:
Move the adc-builtins test to the pattern of the other builtins
tests by predefining _MM_MALLOC_H rather than use -ffreestanding.

Modified:
cfe/trunk/test/CodeGen/adc-builtins.c

Modified: cfe/trunk/test/CodeGen/adc-builtins.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/adc-builtins.c?rev=250203=250202=250203=diff
==
--- cfe/trunk/test/CodeGen/adc-builtins.c (original)
+++ cfe/trunk/test/CodeGen/adc-builtins.c Tue Oct 13 13:40:21 2015
@@ -1,4 +1,6 @@
-// RUN: %clang_cc1 -triple x86_64-unknown-unknown -ffreestanding -emit-llvm -o 
- %s | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -emit-llvm -o - %s | 
FileCheck %s
+
+#define __MM_MALLOC_H
 
 #include 
 


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

r250202 - Add subtarget feature support for 3dnowa to the 3dnowa intrinsics.

[Eric Christopher via cfe-commits]

Author: echristo
Date: Tue Oct 13 13:40:17 2015
New Revision: 250202

URL: http://llvm.org/viewvc/llvm-project?rev=250202=rev
Log:
Add subtarget feature support for 3dnowa to the 3dnowa intrinsics.

Modified:
cfe/trunk/lib/Headers/mm3dnow.h

Modified: cfe/trunk/lib/Headers/mm3dnow.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/mm3dnow.h?rev=250202=250201=250202=diff
==
--- cfe/trunk/lib/Headers/mm3dnow.h (original)
+++ cfe/trunk/lib/Headers/mm3dnow.h Tue Oct 13 13:40:17 2015
@@ -132,6 +132,10 @@ _m_pmulhrw(__m64 __m1, __m64 __m2) {
   return (__m64)__builtin_ia32_pmulhrw((__v4hi)__m1, (__v4hi)__m2);
 }
 
+/* Handle the 3dnowa instructions here. */
+#undef __DEFAULT_FN_ATTRS
+#define __DEFAULT_FN_ATTRS __attribute__((__always_inline__, __nodebug__, 
__target__("3dnowa")))
+
 static __inline__ __m64 __DEFAULT_FN_ATTRS
 _m_pf2iw(__m64 __m) {
   return (__m64)__builtin_ia32_pf2iw((__v2sf)__m);


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

Re: [libcxx] r249738 - Split out of .

[Adrian Prantl via cfe-commits]

Hi Richard,

this commit appears to break the module self-host on Darwin.

When compiling the following program generated by clang’s own cmake script:

> #undef NDEBUG
> #include 
> #define NDEBUG
> #include 
> int main() { assert(this code is not compiled); }

with clang++ -std=c++11 -fmodules -fcxx-modules test.cpp
I get 

> While building module 'std' imported from 
> /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:
> While building module 'Darwin' imported from 
> /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:
> In file included from :98:
> In file included from 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/wchar.h:92:
> In file included from 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/_wctype.h:57:
> /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/ctype.h:33:10:
>  fatal error: cyclic dependency in module 'std': std -> Darwin -> std
> #include <__config>
>  ^
> While building module 'std' imported from 
> /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:
> In file included from :1:
> In file included from 
> /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/algorithm:624:
> In file included from 
> /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/initializer_list:47:
> /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:10:
>  fatal error: could not build module 'Darwin'
> #include 
>  ^
> In file included from test.cpp:2:
> /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:10:
>  fatal error: could not build module 'std'
> #include <__config>
>  ^
> 3 errors generated.

Let me know how I can help in diagnosing what’s going on here.
Once this works, I’d like to to set up a green dragon bot that builds clang 
with LLVM_ENABLE_MODULES to catch similar problems earlier.

-- adrian

> On Oct 8, 2015, at 1:36 PM, Richard Smith via cfe-commits 
>  wrote:
> 
> Author: rsmith
> Date: Thu Oct  8 15:36:30 2015
> New Revision: 249738
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=249738=rev
> Log:
> Split  out of .
> 
> Added:
>libcxx/trunk/include/ctype.h
>  - copied, changed from r249736, libcxx/trunk/include/cctype
> Modified:
>libcxx/trunk/include/cctype
>libcxx/trunk/test/std/strings/c.strings/cctype.pass.cpp
> 
> Modified: libcxx/trunk/include/cctype
> URL: 
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/cctype?rev=249738=249737=249738=diff
> ==
> --- libcxx/trunk/include/cctype (original)
> +++ libcxx/trunk/include/cctype Thu Oct  8 15:36:30 2015
> @@ -37,10 +37,6 @@ int toupper(int c);
> 
> #include <__config>
> #include 
> -#if defined(_LIBCPP_MSVCRT)
> -#include "support/win32/support.h"
> -#include "support/win32/locale_win32.h"
> -#endif // _LIBCPP_MSVCRT
> 
> #if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
> #pragma GCC system_header
> @@ -48,33 +44,19 @@ int toupper(int c);
> 
> _LIBCPP_BEGIN_NAMESPACE_STD
> 
> -#undef isalnum
> using ::isalnum;
> -#undef isalpha
> using ::isalpha;
> -#undef isblank
> using ::isblank;
> -#undef iscntrl
> using ::iscntrl;
> -#undef isdigit
> using ::isdigit;
> -#undef isgraph
> using ::isgraph;
> -#undef islower
> using ::islower;
> -#undef isprint
> using ::isprint;
> -#undef ispunct
> using ::ispunct;
> -#undef isspace
> using ::isspace;
> -#undef isupper
> using ::isupper;
> -#undef isxdigit
> using ::isxdigit;
> -#undef tolower
> using ::tolower;
> -#undef toupper
> using ::toupper;
> 
> _LIBCPP_END_NAMESPACE_STD
> 
> Copied: libcxx/trunk/include/ctype.h (from r249736, 
> libcxx/trunk/include/cctype)
> URL: 
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/ctype.h?p2=libcxx/trunk/include/ctype.h=libcxx/trunk/include/cctype=249736=249738=249738=diff
> ==
> --- libcxx/trunk/include/cctype (original)
> +++ libcxx/trunk/include/ctype.h Thu Oct  8 15:36:30 2015
> @@ -1,5 +1,5 @@
> // -*- C++ -*-
> -//=== cctype 
> --===//
> +//=== ctype.h 
> -===//
> //
> // The LLVM Compiler Infrastructure
> //
> @@ -8,14 +8,11 @@
> //
> //===--===//
> 
> -#ifndef _LIBCPP_CCTYPE
> -#define _LIBCPP_CCTYPE
> +#ifndef _LIBCPP_CTYPE_H
> +#define _LIBCPP_CTYPE_H
> 
> /*
> -cctype synopsis
> -
> -namespace std
> -{
> +ctype.h synopsis
> 
> int isalnum(int c);
> int isalpha(int c);
> @@ -31,52 +28,41 @@ int isupper(int c);

Re: [libcxx] r249798 - Split out of .

[Eric Fiselier via cfe-commits]

I would rather not do this if possible but I understand why we need to do
it.

Richard is there a cost associated with the 'extern "C++"' construct? or by
forcing the compiler to switch modes in general?




On Mon, Oct 12, 2015 at 12:27 PM, Richard Smith 
wrote:

> On Mon, Oct 12, 2015 at 9:41 AM, Steven Wu via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Hi Richard
>>
>> Your splitting seems causing problem when using extern "C". Here is a
>> test case:
>>
>> $ cat test.cpp
>> #ifdef __cplusplus
>> extern "C" {
>> #endif
>> #include 
>> #ifdef __cplusplus
>> }
>> #endif
>>
>> Error:
>> clang -fsyntax-only test.cpp
>> In file included from test.cpp:4:
>> In file included from /usr/bin/../include/c++/v1/stdio.h:102:
>> /usr/bin/../include/c++/v1/__config:593:1: error:
>>   templates must have C++ linkage
>> template  struct __static_assert_test;
>> ^~~
>> /usr/bin/../include/c++/v1/__config:594:20: error:
>>   explicit specialization of non-template struct
>> '__static_assert_test'
>> template <> struct __static_assert_test {};
>>^   ~~
>> /usr/bin/../include/c++/v1/__config:595:1: error:
>>   templates must have C++ linkage
>> template  struct __static_assert_check {};
>> ^~~
>> 3 errors generated.
>>
>> Because the code is actually compiled in C++, the guard in the header
>> failed to exclude the templates. In the meantime, I don't know if there are
>> ways to detect the header is in extern "C".
>>
>
> This was supposed to work, but apparently I only tested it when compiling
> as C++11; the static_assert emulation in C++98 mode needs some massaging to
> cope with this.
>
> Eric, Marshall: Are you OK with the attached patch? The idea is to make
> <__config> be fine to include in extern "C" or extern "C++" modes (and
> likewise for the  headers). This is something that comes up pretty
> often in practice (people wrap an include of a C header in 'extern "C"',
> and that C header includes a  file that libc++ provides).
>
>
>> Steven
>>
>>
>> > On Oct 8, 2015, at 6:29 PM, Richard Smith via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>> >
>> > Author: rsmith
>> > Date: Thu Oct  8 20:29:09 2015
>> > New Revision: 249798
>> >
>> > URL: http://llvm.org/viewvc/llvm-project?rev=249798=rev
>> > Log:
>> > Split  out of .
>> >
>> > As with , skip our custom header if __need_FILE or
>> __need___FILE is defined.
>> >
>> > Added:
>> >libcxx/trunk/include/stdio.h
>> >  - copied, changed from r249736, libcxx/trunk/include/cstdio
>> > Modified:
>> >libcxx/trunk/include/cstdio
>> >libcxx/trunk/test/std/depr/depr.c.headers/stdio_h.pass.cpp
>> >
>> > Modified: libcxx/trunk/include/cstdio
>> > URL:
>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/cstdio?rev=249798=249797=249798=diff
>> >
>> ==
>> > --- libcxx/trunk/include/cstdio (original)
>> > +++ libcxx/trunk/include/cstdio Thu Oct  8 20:29:09 2015
>> > @@ -103,16 +103,6 @@ void perror(const char* s);
>> > #pragma GCC system_header
>> > #endif
>> >
>> > -// snprintf
>> > -#if defined(_LIBCPP_MSVCRT)
>> > -#include "support/win32/support.h"
>> > -#endif
>> > -
>> > -#undef getc
>> > -#undef putc
>> > -#undef clearerr
>> > -#undef feof
>> > -#undef ferror
>> > _LIBCPP_BEGIN_NAMESPACE_STD
>> >
>> > using ::FILE;
>> >
>> > Copied: libcxx/trunk/include/stdio.h (from r249736,
>> libcxx/trunk/include/cstdio)
>> > URL:
>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/stdio.h?p2=libcxx/trunk/include/stdio.h=libcxx/trunk/include/cstdio=249736=249798=249798=diff
>> >
>> ==
>> > --- libcxx/trunk/include/cstdio (original)
>> > +++ libcxx/trunk/include/stdio.h Thu Oct  8 20:29:09 2015
>> > @@ -1,5 +1,5 @@
>> > // -*- C++ -*-
>> > -//=== cstdio
>> --===//
>> > +//=== stdio.h
>> -===//
>> > //
>> > // The LLVM Compiler Infrastructure
>> > //
>> > @@ -8,11 +8,19 @@
>> > //
>> >
>> //===--===//
>> >
>> > -#ifndef _LIBCPP_CSTDIO
>> > -#define _LIBCPP_CSTDIO
>> > +#if defined(__need_FILE) || defined(__need___FILE)
>> > +
>> > +#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
>> > +#pragma GCC system_header
>> > +#endif
>> > +
>> > +#include_next 
>> > +
>> > +#elif !defined(_LIBCPP_STDIO_H)
>> > +#define _LIBCPP_STDIO_H
>> >
>> > /*
>> > -cstdio synopsis
>> > +stdio.h synopsis
>> >
>> > Macros:
>> >
>> > @@ -33,9 +41,6 @@ Macros:
>> > stdin
>> > stdout
>> >
>> > -namespace std
>> > -{
>> > -
>> > Types:
>> >
>> > FILE
>> > @@ -92,20 +97,23 @@ void clearerr(FILE* stream);
>> > int feof(FILE* stream);
>> > int ferror(FILE* stream);
>> > void perror(const char* s);
>> > 

[clang-tools-extra] r250221 - Exposing an existing checker under the name cert-err61-cpp, as it corresponds to the CERT C++ secure coding rule: https://www.securecoding.cert.org/confluence/display/cpl

[Aaron Ballman via cfe-commits]

Author: aaronballman
Date: Tue Oct 13 15:42:41 2015
New Revision: 250221

URL: http://llvm.org/viewvc/llvm-project?rev=250221=rev
Log:
Exposing an existing checker under the name cert-err61-cpp, as it corresponds 
to the CERT C++ secure coding rule: 
https://www.securecoding.cert.org/confluence/display/cplusplus/ERR61-CPP.+Catch+exceptions+by+lvalue+reference

Modified:
clang-tools-extra/trunk/clang-tidy/cert/CERTTidyModule.cpp

Modified: clang-tools-extra/trunk/clang-tidy/cert/CERTTidyModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/cert/CERTTidyModule.cpp?rev=250221=250220=250221=diff
==
--- clang-tools-extra/trunk/clang-tidy/cert/CERTTidyModule.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/cert/CERTTidyModule.cpp Tue Oct 13 
15:42:41 2015
@@ -15,6 +15,7 @@
 #include "../misc/NewDeleteOverloadsCheck.h"
 #include "../misc/NonCopyableObjects.h"
 #include "../misc/StaticAssertCheck.h"
+#include "../misc/ThrowByValueCatchByReferenceCheck.h"
 #include "SetLongJmpCheck.h"
 #include "VariadicFunctionDefCheck.h"
 
@@ -39,6 +40,8 @@ public:
 // ERR
 CheckFactories.registerCheck(
 "cert-err52-cpp");
+CheckFactories.registerCheck(
+"cert-err61-cpp");
 
 // C checkers
 // DCL


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

Re: [PATCH] D6700: Diagnose UnresolvedLookupExprs that resolve to instance members in static methods

[John McCall via cfe-commits]

rjmccall added inline comments.


Comment at: lib/Sema/TreeTransform.h:9135
@@ +9134,3 @@
+if (NamedDecl *D = R.getAsSingle()) {
+  D = D->getUnderlyingDecl();
+  if (isa(D) || isa(D) ||

getAsSingle already looks through to the underlying decl.


Comment at: lib/Sema/TreeTransform.h:9138
@@ +9137,3 @@
+  isa(D))
+return getSema().BuildPossibleImplicitMemberExpr(
+SS, SourceLocation(), R, /*TemplateArgs=*/nullptr,

rnk wrote:
> I believe this will always fail, so one alternative way to do this would be 
> to add a stripped down entry point into Sema just for template instantiation 
> that diagnoses UnresolvedLookupExprs finding instance members.
At the very least, we should leave a comment explaining that we don't expect 
this to succeed, and that we're just doing this for diagnostic purposes.  Might 
want to assert that as well.


http://reviews.llvm.org/D6700



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

Re: [PATCH] D6700: Diagnose UnresolvedLookupExprs that resolve to instance members in static methods

[John McCall via cfe-commits]

rjmccall added a comment.

As a more general comment, I believe the rule is that we try to always make a 
MemberExpr/UnresolvedMemberExpr whenever there *might* be a base, but that the 
resulting distinction between an implicit-base UnresolvedMemberExpr and an 
UnresolvedLookupExpr is not actually used for anything in Sema.  When I wrote 
this code originally, I wanted to make sure we made the "right" decision early 
to leave plenty of room to handle language requirements that drove a stronger 
wedge between them, and that's probably still a good idea; but I'm pretty sure 
it's true that those requirements don't exist right now.  It does give you an 
invariant that you only see implicit-base MemberExprs and UnresolvedMemberExprs 
in contexts that actually have a 'this'.


http://reviews.llvm.org/D6700



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

Re: [PATCH] D13407: [libcxx] Capture configuration information when installing the libc++ headers

[Eric Fiselier via cfe-commits]

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

Maintainers from Apple and FreeBSD gave this the thumbs up.


http://reviews.llvm.org/D13407



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

Re: [PATCH] D13285: Fix for bug 24196: clang fails on assertion on complex doubles multiplication when EH is enabled

[John McCall via cfe-commits]

rjmccall added a comment.

This is an inappropriate fix for this problem.  If these runtime functions can 
never throw, which seems to be the case, you should create the function type 
with a no-throw exception specification, which will make EmitCall emit the call 
with a CallInst.  EST_BasicNoexcept should be sufficient.


http://reviews.llvm.org/D13285



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

Re: [PATCH] D12358: [Analyzer] Widening loops which do not exit

[Devin Coughlin via cfe-commits]

dcoughlin added a comment.

> There is a loss of precision for loops that need to be executed exactly 
> maxBlockVisitOnPath times, as the loop body is executed with the widened 
> state instead of the last iteration.


I think this is an acceptable loss of precision because, in general, it is 
unlikely that a concrete-bounded loop will be executed *exactly* 
maxBlockVisitOnPath times. You could add special syntactic checks to try to 
detect this, but I think it is unlikely to make much different in practice.



Comment at: lib/StaticAnalyzer/Core/LoopWidening.cpp:64
@@ +63,3 @@
+  }
+  return PrevState->invalidateRegions(Regions, getLoopCondition(LoopStmt),
+  BlockCount, LCtx, false, nullptr,

Passing `true` here instead of `false` for `CausedByPointerEscape` should fix 
the false alarm. This will cause invalidation to tell the MallocChecker that 
the pointer has escaped and so shouldn't be treated as a leak.


Comment at: test/Analysis/loop-widening.c:3
@@ +2,3 @@
+
+extern void clang_analyzer_eval(_Bool);
+extern void clang_analyzer_warnIfReached();

There seems to be some weirdness when using `_Bool` in the prototype (vs. int). 
It adds an extra `!= 0` to symbolic expressions, which can result in 
clang_analyzer_eval() yielding `UNKNOWN` when using `extern void 
clang_analyze_eval(int)` would print `TRUE` or `FALSE`.

We should track this down and fix it, but for now I think it is better to use 
`extern void clang_analyze_eval(int)`.


Comment at: test/Analysis/loop-widening.c:13
@@ +12,3 @@
+  int x = 1;
+  // Check loop isn't widened by checking x isn't invalidated
+  for (i = 0; i < 1; ++i) {}

This is clever.


Comment at: test/Analysis/loop-widening.c:111
@@ +110,3 @@
+  }
+  if (i < 50) {
+clang_analyzer_warnIfReached(); // no-warning

After changing the `clang_analyzer_eval()` prototype to take an int, you can 
use `clang_analyzer_eval(i >= 50); // expected-warning {{TRUE}}`.


Comment at: test/Analysis/loop-widening.c:158
@@ +157,3 @@
+  clang_analyzer_eval(h_ptr); // expected-warning {{UNKNOWN}}
+  free(h_ptr);
+}

I think it would be good to add some nested loop tests. For example:


```
void nested1() {
  int i = 0, j = 0;
  for (i = 0; i < 10; i++) {
clang_analyzer_eval(i < 10); // expected-warning {{TRUE}}
for (j = 0; j < 2; j++) {
  clang_analyzer_eval(j < 2); // expected-warning {{TRUE}}
}
clang_analyzer_eval(j >= 2); // expected-warning {{TRUE}}
  }
  clang_analyzer_eval(i >= 10); // expected-warning {{TRUE}}
}

void nested2() {
  int i = 0, j = 0;
  for (i = 0; i < 2; i++) {
clang_analyzer_eval(i < 2); // expected-warning {{TRUE}}
for (j = 0; j < 10; j++) {
  clang_analyzer_eval(j < 10); // expected-warning {{TRUE}}
}
clang_analyzer_eval(j >= 10); // expected-warning {{TRUE}}
  }
  clang_analyzer_eval(i >= 2); // expected-warning {{TRUE}}
}
```


http://reviews.llvm.org/D12358



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

[libcxx] r250235 - [libcxx] Capture configuration information when installing the libc++ headers

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Tue Oct 13 17:12:02 2015
New Revision: 250235

URL: http://llvm.org/viewvc/llvm-project?rev=250235=rev
Log:
[libcxx] Capture configuration information when installing the libc++ headers

Summary:
Hi all,

This patch is a successor to D11963. However it has changed dramatically and I 
felt it would be best to start a new review thread.

Please read the design documentation added in this patch for a description of 
how it works.

Reviewers: mclow.lists, danalbert, jroelofs, EricWF

Subscribers: vkalintiris, rnk, ed, espositofulvio, asl, eugenis, cfe-commits

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

Added:
libcxx/trunk/docs/DesignDocs/
libcxx/trunk/docs/DesignDocs/CapturingConfigInfo.rst
libcxx/trunk/include/__config_site.in
Modified:
libcxx/trunk/CMakeLists.txt
libcxx/trunk/cmake/Modules/HandleLibcxxFlags.cmake
libcxx/trunk/docs/index.rst
libcxx/trunk/include/CMakeLists.txt

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=250235=250234=250235=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Tue Oct 13 17:12:02 2015
@@ -260,13 +260,6 @@ endif()
 
 # Feature flags ===
 define_if(MSVC -D_CRT_SECURE_NO_WARNINGS)
-define_if_not(LIBCXX_ENABLE_GLOBAL_FILESYSTEM_NAMESPACE 
-D_LIBCPP_HAS_NO_GLOBAL_FILESYSTEM_NAMESPACE)
-define_if_not(LIBCXX_ENABLE_STDIN -D_LIBCPP_HAS_NO_STDIN)
-define_if_not(LIBCXX_ENABLE_STDOUT -D_LIBCPP_HAS_NO_STDOUT)
-define_if_not(LIBCXX_ENABLE_THREADS -D_LIBCPP_HAS_NO_THREADS)
-define_if_not(LIBCXX_ENABLE_MONOTONIC_CLOCK -D_LIBCPP_HAS_NO_MONOTONIC_CLOCK)
-define_if_not(LIBCXX_ENABLE_THREAD_UNSAFE_C_FUNCTIONS 
-D_LIBCPP_HAS_NO_THREAD_UNSAFE_C_FUNCTIONS)
-
 
 # Sanitizer flags =
 
@@ -303,6 +296,22 @@ if (LIBCXX_BUILT_STANDALONE)
 message(WARNING "LLVM_USE_SANITIZER is not supported on this platform.")
   endif()
 endif()
+
+# Configuration file flags 
=
+config_define_if_not(LIBCXX_ENABLE_GLOBAL_FILESYSTEM_NAMESPACE 
_LIBCPP_HAS_NO_GLOBAL_FILESYSTEM_NAMESPACE)
+config_define_if_not(LIBCXX_ENABLE_STDIN _LIBCPP_HAS_NO_STDIN)
+config_define_if_not(LIBCXX_ENABLE_STDOUT _LIBCPP_HAS_NO_STDOUT)
+config_define_if_not(LIBCXX_ENABLE_THREADS _LIBCPP_HAS_NO_THREADS)
+config_define_if_not(LIBCXX_ENABLE_MONOTONIC_CLOCK 
_LIBCPP_HAS_NO_MONOTONIC_CLOCK)
+config_define_if_not(LIBCXX_ENABLE_THREAD_UNSAFE_C_FUNCTIONS 
_LIBCPP_HAS_NO_THREAD_UNSAFE_C_FUNCTIONS)
+
+if (LIBCXX_NEEDS_SITE_CONFIG)
+  configure_file(
+include/__config_site.in
+${LIBCXX_BINARY_DIR}/__config_site
+@ONLY)
+endif()
+
 
#===
 # Setup Source Code And Tests
 
#===

Modified: libcxx/trunk/cmake/Modules/HandleLibcxxFlags.cmake
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/Modules/HandleLibcxxFlags.cmake?rev=250235=250234=250235=diff
==
--- libcxx/trunk/cmake/Modules/HandleLibcxxFlags.cmake (original)
+++ libcxx/trunk/cmake/Modules/HandleLibcxxFlags.cmake Tue Oct 13 17:12:02 2015
@@ -49,6 +49,22 @@ macro(define_if_not condition def)
   endif()
 endmacro()
 
+macro(config_define_if condition def)
+  if (${condition})
+set(${def} ON)
+add_definitions(-D${def})
+set(LIBCXX_NEEDS_SITE_CONFIG ON)
+  endif()
+endmacro()
+
+macro(config_define_if_not condition def)
+  if (NOT ${condition})
+set(${def} ON)
+add_definitions(-D${def})
+set(LIBCXX_NEEDS_SITE_CONFIG ON)
+  endif()
+endmacro()
+
 # Add a specified list of flags to both 'LIBCXX_COMPILE_FLAGS' and
 # 'LIBCXX_LINK_FLAGS'.
 macro(add_flags)

Added: libcxx/trunk/docs/DesignDocs/CapturingConfigInfo.rst
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/docs/DesignDocs/CapturingConfigInfo.rst?rev=250235=auto
==
--- libcxx/trunk/docs/DesignDocs/CapturingConfigInfo.rst (added)
+++ libcxx/trunk/docs/DesignDocs/CapturingConfigInfo.rst Tue Oct 13 17:12:02 
2015
@@ -0,0 +1,88 @@
+===
+Capturing configuration information during installation
+===
+
+.. contents::
+   :local:
+
+The Problem
+===
+
+Currently the libc++ supports building the library with a number of different
+configuration options.  Unfortunately all of that configuration information is
+lost when libc++ is installed. In order to support "persistent"
+configurations libc++ needs a mechanism to capture the configuration options
+in the INSTALLED headers.
+
+
+Design Goals

Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain

[Ed Maste via cfe-commits]

emaste added a subscriber: emaste.


Comment at: cfe/trunk/lib/Driver/ToolChains.cpp:4080
@@ +4079,3 @@
+  SmallString<512> PS4SDKDir;
+  if (const char *EnvValue = getenv("SCE_PS4_SDK_DIR"))
+if (!llvm::sys::fs::exists(EnvValue))

Looks like a missing { here


Repository:
  rL LLVM

http://reviews.llvm.org/D13482



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

Re: [PATCH] D6700: Diagnose UnresolvedLookupExprs that resolve to instance members in static methods

[Reid Kleckner via cfe-commits]

rnk updated this revision to Diff 37303.
rnk added a comment.

- Remove duplicate tests, beef them up


http://reviews.llvm.org/D6700

Files:
  include/clang/Sema/Sema.h
  lib/Sema/SemaExprMember.cpp
  lib/Sema/TreeTransform.h
  test/SemaCXX/using-decl-1.cpp
  test/SemaTemplate/instantiate-using-decl.cpp

Index: test/SemaTemplate/instantiate-using-decl.cpp
===
--- test/SemaTemplate/instantiate-using-decl.cpp
+++ test/SemaTemplate/instantiate-using-decl.cpp
@@ -104,3 +104,37 @@
 x.f();
   }
 }
+
+namespace PR21923 {
+struct A {
+  int member;
+  int method();
+};
+template 
+struct B : public T {
+  using T::member;
+  using T::method;
+  static void StaticFun() {
+(void)B::member; // expected-error {{invalid use of member 'member' in static member function}}
+(void)member; // expected-error {{invalid use of member 'member' in static member function}}
+(void) // expected-error {{invalid use of member 'member' in static member function}}
+(void)method; // expected-error {{call to non-static member function without an object argument}}
+(void) // expected-error {{call to non-static member function without an object argument}}
+method(); // expected-error {{call to non-static member function without an object argument}}
+  }
+  void InstanceFun() {
+(void)member;
+(void)B::member;
+method();
+  }
+};
+template 
+struct C : public T {
+  using T::member;
+  using T::method;
+  static const int sdm1 = member; // expected-error {{invalid use of non-static data member 'member'}}
+  static const int sdm2 = method(); // expected-error {{call to non-static member function without an object argument}}
+};
+template class B; // expected-note 1 {{requested here}}
+template class C; // expected-note 1 {{requested here}}
+}
Index: test/SemaCXX/using-decl-1.cpp
===
--- test/SemaCXX/using-decl-1.cpp
+++ test/SemaCXX/using-decl-1.cpp
@@ -327,3 +327,28 @@
 using PR24033::st; // expected-error {{target of using declaration conflicts with declaration already in scope}}
   }
 }
+
+namespace pr21923 {
+template  struct Base {
+  int field;
+  void method();
+};
+template  struct Derived : Base {
+  using Base::field;
+  using Base::method;
+  static void m_fn1() {
+// expected-error@+1 {{invalid use of member 'field' in static member function}}
+(void)field;
+// expected-error@+1 {{invalid use of member 'field' in static member function}}
+(void)
+// expected-error@+1 {{call to non-static member function without an object argument}}
+(void)method;
+// expected-error@+1 {{call to non-static member function without an object argument}}
+(void)
+// expected-error@+1 {{call to non-static member function without an object argument}}
+method();
+  }
+};
+// expected-note@+1 {{in instantiation of member function 'pr21923::Derived::m_fn1' requested here}}
+template class Derived;
+}
Index: lib/Sema/TreeTransform.h
===
--- lib/Sema/TreeTransform.h
+++ lib/Sema/TreeTransform.h
@@ -9128,8 +9128,18 @@
 
   // If we have neither explicit template arguments, nor the template keyword,
   // it's a normal declaration name.
-  if (!Old->hasExplicitTemplateArgs() && !TemplateKWLoc.isValid())
+  if (!Old->hasExplicitTemplateArgs() && !TemplateKWLoc.isValid()) {
+// If an UnresolvedLookupExpr resolved to an instance member, that's an
+// error.
+NamedDecl *D = R.getAsSingle();
+if (D && D->isCXXInstanceMember()) {
+  SemaRef.DiagnoseInstanceReference(SS, D, Old->getNameInfo());
+  R.clear();
+  return ExprError();
+}
+
 return getDerived().RebuildDeclarationNameExpr(SS, R, Old->requiresADL());
+  }
 
   // If we have template arguments, rebuild them, then rebuild the
   // templateid expression.
Index: lib/Sema/SemaExprMember.cpp
===
--- lib/Sema/SemaExprMember.cpp
+++ lib/Sema/SemaExprMember.cpp
@@ -192,18 +192,16 @@
 }
 
 /// Diagnose a reference to a field with no object available.
-static void diagnoseInstanceReference(Sema ,
-  const CXXScopeSpec ,
-  NamedDecl *Rep,
-  const DeclarationNameInfo ) {
+void Sema::DiagnoseInstanceReference(const CXXScopeSpec , NamedDecl *Rep,
+ const DeclarationNameInfo ) {
   SourceLocation Loc = nameInfo.getLoc();
   SourceRange Range(Loc);
   if (SS.isSet()) Range.setBegin(SS.getRange().getBegin());
 
   // Look through using shadow decls and aliases.
   Rep = Rep->getUnderlyingDecl();
 
-  DeclContext *FunctionLevelDC = SemaRef.getFunctionLevelDeclContext();
+  DeclContext *FunctionLevelDC = getFunctionLevelDeclContext();
   CXXMethodDecl *Method = dyn_cast(FunctionLevelDC);
   CXXRecordDecl 

[libcxx] r250261 - Use __config_site when building libc++. Also cleanup ABI versioning doc

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Tue Oct 13 19:22:05 2015
New Revision: 250261

URL: http://llvm.org/viewvc/llvm-project?rev=250261=rev
Log:
Use __config_site when building libc++. Also cleanup ABI versioning doc

Added:
libcxx/trunk/docs/DesignDocs/ABIVersioning.rst
Removed:
libcxx/trunk/docs/Abi.rst
Modified:
libcxx/trunk/CMakeLists.txt
libcxx/trunk/cmake/Modules/HandleLibcxxFlags.cmake
libcxx/trunk/docs/index.rst
libcxx/trunk/test/libcxx/test/config.py

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=250261=250260=250261=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Tue Oct 13 19:22:05 2015
@@ -321,6 +321,9 @@ if (LIBCXX_NEEDS_SITE_CONFIG)
 include/__config_site.in
 ${LIBCXX_BINARY_DIR}/__config_site
 @ONLY)
+  # Provide the config definitions by included the generated __config_site
+  # file at compile time.
+  add_compile_flags("-include ${LIBCXX_BINARY_DIR}/__config_site")
 endif()
 
 
#===

Modified: libcxx/trunk/cmake/Modules/HandleLibcxxFlags.cmake
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/Modules/HandleLibcxxFlags.cmake?rev=250261=250260=250261=diff
==
--- libcxx/trunk/cmake/Modules/HandleLibcxxFlags.cmake (original)
+++ libcxx/trunk/cmake/Modules/HandleLibcxxFlags.cmake Tue Oct 13 19:22:05 2015
@@ -49,10 +49,12 @@ macro(define_if_not condition def)
   endif()
 endmacro()
 
+# Add a macro definition to the __config_site file if the specified condition
+# is 'true'. Note that '-D${def}' is not added. Instead it is expected that
+# the build include the '__config_site' header.
 macro(config_define_if condition def)
   if (${condition})
 set(${def} ON)
-add_definitions(-D${def})
 set(LIBCXX_NEEDS_SITE_CONFIG ON)
   endif()
 endmacro()
@@ -60,14 +62,12 @@ endmacro()
 macro(config_define_if_not condition def)
   if (NOT ${condition})
 set(${def} ON)
-add_definitions(-D${def})
 set(LIBCXX_NEEDS_SITE_CONFIG ON)
   endif()
 endmacro()
 
 macro(config_define value def)
   set(${def} ${value})
-  add_definitions(-D${def}=${value})
   set(LIBCXX_NEEDS_SITE_CONFIG ON)
 endmacro()
 

Removed: libcxx/trunk/docs/Abi.rst
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/docs/Abi.rst?rev=250260=auto
==
--- libcxx/trunk/docs/Abi.rst (original)
+++ libcxx/trunk/docs/Abi.rst (removed)
@@ -1,17 +0,0 @@
-
-
-Libc++ ABI stability
-
-
-Libc++ aims to preserve stable ABI to avoid subtle bugs when code built to the 
old ABI
-is linked with the code build to the new ABI. At the same time, libc++ allows 
ABI-breaking
-improvements and bugfixes for the scenarios when ABI change is not a issue.
-
-To support both cases, libc++ allows specifying the ABI version at the
-build time.  The version is defined with a cmake option
-LIBCXX_ABI_VERSION. Another option LIBCXX_ABI_UNSTABLE can be used to
-include all present ABI breaking features. These options translate
-into C++ macro definitions _LIBCPP_ABI_VERSION, _LIBCPP_ABI_UNSTABLE.
-
-Any ABI-changing feature is placed under it's own macro, _LIBCPP_ABI_XXX, 
which is enabled
-based on the value of _LIBCPP_ABI_VERSION. _LIBCPP_ABI_UNSTABLE, if set, 
enables all features at once.

Added: libcxx/trunk/docs/DesignDocs/ABIVersioning.rst
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/docs/DesignDocs/ABIVersioning.rst?rev=250261=auto
==
--- libcxx/trunk/docs/DesignDocs/ABIVersioning.rst (added)
+++ libcxx/trunk/docs/DesignDocs/ABIVersioning.rst Tue Oct 13 19:22:05 2015
@@ -0,0 +1,17 @@
+
+
+Libc++ ABI stability
+
+
+Libc++ aims to preserve stable ABI to avoid subtle bugs when code built to the 
old ABI
+is linked with the code build to the new ABI. At the same time, libc++ allows 
ABI-breaking
+improvements and bugfixes for the scenarios when ABI change is not a issue.
+
+To support both cases, libc++ allows specifying the ABI version at the
+build time.  The version is defined with a cmake option
+LIBCXX_ABI_VERSION. Another option LIBCXX_ABI_UNSTABLE can be used to
+include all present ABI breaking features. These options translate
+into C++ macro definitions _LIBCPP_ABI_VERSION, _LIBCPP_ABI_UNSTABLE.
+
+Any ABI-changing feature is placed under it's own macro, _LIBCPP_ABI_XXX, 
which is enabled
+based on the value of _LIBCPP_ABI_VERSION. _LIBCPP_ABI_UNSTABLE, if set, 
enables all features at once.

Modified: libcxx/trunk/docs/index.rst
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/docs/index.rst?rev=250261=250260=250261=diff

Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain

[Ed Maste via cfe-commits]

emaste added a comment.

> Can we get this fixed or reversed out? Thanks!


It's already reverted.


Repository:
  rL LLVM

http://reviews.llvm.org/D13482



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

Re: [PATCH] D11740: ABI versioning macros for libc++

[Evgeniy Stepanov via cfe-commits]

eugenis closed this revision.
eugenis added a comment.

Landed as r250254, thanks for the review!


Repository:
  rL LLVM

http://reviews.llvm.org/D11740



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

Re: [PATCH] D11740: ABI versioning macros for libc++

[Eric Fiselier via cfe-commits]

EricWF added a comment.

http://reviews.llvm.org/D13407 has landed and this is good to go.


Repository:
  rL LLVM

http://reviews.llvm.org/D11740



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

Re: [libcxx] r249798 - Split out of .

[Eric Fiselier via cfe-commits]

This change LGTM. Let's hold off on the using "_Static_assert" until we
understand how that would work with "-pedantic" when the macro is expanded
in user code.

/Eric

On Tue, Oct 13, 2015 at 4:19 PM, Richard Smith 
wrote:

> On Tue, Oct 13, 2015 at 2:12 PM, Eric Fiselier via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> I would rather not do this if possible but I understand why we need to do
>> it.
>>
>> Richard is there a cost associated with the 'extern "C++"' construct? or
>> by forcing the compiler to switch modes in general?
>>
>
> Not a significant one compared to the cost of the code wrapped in the
> 'extern "C++"' here. (Also, this is wrapped in an #ifdef that only applies
> in C++98; we could further reduce the set of cases when this happens by
> using _Static_assert when available instead of this static_assert
> emulation.)
>
>
>> On Mon, Oct 12, 2015 at 12:27 PM, Richard Smith 
>> wrote:
>>
>>> On Mon, Oct 12, 2015 at 9:41 AM, Steven Wu via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 Hi Richard

 Your splitting seems causing problem when using extern "C". Here is a
 test case:

 $ cat test.cpp
 #ifdef __cplusplus
 extern "C" {
 #endif
 #include 
 #ifdef __cplusplus
 }
 #endif

 Error:
 clang -fsyntax-only test.cpp
 In file included from test.cpp:4:
 In file included from /usr/bin/../include/c++/v1/stdio.h:102:
 /usr/bin/../include/c++/v1/__config:593:1: error:
   templates must have C++ linkage
 template  struct __static_assert_test;
 ^~~
 /usr/bin/../include/c++/v1/__config:594:20: error:
   explicit specialization of non-template struct
 '__static_assert_test'
 template <> struct __static_assert_test {};
^   ~~
 /usr/bin/../include/c++/v1/__config:595:1: error:
   templates must have C++ linkage
 template  struct __static_assert_check {};
 ^~~
 3 errors generated.

 Because the code is actually compiled in C++, the guard in the header
 failed to exclude the templates. In the meantime, I don't know if there are
 ways to detect the header is in extern "C".

>>>
>>> This was supposed to work, but apparently I only tested it when
>>> compiling as C++11; the static_assert emulation in C++98 mode needs some
>>> massaging to cope with this.
>>>
>>> Eric, Marshall: Are you OK with the attached patch? The idea is to make
>>> <__config> be fine to include in extern "C" or extern "C++" modes (and
>>> likewise for the  headers). This is something that comes up pretty
>>> often in practice (people wrap an include of a C header in 'extern "C"',
>>> and that C header includes a  file that libc++ provides).
>>>
>>>
 Steven


 > On Oct 8, 2015, at 6:29 PM, Richard Smith via cfe-commits <
 cfe-commits@lists.llvm.org> wrote:
 >
 > Author: rsmith
 > Date: Thu Oct  8 20:29:09 2015
 > New Revision: 249798
 >
 > URL: http://llvm.org/viewvc/llvm-project?rev=249798=rev
 > Log:
 > Split  out of .
 >
 > As with , skip our custom header if __need_FILE or
 __need___FILE is defined.
 >
 > Added:
 >libcxx/trunk/include/stdio.h
 >  - copied, changed from r249736, libcxx/trunk/include/cstdio
 > Modified:
 >libcxx/trunk/include/cstdio
 >libcxx/trunk/test/std/depr/depr.c.headers/stdio_h.pass.cpp
 >
 > Modified: libcxx/trunk/include/cstdio
 > URL:
 http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/cstdio?rev=249798=249797=249798=diff
 >
 ==
 > --- libcxx/trunk/include/cstdio (original)
 > +++ libcxx/trunk/include/cstdio Thu Oct  8 20:29:09 2015
 > @@ -103,16 +103,6 @@ void perror(const char* s);
 > #pragma GCC system_header
 > #endif
 >
 > -// snprintf
 > -#if defined(_LIBCPP_MSVCRT)
 > -#include "support/win32/support.h"
 > -#endif
 > -
 > -#undef getc
 > -#undef putc
 > -#undef clearerr
 > -#undef feof
 > -#undef ferror
 > _LIBCPP_BEGIN_NAMESPACE_STD
 >
 > using ::FILE;
 >
 > Copied: libcxx/trunk/include/stdio.h (from r249736,
 libcxx/trunk/include/cstdio)
 > URL:
 http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/stdio.h?p2=libcxx/trunk/include/stdio.h=libcxx/trunk/include/cstdio=249736=249798=249798=diff
 >
 ==
 > --- libcxx/trunk/include/cstdio (original)
 > +++ libcxx/trunk/include/stdio.h Thu Oct  8 20:29:09 2015
 > @@ -1,5 +1,5 @@
 > // -*- C++ -*-
 > -//=== cstdio
 --===//
 > +//=== stdio.h
 

RE: [PATCH] D13482: Revised Initial patch for PS4 toolchain

[Romanova, Katya via cfe-commits]

Thanks! I just committed the patch.
Katya.

> -Original Message-
> From: Jonathan Roelofs [mailto:jonat...@codesourcery.com]
> Sent: Tuesday, October 13, 2015 3:40 PM
> To: Romanova, Katya; al...@leftfield.org; Robinson, Paul;
> echri...@gmail.com; filcab+llvm.phabrica...@gmail.com;
> jonat...@codesourcery.com
> Cc: Bedwell, Greg; pierregoussea...@gmail.com;
> an...@korobeynikov.info; geek4ci...@gmail.com; cfe-
> comm...@lists.llvm.org; chisophu...@gmail.com
> Subject: Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain
> 
> jroelofs accepted this revision.
> jroelofs added a reviewer: jroelofs.
> jroelofs added a comment.
> 
> One small suggestion. Otherwise, this still LGTM.
> 
> 
> 
> Comment at: lib/Driver/ToolChains.cpp:4078 @@ +4077,3 @@
> +  // should be /host_tools/bin.
> +  const char *EnvValue = getenv("SCE_PS4_SDK_DIR");  if (EnvValue &&
> + !llvm::sys::fs::exists(EnvValue))
> 
> It might help to structure this:
> 
> const char *EnvValue = getenv("SCE_PS4_SDK_DIR");
> if (EnvValue && !llvm::sys::fs::exists(EnvValue))
>   getDriver().Diag(clang::diag::warn_drv_ps4_sdk_dir) << EnvValue;
> 
> SmallString<512> PS4SDKDir(EnvValue ? EnvValue : getDriver().Dir);
> if (!EnvValue) {
>   llvm::sys::path::append(PS4SDKDir, "/../../");
> }
> 
> 
> as:
> 
> SmallString<512> PS4SDKDir;
> if (const char *EnvValue = getenv("SCE_PS4_SDK_DIR"))
>   if (!llvm::sys::fs::exists(EnvValue))
> getDriver().Diag(clang::diag::warn_drv_ps4_sdk_dir) << EnvValue;
> 
>   PS4SDKDir = EnvValue;
> } else {
>   PS4SDKDir = getDriver().Dir;
>   llvm::sys::path::append(PS4SDKDir, "/../../");
> }
> 
> 
> Repository:
>   rL LLVM
> 
> http://reviews.llvm.org/D13482
> 
> 

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

[libcxx] r250256 - Workaround -pedantic flag added by LLVM

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Tue Oct 13 18:56:33 2015
New Revision: 250256

URL: http://llvm.org/viewvc/llvm-project?rev=250256=rev
Log:
Workaround -pedantic flag added by LLVM

Modified:
libcxx/trunk/CMakeLists.txt

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=250256=250255=250256=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Tue Oct 13 18:56:33 2015
@@ -198,6 +198,10 @@ include(HandleLibcxxFlags)
 remove_flags(-DNDEBUG -UNDEBUG -D_DEBUG
  -stdlib=libc++ -stdlib=libstdc++ -lc++abi -m32)
 
+# FIXME(EricWF): See the FIXME on LIBCXX_ENABLE_PEDANTIC.
+# Remove the -pedantic flag provided by LLVM.
+remove_flags(-pedantic)
+
 # Required flags ==
 add_compile_flags_if_supported(-std=c++11)
 if (NOT MSVC AND NOT LIBCXX_SUPPORTS_STD_EQ_CXX11_FLAG)


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

[libcxx] r250236 - Remove __config module to avoid #include cycle when libc headers include libc++'s headers.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Tue Oct 13 17:13:33 2015
New Revision: 250236

URL: http://llvm.org/viewvc/llvm-project?rev=250236=rev
Log:
Remove __config module to avoid #include cycle when libc headers include 
libc++'s  headers.

Modified:
libcxx/trunk/include/module.modulemap

Modified: libcxx/trunk/include/module.modulemap
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/module.modulemap?rev=250236=250235=250236=diff
==
--- libcxx/trunk/include/module.modulemap (original)
+++ libcxx/trunk/include/module.modulemap Tue Oct 13 17:13:33 2015
@@ -455,9 +455,13 @@ module std [system] {
 export *
   }
 
+  // FIXME: We don't have modules for the  headers, because they might
+  // be included from the C library's headers, and that would create a #include
+  // cycle. For the same reason, we don't have a module for __config.
+  //module __config { header "__config" export * }
+
   // FIXME: These should be private.
   module __bit_reference { header "__bit_reference" export * }
-  module __config { header "__config" export * }
   module __debug { header "__debug" export * }
   module __functional_base { header "__functional_base" export * }
   module __hash_table { header "__hash_table" export * }


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

Re: [libcxx] r249798 - Split out of .

[Richard Smith via cfe-commits]

On Tue, Oct 13, 2015 at 2:12 PM, Eric Fiselier via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> I would rather not do this if possible but I understand why we need to do
> it.
>
> Richard is there a cost associated with the 'extern "C++"' construct? or
> by forcing the compiler to switch modes in general?
>

Not a significant one compared to the cost of the code wrapped in the
'extern "C++"' here. (Also, this is wrapped in an #ifdef that only applies
in C++98; we could further reduce the set of cases when this happens by
using _Static_assert when available instead of this static_assert
emulation.)


> On Mon, Oct 12, 2015 at 12:27 PM, Richard Smith 
> wrote:
>
>> On Mon, Oct 12, 2015 at 9:41 AM, Steven Wu via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Hi Richard
>>>
>>> Your splitting seems causing problem when using extern "C". Here is a
>>> test case:
>>>
>>> $ cat test.cpp
>>> #ifdef __cplusplus
>>> extern "C" {
>>> #endif
>>> #include 
>>> #ifdef __cplusplus
>>> }
>>> #endif
>>>
>>> Error:
>>> clang -fsyntax-only test.cpp
>>> In file included from test.cpp:4:
>>> In file included from /usr/bin/../include/c++/v1/stdio.h:102:
>>> /usr/bin/../include/c++/v1/__config:593:1: error:
>>>   templates must have C++ linkage
>>> template  struct __static_assert_test;
>>> ^~~
>>> /usr/bin/../include/c++/v1/__config:594:20: error:
>>>   explicit specialization of non-template struct
>>> '__static_assert_test'
>>> template <> struct __static_assert_test {};
>>>^   ~~
>>> /usr/bin/../include/c++/v1/__config:595:1: error:
>>>   templates must have C++ linkage
>>> template  struct __static_assert_check {};
>>> ^~~
>>> 3 errors generated.
>>>
>>> Because the code is actually compiled in C++, the guard in the header
>>> failed to exclude the templates. In the meantime, I don't know if there are
>>> ways to detect the header is in extern "C".
>>>
>>
>> This was supposed to work, but apparently I only tested it when compiling
>> as C++11; the static_assert emulation in C++98 mode needs some massaging to
>> cope with this.
>>
>> Eric, Marshall: Are you OK with the attached patch? The idea is to make
>> <__config> be fine to include in extern "C" or extern "C++" modes (and
>> likewise for the  headers). This is something that comes up pretty
>> often in practice (people wrap an include of a C header in 'extern "C"',
>> and that C header includes a  file that libc++ provides).
>>
>>
>>> Steven
>>>
>>>
>>> > On Oct 8, 2015, at 6:29 PM, Richard Smith via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>> >
>>> > Author: rsmith
>>> > Date: Thu Oct  8 20:29:09 2015
>>> > New Revision: 249798
>>> >
>>> > URL: http://llvm.org/viewvc/llvm-project?rev=249798=rev
>>> > Log:
>>> > Split  out of .
>>> >
>>> > As with , skip our custom header if __need_FILE or
>>> __need___FILE is defined.
>>> >
>>> > Added:
>>> >libcxx/trunk/include/stdio.h
>>> >  - copied, changed from r249736, libcxx/trunk/include/cstdio
>>> > Modified:
>>> >libcxx/trunk/include/cstdio
>>> >libcxx/trunk/test/std/depr/depr.c.headers/stdio_h.pass.cpp
>>> >
>>> > Modified: libcxx/trunk/include/cstdio
>>> > URL:
>>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/cstdio?rev=249798=249797=249798=diff
>>> >
>>> ==
>>> > --- libcxx/trunk/include/cstdio (original)
>>> > +++ libcxx/trunk/include/cstdio Thu Oct  8 20:29:09 2015
>>> > @@ -103,16 +103,6 @@ void perror(const char* s);
>>> > #pragma GCC system_header
>>> > #endif
>>> >
>>> > -// snprintf
>>> > -#if defined(_LIBCPP_MSVCRT)
>>> > -#include "support/win32/support.h"
>>> > -#endif
>>> > -
>>> > -#undef getc
>>> > -#undef putc
>>> > -#undef clearerr
>>> > -#undef feof
>>> > -#undef ferror
>>> > _LIBCPP_BEGIN_NAMESPACE_STD
>>> >
>>> > using ::FILE;
>>> >
>>> > Copied: libcxx/trunk/include/stdio.h (from r249736,
>>> libcxx/trunk/include/cstdio)
>>> > URL:
>>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/stdio.h?p2=libcxx/trunk/include/stdio.h=libcxx/trunk/include/cstdio=249736=249798=249798=diff
>>> >
>>> ==
>>> > --- libcxx/trunk/include/cstdio (original)
>>> > +++ libcxx/trunk/include/stdio.h Thu Oct  8 20:29:09 2015
>>> > @@ -1,5 +1,5 @@
>>> > // -*- C++ -*-
>>> > -//=== cstdio
>>> --===//
>>> > +//=== stdio.h
>>> -===//
>>> > //
>>> > // The LLVM Compiler Infrastructure
>>> > //
>>> > @@ -8,11 +8,19 @@
>>> > //
>>> >
>>> //===--===//
>>> >
>>> > -#ifndef _LIBCPP_CSTDIO
>>> > -#define _LIBCPP_CSTDIO
>>> > +#if defined(__need_FILE) || defined(__need___FILE)
>>> > +
>>> > +#if 

Re: [PATCH] D13673: Add initial support for the MUSL C library.

[Jonathan Roelofs via cfe-commits]

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

http://reviews.llvm.org/D13407 has landed.


http://reviews.llvm.org/D13673



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

Re: [PATCH] D13099: [Analyzer] Don’t invalidate CXXThis when conservatively evaluating const methods (PR 21606)

[Devin Coughlin via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL250237: [analyzer] Don’t invalidate CXXThis when 
conservatively evaluating const… (authored by dcoughlin).

Changed prior to commit:
  http://reviews.llvm.org/D13099?vs=37084=37291#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D13099

Files:
  cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h
  cfe/trunk/lib/StaticAnalyzer/Core/CallEvent.cpp
  cfe/trunk/test/Analysis/const-method-call.cpp

Index: cfe/trunk/test/Analysis/const-method-call.cpp
===
--- cfe/trunk/test/Analysis/const-method-call.cpp
+++ cfe/trunk/test/Analysis/const-method-call.cpp
@@ -0,0 +1,230 @@
+// RUN: %clang_cc1 -analyze -analyzer-checker=core,debug.ExprInspection -verify %s
+
+void clang_analyzer_eval(bool);
+
+struct A {
+  int x;
+  void foo() const;
+  void bar();
+};
+
+struct B {
+  mutable int mut;
+  void foo() const;
+};
+
+struct C {
+  int *p;
+  void foo() const;
+};
+
+struct MutBase {
+  mutable int b_mut;
+};
+
+struct MutDerived : MutBase {
+  void foo() const;
+};
+
+struct PBase {
+  int *p;
+};
+
+struct PDerived : PBase {
+  void foo() const;
+};
+
+struct Inner {
+  int x;
+  int *p;
+  void bar() const;
+};
+
+struct Outer {
+  int x;
+  Inner in;
+  void foo() const;
+};
+
+void checkThatConstMethodWithoutDefinitionDoesNotInvalidateObject() {
+  A t;
+  t.x = 3;
+  t.foo();
+  clang_analyzer_eval(t.x == 3); // expected-warning{{TRUE}}
+  // Test non-const does invalidate
+  t.bar();
+  clang_analyzer_eval(t.x); // expected-warning{{UNKNOWN}}
+}
+
+void checkThatConstMethodDoesInvalidateMutableFields() {
+  B t;
+  t.mut = 4;
+  t.foo();
+  clang_analyzer_eval(t.mut); // expected-warning{{UNKNOWN}}
+}
+
+void checkThatConstMethodDoesInvalidatePointedAtMemory() {
+  int x = 1;
+  C t;
+  t.p = 
+  t.foo();
+  clang_analyzer_eval(x); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(t.p == ); // expected-warning{{TRUE}}
+}
+
+void checkThatConstMethodDoesInvalidateInheritedMutableFields() {
+  MutDerived t;
+  t.b_mut = 4;
+  t.foo();
+  clang_analyzer_eval(t.b_mut); // expected-warning{{UNKNOWN}}
+}
+
+void checkThatConstMethodDoesInvalidateInheritedPointedAtMemory() {
+  int x = 1;
+  PDerived t;
+  t.p = 
+  t.foo();
+  clang_analyzer_eval(x); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(t.p == ); // expected-warning{{TRUE}}
+}
+
+void checkThatConstMethodDoesInvalidateContainedPointedAtMemory() {
+  int x = 1;
+  Outer t;
+  t.x = 2;
+  t.in.p = 
+  t.foo();
+  clang_analyzer_eval(x); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(t.x == 2); // expected-warning{{TRUE}}
+  clang_analyzer_eval(t.in.p == ); // expected-warning{{TRUE}}
+}
+
+void checkThatContainedConstMethodDoesNotInvalidateObjects() {
+  Outer t;
+  t.x = 1;
+  t.in.x = 2;
+  t.in.bar();
+  clang_analyzer_eval(t.x == 1); // expected-warning{{TRUE}}
+  clang_analyzer_eval(t.in.x == 2); // expected-warning{{TRUE}}
+}
+
+// --- Versions of the above tests where the const method is inherited --- //
+
+struct B1 {
+  void foo() const;
+};
+
+struct D1 : public B1 {
+  int x;
+};
+
+struct D2 : public B1 {
+  mutable int mut;
+};
+
+struct D3 : public B1 {
+  int *p;
+};
+
+struct DInner : public B1 {
+  int x;
+  int *p;
+};
+
+struct DOuter : public B1 {
+  int x;
+  DInner in;
+};
+
+void checkThatInheritedConstMethodDoesNotInvalidateObject() {
+  D1 t;
+  t.x = 1;
+  t.foo();
+  clang_analyzer_eval(t.x == 1); // expected-warning{{TRUE}}
+}
+
+void checkThatInheritedConstMethodDoesInvalidateMutableFields() {
+  D2 t;
+  t.mut = 1;
+  t.foo();
+  clang_analyzer_eval(t.mut); // expected-warning{{UNKNOWN}}
+}
+
+void checkThatInheritedConstMethodDoesInvalidatePointedAtMemory() {
+  int x = 1;
+  D3 t;
+  t.p = 
+  t.foo();
+  clang_analyzer_eval(x); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(t.p == ); // expected-warning{{TRUE}}
+}
+
+void checkThatInheritedConstMethodDoesInvalidateContainedPointedAtMemory() {
+  int x = 1;
+  DOuter t;
+  t.x = 2;
+  t.in.x = 3;
+  t.in.p = 
+  t.foo();
+  clang_analyzer_eval(x); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(t.x == 2); // expected-warning{{TRUE}}
+  clang_analyzer_eval(t.in.x == 3); // expected-warning{{TRUE}}
+  clang_analyzer_eval(t.in.p == ); // expected-warning{{TRUE}}
+}
+
+void checkThatInheritedContainedConstMethodDoesNotInvalidateObjects() {
+  DOuter t;
+  t.x = 1;
+  t.in.x = 2;
+  t.in.foo();
+  clang_analyzer_eval(t.x == 1); // expected-warning{{TRUE}}
+  clang_analyzer_eval(t.in.x == 2); // expected-warning{{TRUE}}
+}
+
+// --- PR21606 --- //
+
+struct s1 {
+void g(const int *i) const;
+};
+
+struct s2 {
+void f(int *i) {
+m_i = i;
+m_s.g(m_i);
+if (m_i)
+*i = 42; // no-warning
+}
+
+int *m_i;
+s1 m_s;
+};
+
+void PR21606()
+{
+s2().f(0);
+}
+
+// FIXME
+// When there is a circular reference to an object and a 

Re: [PATCH] D13673: Add initial support for the MUSL C library.

[Eric Fiselier via cfe-commits]

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

I don't think this is ready to go. Please don't commit yet. Sorry @jroelofs.



Comment at: CMakeLists.txt:309
@@ -307,1 +308,3 @@
 
+config_define_if(LIBCXX_LIBC_IS_MUSL _LIBCXX_LIBC_IS_MUSL)
+

Please name the macro "_LIBCPP_HAS_MUSL_LIBC" for consistency. 


Comment at: include/__config:370
@@ -369,2 +369,3 @@
 #elif defined(__linux__)
-#include 
+#if defined(__GLIBC__)
+# include 

Where does the `__GLIBC__`  macro definition come from? I thought it came from 
the C library headers but we don't include any!


http://reviews.llvm.org/D13673



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

Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain

[Jonathan Roelofs via cfe-commits]

jroelofs accepted this revision.
jroelofs added a reviewer: jroelofs.
jroelofs added a comment.

One small suggestion. Otherwise, this still LGTM.



Comment at: lib/Driver/ToolChains.cpp:4078
@@ +4077,3 @@
+  // should be /host_tools/bin.
+  const char *EnvValue = getenv("SCE_PS4_SDK_DIR");
+  if (EnvValue && !llvm::sys::fs::exists(EnvValue))

It might help to structure this:

const char *EnvValue = getenv("SCE_PS4_SDK_DIR");
if (EnvValue && !llvm::sys::fs::exists(EnvValue))
  getDriver().Diag(clang::diag::warn_drv_ps4_sdk_dir) << EnvValue;

SmallString<512> PS4SDKDir(EnvValue ? EnvValue : getDriver().Dir);
if (!EnvValue) {
  llvm::sys::path::append(PS4SDKDir, "/../../");
}


as:

SmallString<512> PS4SDKDir;
if (const char *EnvValue = getenv("SCE_PS4_SDK_DIR"))
  if (!llvm::sys::fs::exists(EnvValue))
getDriver().Diag(clang::diag::warn_drv_ps4_sdk_dir) << EnvValue;

  PS4SDKDir = EnvValue;
} else {
  PS4SDKDir = getDriver().Dir;
  llvm::sys::path::append(PS4SDKDir, "/../../");
} 


Repository:
  rL LLVM

http://reviews.llvm.org/D13482



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

Re: [PATCH] D13705: [libcxxabi] Set correct libc++ version in tests.

[Eric Fiselier via cfe-commits]

EricWF added a comment.

This is fine as a temporary workaround but it's not complete. I would rather do 
something better.


Repository:
  rL LLVM

http://reviews.llvm.org/D13705



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

Re: [PATCH] D11740: ABI versioning macros for libc++

[Eric Fiselier via cfe-commits]

EricWF added a comment.

Please address the inline comment. I think with that change we can hold off 
modifying libc++abi.



Comment at: test/libcxx/test/config.py:444
@@ -442,1 +443,3 @@
 
+def configure_compile_flags_abi_version(self):
+abi_version = self.get_lit_conf('abi_version', '').strip()

Please allow abi_version to be optional before committing. IE

```
abi_version = self.get_lit_conf('abi_version',  None)
if abi_version is not None:
  self.cxx.compile_flags += ['-D_LIBCPP_ABI_VERSION=' + abi_version']
```

That should allow us to put off the changes to libc++abi.


Repository:
  rL LLVM

http://reviews.llvm.org/D11740



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

r250246 - [CMake]Getting rid of references to LLVM_SUBMIT_VERSION and LLVM_SUBMIT_SUBVERSION in favor of LLVM_VERSION_MAJOR and LLVM_VERSION_MINOR.

[Chris Bieneman via cfe-commits]

Author: cbieneman
Date: Tue Oct 13 18:03:54 2015
New Revision: 250246

URL: http://llvm.org/viewvc/llvm-project?rev=250246=rev
Log:
[CMake]Getting rid of references to LLVM_SUBMIT_VERSION and 
LLVM_SUBMIT_SUBVERSION in favor of LLVM_VERSION_MAJOR and LLVM_VERSION_MINOR.

LLVM_SUBMIT_VERSION and LLVM_SUBMIT_SUBVERSION are commonly used variable names 
in the autoconf build system. They seem to have leeched into clang's CMake in a 
few places, and should just be replaced by the LLVM_VERSION_* variables where 
appropriate.

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

Modified: cfe/trunk/tools/driver/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/driver/CMakeLists.txt?rev=250246=250245=250246=diff
==
--- cfe/trunk/tools/driver/CMakeLists.txt (original)
+++ cfe/trunk/tools/driver/CMakeLists.txt Tue Oct 13 18:03:54 2015
@@ -83,10 +83,7 @@ if (APPLE)
 
   set(TOOL_INFO_UTI "${CLANG_VENDOR_UTI}")
   set(TOOL_INFO_VERSION "${CLANG_VERSION}")
-  if (LLVM_SUBMIT_VERSION)
-set(TOOL_INFO_BUILD_VERSION
-  "${LLVM_SUBMIT_VERSION}.${LLVM_SUBMIT_SUBVERSION}")
-  endif()
+  set(TOOL_INFO_BUILD_VERSION "${LLVM_MAJOR_VERSION}.${LLVM_MINOR_VERSION}")
   
   set(TOOL_INFO_PLIST_OUT "${CMAKE_CURRENT_BINARY_DIR}/${TOOL_INFO_PLIST}")
   target_link_libraries(clang

Modified: cfe/trunk/tools/libclang/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/libclang/CMakeLists.txt?rev=250246=250245=250246=diff
==
--- cfe/trunk/tools/libclang/CMakeLists.txt (original)
+++ cfe/trunk/tools/libclang/CMakeLists.txt Tue Oct 13 18:03:54 2015
@@ -109,12 +109,9 @@ if(ENABLE_SHARED)
   DEFINE_SYMBOL _CINDEX_LIB_)
   endif()
 
-  if(${CMAKE_SYSTEM_NAME} MATCHES "Darwin")
+  if(APPLE)
 set(LIBCLANG_LINK_FLAGS " -Wl,-compatibility_version -Wl,1")
-if (DEFINED ${LLVM_SUBMIT_VERSION})
-  set(LIBCLANG_LINK_FLAGS
-"${LIBCLANG_LINK_FLAGS} -Wl,-current_version 
-Wl,${LLVM_SUBMIT_VERSION}.${LLVM_SUBMIT_SUBVERSION}")
-endif()
+set(LIBCLANG_LINK_FLAGS "${LIBCLANG_LINK_FLAGS} -Wl,-current_version 
-Wl,${LLVM_VERSION_MAJOR}.${LLVM_VERSION_MINOR}")
 
 set_property(TARGET libclang APPEND_STRING PROPERTY
  LINK_FLAGS ${LIBCLANG_LINK_FLAGS})


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

[libcxx] r250247 - Fix use of libc++ headers from within an 'extern "C"' context in C++98.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Tue Oct 13 18:12:22 2015
New Revision: 250247

URL: http://llvm.org/viewvc/llvm-project?rev=250247=rev
Log:
Fix use of libc++  headers from within an 'extern "C"' context in C++98.

Previously, this resulted in us declaring a template for static_assert 
emulation within the 'extern "C"' context, which is ill-formed.

Added:
libcxx/trunk/test/std/depr/depr.c.headers/extern_c.pass.cpp
Modified:
libcxx/trunk/include/__config

Modified: libcxx/trunk/include/__config
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__config?rev=250247=250246=250247=diff
==
--- libcxx/trunk/include/__config (original)
+++ libcxx/trunk/include/__config Tue Oct 13 18:12:22 2015
@@ -591,9 +591,11 @@ typedef unsigned int   char32_t;
 
 #ifdef _LIBCPP_HAS_NO_STATIC_ASSERT
 
+extern "C++" {
 template  struct __static_assert_test;
 template <> struct __static_assert_test {};
 template  struct __static_assert_check {};
+}
 #define static_assert(__b, __m) \
 typedef __static_assert_check)> \
 _LIBCPP_CONCAT(__t, __LINE__)

Added: libcxx/trunk/test/std/depr/depr.c.headers/extern_c.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/depr/depr.c.headers/extern_c.pass.cpp?rev=250247=auto
==
--- libcxx/trunk/test/std/depr/depr.c.headers/extern_c.pass.cpp (added)
+++ libcxx/trunk/test/std/depr/depr.c.headers/extern_c.pass.cpp Tue Oct 13 
18:12:22 2015
@@ -0,0 +1,43 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+// Sometimes C++'s  headers get included within extern "C" contexts. 
This
+// is ill-formed (no diagnostic required), per [using.headers]p3, but we permit
+// it as an extension.
+
+extern "C" {
+#include 
+// complex.h is not supported in extern "C".
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+// tgmath.h is not supported in extern "C".
+#include 
+// FIXME: #include 
+#include 
+#include 
+}
+
+int main() {}


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

Re: [PATCH] D11740: ABI versioning macros for libc++

[Evgeniy Stepanov via cfe-commits]

eugenis added inline comments.


Comment at: test/libcxx/test/config.py:444
@@ -442,1 +443,3 @@
 
+def configure_compile_flags_abi_version(self):
+abi_version = self.get_lit_conf('abi_version', '').strip()

EricWF wrote:
> Please allow abi_version to be optional before committing. IE
> 
> ```
> abi_version = self.get_lit_conf('abi_version',  None)
> if abi_version is not None:
>   self.cxx.compile_flags += ['-D_LIBCPP_ABI_VERSION=' + abi_version']
> ```
> 
> That should allow us to put off the changes to libc++abi.
OK. This would hold while ABI version is 1.



Repository:
  rL LLVM

http://reviews.llvm.org/D11740



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

Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain

[Katya Romanova via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL250252: This patch adds missing pieces to clang, including 
the PS4 toolchain (authored by kromanova).

Changed prior to commit:
  http://reviews.llvm.org/D13482?vs=37292=37301#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D13482

Files:
  cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
  cfe/trunk/include/clang/Basic/DiagnosticGroups.td
  cfe/trunk/lib/Driver/Driver.cpp
  cfe/trunk/lib/Driver/ToolChains.cpp
  cfe/trunk/lib/Driver/ToolChains.h
  cfe/trunk/lib/Driver/Tools.cpp
  cfe/trunk/lib/Driver/Tools.h
  cfe/trunk/lib/Frontend/InitHeaderSearch.cpp
  cfe/trunk/test/Driver/Inputs/scei-ps4_tree/target/include/.keep
  cfe/trunk/test/Driver/Inputs/scei-ps4_tree/target/include_common/.keep
  cfe/trunk/test/Driver/debug-options.c
  cfe/trunk/test/Driver/no-integrated-as.s
  cfe/trunk/test/Driver/ps4-header-search.c
  cfe/trunk/test/Driver/ps4-linker-non-win.c
  cfe/trunk/test/Driver/ps4-linker-win.c
  cfe/trunk/test/Driver/ps4-pic.c
  cfe/trunk/test/Driver/ps4-sdk-root.c
  cfe/trunk/test/Driver/stack-protector.c

Index: cfe/trunk/lib/Driver/ToolChains.h
===
--- cfe/trunk/lib/Driver/ToolChains.h
+++ cfe/trunk/lib/Driver/ToolChains.h
@@ -1015,6 +1015,27 @@
  llvm::opt::ArgStringList ) const override;
 };
 
+class LLVM_LIBRARY_VISIBILITY PS4CPU : public Generic_ELF {
+public:
+  PS4CPU(const Driver , const llvm::Triple ,
+ const llvm::opt::ArgList );
+
+  bool IsMathErrnoDefault() const override { return false; }
+  bool IsObjCNonFragileABIDefault() const override { return true; }
+  bool HasNativeLLVMSupport() const override;
+  bool isPICDefault() const override;
+
+  unsigned GetDefaultStackProtectorLevel(bool KernelOrKext) const override {
+return 2; // SSPStrong
+  }
+
+  SanitizerMask getSupportedSanitizers() const override;
+
+protected:
+  Tool *buildAssembler() const override;
+  Tool *buildLinker() const override;
+};
+
 } // end namespace toolchains
 } // end namespace driver
 } // end namespace clang
Index: cfe/trunk/lib/Driver/Tools.h
===
--- cfe/trunk/lib/Driver/Tools.h
+++ cfe/trunk/lib/Driver/Tools.h
@@ -831,6 +831,36 @@
 };
 } // end namespace Myriad
 
+namespace PS4cpu {
+class LLVM_LIBRARY_VISIBILITY Assemble : public Tool {
+public:
+  Assemble(const ToolChain )
+  : Tool("PS4cpu::Assemble", "assembler", TC, RF_Full) {}
+
+  virtual bool hasIntegratedCPP() const { return false; }
+
+  virtual void ConstructJob(Compilation , const JobAction ,
+const InputInfo ,
+const InputInfoList ,
+const llvm::opt::ArgList ,
+const char *LinkingOutput) const;
+};
+
+class LLVM_LIBRARY_VISIBILITY Link : public Tool {
+public:
+  Link(const ToolChain ) : Tool("PS4cpu::Link", "linker", TC, RF_Full) {}
+
+  virtual bool hasIntegratedCPP() const { return false; }
+  virtual bool isLinkJob() const { return true; }
+
+  virtual void ConstructJob(Compilation , const JobAction ,
+const InputInfo ,
+const InputInfoList ,
+const llvm::opt::ArgList ,
+const char *LinkingOutput) const;
+};
+} // end namespace PS4cpu
+
 } // end namespace tools
 } // end namespace driver
 } // end namespace clang
Index: cfe/trunk/lib/Driver/ToolChains.cpp
===
--- cfe/trunk/lib/Driver/ToolChains.cpp
+++ cfe/trunk/lib/Driver/ToolChains.cpp
@@ -4066,3 +4066,77 @@
  options::OPT_fno_use_init_array, true))
 CC1Args.push_back("-fuse-init-array");
 }
+
+PS4CPU::PS4CPU(const Driver , const llvm::Triple , const ArgList )
+: Generic_ELF(D, Triple, Args) {
+  if (Args.hasArg(options::OPT_static))
+D.Diag(diag::err_drv_unsupported_opt_for_target) << "-static" << "PS4";
+
+  // Determine where to find the PS4 libraries. We use SCE_PS4_SDK_DIR
+  // if it exists; otherwise use the driver's installation path, which
+  // should be /host_tools/bin.
+
+  SmallString<512> PS4SDKDir;
+  if (const char *EnvValue = getenv("SCE_PS4_SDK_DIR"))
+if (!llvm::sys::fs::exists(EnvValue))
+  getDriver().Diag(clang::diag::warn_drv_ps4_sdk_dir) << EnvValue;
+PS4SDKDir = EnvValue;
+  } else {
+PS4SDKDir = getDriver().Dir;
+llvm::sys::path::append(PS4SDKDir, "/../../");
+  } 
+
+  // By default, the driver won't report a warning if it can't find 
+  // PS4's include or lib directories. This behavior could be changed if
+  // -Weverything or -Winvalid-or-nonexistent-directory options are passed.  
+  // If -isysroot was passed, use that as the SDK base path.
+  std::string PrefixDir;
+  if (const Arg *A = Args.getLastArg(options::OPT_isysroot)) {
+PrefixDir 

r250252 - This patch adds missing pieces to clang, including the PS4 toolchain

[Ekaterina Romanova via cfe-commits]

Author: kromanova
Date: Tue Oct 13 18:40:02 2015
New Revision: 250252

URL: http://llvm.org/viewvc/llvm-project?rev=250252=rev
Log:
This patch adds missing pieces to clang, including the PS4 toolchain
definition, added warnings, PS4 defaults, and Driver changes needed for
our compiler.

A patch by Filipe Cabecinhas, Pierre Gousseau and Katya Romanova!

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


Added:
cfe/trunk/test/Driver/Inputs/scei-ps4_tree/target/include/.keep
cfe/trunk/test/Driver/Inputs/scei-ps4_tree/target/include_common/.keep
cfe/trunk/test/Driver/no-integrated-as.s
cfe/trunk/test/Driver/ps4-header-search.c
cfe/trunk/test/Driver/ps4-linker-non-win.c
cfe/trunk/test/Driver/ps4-linker-win.c
cfe/trunk/test/Driver/ps4-pic.c
cfe/trunk/test/Driver/ps4-sdk-root.c
Modified:
cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
cfe/trunk/include/clang/Basic/DiagnosticGroups.td
cfe/trunk/lib/Driver/Driver.cpp
cfe/trunk/lib/Driver/ToolChains.cpp
cfe/trunk/lib/Driver/ToolChains.h
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/lib/Driver/Tools.h
cfe/trunk/lib/Frontend/InitHeaderSearch.cpp
cfe/trunk/test/Driver/debug-options.c
cfe/trunk/test/Driver/stack-protector.c

Modified: cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td?rev=250252=250251=250252=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td Tue Oct 13 18:40:02 
2015
@@ -196,4 +196,18 @@ def warn_target_unsupported_nan2008 : Wa
 def warn_target_unsupported_nanlegacy : Warning<
   "ignoring '-mnan=legacy' option because the '%0' architecture does not 
support it">,
   InGroup;
+
+def warn_drv_unable_to_find_directory_expected : Warning<
+  "unable to find %0 directory, expected to be in '%1'">,
+  InGroup, DefaultIgnore;
+
+def warn_drv_ps4_force_pic : Warning<
+  "option '%0' was ignored by the PS4 toolchain, using '-fPIC'">,
+  InGroup;
+
+def warn_drv_ps4_sdk_dir : Warning<
+  "environment variable SCE_PS4_SDK_DIR is set, but points to invalid or 
nonexistent directory '%0'">,
+  InGroup;
+
+def err_drv_unsupported_linker : Error<"unsupported value '%0' for -linker 
option">;
 }

Modified: cfe/trunk/include/clang/Basic/DiagnosticGroups.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticGroups.td?rev=250252=250251=250252=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticGroups.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticGroups.td Tue Oct 13 18:40:02 2015
@@ -823,3 +823,7 @@ def CudaCompat : DiagGroup<"cuda-compat"
 
 // A warning group for things that will change semantics in the future.
 def FutureCompat : DiagGroup<"future-compat">;
+
+def InvalidOrNonExistentDirectory : 
DiagGroup<"invalid-or-nonexistent-directory">;
+
+def OptionIgnored : DiagGroup<"option-ignored">;

Modified: cfe/trunk/lib/Driver/Driver.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Driver.cpp?rev=250252=250251=250252=diff
==
--- cfe/trunk/lib/Driver/Driver.cpp (original)
+++ cfe/trunk/lib/Driver/Driver.cpp Tue Oct 13 18:40:02 2015
@@ -2261,6 +2261,9 @@ const ToolChain ::getToolChain(co
 case llvm::Triple::CUDA:
   TC = new toolchains::CudaToolChain(*this, Target, Args);
   break;
+case llvm::Triple::PS4:
+  TC = new toolchains::PS4CPU(*this, Target, Args);
+  break;
 default:
   // Of these targets, Hexagon is the only one that might have
   // an OS of Linux, in which case it got handled above already.

Modified: cfe/trunk/lib/Driver/ToolChains.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains.cpp?rev=250252=250251=250252=diff
==
--- cfe/trunk/lib/Driver/ToolChains.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains.cpp Tue Oct 13 18:40:02 2015
@@ -4066,3 +4066,77 @@ void WebAssembly::addClangTargetOptions(
  options::OPT_fno_use_init_array, true))
 CC1Args.push_back("-fuse-init-array");
 }
+
+PS4CPU::PS4CPU(const Driver , const llvm::Triple , const ArgList 
)
+: Generic_ELF(D, Triple, Args) {
+  if (Args.hasArg(options::OPT_static))
+D.Diag(diag::err_drv_unsupported_opt_for_target) << "-static" << "PS4";
+
+  // Determine where to find the PS4 libraries. We use SCE_PS4_SDK_DIR
+  // if it exists; otherwise use the driver's installation path, which
+  // should be /host_tools/bin.
+
+  SmallString<512> PS4SDKDir;
+  if (const char *EnvValue = getenv("SCE_PS4_SDK_DIR"))
+if (!llvm::sys::fs::exists(EnvValue))
+  

Re: [PATCH] D11740: ABI versioning macros for libc++

[Eric Fiselier via cfe-commits]

EricWF added a comment.

LGTM. We'll fix the libc++abi issue later.


Repository:
  rL LLVM

http://reviews.llvm.org/D11740



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