[PATCH] D28727: Add -fstrict-vtable-pointers to UserManual

2017-01-15 Thread Piotr Padlewski via Phabricator via cfe-commits
Prazek updated this revision to Diff 84489.
Prazek added a comment.

suggested fix


https://reviews.llvm.org/D28727

Files:
  docs/UsersManual.rst


Index: docs/UsersManual.rst
===
--- docs/UsersManual.rst
+++ docs/UsersManual.rst
@@ -1097,6 +1097,12 @@
the behavior of sanitizers in the ``cfi`` group to allow checking
of cross-DSO virtual and indirect calls.
 
+
+.. option:: -f[no-]strict-vtable-pointers
+   Enable optimizations based on the strict rules for overwriting polymorphic
+   C++ objects, e.g. vptr is invariant during the lifetime of object.
+   This enables better devirtualization. Turned off by default.
+
 .. option:: -ffast-math
 
Enable fast-math mode. This defines the ``__FAST_MATH__`` preprocessor


Index: docs/UsersManual.rst
===
--- docs/UsersManual.rst
+++ docs/UsersManual.rst
@@ -1097,6 +1097,12 @@
the behavior of sanitizers in the ``cfi`` group to allow checking
of cross-DSO virtual and indirect calls.
 
+
+.. option:: -f[no-]strict-vtable-pointers
+   Enable optimizations based on the strict rules for overwriting polymorphic
+   C++ objects, e.g. vptr is invariant during the lifetime of object.
+   This enables better devirtualization. Turned off by default.
+
 .. option:: -ffast-math
 
Enable fast-math mode. This defines the ``__FAST_MATH__`` preprocessor
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D28606: Mention devirtualization in release notes

2017-01-15 Thread Piotr Padlewski via Phabricator via cfe-commits
Prazek updated this revision to Diff 84491.
Prazek added a comment.

Added link to documentation


https://reviews.llvm.org/D28606

Files:
  docs/ReleaseNotes.rst


Index: docs/ReleaseNotes.rst
===
--- docs/ReleaseNotes.rst
+++ docs/ReleaseNotes.rst
@@ -51,6 +51,24 @@
   clang to emit a warning or error if a function call meets one or more
   user-specified conditions.
 
+- Enhanced devirtualization with
+  '-fstrict-vtable-pointers 
`_.
+  Clang devirtualizes across different basic blocks, like loops:
+
+  .. code-block:: c++
+   struct A {
+   virtual void foo();
+   };
+   void indirect(A &a, int n) {
+   for (int i = 0 ; i < n; i++)
+   a.foo();
+   }
+   void test(int n) {
+   A a;
+   indirect(a, n);
+   }
+
+
 -  ...
 
 Improvements to Clang's diagnostics


Index: docs/ReleaseNotes.rst
===
--- docs/ReleaseNotes.rst
+++ docs/ReleaseNotes.rst
@@ -51,6 +51,24 @@
   clang to emit a warning or error if a function call meets one or more
   user-specified conditions.
 
+- Enhanced devirtualization with
+  '-fstrict-vtable-pointers `_.
+  Clang devirtualizes across different basic blocks, like loops:
+
+  .. code-block:: c++
+   struct A {
+   virtual void foo();
+   };
+   void indirect(A &a, int n) {
+   for (int i = 0 ; i < n; i++)
+   a.foo();
+   }
+   void test(int n) {
+   A a;
+   indirect(a, n);
+   }
+
+
 -  ...
 
 Improvements to Clang's diagnostics
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D28727: Add -fstrict-vtable-pointers to UserManual

2017-01-15 Thread Piotr Padlewski via Phabricator via cfe-commits
Prazek updated this revision to Diff 84492.
Prazek added a comment.

Removed [no-] so hyperlink would work


https://reviews.llvm.org/D28727

Files:
  docs/UsersManual.rst


Index: docs/UsersManual.rst
===
--- docs/UsersManual.rst
+++ docs/UsersManual.rst
@@ -1097,6 +1097,12 @@
the behavior of sanitizers in the ``cfi`` group to allow checking
of cross-DSO virtual and indirect calls.
 
+
+.. option:: -fstrict-vtable-pointers
+   Enable optimizations based on the strict rules for overwriting polymorphic
+   C++ objects, e.g. vptr is invariant during the lifetime of object.
+   This enables better devirtualization. Turned off by default.
+
 .. option:: -ffast-math
 
Enable fast-math mode. This defines the ``__FAST_MATH__`` preprocessor


Index: docs/UsersManual.rst
===
--- docs/UsersManual.rst
+++ docs/UsersManual.rst
@@ -1097,6 +1097,12 @@
the behavior of sanitizers in the ``cfi`` group to allow checking
of cross-DSO virtual and indirect calls.
 
+
+.. option:: -fstrict-vtable-pointers
+   Enable optimizations based on the strict rules for overwriting polymorphic
+   C++ objects, e.g. vptr is invariant during the lifetime of object.
+   This enables better devirtualization. Turned off by default.
+
 .. option:: -ffast-math
 
Enable fast-math mode. This defines the ``__FAST_MATH__`` preprocessor
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D28729: [clang-tidy] Add -enable-alpha-checks command

2017-01-15 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman requested changes to this revision.
aaron.ballman added a comment.

In https://reviews.llvm.org/D28729#646560, @alexfh wrote:

> In https://reviews.llvm.org/D28729#646555, @aaron.ballman wrote:
>
> > In https://reviews.llvm.org/D28729#646548, @alexfh wrote:
> >
> > > As discussed with the Static Analyzer maintainers, alpha checkers are 
> > > completely unsupported and are suitable for very early testing only. We 
> > > had problems with them routinely, that's why I disabled alpha checkers in 
> > > clang-tidy completely. I don't think there should be a user-visible way 
> > > to enable them. Developers can locally change the code to get access to 
> > > alpha checkers, but released binaries shouldn't provide this possibility.
> >
> >
> > That's good to know -- should it be documented a bit more explicitly,
>
>
> Yes, a comment to that effect near the relevant code wouldn't hurt. Or do you 
> have other suggestions?


A comment in the code would be okay, but I think that removing all public 
mention of the alpha checkers (help text and website) would also be useful; I 
would not have thought that a production compiler would carry these checks for 
this many years if they weren't stable and useful.

> 
> 
>>   or perhaps the alpha checks should be removed until they're fit for public 
>> consumption? Some of those alpha checks have been in the product for a long 
>> time, and if they're so unstable that we cannot expose them in a 
>> user-friendly fashion, perhaps they don't belong yet?
> 
> As discussed with SA folks, alpha checkers are convenient for them to develop 
> new checks, but shouldn't be exposed to users. Some of these experimental 
> checkers might deserve being moved out of alpha or removed completely, but 
> that should be reported to and discussed with the SA maintainers.

Agreed.


https://reviews.llvm.org/D28729



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


[PATCH] D28672: [ASTMatchers] update doc by running dump_ast_matchers.py

2017-01-15 Thread Eric Liu via Phabricator via cfe-commits
ioeric added a comment.

In https://reviews.llvm.org/D28672#646336, @malcolm.parsons wrote:

> In https://reviews.llvm.org/D28672#646151, @aaron.ballman wrote:
>
> > I'm not seeing anything wrong, per se, but why has so much of this file 
> > changed recently?
>
>
> The script looks for doxygen docs on clang.llvm.org. Are they missing?


Manuel pointed out that these changes were caused by broken links (e.g. 
http://clang.llvm.org/doxygen/classclang_1_1Decl.html). Some pages have been 
unreachable for at least a few days now.


https://reviews.llvm.org/D28672



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


[PATCH] D12340: [X86] Remove unnecessary 3DNow declarations from Intrin.h

2017-01-15 Thread Simon Pilgrim via Phabricator via cfe-commits
RKSimon abandoned this revision.
RKSimon added a comment.

Abandoning this - unless we have a way to known when to automatically insert 
emms/femms then its not safe to do this.


Repository:
  rL LLVM

https://reviews.llvm.org/D12340



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


[PATCH] D28746: Mention ThinLTO with PGO in ReleaseNotes 4.0

2017-01-15 Thread Piotr Padlewski via Phabricator via cfe-commits
Prazek created this revision.
Prazek added reviewers: tejohnson, mehdi_amini, hans.
Prazek added a subscriber: cfe-commits.

It would be good to also mention
other improvements in ThinLTO for 4.0 release


https://reviews.llvm.org/D28746

Files:
  docs/ReleaseNotes.rst


Index: docs/ReleaseNotes.rst
===
--- docs/ReleaseNotes.rst
+++ docs/ReleaseNotes.rst
@@ -63,6 +63,10 @@
indirect(a, n);
}
 
+- Significantly improved generated code for ThinLTO with profile data. It is
+  achieved by importing hot-chains of functions and by not importing functions
+  called from cold callsite.
+
 
 -  ...
 


Index: docs/ReleaseNotes.rst
===
--- docs/ReleaseNotes.rst
+++ docs/ReleaseNotes.rst
@@ -63,6 +63,10 @@
indirect(a, n);
}
 
+- Significantly improved generated code for ThinLTO with profile data. It is
+  achieved by importing hot-chains of functions and by not importing functions
+  called from cold callsite.
+
 
 -  ...
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D28746: Mention ThinLTO with PGO in ReleaseNotes 4.0

2017-01-15 Thread Piotr Padlewski via Phabricator via cfe-commits
Prazek added a comment.

Maybe I should change ThinLTO for '-flto=thin' and also mention this 
improvement in LLVM release notes?

BTW '-flto=thin' is not documented in UsersManual


https://reviews.llvm.org/D28746



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


[PATCH] D28746: Mention ThinLTO with PGO in ReleaseNotes 4.0

2017-01-15 Thread Mehdi AMINI via Phabricator via cfe-commits
mehdi_amini added inline comments.



Comment at: docs/ReleaseNotes.rst:69
+  called from cold callsite.
+
 

We need to mention ThinLTO in the Release Notes, so thanks for initiating this. 
We likely should go with a paragraph summarizing the improvements, I don't know 
though if there is anything else than 1) PGO and 2) Significant build-time and 
binary-size improvements with debug-info.



https://reviews.llvm.org/D28746



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


Re: [PATCH] D28672: [ASTMatchers] update doc by running dump_ast_matchers.py

2017-01-15 Thread Aaron Ballman via cfe-commits
On Sun, Jan 15, 2017 at 1:00 PM, Eric Liu via Phabricator
 wrote:
> ioeric added a comment.
>
> In https://reviews.llvm.org/D28672#646336, @malcolm.parsons wrote:
>
>> In https://reviews.llvm.org/D28672#646151, @aaron.ballman wrote:
>>
>> > I'm not seeing anything wrong, per se, but why has so much of this file 
>> > changed recently?
>>
>>
>> The script looks for doxygen docs on clang.llvm.org. Are they missing?
>
>
> Manuel pointed out that these changes were caused by broken links (e.g. 
> http://clang.llvm.org/doxygen/classclang_1_1Decl.html). Some pages have been 
> unreachable for at least a few days now.

If links were broken with the recent server switch, we should ask
Tanya about them (the move was not intended to break anything). Or are
you saying that these changes are intended to be what fixes those
broken links?

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


Re: [PATCH] D28672: [ASTMatchers] update doc by running dump_ast_matchers.py

2017-01-15 Thread Eric Liu via cfe-commits
I've sent an email to cfe-dev (and Tanya) about this. And this patch will
be abandoned since it doesn't fix anything.

On Sun, Jan 15, 2017 at 10:04 PM Aaron Ballman 
wrote:

> On Sun, Jan 15, 2017 at 1:00 PM, Eric Liu via Phabricator
>  wrote:
> > ioeric added a comment.
> >
> > In https://reviews.llvm.org/D28672#646336, @malcolm.parsons wrote:
> >
> >> In https://reviews.llvm.org/D28672#646151, @aaron.ballman wrote:
> >>
> >> > I'm not seeing anything wrong, per se, but why has so much of this
> file changed recently?
> >>
> >>
> >> The script looks for doxygen docs on clang.llvm.org. Are they missing?
> >
> >
> > Manuel pointed out that these changes were caused by broken links (e.g.
> http://clang.llvm.org/doxygen/classclang_1_1Decl.html). Some pages have
> been unreachable for at least a few days now.
>
> If links were broken with the recent server switch, we should ask
> Tanya about them (the move was not intended to break anything). Or are
> you saying that these changes are intended to be what fixes those
> broken links?
>
> ~Aaron
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D28672: [ASTMatchers] update doc by running dump_ast_matchers.py

2017-01-15 Thread Aaron Ballman via cfe-commits
On Sun, Jan 15, 2017 at 4:19 PM, Eric Liu  wrote:
> I've sent an email to cfe-dev (and Tanya) about this. And this patch will be
> abandoned since it doesn't fix anything.

Thank you for taking care of this!

~Aaron

>
> On Sun, Jan 15, 2017 at 10:04 PM Aaron Ballman 
> wrote:
>>
>> On Sun, Jan 15, 2017 at 1:00 PM, Eric Liu via Phabricator
>>  wrote:
>> > ioeric added a comment.
>> >
>> > In https://reviews.llvm.org/D28672#646336, @malcolm.parsons wrote:
>> >
>> >> In https://reviews.llvm.org/D28672#646151, @aaron.ballman wrote:
>> >>
>> >> > I'm not seeing anything wrong, per se, but why has so much of this
>> >> > file changed recently?
>> >>
>> >>
>> >> The script looks for doxygen docs on clang.llvm.org. Are they missing?
>> >
>> >
>> > Manuel pointed out that these changes were caused by broken links (e.g.
>> > http://clang.llvm.org/doxygen/classclang_1_1Decl.html). Some pages have 
>> > been
>> > unreachable for at least a few days now.
>>
>> If links were broken with the recent server switch, we should ask
>> Tanya about them (the move was not intended to break anything). Or are
>> you saying that these changes are intended to be what fixes those
>> broken links?
>>
>> ~Aaron
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D28315: Update tools to use new getStyle API

2017-01-15 Thread Antonio Maiorano via Phabricator via cfe-commits
amaiorano added inline comments.



Comment at: change-namespace/ChangeNamespace.cpp:892
+  llvm::errs() << llvm::toString(Style.takeError()) << "\n";
+  continue;
+}

amaiorano wrote:
> amaiorano wrote:
> > ioeric wrote:
> > > I'd still like to apply replacements that are not cleaned up. Could you 
> > > add the following line before continue, thanks! :)
> > > ```
> > > FileToReplacements[FilePath] = Replaces;
> > > ```
> > Will do.
> Ah darn, just realized that I forgot to make this change you asked for 
> @ioeric. Let me know if everything else is okay, and I'll be sure to add this 
> in before submitting. 
@ioeric Was looking at this code, and I'm wondering about the change you wanted 
me to make here. You said that you'd still like to apply replacements that are 
not cleaned up, so shouldn't that also be the case for when 
format::cleanupAroundReplacements fails (just below)? In other words, shouldn't 
it be:

```
// Clean up old namespaces if there is nothing in it after moving.
auto CleanReplacements =
format::cleanupAroundReplacements(Code, Replaces, *Style);
if (!CleanReplacements) {
  llvm::errs() << llvm::toString(CleanReplacements.takeError()) << "\n";
  FileToReplacements[FilePath] = Replaces;
  continue;
}
FileToReplacements[FilePath] = *CleanReplacements;
  }
```

If so, I propose instead that we add 
```
FileToReplacements[FilePath] = Replaces;
``` 
before the call to format::getStyle so that if either of the format-related 
calls below it (getStyle or cleanupAroundReplacements) fail, we get the unclean 
replacements.


https://reviews.llvm.org/D28315



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


[PATCH] D28746: Mention ThinLTO with PGO in ReleaseNotes 4.0

2017-01-15 Thread Teresa Johnson via Phabricator via cfe-commits
tejohnson added a comment.

In https://reviews.llvm.org/D28746#646793, @Prazek wrote:

> Maybe I should change ThinLTO for '-flto=thin' and also mention this 
> improvement in LLVM release notes?
>
> BTW '-flto=thin' is not documented in UsersManual


It's documented here:

  http://clang.llvm.org/docs/index.html

and here:

  http://clang.llvm.org/docs/CommandGuide/clang.html

but not (yet) here:

  http://clang.llvm.org/docs/UsersManual.html

I can add that.

Thanks!




Comment at: docs/ReleaseNotes.rst:69
+  called from cold callsite.
+
 

mehdi_amini wrote:
> We need to mention ThinLTO in the Release Notes, so thanks for initiating 
> this. 
> We likely should go with a paragraph summarizing the improvements, I don't 
> know though if there is anything else than 1) PGO and 2) Significant 
> build-time and binary-size improvements with debug-info.
> 
Yes this is a good start. One of the big improvements from PGO is the 
integration with indirect call promotion. I would suggest something like:

Improvements to ThinLTO (-flto=thin):
- Integration with profile data. When available, profile data enables more 
accurate function importing decisions, as well as cross-module indirect call 
promotion.
- Significant build-time and binary-size improvements when compiling with debug 
info (-g).


https://reviews.llvm.org/D28746



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


[PATCH] D28746: Mention ThinLTO with PGO in ReleaseNotes 4.0

2017-01-15 Thread Piotr Padlewski via Phabricator via cfe-commits
Prazek updated this revision to Diff 84503.
Prazek added a comment.

update


https://reviews.llvm.org/D28746

Files:
  docs/ReleaseNotes.rst


Index: docs/ReleaseNotes.rst
===
--- docs/ReleaseNotes.rst
+++ docs/ReleaseNotes.rst
@@ -63,9 +63,18 @@
indirect(a, n);
}
 
-
 -  ...
 
+Improvements to ThinLTO (-flto=thin)
+
+  - Integration with profile data. When available, profile data enables more
+accurate function importing decisions, as well as cross-module indirect 
call
+promotion.
+  - Significant build-time and binary-size improvements when compiling with
+debug info (-g).
+
+
+
 Improvements to Clang's diagnostics
 ^^^
 


Index: docs/ReleaseNotes.rst
===
--- docs/ReleaseNotes.rst
+++ docs/ReleaseNotes.rst
@@ -63,9 +63,18 @@
indirect(a, n);
}
 
-
 -  ...
 
+Improvements to ThinLTO (-flto=thin)
+
+  - Integration with profile data. When available, profile data enables more
+accurate function importing decisions, as well as cross-module indirect call
+promotion.
+  - Significant build-time and binary-size improvements when compiling with
+debug info (-g).
+
+
+
 Improvements to Clang's diagnostics
 ^^^
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D28746: Mention ThinLTO with PGO in ReleaseNotes 4.0

2017-01-15 Thread Piotr Padlewski via Phabricator via cfe-commits
Prazek marked 2 inline comments as done.
Prazek added a comment.

Cool, This still might require some small fixes - I haven't generate docs for 
it, so I will check it before release.


https://reviews.llvm.org/D28746



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


[PATCH] D28746: Mention ThinLTO with PGO in ReleaseNotes 4.0

2017-01-15 Thread Mehdi AMINI via Phabricator via cfe-commits
mehdi_amini accepted this revision.
mehdi_amini added a comment.
This revision is now accepted and ready to land.

LGTM, thanks.




Comment at: docs/ReleaseNotes.rst:70
+
+  - Integration with profile data. When available, profile data enables more
+accurate function importing decisions, as well as cross-module indirect 
call

I'd add a parenthesis: `Integration with profile data (PGO).`


https://reviews.llvm.org/D28746



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


[PATCH] D28746: Mention ThinLTO with PGO in ReleaseNotes 4.0

2017-01-15 Thread Piotr Padlewski via Phabricator via cfe-commits
Prazek updated this revision to Diff 84504.
Prazek marked an inline comment as done.
Prazek added a comment.

(PGO)


https://reviews.llvm.org/D28746

Files:
  docs/ReleaseNotes.rst


Index: docs/ReleaseNotes.rst
===
--- docs/ReleaseNotes.rst
+++ docs/ReleaseNotes.rst
@@ -63,9 +63,16 @@
indirect(a, n);
}
 
-
 -  ...
 
+Improvements to ThinLTO (-flto=thin)
+
+- Integration with profile data (PGO). When available, profile data enables
+  more accurate function importing decisions, as well as cross-module indirect
+  call promotion.
+- Significant build-time and binary-size improvements when compiling with debug
+  info (-g).
+
 Improvements to Clang's diagnostics
 ^^^
 


Index: docs/ReleaseNotes.rst
===
--- docs/ReleaseNotes.rst
+++ docs/ReleaseNotes.rst
@@ -63,9 +63,16 @@
indirect(a, n);
}
 
-
 -  ...
 
+Improvements to ThinLTO (-flto=thin)
+
+- Integration with profile data (PGO). When available, profile data enables
+  more accurate function importing decisions, as well as cross-module indirect
+  call promotion.
+- Significant build-time and binary-size improvements when compiling with debug
+  info (-g).
+
 Improvements to Clang's diagnostics
 ^^^
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D28746: Mention ThinLTO with PGO in ReleaseNotes 4.0

2017-01-15 Thread Piotr Padlewski via Phabricator via cfe-commits
Prazek added a comment.

Shoud I add the same note to LLVM Release notes?


https://reviews.llvm.org/D28746



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


[PATCH] D28746: Mention ThinLTO with PGO in ReleaseNotes 4.0

2017-01-15 Thread Mehdi AMINI via Phabricator via cfe-commits
mehdi_amini added a comment.

Oh I didn't notice that we were in the clang Release Notes, actually I've only 
updated the LLVM ones in the past.

So yes, I think this should be in LLVM as well, I don't know if it should 
differ in some way?


https://reviews.llvm.org/D28746



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


[PATCH] D28729: [clang-tidy] Add -enable-alpha-checks command

2017-01-15 Thread Piotr Padlewski via Phabricator via cfe-commits
Prazek added a comment.

In https://reviews.llvm.org/D28729#646758, @aaron.ballman wrote:

> In https://reviews.llvm.org/D28729#646560, @alexfh wrote:
>
> > In https://reviews.llvm.org/D28729#646555, @aaron.ballman wrote:
> >
> > > In https://reviews.llvm.org/D28729#646548, @alexfh wrote:
> > >
> > > > As discussed with the Static Analyzer maintainers, alpha checkers are 
> > > > completely unsupported and are suitable for very early testing only. We 
> > > > had problems with them routinely, that's why I disabled alpha checkers 
> > > > in clang-tidy completely. I don't think there should be a user-visible 
> > > > way to enable them. Developers can locally change the code to get 
> > > > access to alpha checkers, but released binaries shouldn't provide this 
> > > > possibility.
> > >
> > >
> > > That's good to know -- should it be documented a bit more explicitly,
> >
> >
> > Yes, a comment to that effect near the relevant code wouldn't hurt. Or do 
> > you have other suggestions?
>
>
> A comment in the code would be okay, but I think that removing all public 
> mention of the alpha checkers (help text and website) would also be useful; I 
> would not have thought that a production compiler would carry these checks 
> for this many years if they weren't stable and useful.


I don't quite understand. Are you suggesting:

- removing help text
- adding cl::hidden

What website are you talking about?

>> 
>> 
>>>   or perhaps the alpha checks should be removed until they're fit for 
>>> public consumption? Some of those alpha checks have been in the product for 
>>> a long time, and if they're so unstable that we cannot expose them in a 
>>> user-friendly fashion, perhaps they don't belong yet?
>> 
>> As discussed with SA folks, alpha checkers are convenient for them to 
>> develop new checks, but shouldn't be exposed to users. Some of these 
>> experimental checkers might deserve being moved out of alpha or removed 
>> completely, but that should be reported to and discussed with the SA 
>> maintainers.
> 
> Agreed.

I don't agree that alpha checkers are that bad. When I was testing it year ago 
there were only few false positives, probably in 2 checkers.


https://reviews.llvm.org/D28729



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


[PATCH] D28746: Mention ThinLTO with PGO in ReleaseNotes 4.0

2017-01-15 Thread Piotr Padlewski via Phabricator via cfe-commits
Prazek added a comment.

In https://reviews.llvm.org/D28746#646875, @mehdi_amini wrote:

> Oh I didn't notice that we were in the clang Release Notes, actually I've 
> only updated the LLVM ones in the past.
>
> So yes, I think this should be in LLVM as well, I don't know if it should 
> differ in some way?


It probably should not differ in any way. I think it is very important to have 
note in clang's release notes, because this is where clang users look :)


https://reviews.llvm.org/D28746



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


[PATCH] D28729: [clang-tidy] Add -enable-alpha-checks command

2017-01-15 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In https://reviews.llvm.org/D28729#646876, @Prazek wrote:

> In https://reviews.llvm.org/D28729#646758, @aaron.ballman wrote:
>
> > In https://reviews.llvm.org/D28729#646560, @alexfh wrote:
> >
> > > In https://reviews.llvm.org/D28729#646555, @aaron.ballman wrote:
> > >
> > > > In https://reviews.llvm.org/D28729#646548, @alexfh wrote:
> > > >
> > > > > As discussed with the Static Analyzer maintainers, alpha checkers are 
> > > > > completely unsupported and are suitable for very early testing only. 
> > > > > We had problems with them routinely, that's why I disabled alpha 
> > > > > checkers in clang-tidy completely. I don't think there should be a 
> > > > > user-visible way to enable them. Developers can locally change the 
> > > > > code to get access to alpha checkers, but released binaries shouldn't 
> > > > > provide this possibility.
> > > >
> > > >
> > > > That's good to know -- should it be documented a bit more explicitly,
> > >
> > >
> > > Yes, a comment to that effect near the relevant code wouldn't hurt. Or do 
> > > you have other suggestions?
> >
> >
> > A comment in the code would be okay, but I think that removing all public 
> > mention of the alpha checkers (help text and website) would also be useful; 
> > I would not have thought that a production compiler would carry these 
> > checks for this many years if they weren't stable and useful.
>
>
> I don't quite understand. Are you suggesting:
>
> - removing help text
> - adding cl::hidden


I'm suggesting removing help text.

> What website are you talking about?

Things like this: http://clang-analyzer.llvm.org/alpha_checks.html

To me, there's a difference between "prevented from being on by default" and 
"completely unsupported". If they're completely unsupported, we probably 
shouldn't expose them more easily, but we may want to clarify this in 
user-facing documentation and help text.

> 
> 
>>> 
>>> 
   or perhaps the alpha checks should be removed until they're fit for 
 public consumption? Some of those alpha checks have been in the product 
 for a long time, and if they're so unstable that we cannot expose them in 
 a user-friendly fashion, perhaps they don't belong yet?
>>> 
>>> As discussed with SA folks, alpha checkers are convenient for them to 
>>> develop new checks, but shouldn't be exposed to users. Some of these 
>>> experimental checkers might deserve being moved out of alpha or removed 
>>> completely, but that should be reported to and discussed with the SA 
>>> maintainers.
>> 
>> Agreed.
> 
> I don't agree that alpha checkers are that bad. When I was testing it year 
> ago there were only few false positives, probably in 2 checkers.

If the maintainers of the static analyzer think they shouldn't be exposed to 
users, I'm inclined to follow that advice.


https://reviews.llvm.org/D28729



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


Re: r291905 - [Sema] Add warning for unused lambda captures

2017-01-15 Thread Daniel Jasper via cfe-commits
This patch seems to break on some of our code. Reproducer:

$ cat /tmp/ctor.cc
template 
struct A {
  A() {}
};

template 
class B : T {
  using T::T;
};

struct C {
  B> d;
  C(A b) : d(b) {}
};

djasper@dj:~/llvm/release$ bin/clang -cc1 -std=c++11 /tmp/ctor.cc
/tmp/ctor.cc:13:17: error: no matching constructor for initialization of
'B >'
  C(A b) : d(b) {}
^ ~
/tmp/ctor.cc:7:7: note: candidate constructor (the implicit copy
constructor) not viable: no known conversion from 'A' to 'const
B >' for 1st argument
class B : T {
  ^
/tmp/ctor.cc:7:7: note: candidate constructor (the implicit move
constructor) not viable: no known conversion from 'A' to 'B >'
for 1st argument
class B : T {
  ^
/tmp/ctor.cc:7:7: note: candidate constructor (the implicit default
constructor) not viable: requires 0 arguments, but 1 was provided
1 error generated.

As far as I can tell, the copy constructor of class A does not get
forwarded with the "using T::T". I am not an expert on this parts of the
language, but this does seem like an unwanted side-effect. It builds find
with a version of Clang prior to this patch.

On Fri, Jan 13, 2017 at 4:01 PM, Malcolm Parsons via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: malcolm.parsons
> Date: Fri Jan 13 09:01:06 2017
> New Revision: 291905
>
> URL: http://llvm.org/viewvc/llvm-project?rev=291905&view=rev
> Log:
> [Sema] Add warning for unused lambda captures
>
> Summary:
> Warn when a lambda explicitly captures something that is not used in its
> body.
>
> The warning is part of -Wunused and can be enabled with
> -Wunused-lambda-capture.
>
> Reviewers: rsmith, arphaman, jbcoe, aaron.ballman
>
> Subscribers: Quuxplusone, arphaman, cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D28467
>
> Added:
> cfe/trunk/test/SemaCXX/warn-unused-lambda-capture.cpp
> Modified:
> cfe/trunk/include/clang/Basic/DiagnosticGroups.td
> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> cfe/trunk/include/clang/Sema/ScopeInfo.h
> cfe/trunk/include/clang/Sema/Sema.h
> cfe/trunk/lib/Sema/SemaExpr.cpp
> cfe/trunk/lib/Sema/SemaExprCXX.cpp
> cfe/trunk/lib/Sema/SemaLambda.cpp
> cfe/trunk/test/CXX/expr/expr.prim/expr.prim.lambda/p12.cpp
> cfe/trunk/test/CXX/expr/expr.prim/expr.prim.lambda/p13.cpp
> cfe/trunk/test/CXX/expr/expr.prim/expr.prim.lambda/p16.cpp
> cfe/trunk/test/CXX/expr/expr.prim/expr.prim.lambda/p18.cpp
> cfe/trunk/test/CXX/expr/expr.prim/expr.prim.lambda/p19.cpp
> cfe/trunk/test/SemaCXX/uninitialized.cpp
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticGroups.td
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Basic/DiagnosticGroups.td?rev=291905&r1=291904&r2=291905&view=diff
> 
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticGroups.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticGroups.td Fri Jan 13 09:01:06
> 2017
> @@ -480,6 +480,7 @@ def UnusedFunction : DiagGroup<"unused-f
>  def UnusedMemberFunction : DiagGroup<"unused-member-function",
>   [UnneededMemberFunction]>;
>  def UnusedLabel : DiagGroup<"unused-label">;
> +def UnusedLambdaCapture : DiagGroup<"unused-lambda-capture">;
>  def UnusedParameter : DiagGroup<"unused-parameter">;
>  def UnusedResult : DiagGroup<"unused-result">;
>  def PotentiallyEvaluatedExpression : DiagGroup<"potentially-
> evaluated-expression">;
> @@ -617,8 +618,9 @@ def Unused : DiagGroup<"unused",
> [UnusedArgument, UnusedFunction, UnusedLabel,
>  // UnusedParameter, (matches GCC's behavior)
>  // UnusedMemberFunction, (clean-up llvm before
> enabling)
> -UnusedPrivateField, UnusedLocalTypedef,
> -UnusedValue, UnusedVariable, UnusedPropertyIvar]>,
> +UnusedPrivateField, UnusedLambdaCapture,
> +UnusedLocalTypedef, UnusedValue, UnusedVariable,
> +UnusedPropertyIvar]>,
>  DiagCategory<"Unused Entity Issue">;
>
>  // Format settings.
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/
> DiagnosticSemaKinds.td?rev=291905&r1=291904&r2=291905&view=diff
> 
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Fri Jan 13
> 09:01:06 2017
> @@ -316,6 +316,9 @@ def warn_unneeded_member_function : Warn
>InGroup, DefaultIgnore;
>  def warn_unused_private_field: Warning<"private field %0 is not used">,
>InGroup, DefaultIgnore;
> +def warn_unused_lambda_capture: Warning<"lambda capture %0 is not "
> +  "%select{used|required to be captured for use in an unevaluate

[PATCH] D28727: Add -fstrict-vtable-pointers to UserManual

2017-01-15 Thread Hans Wennborg via Phabricator via cfe-commits
hans accepted this revision.
hans added a comment.
This revision is now accepted and ready to land.

lgtm with comment




Comment at: docs/UsersManual.rst:1103
+   Enable optimizations based on the strict rules for overwriting polymorphic
+   C++ objects, e.g. vptr is invariant during the lifetime of object.
+   This enables better devirtualization. Turned off by default.

e.g should be i.e. (or you could even spell it out: "that is")

I think it should also be "*the* vptr" and "*the* object* or "during an 
object's lifetime".


https://reviews.llvm.org/D28727



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


Re: r291905 - [Sema] Add warning for unused lambda captures

2017-01-15 Thread Daniel Jasper via cfe-commits
Sorry, for the noise.
This is probably not the revision that caused this.

On Mon, Jan 16, 2017 at 1:08 AM, Daniel Jasper  wrote:

> This patch seems to break on some of our code. Reproducer:
>
> $ cat /tmp/ctor.cc
> template 
> struct A {
>   A() {}
> };
>
> template 
> class B : T {
>   using T::T;
> };
>
> struct C {
>   B> d;
>   C(A b) : d(b) {}
> };
>
> djasper@dj:~/llvm/release$ bin/clang -cc1 -std=c++11 /tmp/ctor.cc
> /tmp/ctor.cc:13:17: error: no matching constructor for initialization of
> 'B >'
>   C(A b) : d(b) {}
> ^ ~
> /tmp/ctor.cc:7:7: note: candidate constructor (the implicit copy
> constructor) not viable: no known conversion from 'A' to 'const
> B >' for 1st argument
> class B : T {
>   ^
> /tmp/ctor.cc:7:7: note: candidate constructor (the implicit move
> constructor) not viable: no known conversion from 'A' to 'B >'
> for 1st argument
> class B : T {
>   ^
> /tmp/ctor.cc:7:7: note: candidate constructor (the implicit default
> constructor) not viable: requires 0 arguments, but 1 was provided
> 1 error generated.
>
> As far as I can tell, the copy constructor of class A does not get
> forwarded with the "using T::T". I am not an expert on this parts of the
> language, but this does seem like an unwanted side-effect. It builds find
> with a version of Clang prior to this patch.
>
> On Fri, Jan 13, 2017 at 4:01 PM, Malcolm Parsons via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: malcolm.parsons
>> Date: Fri Jan 13 09:01:06 2017
>> New Revision: 291905
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=291905&view=rev
>> Log:
>> [Sema] Add warning for unused lambda captures
>>
>> Summary:
>> Warn when a lambda explicitly captures something that is not used in its
>> body.
>>
>> The warning is part of -Wunused and can be enabled with
>> -Wunused-lambda-capture.
>>
>> Reviewers: rsmith, arphaman, jbcoe, aaron.ballman
>>
>> Subscribers: Quuxplusone, arphaman, cfe-commits
>>
>> Differential Revision: https://reviews.llvm.org/D28467
>>
>> Added:
>> cfe/trunk/test/SemaCXX/warn-unused-lambda-capture.cpp
>> Modified:
>> cfe/trunk/include/clang/Basic/DiagnosticGroups.td
>> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
>> cfe/trunk/include/clang/Sema/ScopeInfo.h
>> cfe/trunk/include/clang/Sema/Sema.h
>> cfe/trunk/lib/Sema/SemaExpr.cpp
>> cfe/trunk/lib/Sema/SemaExprCXX.cpp
>> cfe/trunk/lib/Sema/SemaLambda.cpp
>> cfe/trunk/test/CXX/expr/expr.prim/expr.prim.lambda/p12.cpp
>> cfe/trunk/test/CXX/expr/expr.prim/expr.prim.lambda/p13.cpp
>> cfe/trunk/test/CXX/expr/expr.prim/expr.prim.lambda/p16.cpp
>> cfe/trunk/test/CXX/expr/expr.prim/expr.prim.lambda/p18.cpp
>> cfe/trunk/test/CXX/expr/expr.prim/expr.prim.lambda/p19.cpp
>> cfe/trunk/test/SemaCXX/uninitialized.cpp
>>
>> Modified: cfe/trunk/include/clang/Basic/DiagnosticGroups.td
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/
>> Basic/DiagnosticGroups.td?rev=291905&r1=291904&r2=291905&view=diff
>> 
>> ==
>> --- cfe/trunk/include/clang/Basic/DiagnosticGroups.td (original)
>> +++ cfe/trunk/include/clang/Basic/DiagnosticGroups.td Fri Jan 13
>> 09:01:06 2017
>> @@ -480,6 +480,7 @@ def UnusedFunction : DiagGroup<"unused-f
>>  def UnusedMemberFunction : DiagGroup<"unused-member-function",
>>   [UnneededMemberFunction]>;
>>  def UnusedLabel : DiagGroup<"unused-label">;
>> +def UnusedLambdaCapture : DiagGroup<"unused-lambda-capture">;
>>  def UnusedParameter : DiagGroup<"unused-parameter">;
>>  def UnusedResult : DiagGroup<"unused-result">;
>>  def PotentiallyEvaluatedExpression : DiagGroup<"potentially-evaluat
>> ed-expression">;
>> @@ -617,8 +618,9 @@ def Unused : DiagGroup<"unused",
>> [UnusedArgument, UnusedFunction, UnusedLabel,
>>  // UnusedParameter, (matches GCC's behavior)
>>  // UnusedMemberFunction, (clean-up llvm before
>> enabling)
>> -UnusedPrivateField, UnusedLocalTypedef,
>> -UnusedValue, UnusedVariable,
>> UnusedPropertyIvar]>,
>> +UnusedPrivateField, UnusedLambdaCapture,
>> +UnusedLocalTypedef, UnusedValue, UnusedVariable,
>> +UnusedPropertyIvar]>,
>>  DiagCategory<"Unused Entity Issue">;
>>
>>  // Format settings.
>>
>> Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/
>> Basic/DiagnosticSemaKinds.td?rev=291905&r1=291904&r2=291905&view=diff
>> 
>> ==
>> --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
>> +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Fri Jan 13
>> 09:01:06 2017
>> @@ -316,6 +316,9 @@ def warn_unneeded

[PATCH] D28752: [OpenMP] Refactor code that calls codegen for target regions on the device.

2017-01-15 Thread Arpith Jacob via Phabricator via cfe-commits
arpith-jacob created this revision.
arpith-jacob added reviewers: ABataev, sfantao, carlo.bertolli, kkwli0, 
caomhin, gtbercea.
arpith-jacob added a subscriber: cfe-commits.

This patch refactors code that calls codegen for target regions. Currently
the codebase only supports the 'target' directive. The patch pulls out
common target processing code into a static function that can be called
by codegen for any target directive.


https://reviews.llvm.org/D28752

Files:
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGStmtOpenMP.cpp
  lib/CodeGen/CodeGenFunction.h

Index: lib/CodeGen/CodeGenFunction.h
===
--- lib/CodeGen/CodeGenFunction.h
+++ lib/CodeGen/CodeGenFunction.h
@@ -2704,13 +2704,10 @@
   void EmitOMPTargetTeamsDistributeSimdDirective(
   const OMPTargetTeamsDistributeSimdDirective &S);
 
-  /// Emit outlined function for the target directive.
-  static std::pair
-  EmitOMPTargetDirectiveOutlinedFunction(CodeGenModule &CGM,
- const OMPTargetDirective &S,
- StringRef ParentName,
- bool IsOffloadEntry);
+  /// Emit device code for the target directive.
+  static void EmitOMPTargetDeviceFunction(CodeGenModule &CGM,
+  StringRef ParentName,
+  const OMPTargetDirective &S);
   /// \brief Emit inner loop of the worksharing/simd construct.
   ///
   /// \param S Directive, for which the inner loop must be emitted.
Index: lib/CodeGen/CGStmtOpenMP.cpp
===
--- lib/CodeGen/CGStmtOpenMP.cpp
+++ lib/CodeGen/CGStmtOpenMP.cpp
@@ -3404,32 +3404,15 @@
   CGM.getOpenMPRuntime().emitInlinedDirective(*this, OMPD_atomic, CodeGen);
 }
 
-std::pair
-CodeGenFunction::EmitOMPTargetDirectiveOutlinedFunction(
-CodeGenModule &CGM, const OMPTargetDirective &S, StringRef ParentName,
-bool IsOffloadEntry) {
-  llvm::Function *OutlinedFn = nullptr;
-  llvm::Constant *OutlinedFnID = nullptr;
-  auto &&CodeGen = [&S](CodeGenFunction &CGF, PrePostActionTy &Action) {
-OMPPrivateScope PrivateScope(CGF);
-(void)CGF.EmitOMPFirstprivateClause(S, PrivateScope);
-CGF.EmitOMPPrivateClause(S, PrivateScope);
-(void)PrivateScope.Privatize();
-
-Action.Enter(CGF);
-CGF.EmitStmt(cast(S.getAssociatedStmt())->getCapturedStmt());
-  };
-  // Emit target region as a standalone region.
-  CGM.getOpenMPRuntime().emitTargetOutlinedFunction(
-  S, ParentName, OutlinedFn, OutlinedFnID, IsOffloadEntry, CodeGen);
-  return std::make_pair(OutlinedFn, OutlinedFnID);
-}
-
-void CodeGenFunction::EmitOMPTargetDirective(const OMPTargetDirective &S) {
+static void emitCommonOMPTargetDirective(CodeGenFunction &CGF,
+ const OMPExecutableDirective &S,
+ const RegionCodeGenTy &CodeGen) {
+  assert(isOpenMPTargetExecutionDirective(S.getDirectiveKind()));
+  CodeGenModule &CGM = CGF.CGM;
   const CapturedStmt &CS = *cast(S.getAssociatedStmt());
 
   llvm::SmallVector CapturedVars;
-  GenerateOpenMPCapturedVars(CS, CapturedVars);
+  CGF.GenerateOpenMPCapturedVars(CS, CapturedVars);
 
   llvm::Function *Fn = nullptr;
   llvm::Constant *FnID = nullptr;
@@ -3453,31 +3436,64 @@
   bool IsOffloadEntry = true;
   if (IfCond) {
 bool Val;
-if (ConstantFoldsToSimpleInteger(IfCond, Val) && !Val)
+if (CGF.ConstantFoldsToSimpleInteger(IfCond, Val) && !Val)
   IsOffloadEntry = false;
   }
   if (CGM.getLangOpts().OMPTargetTriples.empty())
 IsOffloadEntry = false;
 
-  assert(CurFuncDecl && "No parent declaration for target region!");
+  assert(CGF.CurFuncDecl && "No parent declaration for target region!");
   StringRef ParentName;
   // In case we have Ctors/Dtors we use the complete type variant to produce
   // the mangling of the device outlined kernel.
-  if (auto *D = dyn_cast(CurFuncDecl))
+  if (auto *D = dyn_cast(CGF.CurFuncDecl))
 ParentName = CGM.getMangledName(GlobalDecl(D, Ctor_Complete));
-  else if (auto *D = dyn_cast(CurFuncDecl))
+  else if (auto *D = dyn_cast(CGF.CurFuncDecl))
 ParentName = CGM.getMangledName(GlobalDecl(D, Dtor_Complete));
   else
 ParentName =
-CGM.getMangledName(GlobalDecl(cast(CurFuncDecl)));
+CGM.getMangledName(GlobalDecl(cast(CGF.CurFuncDecl)));
 
-  std::tie(Fn, FnID) = EmitOMPTargetDirectiveOutlinedFunction(
-  CGM, S, ParentName, IsOffloadEntry);
-  OMPLexicalScope Scope(*this, S);
-  CGM.getOpenMPRuntime().emitTargetCall(*this, S, Fn, FnID, IfCond, Device,
+  // Emit target region as a standalone region.
+  CGM.getOpenMPRuntime().emitTargetOutlinedFunction(S, ParentName, Fn, FnID,
+IsOffloadEntry, CodeGen);
+  OMPLexicalScope Scope(CGF, S);
+  CGM.getOpenMPRuntime().emitTargetCall(CGF, S, Fn, FnID,

[libcxx] r292086 - Reland "[CMake][libcxx] Check that we have libcxxabi before using it"

2017-01-15 Thread Petr Hosek via cfe-commits
Author: phosek
Date: Sun Jan 15 18:33:11 2017
New Revision: 292086

URL: http://llvm.org/viewvc/llvm-project?rev=292086&view=rev
Log:
Reland "[CMake][libcxx] Check that we have libcxxabi before using it"

This relands commit r291726.

Modified:
libcxx/trunk/CMakeLists.txt

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=292086&r1=292085&r2=292086&view=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Sun Jan 15 18:33:11 2017
@@ -125,7 +125,8 @@ if (LIBCXX_CXX_ABI STREQUAL "default")
   ${LLVM_MAIN_SRC_DIR}/runtimes/libcxxabi/include
 NO_DEFAULT_PATH
   )
-  if (IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
+  if ((NOT LIBCXX_STANDALONE_BUILD OR HAVE_LIBCXXABI) AND
+  IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
 set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
 set(LIBCXX_CXX_ABI_INCLUDE_PATHS "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
 set(LIBCXX_CXX_ABI_INTREE 1)


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


[libcxx] r292085 - Reland "[CMake][libcxx] Do not rely on the existence of c++abi or unwind targets"

2017-01-15 Thread Petr Hosek via cfe-commits
Author: phosek
Date: Sun Jan 15 18:33:09 2017
New Revision: 292085

URL: http://llvm.org/viewvc/llvm-project?rev=292085&view=rev
Log:
Reland "[CMake][libcxx] Do not rely on the existence of c++abi or unwind 
targets"

This relands commit r291727.

Modified:
libcxx/trunk/CMakeLists.txt
libcxx/trunk/lib/CMakeLists.txt

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=292085&r1=292084&r2=292085&view=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Sun Jan 15 18:33:09 2017
@@ -125,8 +125,7 @@ if (LIBCXX_CXX_ABI STREQUAL "default")
   ${LLVM_MAIN_SRC_DIR}/runtimes/libcxxabi/include
 NO_DEFAULT_PATH
   )
-  if (NOT DEFINED LIBCXX_STANDALONE_BUILD AND
-  IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
+  if (IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
 set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
 set(LIBCXX_CXX_ABI_INCLUDE_PATHS "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
 set(LIBCXX_CXX_ABI_INTREE 1)

Modified: libcxx/trunk/lib/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/lib/CMakeLists.txt?rev=292085&r1=292084&r2=292085&view=diff
==
--- libcxx/trunk/lib/CMakeLists.txt (original)
+++ libcxx/trunk/lib/CMakeLists.txt Sun Jan 15 18:33:09 2017
@@ -247,7 +247,8 @@ if (LIBCXX_ENABLE_STATIC)
 if (LIBCXX_CXX_ABI_LIBRARY_PATH)
   set(MERGE_ARCHIVES_SEARCH_PATHS "-L${LIBCXX_CXX_ABI_LIBRARY_PATH}")
 endif()
-if (TARGET ${LIBCXX_CXX_ABI_LIBRARY})
+if ((TARGET ${LIBCXX_CXX_ABI_LIBRARY}) OR
+(${LIBCXX_CXX_ABI_LIBRARY} STREQUAL "cxxabi(_static|_shared)?" AND 
HAVE_LIBCXXABI))
   set(MERGE_ARCHIVES_ABI_TARGET 
"$")
 else()
   set(MERGE_ARCHIVES_ABI_TARGET
@@ -318,7 +319,9 @@ if (LIBCXX_ENABLE_SHARED AND LIBCXX_ENAB
   set(LIBCXX_INTERFACE_LIBRARY_NAMES)
   foreach(lib ${LIBCXX_INTERFACE_LIBRARIES})
 # FIXME: Handle cxxabi_static and unwind_static.
-if (TARGET ${lib})
+if (TARGET ${lib} OR
+(${lib} MATCHES "cxxabi(_static|_shared)?" AND HAVE_LIBCXXABI) OR
+(${lib} MATCHES "unwind(_static|_shared)?" AND HAVE_LIBUNWIND))
   list(APPEND LIBCXX_INTERFACE_LIBRARY_NAMES 
"$")
 else()
   list(APPEND LIBCXX_INTERFACE_LIBRARY_NAMES "${lib}")


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


[libcxx] r292084 - Reland "[CMake][libcxx] Move Python check to main CMake file"

2017-01-15 Thread Petr Hosek via cfe-commits
Author: phosek
Date: Sun Jan 15 18:33:07 2017
New Revision: 292084

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

This relands commit r291728.

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

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

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


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


[PATCH] D28753: [OpenMP] Codegen support for 'target parallel' on the host.

2017-01-15 Thread Arpith Jacob via Phabricator via cfe-commits
arpith-jacob created this revision.
arpith-jacob added reviewers: ABataev, sfantao, carlo.bertolli, caomhin, 
kkwli0, gtbercea.
arpith-jacob added a subscriber: cfe-commits.
Herald added a subscriber: jholewinski.

This patch adds support for codegen of 'target parallel' on the host.
It is also the first combined directive that requires two or more
captured statements. Support for this functionality is included in
the patch.

  

A combined directive such as 'target parallel' has two captured
statements, one for the 'target' and the other for the 'parallel'
region. Two captured statements are required because each has
different implicit parameters (see SemaOpenMP.cpp). For example,
the 'parallel' has 'global_tid' and 'bound_tid' while the 'target'
does not. The patch adds support for handling multiple captured
statements based on the combined directive.

  

When codegen'ing the 'target parallel' directive, the 'target'
outlined function is created using the outer captured statement
and the 'parallel' outlined function is created using the inner
captured statement.


https://reviews.llvm.org/D28753

Files:
  include/clang/Sema/Sema.h
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntime.h
  lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
  lib/CodeGen/CGOpenMPRuntimeNVPTX.h
  lib/CodeGen/CGStmtOpenMP.cpp
  lib/CodeGen/CodeGenFunction.h
  lib/Sema/SemaOpenMP.cpp
  lib/Sema/TreeTransform.h
  test/OpenMP/target_parallel_codegen.cpp
  test/OpenMP/target_parallel_codegen_registration.cpp
  test/OpenMP/target_parallel_codegen_registration_naming.cpp

Index: test/OpenMP/target_parallel_codegen_registration_naming.cpp
===
--- /dev/null
+++ test/OpenMP/target_parallel_codegen_registration_naming.cpp
@@ -0,0 +1,66 @@
+// Test host codegen.
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -fopenmp-targets=powerpc64le-ibm-linux-gnu -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -fopenmp -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -fopenmp-targets=powerpc64le-ibm-linux-gnu -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -fopenmp-targets=powerpc64le-ibm-linux-gnu -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -std=c++11 -triple i386-unknown-unknown -fopenmp-targets=i386-pc-linux-gnu -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -fopenmp -x c++ -std=c++11 -triple i386-unknown-unknown -fopenmp-targets=i386-pc-linux-gnu -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -x c++ -std=c++11 -triple i386-unknown-unknown -fopenmp-targets=i386-pc-linux-gnu -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s
+
+// Test target parallel codegen - host bc file has to be created first.
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -fopenmp-targets=powerpc64le-ibm-linux-gnu -emit-llvm-bc %s -o %t-ppc-host.bc
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -fopenmp-targets=powerpc64le-ibm-linux-gnu -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o - | FileCheck %s -check-prefix=TCHECK
+// RUN: %clang_cc1 -fopenmp -x c++ -std=c++11 -std=c++11 -triple powerpc64le-unknown-unknown -fopenmp-targets=powerpc64le-ibm-linux-gnu -emit-pch -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o %t %s
+// RUN: %clang_cc1 -fopenmp -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -fopenmp-targets=powerpc64le-ibm-linux-gnu -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s -check-prefix=TCHECK
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -std=c++11 -triple i386-unknown-unknown -fopenmp-targets=i386-pc-linux-gnu -emit-llvm-bc %s -o %t-x86-host.bc
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -std=c++11 -triple i386-unknown-unknown -fopenmp-targets=i386-pc-linux-gnu -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-x86-host.bc -o - | FileCheck %s -check-prefix=TCHECK
+// RUN: %clang_cc1 -fopenmp -x c++ -std=c++11 -triple i386-unknown-unknown -fopenmp-targets=i386-pc-linux-gnu -emit-pch -fopenmp-is-device -fopenmp-host-ir-file-path %t-x86-host.bc -o %t %s
+// RUN: %clang_cc1 -fopenmp -x c++ -std=c++11 -triple i386-unknown-unknown -fopenmp-targets=i386-pc-linux-gnu -fopenmp-is-device -fopenmp-host-ir-file-path %t-x86-host.bc -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s -check-prefix=TCHECK
+
+// expected-no-diagnostics
+#ifndef HEADER
+#define HEADER
+
+// CHECK: [[CA:%.+]] = type { i32* }
+
+// CHECK: define {{.*}}i32 @[[NNAME:.+]](i32 {{.*}}%{{.+}})
+int nested(int a){
+  // CHECK: call void @__omp_offloading_[[FILEID:[0-9a-f]+_[0-9a-f]+]]_[[NNAME]]_l[[T1L:[0-9]+]](
+  #pragma omp target parallel
+++a;
+
+  // CHECK: call void @"[[LNAME:.+]]"([[CA]]*
+  auto F = [&](){
+#pragma omp p

[PATCH] D28755: [OpenMP] Codegen for the 'target parallel' directive on the NVPTX device.

2017-01-15 Thread Arpith Jacob via Phabricator via cfe-commits
arpith-jacob created this revision.
arpith-jacob added reviewers: ABataev, sfantao, carlo.bertolli, caomhin, 
kkwli0, gtbercea.
arpith-jacob added a subscriber: cfe-commits.
Herald added a subscriber: jholewinski.

This patch adds codegen for the 'target parallel' directive on the NVPTX
device. We term offload OpenMP directives such as 'target parallel' and
'target teams distribute parallel for' as SPMD constructs. SPMD constructs,
in contrast to generic ones like the plain 'target', can never contain
a serial region.

SPMD constructs can be handled more efficiently on the GPU and do not
require the Warp loop of the generic codegen scheme. This patch adds
SPMD codegen support for 'target parallel' and can be reused for other
SPMD constructs.


https://reviews.llvm.org/D28755

Files:
  lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
  lib/CodeGen/CGOpenMPRuntimeNVPTX.h
  test/OpenMP/nvptx_target_codegen.cpp
  test/OpenMP/nvptx_target_parallel_codegen.cpp

Index: test/OpenMP/nvptx_target_parallel_codegen.cpp
===
--- /dev/null
+++ test/OpenMP/nvptx_target_parallel_codegen.cpp
@@ -0,0 +1,136 @@
+// Test target codegen - host bc file has to be created first.
+// RUN: %clang_cc1 -verify -fopenmp -fopenmp-version=45 -x c++ -triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm-bc %s -o %t-ppc-host.bc
+// RUN: %clang_cc1 -verify -fopenmp -fopenmp-version=45 -x c++ -triple nvptx64-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o - | FileCheck %s --check-prefix CHECK --check-prefix CHECK-64
+// RUN: %clang_cc1 -verify -fopenmp -fopenmp-version=45 -x c++ -triple i386-unknown-unknown -fopenmp-targets=nvptx-nvidia-cuda -emit-llvm-bc %s -o %t-x86-host.bc
+// RUN: %clang_cc1 -verify -fopenmp -fopenmp-version=45 -x c++ -triple nvptx-unknown-unknown -fopenmp-targets=nvptx-nvidia-cuda -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-x86-host.bc -o - | FileCheck %s --check-prefix CHECK --check-prefix CHECK-32
+// RUN: %clang_cc1 -verify -fopenmp -fopenmp-version=45 -fexceptions -fcxx-exceptions -x c++ -triple nvptx-unknown-unknown -fopenmp-targets=nvptx-nvidia-cuda -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-x86-host.bc -o - | FileCheck %s --check-prefix CHECK --check-prefix CHECK-32
+// expected-no-diagnostics
+#ifndef HEADER
+#define HEADER
+
+// Check that the execution mode of all 2 target regions on the gpu is set to SPMD Mode.
+// CHECK-DAG: {{@__omp_offloading_.+l26}}_exec_mode = weak constant i8 0
+// CHECK-DAG: {{@__omp_offloading_.+l31}}_exec_mode = weak constant i8 0
+
+template
+tx ftemplate(int n) {
+  tx a = 0;
+  short aa = 0;
+  tx b[10];
+
+  #pragma omp target parallel if(target: 0)
+  {
+a += 1;
+  }
+
+  #pragma omp target parallel map(tofrom: aa)
+  {
+aa += 1;
+  }
+
+  #pragma omp target parallel map(tofrom:a, aa, b) if(target: n>40)
+  {
+a += 1;
+aa += 1;
+b[2] += 1;
+  }
+
+  return a;
+}
+
+int bar(int n){
+  int a = 0;
+
+  a += ftemplate(n);
+
+  return a;
+}
+
+  // CHECK-NOT: define {{.*}}void {{@__omp_offloading_.+template.+l17}}
+
+
+
+
+
+
+  // CHECK-LABEL: define {{.*}}void {{@__omp_offloading_.+template.+l26}}(
+  // CHECK: [[AA_ADDR:%.+]] = alloca i16*, align
+  // CHECK: store i16* {{%.+}}, i16** [[AA_ADDR]], align
+  // CHECK: [[AA:%.+]] = load i16*, i16** [[AA_ADDR]], align
+  // CHECK: [[THREAD_LIMIT:%.+]] = call i32 @llvm.nvvm.read.ptx.sreg.ntid.x()
+  // CHECK: call void @__kmpc_spmd_kernel_init(i32 [[THREAD_LIMIT]],
+  // CHECK: br label {{%?}}[[EXEC:.+]]
+  //
+  // CHECK: [[EXEC]]
+  // CHECK: {{call|invoke}} void [[OP1:@.+]](i32* null, i32* null, i16* [[AA]])
+  // CHECK: br label {{%?}}[[DONE:.+]]
+  //
+  // CHECK: [[DONE]]
+  // CHECK: call void @__kmpc_spmd_kernel_deinit()
+  // CHECK: br label {{%?}}[[EXIT:.+]]
+  //
+  // CHECK: [[EXIT]]
+  // CHECK: ret void
+  // CHECK: }
+
+  // CHECK: define internal void [[OP1]](i32* noalias %.global_tid., i32* noalias %.bound_tid., i16* {{[^%]*}}[[ARG:%.+]])
+  // CHECK: = alloca i32*, align
+  // CHECK: = alloca i32*, align
+  // CHECK: [[AA_ADDR:%.+]] = alloca i16*, align
+  // CHECK: store i16* [[ARG]], i16** [[AA_ADDR]], align
+  // CHECK: [[AA:%.+]] = load i16*, i16** [[AA_ADDR]], align
+  // CHECK: [[VAL:%.+]] = load i16, i16* [[AA]], align
+  // CHECK: store i16 {{%.+}}, i16* [[AA]], align
+  // CHECK: ret void
+  // CHECK: }
+
+
+
+
+
+
+  // CHECK-LABEL: define {{.*}}void {{@__omp_offloading_.+template.+l31}}(
+  // CHECK: [[A_ADDR:%.+]] = alloca i32*, align
+  // CHECK: [[AA_ADDR:%.+]] = alloca i16*, align
+  // CHECK: [[B_ADDR:%.+]] = alloca [10 x i32]*, align
+  // CHECK: store i32* {{%.+}}, i32** [[A_ADDR]], align
+  // CHECK: store i16* {{%.+}}, i16** [[AA_ADDR]], align
+  // CHECK: store [10 x i32]* {{%.+}}, [10 x i32]** [[B_ADDR]], align
+  // CHECK: [[A:%.+]] = load i32*, i32** [[A_ADDR]], align
+  // C

[libcxx] r292091 - Implement the missing constexpr stuff in . Fixes PR#31645.

2017-01-15 Thread Marshall Clow via cfe-commits
Author: marshall
Date: Sun Jan 15 21:02:10 2017
New Revision: 292091

URL: http://llvm.org/viewvc/llvm-project?rev=292091&view=rev
Log:
Implement the missing constexpr stuff in . Fixes PR#31645.

Modified:
libcxx/trunk/include/array
libcxx/trunk/test/std/containers/sequences/array/at.pass.cpp
libcxx/trunk/test/std/containers/sequences/array/front_back.pass.cpp
libcxx/trunk/test/std/containers/sequences/array/indexing.pass.cpp

Modified: libcxx/trunk/include/array
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/array?rev=292091&r1=292090&r2=292091&view=diff
==
--- libcxx/trunk/include/array (original)
+++ libcxx/trunk/include/array Sun Jan 15 21:02:10 2017
@@ -185,14 +185,17 @@ struct _LIBCPP_TEMPLATE_VIS array
 _LIBCPP_CONSTEXPR bool empty() const _NOEXCEPT {return _Size == 0;}
 
 // element access:
-_LIBCPP_INLINE_VISIBILITY reference operator[](size_type __n) 
{return __elems_[__n];}
-_LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_AFTER_CXX11 const_reference 
operator[](size_type __n) const {return __elems_[__n];}
-reference at(size_type __n);
+_LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_AFTER_CXX14
+reference operator[](size_type __n) {return __elems_[__n];}
+_LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_AFTER_CXX11
+const_reference operator[](size_type __n) const {return __elems_[__n];}
+
+_LIBCPP_CONSTEXPR_AFTER_CXX14   reference at(size_type __n);
 _LIBCPP_CONSTEXPR_AFTER_CXX11 const_reference at(size_type __n) const;
 
-_LIBCPP_INLINE_VISIBILITY reference front() {return 
__elems_[0];}
+_LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_AFTER_CXX14 reference front()  
   {return __elems_[0];}
 _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_AFTER_CXX11 const_reference 
front() const {return __elems_[0];}
-_LIBCPP_INLINE_VISIBILITY reference back()  {return 
__elems_[_Size > 0 ? _Size-1 : 0];}
+_LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_AFTER_CXX14 reference back()   
   {return __elems_[_Size > 0 ? _Size-1 : 0];}
 _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_AFTER_CXX11 const_reference 
back() const  {return __elems_[_Size > 0 ? _Size-1 : 0];}
 
 _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_AFTER_CXX14
@@ -202,6 +205,7 @@ struct _LIBCPP_TEMPLATE_VIS array
 };
 
 template 
+_LIBCPP_CONSTEXPR_AFTER_CXX14
 typename array<_Tp, _Size>::reference
 array<_Tp, _Size>::at(size_type __n)
 {

Modified: libcxx/trunk/test/std/containers/sequences/array/at.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/containers/sequences/array/at.pass.cpp?rev=292091&r1=292090&r2=292091&view=diff
==
--- libcxx/trunk/test/std/containers/sequences/array/at.pass.cpp (original)
+++ libcxx/trunk/test/std/containers/sequences/array/at.pass.cpp Sun Jan 15 
21:02:10 2017
@@ -23,6 +23,14 @@
 // Disable the missing braces warning for this reason.
 #include "disable_missing_braces_warning.h"
 
+#if TEST_STD_VER > 14
+constexpr bool check_idx( size_t idx, double val )
+{ 
+std::array arr = {1, 2, 3.5};
+   return arr.at(idx) == val;
+}
+#endif
+
 int main()
 {
 {
@@ -82,4 +90,11 @@ int main()
 }
 #endif
 
+#if TEST_STD_VER > 14
+{
+static_assert (check_idx(0, 1), "");
+static_assert (check_idx(1, 2), "");
+static_assert (check_idx(2, 3.5), "");
+}
+#endif
 }

Modified: libcxx/trunk/test/std/containers/sequences/array/front_back.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/containers/sequences/array/front_back.pass.cpp?rev=292091&r1=292090&r2=292091&view=diff
==
--- libcxx/trunk/test/std/containers/sequences/array/front_back.pass.cpp 
(original)
+++ libcxx/trunk/test/std/containers/sequences/array/front_back.pass.cpp Sun 
Jan 15 21:02:10 2017
@@ -9,10 +9,10 @@
 
 // 
 
-// reference front();
-// reference back();
+// reference front();   // constexpr in C++17
+// reference back();// constexpr in C++17
 // const_reference front(); // constexpr in C++14
-// const_reference back(); // constexpr in C++14
+// const_reference back();  // constexpr in C++14
 
 #include 
 #include 
@@ -23,6 +23,20 @@
 // Disable the missing braces warning for this reason.
 #include "disable_missing_braces_warning.h"
 
+#if TEST_STD_VER > 14
+constexpr bool check_front( double val )
+{ 
+std::array arr = {1, 2, 3.5};
+   return arr.front() == val;
+}
+
+constexpr bool check_back( double val )
+{ 
+std::array arr = {1, 2, 3.5};
+   return arr.back() == val;
+}
+#endif
+
 int main()
 {
 {
@@ -65,4 +79,10 @@ int main()
 }
 #endif
 
+#if TEST_STD_VER > 14
+{
+static_assert (check_front(1),   "");
+static_assert (check_back (3.5), "");
+}

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

2017-01-15 Thread Vlad Tsyrklevich via Phabricator via cfe-commits
vlad.tsyrklevich updated this revision to Diff 84517.
vlad.tsyrklevich added a comment.

Artem, thank you for the very detailed reply! Between this, and hitting the 
right search terms to find your clang analyzer guide my understanding of the 
symbol abstractions the analyzer exposes has improved significantly.

You state that it's not easy to derive the conjured symbols from the Store; 
however, it didn't seem to be too difficult to do by recursively finding the 
bindings for the constituent FieldRegions (if the LCV is backing a 
struct/union) or the first ElementRegion (if the LCV is backing an array) until 
you reach an element/field initialized with the conjured symbol. Does the new 
patch look correct to you? Your comment about the difficulty has me unsure 
whether I've fully grasped the scope of the problem.

One wrinkle you'll notice is in the patch to `taint-tester.c`, one FIXME for 
missing taint has been fixed, but now one variable that should not be tainted 
is! This seems to be because of overeager invalidation, not strictly the fault 
of the patch but it is exposed by it.


https://reviews.llvm.org/D28445

Files:
  lib/StaticAnalyzer/Checkers/GenericTaintChecker.cpp
  lib/StaticAnalyzer/Core/ProgramState.cpp
  test/Analysis/taint-generic.c
  test/Analysis/taint-tester.c

Index: test/Analysis/taint-tester.c
===
--- test/Analysis/taint-tester.c
+++ test/Analysis/taint-tester.c
@@ -51,8 +51,9 @@
   scanf("%d", &xy.y);
   scanf("%d", &xy.x);
   int tx = xy.x; // expected-warning + {{tainted}}
-  int ty = xy.y; // FIXME: This should be tainted as well.
-  char ntz = xy.z;// no warning
+  int ty = xy.y; // expected-warning + {{tainted}}
+  // FIXME: xy.z should not be tainted
+  char ntz = xy.z; // expected-warning + {{tainted}}
   // Now, scanf scans both.
   scanf("%d %d", &xy.y, &xy.x);
   int ttx = xy.x; // expected-warning + {{tainted}}
Index: test/Analysis/taint-generic.c
===
--- test/Analysis/taint-generic.c
+++ test/Analysis/taint-generic.c
@@ -169,6 +169,26 @@
   sock = socket(AF_LOCAL, SOCK_STREAM, 0);
   read(sock, buffer, 100);
   execl(buffer, "filename", 0); // no-warning
+
+  sock = socket(AF_INET, SOCK_STREAM, 0);
+  // References to both buffer and &buffer as an argument should taint the argument
+  read(sock, &buffer, 100);
+  execl(buffer, "filename", 0); // expected-warning {{Untrusted data is passed to a system call}}
+}
+
+void testStruct() {
+  struct {
+struct {} st;
+char buf[16];
+int length;
+  } tainted;
+
+  char buffer[16];
+  int sock;
+
+  sock = socket(AF_INET, SOCK_STREAM, 0);
+  read(sock, &tainted, sizeof(tainted));
+  __builtin_memcpy(buffer, tainted.buf, tainted.length); // expected-warning {{Untrusted data is used to specify the buffer size}}
 }
 
 int testDivByZero() {
Index: lib/StaticAnalyzer/Core/ProgramState.cpp
===
--- lib/StaticAnalyzer/Core/ProgramState.cpp
+++ lib/StaticAnalyzer/Core/ProgramState.cpp
@@ -664,6 +664,10 @@
   while (const SymbolCast *SC = dyn_cast(Sym))
 Sym = SC->getOperand();
 
+  // If this a derived symbol, taint the parent symbol.
+  if (const SymbolDerived *SD = dyn_cast(Sym))
+Sym = SD->getParentSymbol();
+
   ProgramStateRef NewState = set(Sym, Kind);
   assert(NewState);
   return NewState;
Index: lib/StaticAnalyzer/Checkers/GenericTaintChecker.cpp
===
--- lib/StaticAnalyzer/Checkers/GenericTaintChecker.cpp
+++ lib/StaticAnalyzer/Checkers/GenericTaintChecker.cpp
@@ -65,6 +65,11 @@
   /// and thus, is tainted.
   static bool isStdin(const Expr *E, CheckerContext &C);
 
+  /// \brief Given a LazyCompoundValue, get the symbol of the first FieldRegion/
+  /// ElementRegion we can find a binding for.
+  static SymbolRef getLCVSymbol(CheckerContext &C,
+nonloc::LazyCompoundVal &LCV);
+
   /// \brief Given a pointer argument, get the symbol of the value it contains
   /// (points to).
   static SymbolRef getPointedToSymbol(CheckerContext &C, const Expr *Arg);
@@ -423,6 +428,43 @@
   return false;
 }
 
+SymbolRef GenericTaintChecker::getLCVSymbol(CheckerContext &C,
+nonloc::LazyCompoundVal &LCV) {
+  StoreManager &StoreMgr = C.getStoreManager();
+  MemRegionManager &MrMgr = C.getSValBuilder().getRegionManager();
+
+  QualType T = LCV.getRegion()->getValueType();
+  if (T->isStructureType() || T->isUnionType()) {
+const RecordType *RT = T->getAsStructureType();
+if (!RT)
+  RT = T->getAsUnionType();
+
+const RecordDecl *RD = RT->getDecl()->getDefinition();
+for (const auto *I : RD->fields()) {
+  const FieldRegion *FR = MrMgr.getFieldRegion(I, LCV.getRegion());
+  const SVal &V =
+  StoreMgr.getBinding(LCV.getStore(), loc::MemRegionVal(FR));
+  if (auto

[PATCH] D28667: [clang-tidy] Don't modernize-raw-string-literal if replacement is longer.

2017-01-15 Thread AndrĂ¡s Leitereg via Phabricator via cfe-commits
leanil added inline comments.



Comment at: test/clang-tidy/modernize-raw-string-literal.cpp:94
 
+char const *const Concatenated("\"foo\""
+   "\"bar\"");

alexfh wrote:
> Does this test fail without the patch? Also, should there be a test covering 
> the case where no replacement is made (and the current code issues a warning)?
No, it doesn't. This is to check that MeasureTokenLength works as I expect. It 
wouldn't warn if it measured the two parts separately.
And I left the check here for those who may have the same concerns, although 
it's indeed not the core functionality I test here. Should I remove it?


https://reviews.llvm.org/D28667



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


[PATCH] D28752: [OpenMP] Refactor code that calls codegen for target regions on the device.

2017-01-15 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev accepted this revision.
ABataev added a comment.
This revision is now accepted and ready to land.

Is this an NFC patch? If so add 'NFC' to this patch.
LG


https://reviews.llvm.org/D28752



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