Re: [PATCH] D22374: [analyzer] Copy and move constructors - ExprEngine extended for "almost trivial" copy and move constructors

[Aleksei Sidorin via cfe-commits]

a.sidorin added a comment.

Adam,

It is not a debug checker. It is UndefinedAssignment checker which correctly 
tells us that `Inner.y` is assigned with an uninitialized value while copying. 
So I wonder if we are allowed to skip such warnings because these warnings 
don't look like false positives.
As I understand, these warnings disappeared because `performTrivialCopy()` 
doesn't run checkers for `check::Bind`event. Not sure but maybe we should fix 
that?


https://reviews.llvm.org/D22374



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

r275826 - [clang-cl] Reinstate -gline-tables-only as a CoreOption while we sort out the fate of /Zd

[Reid Kleckner via cfe-commits]

Author: rnk
Date: Mon Jul 18 12:49:40 2016
New Revision: 275826

URL: http://llvm.org/viewvc/llvm-project?rev=275826&view=rev
Log:
[clang-cl] Reinstate -gline-tables-only as a CoreOption while we sort out the 
fate of /Zd

Modified:
cfe/trunk/include/clang/Driver/Options.td

Modified: cfe/trunk/include/clang/Driver/Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=275826&r1=275825&r2=275826&view=diff
==
--- cfe/trunk/include/clang/Driver/Options.td (original)
+++ cfe/trunk/include/clang/Driver/Options.td Mon Jul 18 12:49:40 2016
@@ -1246,7 +1246,7 @@ def fdebug_prefix_map_EQ
 def g_Flag : Flag<["-"], "g">, Group,
   HelpText<"Generate source-level debug information">;
 def gline_tables_only : Flag<["-"], "gline-tables-only">, Group,
-  HelpText<"Emit debug line number tables only">;
+  Flags<[CoreOption]>, HelpText<"Emit debug line number tables only">;
 def gmlt : Flag<["-"], "gmlt">, Alias;
 def g0 : Flag<["-"], "g0">, Group;
 def g1 : Flag<["-"], "g1">, Group, Alias;


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

Re: r275820 - [analyzer] Add checker modeling potential C++ self-assignment

[Devin Coughlin via cfe-commits]

Hans,

I’m happy to revert — but I think r275820 is very unlikely to have been the 
root cause of the issue at 
http://bb.pgr.jp/builders/cmake-llvm-x86_64-linux/builds/40225/ 
. (The commit 
is a change to the clang static analyzer and the bot failure seems to be in 
LLVM CodeGen).

Was this just a link mis-copy/paste? Is there another bot failing?

Devin

> On Jul 18, 2016, at 10:50 AM, Hans Wennborg  wrote:
> 
> It seems to have broken this buildbot:
> http://bb.pgr.jp/builders/cmake-llvm-x86_64-linux/builds/40225/
> 
> I'm just about to create the 3.9 release branch, so it would be great
> if this could fixed/figured out soon.
> 
> Thanks,
> Hans
> 
> On Mon, Jul 18, 2016 at 10:23 AM, Devin Coughlin via cfe-commits
>  wrote:
>> Author: dcoughlin
>> Date: Mon Jul 18 12:23:30 2016
>> New Revision: 275820
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=275820&view=rev
>> Log:
>> [analyzer] Add checker modeling potential C++ self-assignment
>> 
>> This checker checks copy and move assignment operators whether they are
>> protected against self-assignment. Since C++ core guidelines discourages
>> explicit checking for `&rhs==this` in general we take a different approach: 
>> in
>> top-frame analysis we branch the exploded graph for two cases, where 
>> &rhs==this
>> and &rhs!=this and let existing checkers (e.g. unix.Malloc) do the rest of 
>> the
>> work. It is important that we check all copy and move assignment operator in 
>> top
>> frame even if we checked them already since self-assignments may happen
>> undetected even in the same translation unit (e.g. using random indices for 
>> an
>> array what may or may not be the same).
>> 
>> A patch by Ádám Balogh!
>> 
>> Differential Revision: https://reviews.llvm.org/D19311
>> 
>> Added:
>>cfe/trunk/lib/StaticAnalyzer/Checkers/CXXSelfAssignmentChecker.cpp
>>cfe/trunk/test/Analysis/self-assign.cpp
>> Modified:
>>cfe/trunk/include/clang/StaticAnalyzer/Checkers/Checkers.td
>>
>> cfe/trunk/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitor.h
>>cfe/trunk/lib/StaticAnalyzer/Checkers/CMakeLists.txt
>>cfe/trunk/lib/StaticAnalyzer/Core/BugReporter.cpp
>>cfe/trunk/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
>>cfe/trunk/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
>> 
>> Modified: cfe/trunk/include/clang/StaticAnalyzer/Checkers/Checkers.td
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/StaticAnalyzer/Checkers/Checkers.td?rev=275820&r1=275819&r2=275820&view=diff
>> ==
>> --- cfe/trunk/include/clang/StaticAnalyzer/Checkers/Checkers.td (original)
>> +++ cfe/trunk/include/clang/StaticAnalyzer/Checkers/Checkers.td Mon Jul 18 
>> 12:23:30 2016
>> @@ -247,6 +247,10 @@ def NewDeleteLeaksChecker : Checker<"New
>>   HelpText<"Check for memory leaks. Traces memory managed by new/delete.">,
>>   DescFile<"MallocChecker.cpp">;
>> 
>> +def CXXSelfAssignmentChecker : Checker<"SelfAssignment">,
>> +  HelpText<"Checks C++ copy and move assignment operators for self 
>> assignment">,
>> +  DescFile<"CXXSelfAssignmentChecker.cpp">;
>> +
>> } // end: "cplusplus"
>> 
>> let ParentPackage = CplusplusAlpha in {
>> 
>> Modified: 
>> cfe/trunk/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitor.h
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitor.h?rev=275820&r1=275819&r2=275820&view=diff
>> ==
>> --- 
>> cfe/trunk/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitor.h 
>> (original)
>> +++ 
>> cfe/trunk/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitor.h 
>> Mon Jul 18 12:23:30 2016
>> @@ -331,6 +331,22 @@ public:
>>  BugReport &BR) override;
>> };
>> 
>> +class CXXSelfAssignmentBRVisitor final
>> +  : public BugReporterVisitorImpl {
>> +
>> +  bool Satisfied;
>> +
>> +public:
>> +  CXXSelfAssignmentBRVisitor() : Satisfied(false) {}
>> +
>> +  void Profile(llvm::FoldingSetNodeID &ID) const override {}
>> +
>> +  PathDiagnosticPiece *VisitNode(const ExplodedNode *Succ,
>> + const ExplodedNode *Pred,
>> + BugReporterContext &BRC,
>> + BugReport &BR) override;
>> +};
>> +
>> namespace bugreporter {
>> 
>> /// Attempts to add visitors to trace a null or undefined value back to its
>> 
>> Modified: cfe/trunk/lib/StaticAnalyzer/Checkers/CMakeLists.txt
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Checkers/CMakeLists.txt?rev=275820&r1=275819&r2=275820&view=diff
>> ==
>> --- cfe/trunk/lib/StaticAnalyzer/Checkers/CMakeLists.txt (original)
>> +++ cfe/trunk/lib/Stati

Re: [PATCH] D22200: [libc++] Fix macOS Sierra build issues by declaring basic_string(const allocator_type& __a) noexcept.

[Bruno Cardoso Lopes via cfe-commits]

bruno added a subscriber: bruno.
bruno added a comment.

Hi,

Can you provide more details on what the build issues are? It seems that the 
line you introduce is covered in the ifdef below, wonder why it's not 
triggering in your build?


Repository:
  rL LLVM

https://reviews.llvm.org/D22200



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

[libcxxabi] r275833 - Creating release_39 branch off revision 275826

[Hans Wennborg via cfe-commits]

Author: hans
Date: Mon Jul 18 12:52:59 2016
New Revision: 275833

URL: http://llvm.org/viewvc/llvm-project?rev=275833&view=rev
Log:
Creating release_39 branch off revision 275826

Added:
libcxxabi/branches/release_39/
  - copied from r275826, libcxxabi/trunk/

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

[libcxx] r275832 - Creating release_39 branch off revision 275826

[Hans Wennborg via cfe-commits]

Author: hans
Date: Mon Jul 18 12:52:56 2016
New Revision: 275832

URL: http://llvm.org/viewvc/llvm-project?rev=275832&view=rev
Log:
Creating release_39 branch off revision 275826

Added:
libcxx/branches/release_39/   (props changed)
  - copied from r275826, libcxx/trunk/

Propchange: libcxx/branches/release_39/
--
svn:mergeinfo = /libcxx/branches/apple:136569-137939


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

[libunwind] r275841 - Creating release_39 branch off revision 275826

[Hans Wennborg via cfe-commits]

Author: hans
Date: Mon Jul 18 12:53:22 2016
New Revision: 275841

URL: http://llvm.org/viewvc/llvm-project?rev=275841&view=rev
Log:
Creating release_39 branch off revision 275826

Added:
libunwind/branches/release_39/
  - copied from r275826, libunwind/trunk/

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

Re: [libcxx] r275114 - Don't compute modulus of hash if it is smaller than the bucket count.

[Duncan P. N. Exon Smith via cfe-commits]

It looks like Shootout-C++ improved after that commit, if I'm reading these 
results correctly:
  http://llvm.org/perf/db_default/v4/nts/87812

> On 2016-Jul-17, at 15:16, Eric Fiselier  wrote:
> 
> FYI,
> 
> I recommitted the previously removed optimization in r275734. I believe it 
> should fix the LNT performance regression. The benchmarks I used to test this 
> change can be found in D22240 (https://reviews.llvm.org/D22240#3266819f)
> 
> /Eric
> 
> On Sun, Jul 17, 2016 at 3:09 PM, Eric Fiselier  wrote:
> 
> 
> On Sun, Jul 17, 2016 at 2:54 PM, Arthur O'Dwyer  
> wrote:
> Given that this patch is basically Chandler's talk from CppCon 2015 
> (https://www.youtube.com/watch?v=nXaxk27zwlk), I'm surprised that the commit 
> message isn't explicitly mentioning that; and surprised that Chandler himself 
> isn't weighing in on either the "this is a good idea" or "this is a bad idea" 
> side.
> 
> 
> The commit message should have been clearer. Hopefully Chandler will weigh in 
> one way or another.
>  
> 
> IMHO, if replacing "%" with "fastmod" in general-purpose code like this were 
> a good idea,
> (A) libc++ should introduce a helper function __fastmod(m,n) for the purpose, 
> not repeat the same patch everywhere there's currently a "%" operator; and/or
> (B) someone with authority over the Clang x86 backend 
> (*cough*Chandler*cough*) should look into improving the codegen for "%" by 
> auto-detecting when it might make sense to use this heuristic.
> 
> The alleged existence of performance regressions on this patch as it stands 
> seems like evidence for doing (B), IMHO, even if it takes longer.
> 
> The performance regressions are almost certainly related to the optimization 
> I removed/replaced in this patch. Previously when __hash_table::find was 
> walking the bucket elements it would only re-computer the constrained hash
> if the unconstrained hash didn't match that of the element being searched 
> for. I removed this optimization in this patch with the intent of 
> re-implementing it in the very near future (it was only in-tree for about a 
> week).
> 
> What I'm curious about if this performance regression was cause by (1) the 
> removal of this 2 week old optimization or (2) the implementation of "fast 
> mod". I suspect it's because of (1).
> 
> I'm writing more benchmarks as we speak to figure this out.
> 
>  
> 
> It's also counterintuitive to me that (__h < __bc) would be true any 
> significant fraction of the time, on a 64-bit platform. Does this happen 
> because __bc is often astronomically high, or because __h is often 
> astronomically low (presumably due to bad hash functions, such as "always 
> hash to constant 0")?
> 
> It happens due to bad hash functions. Primarily because integral types use 
> the identify hash function.
>  
> 
> my $.02,
> Arthur
> 
> 
> On Sun, Jul 17, 2016 at 1:11 PM, Eric Fiselier via cfe-commits 
>  wrote:
> Hi Duncan,
> 
> It's possibly expected. It depends on what operation it's performing. I 
> expected a bit of a performance drop in some cases but I have a plan to fix 
> those.
> Do you have a link to LNT?
> 
> On Wed, Jul 13, 2016 at 6:41 PM, Duncan P. N. Exon Smith 
>  wrote:
> Hmm.  I implied there were other regressions, but I just finished scanning 
> them.  Shootout-C++/hash2 is the only major one.  The others were small, and 
> only at -O0.
> 
> > On 2016-Jul-13, at 17:38, Duncan P. N. Exon Smith via cfe-commits 
> >  wrote:
> >
> > We saw mixed results from this on LNT, including some major regressions.  
> > For example, on x86_64, SingleSource/Benchmarks/Shootout-C++/hash2 
> > regressed 18.5% at -O3 and over 20% at -Os.
> >
> > Is this expected?
> 
> ^ Still interested in an answer, though ;).
> 
> >
> >> On 2016-Jul-11, at 15:02, Eric Fiselier via cfe-commits 
> >>  wrote:
> >>
> >> Author: ericwf
> >> Date: Mon Jul 11 17:02:02 2016
> >> New Revision: 275114
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=275114&view=rev
> >> Log:
> >> Don't compute modulus of hash if it is smaller than the bucket count.
> >>
> >> This cleans up a previous optimization attempt in hash, and results in
> >> additional performance improvements over that previous attempt. 
> >> Additionally
> >> this new optimization does not hinder the power of 2 bucket count 
> >> optimization.
> >>
> >> Modified:
> >>   libcxx/trunk/include/__hash_table
> >>
> >> Modified: libcxx/trunk/include/__hash_table
> >> URL: 
> >> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__hash_table?rev=275114&r1=275113&r2=275114&view=diff
> >> ==
> >> --- libcxx/trunk/include/__hash_table (original)
> >> +++ libcxx/trunk/include/__hash_table Mon Jul 11 17:02:02 2016
> >> @@ -90,7 +90,8 @@ inline _LIBCPP_INLINE_VISIBILITY
> >> size_t
> >> __constrain_hash(size_t __h, size_t __bc)
> >> {
> >> -return !(__bc & (__bc - 1)) ? __h & (__bc - 1) : __h % __bc;
> >> +return !(__bc & (__bc - 1)) ? __h & (__bc

Re: [PATCH] D22426: Fix automatic detection of ARM MSVC toolset in clang.exe

[Reid Kleckner via cfe-commits]

rnk added a comment.

In https://reviews.llvm.org/D22426#486129, @DaveBartolomeo wrote:

> One reasonable solution would be to choose the toolset that is hosted on the 
> same architecture as the host of clang.exe (e.g. x64-hosted Clang looks for 
> x64-hosted MSVC). If this sounds good, I can make that change in a follow-up 
> commit.


I like that, it seems more principled. In the meantime, I think we should go 
with VC/amd64_{x86|arm}/bin instead. Maybe I'm biased, but I've seem more 
linker failures due to address space exhaustion than 32-bit Windows kernels.


https://reviews.llvm.org/D22426



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

r275844 - Trunk release notes are now for 4.0.0

[Hans Wennborg via cfe-commits]

Author: hans
Date: Mon Jul 18 13:05:19 2016
New Revision: 275844

URL: http://llvm.org/viewvc/llvm-project?rev=275844&view=rev
Log:
Trunk release notes are now for 4.0.0

The 3.9 release are on the 3.9 branch.

Modified:
cfe/trunk/docs/ReleaseNotes.rst

Modified: cfe/trunk/docs/ReleaseNotes.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ReleaseNotes.rst?rev=275844&r1=275843&r2=275844&view=diff
==
--- cfe/trunk/docs/ReleaseNotes.rst (original)
+++ cfe/trunk/docs/ReleaseNotes.rst Mon Jul 18 13:05:19 2016
@@ -1,6 +1,6 @@
-=
-Clang 3.9 (In-Progress) Release Notes
-=
+===
+Clang 4.0.0 (In-Progress) Release Notes
+===
 
 .. contents::
:local:
@@ -10,7 +10,7 @@ Written by the `LLVM Team `_.
 
@@ -18,7 +18,7 @@ Introduction
 
 
 This document contains the release notes for the Clang C/C++/Objective-C
-frontend, part of the LLVM Compiler Infrastructure, release 3.9. Here we
+frontend, part of the LLVM Compiler Infrastructure, release 4.0.0. Here we
 describe the status of Clang in some detail, including major
 improvements from the previous release and new feature work. For the
 general LLVM release notes, see `the LLVM
@@ -36,8 +36,8 @@ main Clang web page, this document appli
 the current one. To see the release notes for a specific release, please
 see the `releases page `_.
 
-What's New in Clang 3.9?
-
+What's New in Clang 4.0.0?
+==
 
 Some of the major new features and improvements to Clang are listed
 here. Generic improvements to Clang as a whole or to its underlying
@@ -47,18 +47,11 @@ sections with improvements to Clang's su
 Major New Features
 --
 
-- Clang will no longer passes --build-id by default to the linker. In modern
-  linkers that is a relatively expensive option. It can be passed explicitly
-  with -Wl,--build-id. To have clang always pass it, build clang with
-  -DENABLE_LINKER_BUILD_ID.
+-  ...
 
 Improvements to Clang's diagnostics
 ^^^
 
-Clang's diagnostics are constantly being improved to catch more issues,
-explain them more clearly, and provide more accurate source information
-about them. The improvements since the 3.7 release include:
-
 -  ...
 
 New Compiler Flags
@@ -76,28 +69,18 @@ Clang now supports the ...
 Attribute Changes in Clang
 --
 
-- The ``nodebug`` attribute may now be applied to static, global, and local
-  variables (but not parameters or non-static data members). This will suppress
-  all debugging information for the variable (and its type, if there are no
-  other uses of the type).
-
+-  ...
 
 Windows Support
 ---
 
 Clang's support for building native Windows programs ...
 
-TLS is enabled for Cygwin defaults to -femulated-tls.
-
 
 C Language Changes in Clang
 ---
-The -faltivec and -maltivec flags no longer silently include altivec.h on 
Power platforms.
 
-`RenderScript
-`_
-support added to the Frontend and enabled by the '-x renderscript' option or
-the '.rs' file extension.
+- ...
 
 ...
 
@@ -109,61 +92,11 @@ C11 Feature Support
 C++ Language Changes in Clang
 -
 
-- Clang now enforces the rule that a *using-declaration* cannot name an 
enumerator of a
-  scoped enumeration.
-
-  .. code-block:: c++
-
-namespace Foo { enum class E { e }; }
-namespace Bar {
-  using Foo::E::e; // error
-  constexpr auto e = Foo::E::e; // ok
-}
-
-- Clang now enforces the rule that an enumerator of an unscoped enumeration 
declared at
-  class scope can only be named by a *using-declaration* in a derived class.
-
-  .. code-block:: c++
-
-class Foo { enum E { e }; }
-using Foo::e; // error
-static constexpr auto e = Foo::e; // ok
-
 ...
 
 C++1z Feature Support
 ^
 
-Clang's experimental support for the upcoming C++1z standard can be enabled 
with ``-std=c++1z``.
-Changes to C++1z features since Clang 3.8:
-
-- The ``[[fallthrough]]``, ``[[nodiscard]]``, and ``[[maybe_unused]]`` 
attributes are
-  supported in C++11 onwards, and are largely synonymous with Clang's existing 
attributes
-  ``[[clang::fallthrough]]``, ``[[gnu::warn_unused_result]]``, and 
``[[gnu::unused]]``.
-  Use ``-Wimplicit-fallthrough`` to warn on unannotated fallthrough within 
``switch``
-  statements.
-
-- In C++1z mode, aggregat

Re: [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!

[Paul Robinson via cfe-commits]

probinson added a subscriber: probinson.


Comment at: docs/Proposals/GitHub.rst:141
@@ +140,3 @@
+has commit access to our current repository. In the future, you only need to
+provide the GitHub user to be granted access.
+

This reads a little bit like "we will create a GitHub account for you if you 
don't have one" but I suspect people actually need to create their own GitHub 
accounts first.  (We're not all on GitHub already!)


https://reviews.llvm.org/D22463



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

[clang-tools-extra] r275846 - Trunk release notes are now for 4.0.0

[Hans Wennborg via cfe-commits]

Author: hans
Date: Mon Jul 18 13:08:59 2016
New Revision: 275846

URL: http://llvm.org/viewvc/llvm-project?rev=275846&view=rev
Log:
Trunk release notes are now for 4.0.0

The 3.9 release are on the 3.9 branch.

Modified:
clang-tools-extra/trunk/docs/ReleaseNotes.rst

Modified: clang-tools-extra/trunk/docs/ReleaseNotes.rst
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/docs/ReleaseNotes.rst?rev=275846&r1=275845&r2=275846&view=diff
==
--- clang-tools-extra/trunk/docs/ReleaseNotes.rst (original)
+++ clang-tools-extra/trunk/docs/ReleaseNotes.rst Mon Jul 18 13:08:59 2016
@@ -1,6 +1,6 @@
-=
-Extra Clang Tools 3.9 (In-Progress) Release Notes
-=
+===
+Extra Clang Tools 4.0.0 (In-Progress) Release Notes
+===
 
 .. contents::
:local:
@@ -10,7 +10,7 @@ Written by the `LLVM Team `_.
 
@@ -18,7 +18,7 @@ Introduction
 
 
 This document contains the release notes for the Extra Clang Tools, part of the
-Clang release 3.9.  Here we describe the status of the Extra Clang Tools in 
some
+Clang release 4.0.0.  Here we describe the status of the Extra Clang Tools in 
some
 detail, including major improvements from the previous release and new feature
 work. For the general Clang release notes, see `the Clang documentation
 `_.  All 
LLVM
@@ -34,8 +34,8 @@ main Clang web page, this document appli
 the current one. To see the release notes for a specific release, please
 see the `releases page `_.
 
-What's New in Extra Clang Tools 3.9?
-
+What's New in Extra Clang Tools 4.0.0?
+==
 
 Some of the major new features and improvements to Extra Clang Tools are listed
 here. Generic improvements to Extra Clang Tools as a whole or to its underlying
@@ -44,8 +44,7 @@ infrastructure are described first, foll
 Major New Features
 --
 
-- :program:`clang-include-fixer`, a tool that provides an automated way of
-  adding ``#include`` directives for missing symbols in one translation unit.
+...
 
 Improvements to clang-query
 ---
@@ -60,343 +59,12 @@ The improvements are...
 Improvements to clang-tidy
 --
 
-:program:`clang-tidy`'s checks are constantly being improved to catch more 
issues,
-explain them more clearly, and provide more accurate fix-its for the issues
-identified.  The improvements since the 3.8 release include:
+...
 
-- New Boost module containing checks for issues with Boost library.
-
-- New `boost-use-to-string 
-  `_ 
check
-
-  Finds usages of ``boost::lexical_cast`` and changes it to
-  ``std::to_string``.
-
-- New `cert-env33-c
-  `_ check
-
-  Flags calls to ``system()``, ``popen()``, and ``_popen()``, which execute a
-  command processor.
-
-- New `cert-err34-c
-  `_ check
-
-  Flags calls to string-to-number conversion functions that do not verify the
-  validity of the conversion.
-
-- New `cert-flp30-c
-  `_ check
-
-  Flags ``for`` loops where the induction expression has a floating-point type.
-
-- New `cppcoreguidelines-interfaces-global-init
-  
`_
 check
-
-  Flags initializers of globals that access extern objects, and therefore can
-  lead to order-of-initialization problems.
-
-- New `cppcoreguidelines-pro-type-member-init
-  
`_
 check
-
-  Flags user-defined constructor definitions that do not initialize all builtin
-  and pointer fields which leaves their memory in an undefined state.
-
-- New `google-default-arguments
-  
`_ 
check
-
-  Flags default arguments in virtual methods.
-
-- New `misc-dangling-handle
-  `_ 
check
-
-  Detects dangling references in value handlers like
-  ``std::experimental::string_view``.
-
-- New `misc-fold-init-type
-  

Re: [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!

[Ed Maste via cfe-commits]

emaste added a subscriber: emaste.


Comment at: docs/Proposals/GitHub.rst:8-9
@@ +7,4 @@
+
+This is a proposal to move our current revision control system from Subversion
+to GitHub. Below are the financial and technical arguments as to why we need
+such a move and how will people (and validation infrastructure) continue to 
work

It seems pedantic, but I think we should try hard to avoid conflating Git and 
GitHub. What about: "move our revision control system from //self-hosted// 
Subversion to Git hosted by GitHub."


Comment at: docs/Proposals/GitHub.rst:93
@@ +92,3 @@
+Furthermore, GitHub has an *SVN view* 
(https://github.com/blog/626-announcing-svn-support)
+where people stuck with SVN infrastructure and tooling can slowly migrate or
+even stay working as if it was an SVN repository (including read-write access).

Replace "stuck" with something neutral. "stuck" implies that everyone will want 
to move but some may not be able to for technical or other reasons, but some 
people actually prefer SVN.


Comment at: docs/Proposals/GitHub.rst:180
@@ +179,3 @@
+
+As soon as we decide to move, we'll have to set a date for the process to 
begin.
+

This presents it as if the decision is already made, which somewhat defeats the 
purpose of writing a proposal for the LLVM community to vote on.

Maybe "If we decide to move"?


https://reviews.llvm.org/D22463



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

Re: [PATCH] D22075: [OpenMP] Fix incorrect diagnostics in map clause

[David S via cfe-commits]

davidsh updated this revision to Diff 64353.
davidsh added a comment.

Fix a typo in code and address test case issues.


https://reviews.llvm.org/D22075

Files:
  lib/Sema/SemaOpenMP.cpp
  test/OpenMP/target_map_messages.cpp
  test/OpenMP/target_parallel_for_map_messages.cpp
  test/OpenMP/target_parallel_for_simd_map_messages.cpp
  test/OpenMP/target_parallel_map_messages.cpp

Index: test/OpenMP/target_parallel_map_messages.cpp
===
--- test/OpenMP/target_parallel_map_messages.cpp
+++ test/OpenMP/target_parallel_map_messages.cpp
@@ -143,13 +143,13 @@
   foo();
 #pragma omp target parallel map(l) map(l[:5]) // expected-error 2 {{variable already marked as mapped in current construct}} expected-note 2 {{used here}}
   foo();
-#pragma omp target data map(k[:4], j, l[:5]) // expected-note 4 {{used here}}
+#pragma omp target data map(k[:4], j, l[:5]) // expected-note 2 {{used here}}
 {
 #pragma omp target parallel map(k) // expected-error 2 {{pointer cannot be mapped along with a section derived from itself}}
   foo();
 #pragma omp target parallel map(j)
   foo();
-#pragma omp target parallel map(l) // expected-error 2 {{original storage of expression in data environment is shared but data environment do not fully contain mapped expression storage}}
+#pragma omp target parallel map(l)
   foo();
 }
 
@@ -246,13 +246,13 @@
   foo();
 #pragma omp target parallel map(l) map(l[:5]) // expected-error 1 {{variable already marked as mapped in current construct}} expected-note 1 {{used here}}
   foo();
-#pragma omp target data map(k[:4], j, l[:5]) // expected-note 2 {{used here}}
+#pragma omp target data map(k[:4], j, l[:5]) // expected-note 1 {{used here}}
 {
 #pragma omp target parallel map(k) // expected-error {{pointer cannot be mapped along with a section derived from itself}}
   foo();
 #pragma omp target parallel map(j)
   foo();
-#pragma omp target parallel map(l) // expected-error {{original storage of expression in data environment is shared but data environment do not fully contain mapped expression storage}}
+#pragma omp target parallel map(l)
   foo();
 }
 
Index: test/OpenMP/target_parallel_for_simd_map_messages.cpp
===
--- test/OpenMP/target_parallel_for_simd_map_messages.cpp
+++ test/OpenMP/target_parallel_for_simd_map_messages.cpp
@@ -143,13 +143,13 @@
   for (i = 0; i < argc; ++i) foo();
 #pragma omp target parallel for simd map(l) map(l[:5]) // expected-error 2 {{variable already marked as mapped in current construct}} expected-note 2 {{used here}}
   for (i = 0; i < argc; ++i) foo();
-#pragma omp target data map(k[:4], j, l[:5]) // expected-note 4 {{used here}}
+#pragma omp target data map(k[:4], j, l[:5]) // expected-note 2 {{used here}}
 {
 #pragma omp target parallel for simd map(k) // expected-error 2 {{pointer cannot be mapped along with a section derived from itself}}
   for (i = 0; i < argc; ++i) foo();
 #pragma omp target parallel for simd map(j)
   for (i = 0; i < argc; ++i) foo();
-#pragma omp target parallel for simd map(l) // expected-error 2 {{original storage of expression in data environment is shared but data environment do not fully contain mapped expression storage}}
+#pragma omp target parallel for simd map(l)
   for (i = 0; i < argc; ++i) foo();
 }
 
@@ -247,13 +247,13 @@
   for (i = 0; i < argc; ++i) foo();
 #pragma omp target parallel for simd map(l) map(l[:5]) // expected-error 1 {{variable already marked as mapped in current construct}} expected-note 1 {{used here}}
   for (i = 0; i < argc; ++i) foo();
-#pragma omp target data map(k[:4], j, l[:5]) // expected-note 2 {{used here}}
+#pragma omp target data map(k[:4], j, l[:5]) // expected-note {{used here}}
 {
 #pragma omp target parallel for simd map(k) // expected-error {{pointer cannot be mapped along with a section derived from itself}}
   for (i = 0; i < argc; ++i) foo();
 #pragma omp target parallel for simd map(j)
   for (i = 0; i < argc; ++i) foo();
-#pragma omp target parallel for simd map(l) // expected-error {{original storage of expression in data environment is shared but data environment do not fully contain mapped expression storage}}
+#pragma omp target parallel for simd map(l)
   for (i = 0; i < argc; ++i) foo();
 }
 
Index: test/OpenMP/target_parallel_for_map_messages.cpp
===
--- test/OpenMP/target_parallel_for_map_messages.cpp
+++ test/OpenMP/target_parallel_for_map_messages.cpp
@@ -143,13 +143,13 @@
   for (i = 0; i < argc; ++i) foo();
 #pragma omp target parallel for map(l) map(l[:5]) // expected-error 2 {{variable already marked as mapped in current construct}} expected-note 2 {{used here}}
   for (i = 0; i < argc; ++i) foo();
-#pragma omp target data map(k[:4], j, l[:5]) // expected-note 4 {{used here}}
+#pragma omp target data map(k[:4], j, l[:5]) // expected-note 2 {{used here}}
 {
 #pragma omp target parallel for m

Re: [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!

[Wink Saville via cfe-commits]

winksaville added a subscriber: winksaville.


Comment at: docs/Proposals/GitHub.rst:132
@@ +131,3 @@
+
+There is no need to additional tags, flags and properties, nor of external
+services controlling the history, since both SVN and *git rev-list* can already

This could be worded a little better, may I suggest something like:

"There is no need for additional tags, flags, properties, or external ..."



https://reviews.llvm.org/D22463



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

Re: r251898 - [modules] Rationalize the behavior of Decl::declarationReplaces, and in

[Stephan Tolksdorf via cfe-commits]

On 3 November 2015 at 04:13, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Mon Nov  2 21:13:11 2015
> New Revision: 251898
>
> URL: http://llvm.org/viewvc/llvm-project?rev=251898&view=rev
> Log:
> [modules] Rationalize the behavior of Decl::declarationReplaces, and in
> particular don't assume that two declarations of the same kind in the same
> context are declaring the same entity. That's not true when the same name
> is
> declared multiple times as internal-linkage symbols within a module.
> (getCanonicalDecl is cheap now, so we can just use it here.)
>

This commit from November seems to have triggered the issue described in
llvm.org/pr27317

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

r275848 - docs/conf.py: update version to 4.0

[Hans Wennborg via cfe-commits]

Author: hans
Date: Mon Jul 18 13:13:08 2016
New Revision: 275848

URL: http://llvm.org/viewvc/llvm-project?rev=275848&view=rev
Log:
docs/conf.py: update version to 4.0

Modified:
cfe/trunk/docs/analyzer/conf.py
cfe/trunk/docs/conf.py

Modified: cfe/trunk/docs/analyzer/conf.py
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/analyzer/conf.py?rev=275848&r1=275847&r2=275848&view=diff
==
--- cfe/trunk/docs/analyzer/conf.py (original)
+++ cfe/trunk/docs/analyzer/conf.py Mon Jul 18 13:13:08 2016
@@ -49,9 +49,9 @@ copyright = u'2013-%d, Analyzer Team' %
 # built documents.
 #
 # The short X.Y version.
-version = '3.4'
+version = '4.0'
 # The full version, including alpha/beta/rc tags.
-release = '3.4'
+release = '4.0'
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.

Modified: cfe/trunk/docs/conf.py
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/conf.py?rev=275848&r1=275847&r2=275848&view=diff
==
--- cfe/trunk/docs/conf.py (original)
+++ cfe/trunk/docs/conf.py Mon Jul 18 13:13:08 2016
@@ -49,9 +49,9 @@ copyright = u'2007-%d, The Clang Team' %
 # built documents.
 #
 # The short X.Y version.
-version = '3.9'
+version = '4.0'
 # The full version, including alpha/beta/rc tags.
-release = '3.9'
+release = '4.0'
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.


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

[clang-tools-extra] r275849 - docs/conf.py: update version to 4.0

[Hans Wennborg via cfe-commits]

Author: hans
Date: Mon Jul 18 13:13:46 2016
New Revision: 275849

URL: http://llvm.org/viewvc/llvm-project?rev=275849&view=rev
Log:
docs/conf.py: update version to 4.0

Modified:
clang-tools-extra/trunk/docs/conf.py

Modified: clang-tools-extra/trunk/docs/conf.py
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/docs/conf.py?rev=275849&r1=275848&r2=275849&view=diff
==
--- clang-tools-extra/trunk/docs/conf.py (original)
+++ clang-tools-extra/trunk/docs/conf.py Mon Jul 18 13:13:46 2016
@@ -49,9 +49,9 @@ copyright = u'2007-%d, The Clang Team' %
 # built documents.
 #
 # The short X.Y version.
-version = '3.9'
+version = '4.0'
 # The full version, including alpha/beta/rc tags.
-release = '3.9'
+release = '4.0'
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.


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

Re: r275377 - Use hasFlag instead of hasArg

[David Blaikie via cfe-commits]

What build problem did this cause? Did this just not compile (it looks as
if ArgList has hasArg and hasFlag, so I'm not sure what the specific
problem might've been)

On Wed, Jul 13, 2016 at 11:45 PM Dean Michael Berris via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: dberris
> Date: Thu Jul 14 01:37:46 2016
> New Revision: 275377
>
> URL: http://llvm.org/viewvc/llvm-project?rev=275377&view=rev
> Log:
> Use hasFlag instead of hasArg
>
> Summary: Fix the build to use hasFlag instead of hasArg for checking some
> flags.
>
> Reviewers: echristo
>
> Subscribers: mehdi_amini, cfe-commits
>
> Differential Revision: http://reviews.llvm.org/D22338
>
> Modified:
> cfe/trunk/lib/Driver/Tools.cpp
>
> Modified: cfe/trunk/lib/Driver/Tools.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=275377&r1=275376&r2=275377&view=diff
>
> ==
> --- cfe/trunk/lib/Driver/Tools.cpp (original)
> +++ cfe/trunk/lib/Driver/Tools.cpp Thu Jul 14 01:37:46 2016
> @@ -4609,8 +4609,8 @@ void Clang::ConstructJob(Compilation &C,
>
>Args.AddAllArgs(CmdArgs, options::OPT_finstrument_functions);
>
> -  if (Args.hasArg(options::OPT_fxray_instrument,
> -  options::OPT_fnoxray_instrument, false)) {
> +  if (Args.hasFlag(options::OPT_fxray_instrument,
> +   options::OPT_fnoxray_instrument, false)) {
>  CmdArgs.push_back("-fxray-instrument");
>  if (Arg *A =
> Args.getLastArg(options::OPT_fxray_instruction_threshold_,
>
> options::OPT_fxray_instruction_threshold_EQ)) {
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D22470: [libcxx] Improve shared_ptr dtor performance

[Ben Craig via cfe-commits]

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

If the last destruction is uncontended, skip the atomic store on
__shared_weak_owners_.

For x86_64, this results in an 8% improvement in shared_ptr ctor+dtor
performance.
Old benchmarks/shared_ptr_create_destroy.cpp: 26.8638 seconds
New benchmarks/shared_ptr_create_destroy.cpp: 24.6019 seconds

The increment / decrement code path did not degrade on X86_64.
Old benchmarks/shared_ptr_inc_dec_ref.cpp: 13.0896 seconds
New benchmarks/shared_ptr_inc_dec_ref.cpp: 13.0463 seconds


https://reviews.llvm.org/D22470

Files:
  benchmarks/shared_ptr_create_destroy.cpp
  benchmarks/shared_ptr_inc_dec_ref.cpp
  src/memory.cpp

Index: src/memory.cpp
===
--- src/memory.cpp
+++ src/memory.cpp
@@ -96,7 +96,35 @@
 void
 __shared_weak_count::__release_weak() _NOEXCEPT
 {
-if (decrement(__shared_weak_owners_) == -1)
+// NOTE: The acquire load here is an optimization of the very
+// common case where a shared pointer is being destructed while
+// having no other contended references.
+//
+// BENEFIT: We avoid expensive atomic stores like XADD and STREX
+// in a common case.  Those instructions are slow and do nasty
+// things to caches.
+//
+// IS THIS SAFE?  Yes.  During weak destruction, if we see that we
+// are the last reference, we know that no-one else is accessing
+// us. If someone were accessing us, then they would be doing so
+// while the last shared / weak_ptr was being destructed, and
+// that's undefined anyway.
+//
+// If we see anything other than a 0, then we have possible
+// contention, and need to use an atomicrmw primitive.
+// The same arguments don't apply for increment, where it is legal
+// (though inadvisable) to share shared_ptr references between
+// threads, and have them all get copied at once.  The argument
+// also doesn't apply for __release_shared, because an outstanding
+// weak_ptr::lock() could read / modify the shared count.
+if (__libcpp_atomic_load(&__shared_weak_owners_, _AO_Aquire) == 0)
+{
+// no need to do this store, because we are about
+// to destroy everything.
+//__libcpp_atomic_store(&__shared_weak_owners_, -1, _AO_Release);
+__on_zero_shared_weak();
+}
+else if (decrement(__shared_weak_owners_) == -1)
 __on_zero_shared_weak();
 }
 
Index: benchmarks/shared_ptr_inc_dec_ref.cpp
===
--- /dev/null
+++ benchmarks/shared_ptr_inc_dec_ref.cpp
@@ -0,0 +1,38 @@
+//===--===//
+//
+// 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.
+//
+//===--===//
+
+#include 
+#include 
+#include 
+#include 
+
+void clobber()
+{
+asm volatile("" : : : "memory");
+}
+
+std::atomic g_int;
+std::atomic g_other;
+
+int main() {
+  auto a = std::chrono::high_resolution_clock::now();
+  auto sp = std::make_shared(g_int.load(std::memory_order_relaxed));
+  {
+clobber();
+for (int i = 0; i < 10; ++i)
+{
+  std::shared_ptr sp2(sp);
+  g_other.store(*sp2, std::memory_order_relaxed);
+}
+clobber();
+  }
+  auto b = std::chrono::high_resolution_clock::now();
+  std::cout<(b - a).count()/10.0<<" seconds"<
+#include 
+#include 
+#include 
+
+void clobber()
+{
+asm volatile("" : : : "memory");
+}
+
+std::atomic g_int;
+std::atomic g_other;
+
+int main() {
+  auto a = std::chrono::high_resolution_clock::now();
+  {
+clobber();
+for (int i = 0; i < 10; ++i)
+{
+  auto sp = std::make_shared(g_int.load(std::memory_order_relaxed));
+  g_other.store(*sp, std::memory_order_relaxed);
+}
+clobber();
+  }
+  auto b = std::chrono::high_resolution_clock::now();
+  std::cout<(b - a).count()/10.0<<" seconds"<___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D22285: Support -masm= flag for x86 assembly targets

[Bruno Cardoso Lopes via cfe-commits]

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

LGTM with one small fix, see below.



Comment at: lib/Driver/Tools.cpp:6379
@@ +6378,3 @@
+void ClangAs::AddX86TargetArgs(const ArgList &Args,
+ArgStringList &CmdArgs) const {
+  if (Arg *A = Args.getLastArg(options::OPT_masm_EQ)) {

Fix the param indentation.


https://reviews.llvm.org/D22285



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

Re: [PATCH] D22010: Add more gcc compatibility names to clang's cpuid.h

[Bruno Cardoso Lopes via cfe-commits]

bruno added a subscriber: bruno.


Comment at: lib/Headers/cpuid.h:114
@@ -109,2 +113,3 @@
 #define bit_AVX 0x1000
+#define bit_F16C0x2000
 #define bit_RDRND   0x4000

Isn't this one also meant for gcc compat?


https://reviews.llvm.org/D22010



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

[libclc] r275874 - R600: Use new barrier intrinsic

[Matt Arsenault via cfe-commits]

Author: arsenm
Date: Mon Jul 18 13:42:17 2016
New Revision: 275874

URL: http://llvm.org/viewvc/llvm-project?rev=275874&view=rev
Log:
R600: Use new barrier intrinsic

Modified:
libclc/trunk/r600/lib/synchronization/barrier_impl.ll

Modified: libclc/trunk/r600/lib/synchronization/barrier_impl.ll
URL: 
http://llvm.org/viewvc/llvm-project/libclc/trunk/r600/lib/synchronization/barrier_impl.ll?rev=275874&r1=275873&r2=275874&view=diff
==
--- libclc/trunk/r600/lib/synchronization/barrier_impl.ll (original)
+++ libclc/trunk/r600/lib/synchronization/barrier_impl.ll Mon Jul 18 13:42:17 
2016
@@ -1,7 +1,6 @@
 declare i32 @__clc_clk_local_mem_fence() #1
 declare i32 @__clc_clk_global_mem_fence() #1
-declare void @llvm.AMDGPU.barrier.local() #0
-declare void @llvm.AMDGPU.barrier.global() #0
+declare void @llvm.r600.group.barrier() #0
 
 define void @barrier(i32 %flags) #2 {
 barrier_local_test:
@@ -11,7 +10,7 @@ barrier_local_test:
   br i1 %1, label %barrier_local, label %barrier_global_test
 
 barrier_local:
-  call void @llvm.AMDGPU.barrier.local()
+  call void @llvm.r600.group.barrier()
   br label %barrier_global_test
 
 barrier_global_test:
@@ -21,7 +20,7 @@ barrier_global_test:
   br i1 %3, label %barrier_global, label %done
 
 barrier_global:
-  call void @llvm.AMDGPU.barrier.global()
+  call void @llvm.r600.group.barrier()
   br label %done
 
 done:


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

r275877 - Support -masm= flag for x86 assembly targets.

[Yunzhong Gao via cfe-commits]

Author: ygao
Date: Mon Jul 18 13:44:51 2016
New Revision: 275877

URL: http://llvm.org/viewvc/llvm-project?rev=275877&view=rev
Log:
Support -masm= flag for x86 assembly targets.

For assembly files without .intel_syntax or .att_syntax directives, allow the
-masm= flag to supply a default assembly dialect. For example,

C:\TMP> type intel.s
.text
mov al,0

C:\TMP> clang -masm=intel -c intel.s

Without this patch, one would need to pass an "-mllvm -x86-asm-syntax=" flag
directly to the backend.
C:\TMP> clang -mllvm --x86-asm-syntax=intel -c intel.s

Differentials Review: http://reviews.llvm.org/D22285


Added:
cfe/trunk/test/Driver/masm.s
Modified:
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/lib/Driver/Tools.h

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=275877&r1=275876&r2=275877&view=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Mon Jul 18 13:44:51 2016
@@ -6460,6 +6460,20 @@ void ClangAs::AddMIPSTargetArgs(const Ar
   CmdArgs.push_back(ABIName.data());
 }
 
+void ClangAs::AddX86TargetArgs(const ArgList &Args,
+   ArgStringList &CmdArgs) const {
+  if (Arg *A = Args.getLastArg(options::OPT_masm_EQ)) {
+StringRef Value = A->getValue();
+if (Value == "intel" || Value == "att") {
+  CmdArgs.push_back("-mllvm");
+  CmdArgs.push_back(Args.MakeArgString("-x86-asm-syntax=" + Value));
+} else {
+  
getToolChain().getDriver().Diag(diag::err_drv_unsupported_option_argument)
+  << A->getOption().getName() << Value;
+}
+  }
+}
+
 void ClangAs::ConstructJob(Compilation &C, const JobAction &JA,
const InputInfo &Output, const InputInfoList 
&Inputs,
const ArgList &Args,
@@ -6607,6 +6621,11 @@ void ClangAs::ConstructJob(Compilation &
   case llvm::Triple::mips64el:
 AddMIPSTargetArgs(Args, CmdArgs);
 break;
+
+  case llvm::Triple::x86:
+  case llvm::Triple::x86_64:
+AddX86TargetArgs(Args, CmdArgs);
+break;
   }
 
   // Consume all the warning flags. Usually this would be handled more

Modified: cfe/trunk/lib/Driver/Tools.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.h?rev=275877&r1=275876&r2=275877&view=diff
==
--- cfe/trunk/lib/Driver/Tools.h (original)
+++ cfe/trunk/lib/Driver/Tools.h Mon Jul 18 13:44:51 2016
@@ -125,6 +125,8 @@ public:
   : Tool("clang::as", "clang integrated assembler", TC, RF_Full) {}
   void AddMIPSTargetArgs(const llvm::opt::ArgList &Args,
  llvm::opt::ArgStringList &CmdArgs) const;
+  void AddX86TargetArgs(const llvm::opt::ArgList &Args,
+llvm::opt::ArgStringList &CmdArgs) const;
   bool hasGoodDiagnostics() const override { return true; }
   bool hasIntegratedAssembler() const override { return false; }
   bool hasIntegratedCPP() const override { return false; }

Added: cfe/trunk/test/Driver/masm.s
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/masm.s?rev=275877&view=auto
==
--- cfe/trunk/test/Driver/masm.s (added)
+++ cfe/trunk/test/Driver/masm.s Mon Jul 18 13:44:51 2016
@@ -0,0 +1,11 @@
+// RUN: %clang -target i386-unknown-linux -masm=intel -c %s -### 2>&1 | 
FileCheck --check-prefix=CHECK-INTEL %s
+// RUN: %clang -target i386-unknown-linux -masm=att -c %s -### 2>&1 | 
FileCheck --check-prefix=CHECK-ATT %s
+// RUN: %clang -target i386-unknown-linux -c -masm=somerequired %s -### 2>&1 | 
FileCheck --check-prefix=CHECK-SOMEREQUIRED %s
+// RUN: %clang -target arm-unknown-eabi -c -masm=intel %s -### 2>&1 | 
FileCheck --check-prefix=CHECK-ARM %s
+
+// CHECK-INTEL: -x86-asm-syntax=intel
+// CHECK-ATT: -x86-asm-syntax=att
+// CHECK-SOMEREQUIRED: error: unsupported argument 'somerequired' to option 
'masm='
+// CHECK-ARM: warning: argument unused during compilation: '-masm=intel'
+.text
+moval, 0


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

Re: [PATCH] D22285: Support -masm= flag for x86 assembly targets

[Yunzhong Gao via cfe-commits]

ygao marked an inline comment as done.


Comment at: lib/Driver/Tools.cpp:6379
@@ +6378,3 @@
+void ClangAs::AddX86TargetArgs(const ArgList &Args,
+ArgStringList &CmdArgs) const {
+  if (Arg *A = Args.getLastArg(options::OPT_masm_EQ)) {

bruno wrote:
> Fix the param indentation.
Good catch! Thanks.


https://reviews.llvm.org/D22285



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

Re: [PATCH] D22285: Support -masm= flag for x86 assembly targets

[Yunzhong Gao via cfe-commits]

ygao closed this revision.
ygao marked an inline comment as done.
ygao added a comment.

Closed by https://reviews.llvm.org/rL275877.


https://reviews.llvm.org/D22285



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

Re: [PATCH] D18360: Add AIX Target/ToolChain to Clang Driver

[Andrew Paprocki via cfe-commits]

apaprocki added inline comments.


Comment at: lib/Basic/Targets.cpp:718
@@ +717,3 @@
+Builder.defineMacro("_LONG_LONG");
+Builder.defineMacro("_ALL_SOURCE");
+Builder.defineMacro("_REENTRANT");

majnemer wrote:
> Are we really supposed to define this macro?  Does GCC define this?  I cannot 
> find where it does so in the source.
I defined both `_ALL_SOURCE` and `_REENTRANT` because the `SolarisTargetInfo` 
defines them (`__EXTENSIONS__` is the Solaris equivalent of `_ALL_SOURCE`). If 
that is an oversight in the Solaris work, I'll remove `_ALL_SOURCE` here. GCC 
does not define it by default.


https://reviews.llvm.org/D18360



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

Re: r275820 - [analyzer] Add checker modeling potential C++ self-assignment

[Hans Wennborg via cfe-commits]

Oops, as you suspected I failed at copy/paste. This is the bot that's
broken: http://bb.pgr.jp/builders/cmake-clang-x86_64-linux/builds/51780

On Mon, Jul 18, 2016 at 10:57 AM, Devin Coughlin  wrote:
> Hans,
>
> I’m happy to revert — but I think r275820 is very unlikely to have been the
> root cause of the issue at
> http://bb.pgr.jp/builders/cmake-llvm-x86_64-linux/builds/40225/. (The commit
> is a change to the clang static analyzer and the bot failure seems to be in
> LLVM CodeGen).
>
> Was this just a link mis-copy/paste? Is there another bot failing?
>
> Devin
>
> On Jul 18, 2016, at 10:50 AM, Hans Wennborg  wrote:
>
> It seems to have broken this buildbot:
> http://bb.pgr.jp/builders/cmake-llvm-x86_64-linux/builds/40225/
>
> I'm just about to create the 3.9 release branch, so it would be great
> if this could fixed/figured out soon.
>
> Thanks,
> Hans
>
> On Mon, Jul 18, 2016 at 10:23 AM, Devin Coughlin via cfe-commits
>  wrote:
>
> Author: dcoughlin
> Date: Mon Jul 18 12:23:30 2016
> New Revision: 275820
>
> URL: http://llvm.org/viewvc/llvm-project?rev=275820&view=rev
> Log:
> [analyzer] Add checker modeling potential C++ self-assignment
>
> This checker checks copy and move assignment operators whether they are
> protected against self-assignment. Since C++ core guidelines discourages
> explicit checking for `&rhs==this` in general we take a different approach:
> in
> top-frame analysis we branch the exploded graph for two cases, where
> &rhs==this
> and &rhs!=this and let existing checkers (e.g. unix.Malloc) do the rest of
> the
> work. It is important that we check all copy and move assignment operator in
> top
> frame even if we checked them already since self-assignments may happen
> undetected even in the same translation unit (e.g. using random indices for
> an
> array what may or may not be the same).
>
> A patch by Ádám Balogh!
>
> Differential Revision: https://reviews.llvm.org/D19311
>
> Added:
>cfe/trunk/lib/StaticAnalyzer/Checkers/CXXSelfAssignmentChecker.cpp
>cfe/trunk/test/Analysis/self-assign.cpp
> Modified:
>cfe/trunk/include/clang/StaticAnalyzer/Checkers/Checkers.td
>
> cfe/trunk/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitor.h
>cfe/trunk/lib/StaticAnalyzer/Checkers/CMakeLists.txt
>cfe/trunk/lib/StaticAnalyzer/Core/BugReporter.cpp
>cfe/trunk/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
>cfe/trunk/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
>
> Modified: cfe/trunk/include/clang/StaticAnalyzer/Checkers/Checkers.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/StaticAnalyzer/Checkers/Checkers.td?rev=275820&r1=275819&r2=275820&view=diff
> ==
> --- cfe/trunk/include/clang/StaticAnalyzer/Checkers/Checkers.td (original)
> +++ cfe/trunk/include/clang/StaticAnalyzer/Checkers/Checkers.td Mon Jul 18
> 12:23:30 2016
> @@ -247,6 +247,10 @@ def NewDeleteLeaksChecker : Checker<"New
>   HelpText<"Check for memory leaks. Traces memory managed by new/delete.">,
>   DescFile<"MallocChecker.cpp">;
>
> +def CXXSelfAssignmentChecker : Checker<"SelfAssignment">,
> +  HelpText<"Checks C++ copy and move assignment operators for self
> assignment">,
> +  DescFile<"CXXSelfAssignmentChecker.cpp">;
> +
> } // end: "cplusplus"
>
> let ParentPackage = CplusplusAlpha in {
>
> Modified:
> cfe/trunk/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitor.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitor.h?rev=275820&r1=275819&r2=275820&view=diff
> ==
> ---
> cfe/trunk/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitor.h
> (original)
> +++
> cfe/trunk/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitor.h
> Mon Jul 18 12:23:30 2016
> @@ -331,6 +331,22 @@ public:
>  BugReport &BR) override;
> };
>
> +class CXXSelfAssignmentBRVisitor final
> +  : public BugReporterVisitorImpl {
> +
> +  bool Satisfied;
> +
> +public:
> +  CXXSelfAssignmentBRVisitor() : Satisfied(false) {}
> +
> +  void Profile(llvm::FoldingSetNodeID &ID) const override {}
> +
> +  PathDiagnosticPiece *VisitNode(const ExplodedNode *Succ,
> + const ExplodedNode *Pred,
> + BugReporterContext &BRC,
> + BugReport &BR) override;
> +};
> +
> namespace bugreporter {
>
> /// Attempts to add visitors to trace a null or undefined value back to its
>
> Modified: cfe/trunk/lib/StaticAnalyzer/Checkers/CMakeLists.txt
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Checkers/CMakeLists.txt?rev=275820&r1=275819&r2=275820&view=diff
> ==
> --- cfe/trunk/lib/StaticAnalyzer/Checkers/CMakeLists.txt (original)
> +++ cfe

Re: [PATCH] D22292: [libunwind] Fix unw_getcontext for ARMv6-m

[Weiming Zhao via cfe-commits]

weimingz added inline comments.


Comment at: src/UnwindRegistersRestore.S:325
@@ -324,4 +324,3 @@
 
DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9libunwind13Registers_arm20restoreCoreAndJumpToEv)
-#if !defined(__ARM_ARCH_ISA_ARM)
-  ldr r2, [r0, #52]
-  ldr r3, [r0, #60]
+#if !defined(__ARM_ARCH_ISA_ARM) && __ARM_ARCH_ISA_THUMB == 1
+  @ r8-r12: ldr into r1-r5, then mov to r8-r12

originally, r8-r12 were not restored. Was that some existing bug?


Comment at: src/UnwindRegistersRestore.S:326
@@ +325,3 @@
+#if !defined(__ARM_ARCH_ISA_ARM) && __ARM_ARCH_ISA_THUMB == 1
+  @ r8-r12: ldr into r1-r5, then mov to r8-r12
+  ldr r1, [r0, #0x20]

originally, r0-r7 get loaded from [r0]
now, r8-r12 get loaded from [r0+0x20]

is that expected? 



https://reviews.llvm.org/D22292



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

r275880 - Revert "[analyzer] Add checker modeling potential C++ self-assignment"

[Devin Coughlin via cfe-commits]

Author: dcoughlin
Date: Mon Jul 18 13:57:50 2016
New Revision: 275880

URL: http://llvm.org/viewvc/llvm-project?rev=275880&view=rev
Log:
Revert "[analyzer] Add checker modeling potential C++ self-assignment"

This reverts commit r275820. It is failing on the bots.

Removed:
cfe/trunk/lib/StaticAnalyzer/Checkers/CXXSelfAssignmentChecker.cpp
cfe/trunk/test/Analysis/self-assign.cpp
Modified:
cfe/trunk/include/clang/StaticAnalyzer/Checkers/Checkers.td
cfe/trunk/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitor.h
cfe/trunk/lib/StaticAnalyzer/Checkers/CMakeLists.txt
cfe/trunk/lib/StaticAnalyzer/Core/BugReporter.cpp
cfe/trunk/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
cfe/trunk/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp

Modified: cfe/trunk/include/clang/StaticAnalyzer/Checkers/Checkers.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/StaticAnalyzer/Checkers/Checkers.td?rev=275880&r1=275879&r2=275880&view=diff
==
--- cfe/trunk/include/clang/StaticAnalyzer/Checkers/Checkers.td (original)
+++ cfe/trunk/include/clang/StaticAnalyzer/Checkers/Checkers.td Mon Jul 18 
13:57:50 2016
@@ -247,10 +247,6 @@ def NewDeleteLeaksChecker : Checker<"New
   HelpText<"Check for memory leaks. Traces memory managed by new/delete.">,
   DescFile<"MallocChecker.cpp">;
 
-def CXXSelfAssignmentChecker : Checker<"SelfAssignment">,
-  HelpText<"Checks C++ copy and move assignment operators for self 
assignment">,
-  DescFile<"CXXSelfAssignmentChecker.cpp">;
-
 } // end: "cplusplus"
 
 let ParentPackage = CplusplusAlpha in {

Modified: 
cfe/trunk/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitor.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitor.h?rev=275880&r1=275879&r2=275880&view=diff
==
--- 
cfe/trunk/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitor.h 
(original)
+++ 
cfe/trunk/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitor.h 
Mon Jul 18 13:57:50 2016
@@ -331,22 +331,6 @@ public:
  BugReport &BR) override;
 };
 
-class CXXSelfAssignmentBRVisitor final
-  : public BugReporterVisitorImpl {
-  
-  bool Satisfied;
-
-public:
-  CXXSelfAssignmentBRVisitor() : Satisfied(false) {}
-
-  void Profile(llvm::FoldingSetNodeID &ID) const override {}
-
-  PathDiagnosticPiece *VisitNode(const ExplodedNode *Succ,
- const ExplodedNode *Pred,
- BugReporterContext &BRC,
- BugReport &BR) override;
-};
-
 namespace bugreporter {
 
 /// Attempts to add visitors to trace a null or undefined value back to its

Modified: cfe/trunk/lib/StaticAnalyzer/Checkers/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Checkers/CMakeLists.txt?rev=275880&r1=275879&r2=275880&view=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Checkers/CMakeLists.txt (original)
+++ cfe/trunk/lib/StaticAnalyzer/Checkers/CMakeLists.txt Mon Jul 18 13:57:50 
2016
@@ -22,7 +22,6 @@ add_clang_library(clangStaticAnalyzerChe
   CheckerDocumentation.cpp
   ChrootChecker.cpp
   ClangCheckers.cpp
-  CXXSelfAssignmentChecker.cpp
   DeadStoresChecker.cpp
   DebugCheckers.cpp
   DereferenceChecker.cpp

Removed: cfe/trunk/lib/StaticAnalyzer/Checkers/CXXSelfAssignmentChecker.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Checkers/CXXSelfAssignmentChecker.cpp?rev=275879&view=auto
==
--- cfe/trunk/lib/StaticAnalyzer/Checkers/CXXSelfAssignmentChecker.cpp 
(original)
+++ cfe/trunk/lib/StaticAnalyzer/Checkers/CXXSelfAssignmentChecker.cpp (removed)
@@ -1,62 +0,0 @@
-//=== CXXSelfAssignmentChecker.cpp -*- C++ 
-*--===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is distributed under the University of Illinois Open Source
-// License. See LICENSE.TXT for details.
-//
-//===--===//
-//
-// This file defines CXXSelfAssignmentChecker, which tests all custom defined
-// copy and move assignment operators for the case of self assignment, thus
-// where the parameter refers to the same location where the this pointer
-// points to. The checker itself does not do any checks at all, but it
-// causes the analyzer to check every copy and move assignment operator twice:
-// once for when 'this' aliases with the parameter and once for when it may 
not.
-// It is the task of the other enabled checkers to find the bugs in these two
-// different cases.
-//
-//===---

Re: r275820 - [analyzer] Add checker modeling potential C++ self-assignment

[Devin Coughlin via cfe-commits]

Reverted in r275880. Sorry about that. I’ll have to investigate why I didn’t 
get an email from the bot about the failure.

Thanks
Devin

> On Jul 18, 2016, at 11:59 AM, Hans Wennborg  wrote:
> 
> Oops, as you suspected I failed at copy/paste. This is the bot that's
> broken: http://bb.pgr.jp/builders/cmake-clang-x86_64-linux/builds/51780
> 
> On Mon, Jul 18, 2016 at 10:57 AM, Devin Coughlin  wrote:
>> Hans,
>> 
>> I’m happy to revert — but I think r275820 is very unlikely to have been the
>> root cause of the issue at
>> http://bb.pgr.jp/builders/cmake-llvm-x86_64-linux/builds/40225/. (The commit
>> is a change to the clang static analyzer and the bot failure seems to be in
>> LLVM CodeGen).
>> 
>> Was this just a link mis-copy/paste? Is there another bot failing?
>> 
>> Devin
>> 
>> On Jul 18, 2016, at 10:50 AM, Hans Wennborg  wrote:
>> 
>> It seems to have broken this buildbot:
>> http://bb.pgr.jp/builders/cmake-llvm-x86_64-linux/builds/40225/
>> 
>> I'm just about to create the 3.9 release branch, so it would be great
>> if this could fixed/figured out soon.
>> 
>> Thanks,
>> Hans
>> 
>> On Mon, Jul 18, 2016 at 10:23 AM, Devin Coughlin via cfe-commits
>>  wrote:
>> 
>> Author: dcoughlin
>> Date: Mon Jul 18 12:23:30 2016
>> New Revision: 275820
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=275820&view=rev
>> Log:
>> [analyzer] Add checker modeling potential C++ self-assignment
>> 
>> This checker checks copy and move assignment operators whether they are
>> protected against self-assignment. Since C++ core guidelines discourages
>> explicit checking for `&rhs==this` in general we take a different approach:
>> in
>> top-frame analysis we branch the exploded graph for two cases, where
>> &rhs==this
>> and &rhs!=this and let existing checkers (e.g. unix.Malloc) do the rest of
>> the
>> work. It is important that we check all copy and move assignment operator in
>> top
>> frame even if we checked them already since self-assignments may happen
>> undetected even in the same translation unit (e.g. using random indices for
>> an
>> array what may or may not be the same).
>> 
>> A patch by Ádám Balogh!
>> 
>> Differential Revision: https://reviews.llvm.org/D19311
>> 
>> Added:
>>   cfe/trunk/lib/StaticAnalyzer/Checkers/CXXSelfAssignmentChecker.cpp
>>   cfe/trunk/test/Analysis/self-assign.cpp
>> Modified:
>>   cfe/trunk/include/clang/StaticAnalyzer/Checkers/Checkers.td
>> 
>> cfe/trunk/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitor.h
>>   cfe/trunk/lib/StaticAnalyzer/Checkers/CMakeLists.txt
>>   cfe/trunk/lib/StaticAnalyzer/Core/BugReporter.cpp
>>   cfe/trunk/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
>>   cfe/trunk/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
>> 
>> Modified: cfe/trunk/include/clang/StaticAnalyzer/Checkers/Checkers.td
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/StaticAnalyzer/Checkers/Checkers.td?rev=275820&r1=275819&r2=275820&view=diff
>> ==
>> --- cfe/trunk/include/clang/StaticAnalyzer/Checkers/Checkers.td (original)
>> +++ cfe/trunk/include/clang/StaticAnalyzer/Checkers/Checkers.td Mon Jul 18
>> 12:23:30 2016
>> @@ -247,6 +247,10 @@ def NewDeleteLeaksChecker : Checker<"New
>>  HelpText<"Check for memory leaks. Traces memory managed by new/delete.">,
>>  DescFile<"MallocChecker.cpp">;
>> 
>> +def CXXSelfAssignmentChecker : Checker<"SelfAssignment">,
>> +  HelpText<"Checks C++ copy and move assignment operators for self
>> assignment">,
>> +  DescFile<"CXXSelfAssignmentChecker.cpp">;
>> +
>> } // end: "cplusplus"
>> 
>> let ParentPackage = CplusplusAlpha in {
>> 
>> Modified:
>> cfe/trunk/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitor.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitor.h?rev=275820&r1=275819&r2=275820&view=diff
>> ==
>> ---
>> cfe/trunk/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitor.h
>> (original)
>> +++
>> cfe/trunk/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitor.h
>> Mon Jul 18 12:23:30 2016
>> @@ -331,6 +331,22 @@ public:
>> BugReport &BR) override;
>> };
>> 
>> +class CXXSelfAssignmentBRVisitor final
>> +  : public BugReporterVisitorImpl {
>> +
>> +  bool Satisfied;
>> +
>> +public:
>> +  CXXSelfAssignmentBRVisitor() : Satisfied(false) {}
>> +
>> +  void Profile(llvm::FoldingSetNodeID &ID) const override {}
>> +
>> +  PathDiagnosticPiece *VisitNode(const ExplodedNode *Succ,
>> + const ExplodedNode *Pred,
>> + BugReporterContext &BRC,
>> + BugReport &BR) override;
>> +};
>> +
>> namespace bugreporter {
>> 
>> /// Attempts to add visitors to trace a null or undefined value back to its
>> 
>> Modified: cfe/trunk/lib/St

Re: [PATCH] D22292: [libunwind] Fix unw_getcontext for ARMv6-m

[Weiming Zhao via cfe-commits]

weimingz added inline comments.


Comment at: src/UnwindRegistersRestore.S:326
@@ +325,3 @@
+#if !defined(__ARM_ARCH_ISA_ARM) && __ARM_ARCH_ISA_THUMB == 1
+  @ r8-r12: ldr into r1-r5, then mov to r8-r12
+  ldr r1, [r0, #0x20]

weimingz wrote:
> originally, r0-r7 get loaded from [r0]
> now, r8-r12 get loaded from [r0+0x20]
> 
> is that expected? 
> 
Please ignore the comment on line 326. I thought the “x" icon will delete it.


https://reviews.llvm.org/D22292



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

Re: [PATCH] D19311: [analyzer] Self Assignment Checker

[Devin Coughlin via cfe-commits]

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

Re-opening. Reverted in r275880. It was causing a failure on the bots: 
http://bb.pgr.jp/builders/cmake-clang-x86_64-linux/builds/51780


Repository:
  rL LLVM

https://reviews.llvm.org/D19311



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

Re: [PATCH] D18360: Add AIX Target/ToolChain to Clang Driver

[David Majnemer via cfe-commits]

majnemer added inline comments.


Comment at: lib/Basic/Targets.cpp:718
@@ +717,3 @@
+Builder.defineMacro("_LONG_LONG");
+Builder.defineMacro("_ALL_SOURCE");
+Builder.defineMacro("_REENTRANT");

apaprocki wrote:
> majnemer wrote:
> > Are we really supposed to define this macro?  Does GCC define this?  I 
> > cannot find where it does so in the source.
> I defined both `_ALL_SOURCE` and `_REENTRANT` because the `SolarisTargetInfo` 
> defines them (`__EXTENSIONS__` is the Solaris equivalent of `_ALL_SOURCE`). 
> If that is an oversight in the Solaris work, I'll remove `_ALL_SOURCE` here. 
> GCC does not define it by default.
After a closer examination of the gcc sources, it looks like `ALL_SOURCE` is 
defined if gcc is being used for C++ code (via `CPLUSPLUS_CPP_SPEC`).

I don't see where `_REENTRANT` is defined for AIX though...


https://reviews.llvm.org/D18360



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

Re: [PATCH] D22292: [libunwind] Fix unw_getcontext for ARMv6-m

[Ben Craig via cfe-commits]

bcraig added a subscriber: bcraig.


Comment at: src/UnwindRegistersRestore.S:325
@@ -324,4 +324,3 @@
 
DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9libunwind13Registers_arm20restoreCoreAndJumpToEv)
-#if !defined(__ARM_ARCH_ISA_ARM)
-  ldr r2, [r0, #52]
-  ldr r3, [r0, #60]
+#if !defined(__ARM_ARCH_ISA_ARM) && __ARM_ARCH_ISA_THUMB == 1
+  @ r8-r12: ldr into r1-r5, then mov to r8-r12

weimingz wrote:
> originally, r8-r12 were not restored. Was that some existing bug?
I'm not sure why r12 is getting messed with here.  It is intended as a GOT/PLT 
scratch register.  r8+ isn't ubiquitously available in Thumb state according to 
the ATPCS.  The AAPCS says that r4-r8, r10, r11, and SP must be preserved.  r9 
can optionally be preserved.


https://reviews.llvm.org/D22292



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

[clang-tools-extra] r275886 - Unbreak extra tools build post r275882.

[Benjamin Kramer via cfe-commits]

Author: d0k
Date: Mon Jul 18 14:21:22 2016
New Revision: 275886

URL: http://llvm.org/viewvc/llvm-project?rev=275886&view=rev
Log:
Unbreak extra tools build post r275882.

Modified:
clang-tools-extra/trunk/clang-tidy/ClangTidy.cpp
clang-tools-extra/trunk/include-fixer/tool/ClangIncludeFixer.cpp

Modified: clang-tools-extra/trunk/clang-tidy/ClangTidy.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/ClangTidy.cpp?rev=275886&r1=275885&r2=275886&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/ClangTidy.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/ClangTidy.cpp Mon Jul 18 14:21:22 2016
@@ -32,6 +32,7 @@
 #include "clang/Lex/Preprocessor.h"
 #include "clang/Rewrite/Frontend/FixItRewriter.h"
 #include "clang/Rewrite/Frontend/FrontendActions.h"
+#include "clang/StaticAnalyzer/Core/BugReporter/PathDiagnostic.h"
 #include "clang/StaticAnalyzer/Frontend/AnalysisConsumer.h"
 #include "clang/Tooling/Refactoring.h"
 #include "clang/Tooling/ReplacementsYaml.h"

Modified: clang-tools-extra/trunk/include-fixer/tool/ClangIncludeFixer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/include-fixer/tool/ClangIncludeFixer.cpp?rev=275886&r1=275885&r2=275886&view=diff
==
--- clang-tools-extra/trunk/include-fixer/tool/ClangIncludeFixer.cpp (original)
+++ clang-tools-extra/trunk/include-fixer/tool/ClangIncludeFixer.cpp Mon Jul 18 
14:21:22 2016
@@ -19,6 +19,7 @@
 #include "clang/Tooling/Core/Replacement.h"
 #include "clang/Tooling/Tooling.h"
 #include "llvm/Support/CommandLine.h"
+#include "llvm/Support/Path.h"
 #include "llvm/Support/YAMLTraits.h"
 
 using namespace clang;


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

Re: [clang-tools-extra] r275886 - Unbreak extra tools build post r275882.

[Mehdi Amini via cfe-commits]

Thanks, I just checked out clang-tool-extras and was in the process of doing 
that :)

— 
Mehdi

> On Jul 18, 2016, at 12:21 PM, Benjamin Kramer via cfe-commits 
>  wrote:
> 
> Author: d0k
> Date: Mon Jul 18 14:21:22 2016
> New Revision: 275886
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=275886&view=rev
> Log:
> Unbreak extra tools build post r275882.
> 
> Modified:
>clang-tools-extra/trunk/clang-tidy/ClangTidy.cpp
>clang-tools-extra/trunk/include-fixer/tool/ClangIncludeFixer.cpp
> 
> Modified: clang-tools-extra/trunk/clang-tidy/ClangTidy.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/ClangTidy.cpp?rev=275886&r1=275885&r2=275886&view=diff
> ==
> --- clang-tools-extra/trunk/clang-tidy/ClangTidy.cpp (original)
> +++ clang-tools-extra/trunk/clang-tidy/ClangTidy.cpp Mon Jul 18 14:21:22 2016
> @@ -32,6 +32,7 @@
> #include "clang/Lex/Preprocessor.h"
> #include "clang/Rewrite/Frontend/FixItRewriter.h"
> #include "clang/Rewrite/Frontend/FrontendActions.h"
> +#include "clang/StaticAnalyzer/Core/BugReporter/PathDiagnostic.h"
> #include "clang/StaticAnalyzer/Frontend/AnalysisConsumer.h"
> #include "clang/Tooling/Refactoring.h"
> #include "clang/Tooling/ReplacementsYaml.h"
> 
> Modified: clang-tools-extra/trunk/include-fixer/tool/ClangIncludeFixer.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/include-fixer/tool/ClangIncludeFixer.cpp?rev=275886&r1=275885&r2=275886&view=diff
> ==
> --- clang-tools-extra/trunk/include-fixer/tool/ClangIncludeFixer.cpp 
> (original)
> +++ clang-tools-extra/trunk/include-fixer/tool/ClangIncludeFixer.cpp Mon Jul 
> 18 14:21:22 2016
> @@ -19,6 +19,7 @@
> #include "clang/Tooling/Core/Replacement.h"
> #include "clang/Tooling/Tooling.h"
> #include "llvm/Support/CommandLine.h"
> +#include "llvm/Support/Path.h"
> #include "llvm/Support/YAMLTraits.h"
> 
> using namespace clang;
> 
> 
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

Re: [PATCH] D21228: Deprecated (legacy) string literal conversion to 'char *' causes strange overloading resolution

[Richard Smith via cfe-commits]

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

LGTM


https://reviews.llvm.org/D21228



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

r275895 - [Driver] Compute effective target triples once per job (NFCI)

[Vedant Kumar via cfe-commits]

Author: vedantk
Date: Mon Jul 18 14:56:38 2016
New Revision: 275895

URL: http://llvm.org/viewvc/llvm-project?rev=275895&view=rev
Log:
[Driver] Compute effective target triples once per job (NFCI)

Compute an effective target triple exactly once in ConstructJob(), and
then simply pass around references to it. This eliminates wasteful
re-computation of effective triples (e.g in getARMFloatABI()).

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

Modified:
cfe/trunk/docs/ReleaseNotes.rst
cfe/trunk/include/clang/Driver/SanitizerArgs.h
cfe/trunk/include/clang/Driver/Tool.h
cfe/trunk/include/clang/Driver/ToolChain.h
cfe/trunk/lib/Driver/Driver.cpp
cfe/trunk/lib/Driver/SanitizerArgs.cpp
cfe/trunk/lib/Driver/ToolChain.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

Modified: cfe/trunk/docs/ReleaseNotes.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ReleaseNotes.rst?rev=275895&r1=275894&r2=275895&view=diff
==
--- cfe/trunk/docs/ReleaseNotes.rst (original)
+++ cfe/trunk/docs/ReleaseNotes.rst Mon Jul 18 14:56:38 2016
@@ -121,7 +121,8 @@ These are major API changes that have ha
 Clang. If upgrading an external codebase that uses Clang as a library,
 this section should help get you past the largest hurdles of upgrading.
 
--  ...
+- Classes which inherit from ``driver::Tool`` must be updated to use effective
+  target triples when constructing jobs.
 
 AST Matchers
 

Modified: cfe/trunk/include/clang/Driver/SanitizerArgs.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/SanitizerArgs.h?rev=275895&r1=275894&r2=275895&view=diff
==
--- cfe/trunk/include/clang/Driver/SanitizerArgs.h (original)
+++ cfe/trunk/include/clang/Driver/SanitizerArgs.h Mon Jul 18 14:56:38 2016
@@ -16,6 +16,10 @@
 #include 
 #include 
 
+namespace llvm {
+class Triple;
+}
+
 namespace clang {
 namespace driver {
 
@@ -66,7 +70,8 @@ class SanitizerArgs {
   bool requiresPIE() const;
   bool needsUnwindTables() const;
   bool linkCXXRuntimes() const { return LinkCXXRuntimes; }
-  void addArgs(const ToolChain &TC, const llvm::opt::ArgList &Args,
+  void addArgs(const ToolChain &TC, const llvm::Triple &EffectiveTriple,
+   const llvm::opt::ArgList &Args,
llvm::opt::ArgStringList &CmdArgs, types::ID InputType) const;
 };
 

Modified: cfe/trunk/include/clang/Driver/Tool.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Tool.h?rev=275895&r1=275894&r2=275895&view=diff
==
--- cfe/trunk/include/clang/Driver/Tool.h (original)
+++ cfe/trunk/include/clang/Driver/Tool.h Mon Jul 18 14:56:38 2016
@@ -14,6 +14,7 @@
 #include "llvm/Support/Program.h"
 
 namespace llvm {
+class Triple;
 namespace opt {
   class ArgList;
 }
@@ -127,6 +128,7 @@ public:
   virtual void ConstructJob(Compilation &C, const JobAction &JA,
 const InputInfo &Output,
 const InputInfoList &Inputs,
+const llvm::Triple &EffectiveTriple,
 const llvm::opt::ArgList &TCArgs,
 const char *LinkingOutput) const = 0;
 };

Modified: cfe/trunk/include/clang/Driver/ToolChain.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/ToolChain.h?rev=275895&r1=275894&r2=275895&view=diff
==
--- cfe/trunk/include/clang/Driver/ToolChain.h (original)
+++ cfe/trunk/include/clang/Driver/ToolChain.h Mon Jul 18 14:56:38 2016
@@ -260,11 +260,13 @@ public:
 return ToolChain::CST_Libstdcxx;
   }
 
-  virtual std::string getCompilerRT(const llvm::opt::ArgList &Args,
+  virtual std::string getCompilerRT(const llvm::Triple &EffectiveTriple,
+const llvm::opt::ArgList &Args,
 StringRef Component,
 bool Shared = false) const;
 
-  const char *getCompilerRTArgString(const llvm::opt::ArgList &Args,
+  const char *getCompilerRTArgString(const llvm::Triple &EffectiveTriple,
+ const llvm::opt::ArgList &Args,
  StringRef Component,
  bool Shared = false) const;
   /// needsProfileRT - returns true if instrumentation profile is on.
@@ -410,7 +412,8 @@ public:
   const llvm::opt::ArgList &Args, llvm::opt::ArgStringList &CmdArgs) const;
   /// addProfileRTLibs - When -fprofile-instr-profile is specified, try to pass
   /// a suitable profile runtime library to the linker.
-  virtual void addProfileRTLibs(const llvm::opt::Arg

r275894 - [Driver] Make Driver::DefaultTargetTriple private (NFCI)

[Vedant Kumar via cfe-commits]

Author: vedantk
Date: Mon Jul 18 14:56:33 2016
New Revision: 275894

URL: http://llvm.org/viewvc/llvm-project?rev=275894&view=rev
Log:
[Driver] Make Driver::DefaultTargetTriple private (NFCI)

No in-tree targets access this `DefaultTargetTriple` directly, and usage
of default triples is generally discouraged. Make the field private.

This is part of en effort to make the clang driver use effective triples
more pervasively.

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

Modified:
cfe/trunk/include/clang/Driver/Driver.h
cfe/trunk/lib/Driver/Driver.cpp

Modified: cfe/trunk/include/clang/Driver/Driver.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Driver.h?rev=275894&r1=275893&r2=275894&view=diff
==
--- cfe/trunk/include/clang/Driver/Driver.h (original)
+++ cfe/trunk/include/clang/Driver/Driver.h Mon Jul 18 14:56:33 2016
@@ -130,9 +130,6 @@ public:
   /// If the standard library is used
   bool UseStdLib;
 
-  /// Default target triple.
-  std::string DefaultTargetTriple;
-
   /// Driver title to use with help.
   std::string DriverTitle;
 
@@ -181,6 +178,9 @@ public:
   unsigned CCGenDiagnostics : 1;
 
 private:
+  /// Default target triple.
+  std::string DefaultTargetTriple;
+
   /// Name to use when invoking gcc/g++.
   std::string CCCGenericGCCName;
 

Modified: cfe/trunk/lib/Driver/Driver.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Driver.cpp?rev=275894&r1=275893&r2=275894&view=diff
==
--- cfe/trunk/lib/Driver/Driver.cpp (original)
+++ cfe/trunk/lib/Driver/Driver.cpp Mon Jul 18 14:56:33 2016
@@ -54,12 +54,12 @@ Driver::Driver(StringRef ClangExecutable
   Mode(GCCMode), SaveTemps(SaveTempsNone), BitcodeEmbed(EmbedNone),
   LTOMode(LTOK_None), ClangExecutable(ClangExecutable),
   SysRoot(DEFAULT_SYSROOT), UseStdLib(true),
-  DefaultTargetTriple(DefaultTargetTriple),
   DriverTitle("clang LLVM compiler"), CCPrintOptionsFilename(nullptr),
   CCPrintHeadersFilename(nullptr), CCLogDiagnosticsFilename(nullptr),
   CCCPrintBindings(false), CCPrintHeaders(false), CCLogDiagnostics(false),
-  CCGenDiagnostics(false), CCCGenericGCCName(""), CheckInputsExist(true),
-  CCCUsePCH(true), SuppressMissingInputWarning(false) {
+  CCGenDiagnostics(false), DefaultTargetTriple(DefaultTargetTriple),
+  CCCGenericGCCName(""), CheckInputsExist(true), CCCUsePCH(true),
+  SuppressMissingInputWarning(false) {
 
   // Provide a sane fallback if no VFS is specified.
   if (!this->VFS)


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

Re: [PATCH] D22289: [PATCH 1/2] [Driver] Make Driver::DefaultTargetTriple private (NFCI)

[Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL275894: [Driver] Make Driver::DefaultTargetTriple private 
(NFCI) (authored by vedantk).

Changed prior to commit:
  https://reviews.llvm.org/D22289?vs=63756&id=64366#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D22289

Files:
  cfe/trunk/include/clang/Driver/Driver.h
  cfe/trunk/lib/Driver/Driver.cpp

Index: cfe/trunk/lib/Driver/Driver.cpp
===
--- cfe/trunk/lib/Driver/Driver.cpp
+++ cfe/trunk/lib/Driver/Driver.cpp
@@ -54,12 +54,12 @@
   Mode(GCCMode), SaveTemps(SaveTempsNone), BitcodeEmbed(EmbedNone),
   LTOMode(LTOK_None), ClangExecutable(ClangExecutable),
   SysRoot(DEFAULT_SYSROOT), UseStdLib(true),
-  DefaultTargetTriple(DefaultTargetTriple),
   DriverTitle("clang LLVM compiler"), CCPrintOptionsFilename(nullptr),
   CCPrintHeadersFilename(nullptr), CCLogDiagnosticsFilename(nullptr),
   CCCPrintBindings(false), CCPrintHeaders(false), CCLogDiagnostics(false),
-  CCGenDiagnostics(false), CCCGenericGCCName(""), CheckInputsExist(true),
-  CCCUsePCH(true), SuppressMissingInputWarning(false) {
+  CCGenDiagnostics(false), DefaultTargetTriple(DefaultTargetTriple),
+  CCCGenericGCCName(""), CheckInputsExist(true), CCCUsePCH(true),
+  SuppressMissingInputWarning(false) {
 
   // Provide a sane fallback if no VFS is specified.
   if (!this->VFS)
Index: cfe/trunk/include/clang/Driver/Driver.h
===
--- cfe/trunk/include/clang/Driver/Driver.h
+++ cfe/trunk/include/clang/Driver/Driver.h
@@ -130,9 +130,6 @@
   /// If the standard library is used
   bool UseStdLib;
 
-  /// Default target triple.
-  std::string DefaultTargetTriple;
-
   /// Driver title to use with help.
   std::string DriverTitle;
 
@@ -181,6 +178,9 @@
   unsigned CCGenDiagnostics : 1;
 
 private:
+  /// Default target triple.
+  std::string DefaultTargetTriple;
+
   /// Name to use when invoking gcc/g++.
   std::string CCCGenericGCCName;
 


Index: cfe/trunk/lib/Driver/Driver.cpp
===
--- cfe/trunk/lib/Driver/Driver.cpp
+++ cfe/trunk/lib/Driver/Driver.cpp
@@ -54,12 +54,12 @@
   Mode(GCCMode), SaveTemps(SaveTempsNone), BitcodeEmbed(EmbedNone),
   LTOMode(LTOK_None), ClangExecutable(ClangExecutable),
   SysRoot(DEFAULT_SYSROOT), UseStdLib(true),
-  DefaultTargetTriple(DefaultTargetTriple),
   DriverTitle("clang LLVM compiler"), CCPrintOptionsFilename(nullptr),
   CCPrintHeadersFilename(nullptr), CCLogDiagnosticsFilename(nullptr),
   CCCPrintBindings(false), CCPrintHeaders(false), CCLogDiagnostics(false),
-  CCGenDiagnostics(false), CCCGenericGCCName(""), CheckInputsExist(true),
-  CCCUsePCH(true), SuppressMissingInputWarning(false) {
+  CCGenDiagnostics(false), DefaultTargetTriple(DefaultTargetTriple),
+  CCCGenericGCCName(""), CheckInputsExist(true), CCCUsePCH(true),
+  SuppressMissingInputWarning(false) {
 
   // Provide a sane fallback if no VFS is specified.
   if (!this->VFS)
Index: cfe/trunk/include/clang/Driver/Driver.h
===
--- cfe/trunk/include/clang/Driver/Driver.h
+++ cfe/trunk/include/clang/Driver/Driver.h
@@ -130,9 +130,6 @@
   /// If the standard library is used
   bool UseStdLib;
 
-  /// Default target triple.
-  std::string DefaultTargetTriple;
-
   /// Driver title to use with help.
   std::string DriverTitle;
 
@@ -181,6 +178,9 @@
   unsigned CCGenDiagnostics : 1;
 
 private:
+  /// Default target triple.
+  std::string DefaultTargetTriple;
+
   /// Name to use when invoking gcc/g++.
   std::string CCCGenericGCCName;
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D22290: [PATCH 2/2] [Driver] Compute effective target triples once per job (NFCI)

[Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL275895: [Driver] Compute effective target triples once per 
job (NFCI) (authored by vedantk).

Changed prior to commit:
  https://reviews.llvm.org/D22290?vs=64023&id=64367#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D22290

Files:
  cfe/trunk/docs/ReleaseNotes.rst
  cfe/trunk/include/clang/Driver/SanitizerArgs.h
  cfe/trunk/include/clang/Driver/Tool.h
  cfe/trunk/include/clang/Driver/ToolChain.h
  cfe/trunk/lib/Driver/Driver.cpp
  cfe/trunk/lib/Driver/SanitizerArgs.cpp
  cfe/trunk/lib/Driver/ToolChain.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

Index: cfe/trunk/docs/ReleaseNotes.rst
===
--- cfe/trunk/docs/ReleaseNotes.rst
+++ cfe/trunk/docs/ReleaseNotes.rst
@@ -121,7 +121,8 @@
 Clang. If upgrading an external codebase that uses Clang as a library,
 this section should help get you past the largest hurdles of upgrading.
 
--  ...
+- Classes which inherit from ``driver::Tool`` must be updated to use effective
+  target triples when constructing jobs.
 
 AST Matchers
 
Index: cfe/trunk/include/clang/Driver/SanitizerArgs.h
===
--- cfe/trunk/include/clang/Driver/SanitizerArgs.h
+++ cfe/trunk/include/clang/Driver/SanitizerArgs.h
@@ -16,6 +16,10 @@
 #include 
 #include 
 
+namespace llvm {
+class Triple;
+}
+
 namespace clang {
 namespace driver {
 
@@ -66,7 +70,8 @@
   bool requiresPIE() const;
   bool needsUnwindTables() const;
   bool linkCXXRuntimes() const { return LinkCXXRuntimes; }
-  void addArgs(const ToolChain &TC, const llvm::opt::ArgList &Args,
+  void addArgs(const ToolChain &TC, const llvm::Triple &EffectiveTriple,
+   const llvm::opt::ArgList &Args,
llvm::opt::ArgStringList &CmdArgs, types::ID InputType) const;
 };
 
Index: cfe/trunk/include/clang/Driver/ToolChain.h
===
--- cfe/trunk/include/clang/Driver/ToolChain.h
+++ cfe/trunk/include/clang/Driver/ToolChain.h
@@ -260,11 +260,13 @@
 return ToolChain::CST_Libstdcxx;
   }
 
-  virtual std::string getCompilerRT(const llvm::opt::ArgList &Args,
+  virtual std::string getCompilerRT(const llvm::Triple &EffectiveTriple,
+const llvm::opt::ArgList &Args,
 StringRef Component,
 bool Shared = false) const;
 
-  const char *getCompilerRTArgString(const llvm::opt::ArgList &Args,
+  const char *getCompilerRTArgString(const llvm::Triple &EffectiveTriple,
+ const llvm::opt::ArgList &Args,
  StringRef Component,
  bool Shared = false) const;
   /// needsProfileRT - returns true if instrumentation profile is on.
@@ -410,7 +412,8 @@
   const llvm::opt::ArgList &Args, llvm::opt::ArgStringList &CmdArgs) const;
   /// addProfileRTLibs - When -fprofile-instr-profile is specified, try to pass
   /// a suitable profile runtime library to the linker.
-  virtual void addProfileRTLibs(const llvm::opt::ArgList &Args,
+  virtual void addProfileRTLibs(const llvm::Triple &EffectiveTriple,
+const llvm::opt::ArgList &Args,
 llvm::opt::ArgStringList &CmdArgs) const;
 
   /// \brief Add arguments to use system-specific CUDA includes.
Index: cfe/trunk/include/clang/Driver/Tool.h
===
--- cfe/trunk/include/clang/Driver/Tool.h
+++ cfe/trunk/include/clang/Driver/Tool.h
@@ -14,6 +14,7 @@
 #include "llvm/Support/Program.h"
 
 namespace llvm {
+class Triple;
 namespace opt {
   class ArgList;
 }
@@ -127,6 +128,7 @@
   virtual void ConstructJob(Compilation &C, const JobAction &JA,
 const InputInfo &Output,
 const InputInfoList &Inputs,
+const llvm::Triple &EffectiveTriple,
 const llvm::opt::ArgList &TCArgs,
 const char *LinkingOutput) const = 0;
 };
Index: cfe/trunk/lib/Driver/SanitizerArgs.cpp
===
--- cfe/trunk/lib/Driver/SanitizerArgs.cpp
+++ cfe/trunk/lib/Driver/SanitizerArgs.cpp
@@ -602,7 +602,9 @@
   CmdArgs.push_back(Args.MakeArgString(LinkerOptionFlag));
 }
 
-void SanitizerArgs::addArgs(const ToolChain &TC, const llvm::opt::ArgList &Args,
+void SanitizerArgs::addArgs(const ToolChain &TC,
+const llvm::Triple &EffectiveTriple,
+const llvm::opt::ArgList &Args,
 llvm::opt::ArgStringList &CmdArgs,
 types::ID 

Re: [PATCH] D22227: [ubsan] Disable bounds-check for flexible array ivars

[Vedant Kumar via cfe-commits]

vsk added a comment.

Ping.


https://reviews.llvm.org/D7



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

Re: [PATCH] D22419: [CFG] Fix crash in thread sanitizer.

[Nandor Licker via cfe-commits]

nandor updated this revision to Diff 64368.
nandor added a comment.

Fixed typo


https://reviews.llvm.org/D22419

Files:
  lib/Analysis/CFG.cpp
  test/SemaCXX/warn-thread-safety-analysis.cpp

Index: test/SemaCXX/warn-thread-safety-analysis.cpp
===
--- test/SemaCXX/warn-thread-safety-analysis.cpp
+++ test/SemaCXX/warn-thread-safety-analysis.cpp
@@ -5160,6 +5160,21 @@
 }  // end namespace  GlobalAcquiredBeforeAfterTest
 
 
+namespace LifetimeExtensionTest {
+
+struct Holder {
+  virtual ~Holder() throw() {}
+  int i = 0;
+};
+
+void test() {
+  // Should not crash.
+  const auto &value = Holder().i;
+}
+
+} // end namespace LifetimeExtensionTest
+
+
 namespace LockableUnions {
 
 union LOCKABLE MutexUnion {
Index: lib/Analysis/CFG.cpp
===
--- lib/Analysis/CFG.cpp
+++ lib/Analysis/CFG.cpp
@@ -3902,7 +3902,20 @@
 case CFGElement::AutomaticObjectDtor: {
   const VarDecl *var = castAs().getVarDecl();
   QualType ty = var->getType();
-  ty = ty.getNonReferenceType();
+
+  // FIXME: See CFGBuilder::addLocalScopeForVarDecl.
+  //
+  // Lifetime-extending constructs are handled here. This works for a 
single
+  // temporary in an initializer expression.
+  if (ty.getTypePtr()->isReferenceType()) {
+if (const Expr *Init = var->getInit()) {
+  if (const ExprWithCleanups *EWC = dyn_cast(Init))
+Init = EWC->getSubExpr();
+  if (isa(Init))
+ty = getReferenceInitTemporaryType(astContext, Init);
+}
+  }
+
   while (const ArrayType *arrayType = astContext.getAsArrayType(ty)) {
 ty = arrayType->getElementType();
   }


Index: test/SemaCXX/warn-thread-safety-analysis.cpp
===
--- test/SemaCXX/warn-thread-safety-analysis.cpp
+++ test/SemaCXX/warn-thread-safety-analysis.cpp
@@ -5160,6 +5160,21 @@
 }  // end namespace  GlobalAcquiredBeforeAfterTest
 
 
+namespace LifetimeExtensionTest {
+
+struct Holder {
+  virtual ~Holder() throw() {}
+  int i = 0;
+};
+
+void test() {
+  // Should not crash.
+  const auto &value = Holder().i;
+}
+
+} // end namespace LifetimeExtensionTest
+
+
 namespace LockableUnions {
 
 union LOCKABLE MutexUnion {
Index: lib/Analysis/CFG.cpp
===
--- lib/Analysis/CFG.cpp
+++ lib/Analysis/CFG.cpp
@@ -3902,7 +3902,20 @@
 case CFGElement::AutomaticObjectDtor: {
   const VarDecl *var = castAs().getVarDecl();
   QualType ty = var->getType();
-  ty = ty.getNonReferenceType();
+
+  // FIXME: See CFGBuilder::addLocalScopeForVarDecl.
+  //
+  // Lifetime-extending constructs are handled here. This works for a single
+  // temporary in an initializer expression.
+  if (ty.getTypePtr()->isReferenceType()) {
+if (const Expr *Init = var->getInit()) {
+  if (const ExprWithCleanups *EWC = dyn_cast(Init))
+Init = EWC->getSubExpr();
+  if (isa(Init))
+ty = getReferenceInitTemporaryType(astContext, Init);
+}
+  }
+
   while (const ArrayType *arrayType = astContext.getAsArrayType(ty)) {
 ty = arrayType->getElementType();
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!

[Mehdi AMINI via cfe-commits]

mehdi_amini added a subscriber: mehdi_amini.


Comment at: docs/Proposals/GitHub.rst:122
@@ +121,3 @@
+of understanding the *sequence* in which commits were added by using the
+``git rev-list --count hash`` or ``git describe hash`` commands.
+

filcab wrote:
> How easy will it be to clone the "aggregated" repo, and then get some (but 
> not all) of the submodules?
I expect the umbrella repo to come with scripts for that.


Comment at: docs/Proposals/GitHub.rst:129
@@ +128,3 @@
+* The linear history can still be accessed in the (RO) submodule meta project.
+* Individual projects' history will be broken (linear, but local), and we need
+  the umbrella project (using submodules) to have the same view as we had in 
SVN.

This sentence is not clear: "Individual projects' history will be broken", I 
don't see what's "broken".


Comment at: docs/Proposals/GitHub.rst:168
@@ +167,3 @@
+additional benefits.
+
+2. Which tools will stop working?

I think that's covered line 136-137.


Comment at: docs/Proposals/GitHub.rst:173
@@ +172,3 @@
+use LNT with the SVN-View, but it would be best to move it to Git once and for
+all.
+

I don't think so: LNT is not dependent on SVN history. It is dependent on a 
single revision number cross-repository and cross-branches. This is something 
that the umbrella projects "could" provide.


Comment at: docs/Proposals/GitHub.rst:198
@@ +197,3 @@
+3. Make sure we have an llvm-project (with submodules) setup in the official
+   account.
+4. Make sure bisecting with llvm-project works.

Uh, this point is not clear: there will a need for us to maintain a 
"non-trivial" hook on our server to handle this. This is not fleshed out in 
this document.


https://reviews.llvm.org/D22463



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

Re: [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!

[Renato Golin via cfe-commits]

rengolin added inline comments.


Comment at: docs/Proposals/GitHub.rst:8-9
@@ +7,4 @@
+
+This is a proposal to move our current revision control system from Subversion
+to GitHub. Below are the financial and technical arguments as to why we need
+such a move and how will people (and validation infrastructure) continue to 
work

emaste wrote:
> It seems pedantic, but I think we should try hard to avoid conflating Git and 
> GitHub. What about: "move our revision control system from //self-hosted// 
> Subversion to Git hosted by GitHub."
This is a summary of the whole proposal, which specifically dictates GitHub.

We're not proposing to move to some Git hosting anymore, but exactly GitHub, 
due to the constraints that we outline below. If we do not move to GitHub 
specifically, a lot of the assumptions below will be wrong, and this proposal 
can't be accepted.

There is a paragraph on why git, and another on why GitHub, and both are key 
points of this proposal.

I'll change "from Subversion" to "from our own hosted Subversion" to make that 
even more clear.


Comment at: docs/Proposals/GitHub.rst:93
@@ +92,3 @@
+Furthermore, GitHub has an *SVN view* 
(https://github.com/blog/626-announcing-svn-support)
+where people stuck with SVN infrastructure and tooling can slowly migrate or
+even stay working as if it was an SVN repository (including read-write access).

emaste wrote:
> Replace "stuck" with something neutral. "stuck" implies that everyone will 
> want to move but some may not be able to for technical or other reasons, but 
> some people actually prefer SVN.
good point.


Comment at: docs/Proposals/GitHub.rst:122
@@ +121,3 @@
+of understanding the *sequence* in which commits were added by using the
+``git rev-list --count hash`` or ``git describe hash`` commands.
+

filcab wrote:
> How easy will it be to clone the "aggregated" repo, and then get some (but 
> not all) of the submodules?
Checking out this project:

https://github.com/chapuni/llvm-project-submodule

Will return the references, not the sub modules. You have to "init" each 
sub-module independently, which achieves the same task as only checking out the 
SVN repos you need, with the correct numbering.


Comment at: docs/Proposals/GitHub.rst:130
@@ +129,3 @@
+* Individual projects' history will be broken (linear, but local), and we need
+  the umbrella project (using submodules) to have the same view as we had in 
SVN.
+

filcab wrote:
> I wouldn't call it broken.
> Won't it have the same end result as having a checkout per project and simply 
> updating them close to each other?
> 
> Basically, it won't be "any more broken" than using this method for updating:
> 
> ```
> #!/bin/bash
> for dir in llvm/{,tools/{clang,lld},projects/{libcxx,libcxxabi,compiler-rt}}; 
> do
>   # (cd $dir && svn up) # for SVN
>   (cd $dir && git checkout master && git pull) # for git
> done
> ```
No, it won't.

Checking out LLVM only skips all commits from all other repos. So, for example:

LNT 123
Clang 124
RT 125
LLVM 126

Then, "svn checkout 126" will be:

In LNT, 123 as 126
In Clang, 124 as 126
In RT, 125 as 126
In LLVM, 126 as 126

With the new SVN interface, each one of those commits will be referred to, 
locally, as 123, and 126 will not exist, because the "git rev-list --count" 
won't get as high as 126.

However, on the umbrella submodule project, because the sequence of the commits 
is guaranteed, the rev-list count will bring the correct numbering, the same as 
via the SVN interface, and thus be "just like SVN was".


Comment at: docs/Proposals/GitHub.rst:132
@@ +131,3 @@
+
+There is no need to additional tags, flags and properties, nor of external
+services controlling the history, since both SVN and *git rev-list* can already

winksaville wrote:
> This could be worded a little better, may I suggest something like:
> 
> "There is no need for additional tags, flags, properties, or external ..."
> 
Yup, changing on next round. Thanks!


Comment at: docs/Proposals/GitHub.rst:141
@@ +140,3 @@
+has commit access to our current repository. In the future, you only need to
+provide the GitHub user to be granted access.
+

probinson wrote:
> This reads a little bit like "we will create a GitHub account for you if you 
> don't have one" but I suspect people actually need to create their own GitHub 
> accounts first.  (We're not all on GitHub already!)
well, "you need to provide the GitHub user" should take care of that, but I'll 
try to re-write this to make it more clear.

> (We're not all on GitHub already!)

Are we not? Egregious! :D


Comment at: docs/Proposals/GitHub.rst:180
@@ +179,3 @@
+
+As soon as we decide to move, we'll have to set a date for the process to 
begin.
+

emaste wrote:
> This presents it 

Re: [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!

[Renato Golin via cfe-commits]

rengolin updated this revision to Diff 64371.
rengolin added a comment.

Second round of suggestions applied.


https://reviews.llvm.org/D22463

Files:
  docs/Proposals/GitHub.rst

Index: docs/Proposals/GitHub.rst
===
--- /dev/null
+++ docs/Proposals/GitHub.rst
@@ -0,0 +1,239 @@
+==
+Moving LLVM Projects to GitHub
+==
+
+Introduction
+
+
+This is a proposal to move our current revision control system from our own
+hosted Subversion to GitHub. Below are the financial and technical arguments as
+to why we need such a move and how will people (and validation infrastructure)
+continue to work with a Git-based LLVM.
+
+There will be a survey pointing at this document when we'll know the community's
+reaction and, if we collectively decide to move, the time-frames. Be sure to make
+your views count.
+
+Essentially, the proposal is divided in the following parts:
+
+ * Outline of the reasons to move to Git and GitHub
+ * Description on how the work flow will look like (compared to SVN)
+ * Remaining issues and potential problems
+ * The proposed migration plan
+
+Why Git, and Why GitHub?
+
+
+Why move at all?
+
+
+The strongest reason for the move, and why this discussion started in the first
+place, is that we currently host our own Subversion server and Git mirror in a
+voluntary basis. The LLVM Foundation sponsors the server and provides limited
+support, but there is only so much it can do.
+
+The volunteers are not Sysadmins themselves, but compiler engineers that happen
+to know a thing or two about hosting servers. We also don't have 24/7 support,
+and we sometimes wake up to see that continuous integration is broken because
+the SVN server is either down or unresponsive.
+
+With time and money, the foundation and volunteers could improve our services,
+implement more functionality and provide around the clock support, so that we
+can have a first class infrastructure with which to work. But the cost is not
+small, both in money and time invested.
+
+On the other hand, there are multiple services out there (GitHub, GitLab,
+BitBucket among others) that offer that same service (24/7 stability, disk space,
+Git server, code browsing, forking facilities, etc) for the very affordable price
+of *FREE*.
+
+Why Git?
+
+
+Most new coders nowadays start with Git. A lot of them have never used SVN, CVS
+or anything else. Websites like GitHub have changed the landscape of open source
+contributions, reducing the cost of first contribution and fostering
+collaboration.
+
+Git is also the version control most LLVM developers use. Despite the sources
+being stored in an SVN server, most people develop using the Git-SVN integration,
+and that shows that Git is not only more powerful than SVN, but people have
+resorted to using a bridge because its features are now indispensable to their
+internal and external workflows.
+
+In essence, Git allows you to:
+ * Commit, squash, merge, fork locally without any penalty to the server
+ * Add as many branches as necessary to allow for multiple threads of development
+ * Collaborate with peers directly, even without access to the Internet
+ * Have multiple trees without multiplying disk space, multiple concurrent builds
+
+In addition, because Git seems to be replacing every project's version control
+system, there are many more tools that can use Git's enhanced feature set, so
+new tooling is much more likely to support Git first (if not only), than any
+other version control system.
+
+Why GitHub?
+---
+
+GitHub, like GitLab and BitBucket, provide FREE code hosting for open source
+projects. Essentially, they will completely replace *all* the infrastructure that
+we have today that serves code repository, mirroring, user control, etc.
+
+They also have a dedicated team to monitor, migrate, improve and distribute the
+contents of the repositories depending on region and load. A level of quality
+that we'd never have without spending money that would be better spent elsewhere,
+for example development meetings, sponsoring disadvantaged people to work on
+compilers and foster diversity and quality in our community.
+
+GitHub has the added benefit that we already have a presence there. Many
+developers use it already, and the mirror from our current repository is already
+set up.
+
+Furthermore, GitHub has an *SVN view* (https://github.com/blog/626-announcing-svn-support)
+where people that still have/want to use SVN infrastructure and tooling can
+slowly migrate or even stay working as if it was an SVN repository (including
+read-write access).
+
+So, any of the three solutions solve the cost and maintenance problem, but GitHub
+has two additional features that would be beneficial to the migration plan as
+well as the community already settled there.
+
+
+How will the new workflow look like
+=

Re: r275820 - [analyzer] Add checker modeling potential C++ self-assignment

[Hans Wennborg via cfe-commits]

Thanks, I've merged the revert in r275902.

Cheers,
Hans

On Mon, Jul 18, 2016 at 12:06 PM, Devin Coughlin  wrote:
> Reverted in r275880. Sorry about that. I’ll have to investigate why I didn’t
> get an email from the bot about the failure.
>
> Thanks
> Devin
>
> On Jul 18, 2016, at 11:59 AM, Hans Wennborg  wrote:
>
> Oops, as you suspected I failed at copy/paste. This is the bot that's
> broken: http://bb.pgr.jp/builders/cmake-clang-x86_64-linux/builds/51780
>
> On Mon, Jul 18, 2016 at 10:57 AM, Devin Coughlin 
> wrote:
>
> Hans,
>
> I’m happy to revert — but I think r275820 is very unlikely to have been the
> root cause of the issue at
> http://bb.pgr.jp/builders/cmake-llvm-x86_64-linux/builds/40225/. (The commit
> is a change to the clang static analyzer and the bot failure seems to be in
> LLVM CodeGen).
>
> Was this just a link mis-copy/paste? Is there another bot failing?
>
> Devin
>
> On Jul 18, 2016, at 10:50 AM, Hans Wennborg  wrote:
>
> It seems to have broken this buildbot:
> http://bb.pgr.jp/builders/cmake-llvm-x86_64-linux/builds/40225/
>
> I'm just about to create the 3.9 release branch, so it would be great
> if this could fixed/figured out soon.
>
> Thanks,
> Hans
>
> On Mon, Jul 18, 2016 at 10:23 AM, Devin Coughlin via cfe-commits
>  wrote:
>
> Author: dcoughlin
> Date: Mon Jul 18 12:23:30 2016
> New Revision: 275820
>
> URL: http://llvm.org/viewvc/llvm-project?rev=275820&view=rev
> Log:
> [analyzer] Add checker modeling potential C++ self-assignment
>
> This checker checks copy and move assignment operators whether they are
> protected against self-assignment. Since C++ core guidelines discourages
> explicit checking for `&rhs==this` in general we take a different approach:
> in
> top-frame analysis we branch the exploded graph for two cases, where
> &rhs==this
> and &rhs!=this and let existing checkers (e.g. unix.Malloc) do the rest of
> the
> work. It is important that we check all copy and move assignment operator in
> top
> frame even if we checked them already since self-assignments may happen
> undetected even in the same translation unit (e.g. using random indices for
> an
> array what may or may not be the same).
>
> A patch by Ádám Balogh!
>
> Differential Revision: https://reviews.llvm.org/D19311
>
> Added:
>   cfe/trunk/lib/StaticAnalyzer/Checkers/CXXSelfAssignmentChecker.cpp
>   cfe/trunk/test/Analysis/self-assign.cpp
> Modified:
>   cfe/trunk/include/clang/StaticAnalyzer/Checkers/Checkers.td
>
> cfe/trunk/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitor.h
>   cfe/trunk/lib/StaticAnalyzer/Checkers/CMakeLists.txt
>   cfe/trunk/lib/StaticAnalyzer/Core/BugReporter.cpp
>   cfe/trunk/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
>   cfe/trunk/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
>
> Modified: cfe/trunk/include/clang/StaticAnalyzer/Checkers/Checkers.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/StaticAnalyzer/Checkers/Checkers.td?rev=275820&r1=275819&r2=275820&view=diff
> ==
> --- cfe/trunk/include/clang/StaticAnalyzer/Checkers/Checkers.td (original)
> +++ cfe/trunk/include/clang/StaticAnalyzer/Checkers/Checkers.td Mon Jul 18
> 12:23:30 2016
> @@ -247,6 +247,10 @@ def NewDeleteLeaksChecker : Checker<"New
>  HelpText<"Check for memory leaks. Traces memory managed by new/delete.">,
>  DescFile<"MallocChecker.cpp">;
>
> +def CXXSelfAssignmentChecker : Checker<"SelfAssignment">,
> +  HelpText<"Checks C++ copy and move assignment operators for self
> assignment">,
> +  DescFile<"CXXSelfAssignmentChecker.cpp">;
> +
> } // end: "cplusplus"
>
> let ParentPackage = CplusplusAlpha in {
>
> Modified:
> cfe/trunk/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitor.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitor.h?rev=275820&r1=275819&r2=275820&view=diff
> ==
> ---
> cfe/trunk/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitor.h
> (original)
> +++
> cfe/trunk/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitor.h
> Mon Jul 18 12:23:30 2016
> @@ -331,6 +331,22 @@ public:
> BugReport &BR) override;
> };
>
> +class CXXSelfAssignmentBRVisitor final
> +  : public BugReporterVisitorImpl {
> +
> +  bool Satisfied;
> +
> +public:
> +  CXXSelfAssignmentBRVisitor() : Satisfied(false) {}
> +
> +  void Profile(llvm::FoldingSetNodeID &ID) const override {}
> +
> +  PathDiagnosticPiece *VisitNode(const ExplodedNode *Succ,
> + const ExplodedNode *Pred,
> + BugReporterContext &BRC,
> + BugReport &BR) override;
> +};
> +
> namespace bugreporter {
>
> /// Attempts to add visitors to trace a null or undefined value back to its
>
> Modified: cfe/trunk/lib/StaticAnalyzer/Chec

Re: [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!

[Renato Golin via cfe-commits]

rengolin added inline comments.


Comment at: docs/Proposals/GitHub.rst:198
@@ +197,3 @@
+3. Make sure we have an llvm-project (with submodules) setup in the official
+   account.
+4. Make sure bisecting with llvm-project works.

mehdi_amini wrote:
> Uh, this point is not clear: there will a need for us to maintain a 
> "non-trivial" hook on our server to handle this. This is not fleshed out in 
> this document.
Good point. I added just a description to this topic, since this is covered 
elsewhere.


Comment at: docs/Proposals/GitHub.rst:174
@@ +173,3 @@
+us what's wrong and how to help them fix it.
+
+We also recommend people and companies to migrate to Git, for its many other

So, LNT migration plan could be:

1. Use GitHub's SVN view on llvm-proj-submods
2. Move to understand submods
3. Migrate all instances

Looks fairly orthogonal to me...


https://reviews.llvm.org/D22463



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

Re: [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!

[Renato Golin via cfe-commits]

rengolin updated this revision to Diff 64373.
rengolin added a comment.

Removing "broken" to describe the history, just explaining it'll be local.

Expanding to mention that hooks will need to be implemented in step 3.


https://reviews.llvm.org/D22463

Files:
  docs/Proposals/GitHub.rst

Index: docs/Proposals/GitHub.rst
===
--- /dev/null
+++ docs/Proposals/GitHub.rst
@@ -0,0 +1,240 @@
+==
+Moving LLVM Projects to GitHub
+==
+
+Introduction
+
+
+This is a proposal to move our current revision control system from our own
+hosted Subversion to GitHub. Below are the financial and technical arguments as
+to why we need such a move and how will people (and validation infrastructure)
+continue to work with a Git-based LLVM.
+
+There will be a survey pointing at this document when we'll know the community's
+reaction and, if we collectively decide to move, the time-frames. Be sure to make
+your views count.
+
+Essentially, the proposal is divided in the following parts:
+
+ * Outline of the reasons to move to Git and GitHub
+ * Description on how the work flow will look like (compared to SVN)
+ * Remaining issues and potential problems
+ * The proposed migration plan
+
+Why Git, and Why GitHub?
+
+
+Why move at all?
+
+
+The strongest reason for the move, and why this discussion started in the first
+place, is that we currently host our own Subversion server and Git mirror in a
+voluntary basis. The LLVM Foundation sponsors the server and provides limited
+support, but there is only so much it can do.
+
+The volunteers are not Sysadmins themselves, but compiler engineers that happen
+to know a thing or two about hosting servers. We also don't have 24/7 support,
+and we sometimes wake up to see that continuous integration is broken because
+the SVN server is either down or unresponsive.
+
+With time and money, the foundation and volunteers could improve our services,
+implement more functionality and provide around the clock support, so that we
+can have a first class infrastructure with which to work. But the cost is not
+small, both in money and time invested.
+
+On the other hand, there are multiple services out there (GitHub, GitLab,
+BitBucket among others) that offer that same service (24/7 stability, disk space,
+Git server, code browsing, forking facilities, etc) for the very affordable price
+of *FREE*.
+
+Why Git?
+
+
+Most new coders nowadays start with Git. A lot of them have never used SVN, CVS
+or anything else. Websites like GitHub have changed the landscape of open source
+contributions, reducing the cost of first contribution and fostering
+collaboration.
+
+Git is also the version control most LLVM developers use. Despite the sources
+being stored in an SVN server, most people develop using the Git-SVN integration,
+and that shows that Git is not only more powerful than SVN, but people have
+resorted to using a bridge because its features are now indispensable to their
+internal and external workflows.
+
+In essence, Git allows you to:
+ * Commit, squash, merge, fork locally without any penalty to the server
+ * Add as many branches as necessary to allow for multiple threads of development
+ * Collaborate with peers directly, even without access to the Internet
+ * Have multiple trees without multiplying disk space, multiple concurrent builds
+
+In addition, because Git seems to be replacing every project's version control
+system, there are many more tools that can use Git's enhanced feature set, so
+new tooling is much more likely to support Git first (if not only), than any
+other version control system.
+
+Why GitHub?
+---
+
+GitHub, like GitLab and BitBucket, provide FREE code hosting for open source
+projects. Essentially, they will completely replace *all* the infrastructure that
+we have today that serves code repository, mirroring, user control, etc.
+
+They also have a dedicated team to monitor, migrate, improve and distribute the
+contents of the repositories depending on region and load. A level of quality
+that we'd never have without spending money that would be better spent elsewhere,
+for example development meetings, sponsoring disadvantaged people to work on
+compilers and foster diversity and quality in our community.
+
+GitHub has the added benefit that we already have a presence there. Many
+developers use it already, and the mirror from our current repository is already
+set up.
+
+Furthermore, GitHub has an *SVN view* (https://github.com/blog/626-announcing-svn-support)
+where people that still have/want to use SVN infrastructure and tooling can
+slowly migrate or even stay working as if it was an SVN repository (including
+read-write access).
+
+So, any of the three solutions solve the cost and maintenance problem, but GitHub
+has two additional features that would be beneficial to the m

Re: [PATCH] D22465: [clang-rename] introduce better symbol finding and add few more tests

[Kirill Bobyrev via cfe-commits]

omtcyfz updated this revision to Diff 64374.

https://reviews.llvm.org/D22465

Files:
  clang-rename/RenamingAction.cpp
  clang-rename/USRFinder.cpp
  clang-rename/USRLocFinder.cpp
  test/clang-rename/ClassNameInFunctionDefenition.cpp
  test/clang-rename/ComplicatedClassType.cpp
  test/clang-rename/ComplicatedClassTypeInCustomNamespace.cpp
  test/clang-rename/NestedNamespace.cpp
  test/clang-rename/TemplateTypename.cpp
  test/clang-rename/UserDefinedConversion.cpp
  test/clang-rename/UserDefinedConversionFindByConversion.cpp
  test/clang-rename/UserDefinedConversionFindByTypeDeclaration.cpp

Index: test/clang-rename/UserDefinedConversionFindByTypeDeclaration.cpp
===
--- test/clang-rename/UserDefinedConversionFindByTypeDeclaration.cpp
+++ test/clang-rename/UserDefinedConversionFindByTypeDeclaration.cpp
@@ -1,7 +1,6 @@
-// Currently unsupported test.
 // RUN: cat %s > %t.cpp
-// FIXME: while renaming class/struct clang-rename should be able to change
-// this type name corresponding user-defined conversions, too.
+// RUN: clang-rename -offset=136 -new-name=Bar %t.cpp -i --
+// RUN: sed 's,//.*,,' %t.cpp | FileCheck %s
 
 class Foo { // CHECK: class Bar {
 //^ offset must be here
Index: test/clang-rename/UserDefinedConversionFindByConversion.cpp
===
--- /dev/null
+++ test/clang-rename/UserDefinedConversionFindByConversion.cpp
@@ -0,0 +1,12 @@
+// RUN: cat %s > %t.cpp
+// RUN: clang-rename -offset=136 -new-name=Bar %t.cpp -i --
+// RUN: sed 's,//.*,,' %t.cpp | FileCheck %s
+
+class Foo {}; // CHECK: class Bar {};
+
+class Baz {
+  operator Foo() const {  // CHECK: operator Bar() const {
+Foo foo;  // CHECK: Bar foo;
+return foo;
+  }
+};
Index: test/clang-rename/UserDefinedConversion.cpp
===
--- test/clang-rename/UserDefinedConversion.cpp
+++ /dev/null
@@ -1,13 +0,0 @@
-// Currently unsupported test.
-// RUN: cat %s > %t.cpp
-// FIXME: clang-rename should handle conversions from a class type to another
-// type.
-
-class Foo {}; // CHECK: class Bar {};
-
-class Baz {   // CHECK: class Bar {
-  operator Foo() const {  // CHECK: operator Bar() const {
-Foo foo;  // CHECK: Bar foo;
-return foo;
-  }
-};
Index: test/clang-rename/TemplateTypename.cpp
===
--- test/clang-rename/TemplateTypename.cpp
+++ test/clang-rename/TemplateTypename.cpp
@@ -1,12 +1,20 @@
-// Currently unsupported test.
 // RUN: cat %s > %t.cpp
+// RUN: clang-rename -offset=270 -new-name=U %t.cpp -i --
+// RUN: sed 's,//.*,,' %t.cpp | FileCheck %s
+
+// Currently unsupported test.
 // FIXME: clang-rename should be able to rename template parameters correctly.
+// XFAIL: *
 
-template 
-T foo(T arg, T& ref, T* ptr) {
-  T value;
+template  // CHECK: template 
+class Foo {
+T foo(T arg, T& ref, T* ptr) {// CHECK: U foo(U arg, U& ref, U* ptr) {
+  T value;// CHECK: U value;
   int number = 42;
-  value = (T)number;
-  value = static_cast(number);
+  value = (T)number;  // CHECK: value = (U)number;
+  value = static_cast(number); // CHECK: value = static_cast(number);
   return value;
 }
+
+T member; // CHECK: U member;
+};
Index: test/clang-rename/NestedNamespace.cpp
===
--- /dev/null
+++ test/clang-rename/NestedNamespace.cpp
@@ -0,0 +1,42 @@
+// RUN: cat %s > %t.cpp
+// RUN: clang-rename -offset=274 -new-name=Bar %t.cpp -i --
+// RUN: sed 's,//.*,,' %t.cpp | FileCheck %s
+
+// Currently unsupported test.
+// FIXME: Teach clang-rename to rename namespace in nested constructions.
+// XFAIL: *
+
+namespace Baz {
+namespace Foo { // CHECK: namespace Bar {
+class A {
+public:
+  static int aFunction() { return 0; }
+};
+int FooFunction() { return 0; }
+namespace Qux {
+class B {
+public:
+  static int bFunction() { return 0; }
+};
+int QuxFunction() { return 0; }
+} // namespace Qux
+} // namespace Foo
+} // namespace Baz
+
+int main() {
+
+  // Variable type tests.
+  Baz::Foo::A a;  // CHECK: Baz::Bar::A a;
+  Baz::Foo::Qux::B b; // CHECK: Baz::Bar::Qux::B b;
+  unsigned i = 42;
+  for (Baz::Foo::A c; i < 100; i++);  // CHECK: for (Baz::Bar::A c; i < 100; i++);
+  for (Baz::Foo::Qux::B d; i < 200; i++); // CHECK: for (Baz::Bar::Qux::B d; i < 200; i++);
+
+  // Function tests.
+  int x = Baz::Foo::A::aFunction();   // CHECK: int x = Baz::Bar::A::aFunction();
+  x = Baz::Foo::FooFunction();// CHECK: x = Baz::Bar::FooFunction();
+  x = Baz::Foo::Qux::B::bFunction();  // CHECK: x = Baz::Bar::Qux::B::bFunction();
+  x = Baz::Foo::Qux::QuxFunction();   // CHECK: x = Baz::Ba

Re: [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!

[Mehdi AMINI via cfe-commits]

mehdi_amini added inline comments.


Comment at: docs/Proposals/GitHub.rst:199
@@ +198,3 @@
+
+Here's a proposed plan:
+

Annoyingly my comment does no longer show-up next to the point it was referring 
to, it was about your third point:

> Make sure we have an llvm-project (with submodules) setup in the official 
> account.

I don't think how this project will be updated is explained (or even mentioned) 
anywhere.


https://reviews.llvm.org/D22463



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

Re: [PATCH] D22465: [clang-rename] introduce better symbol finding and add few more tests

[Kirill Bobyrev via cfe-commits]

omtcyfz added a comment.

Removed two `FIXME`s. Seems like types are now handled correctly. +1 test 
passing.


https://reviews.llvm.org/D22465



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

Re: [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!

[Renato Golin via cfe-commits]

rengolin added inline comments.


Comment at: docs/Proposals/GitHub.rst:200
@@ +199,3 @@
+
+Here's a proposed plan:
+

You can click on the "<<" button and it will show where it was first inserted. 
That's how I found out. :)

The hooks, AFAICS, will be added to the project initially, and won't need to be 
updated. Takumi's current repository is automatically updated, and IIRC, it's 
just a hook.

Assuming it's atomic and quick enough, would this process make much of a 
difference to the users?


https://reviews.llvm.org/D22463



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

Re: [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!

[Mehdi AMINI via cfe-commits]

mehdi_amini added inline comments.


Comment at: docs/Proposals/GitHub.rst:208
@@ +207,3 @@
+3. Make sure we have an llvm-project (with submodules) setup in the official
+   account, with all necessary hooks (history, update, merges).
+4. Make sure bisecting with llvm-project works.

I'd like to see clearly mentioned somewhere else than in the plan that on top 
of "hooks" hosted by github, we will need to maintain our own webservice on our 
own server to answer updates from theses hooks and update the umbrella.
That's a non-negligible drawback in face of the motivation exposed in the "Why 
move at all?" section.


https://reviews.llvm.org/D22463



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

Re: [PATCH] D22069: clang-tidy modernize-loop-convert: preserve type of alias declaration (bug 28341)

[Matthias Gehre via cfe-commits]

mgehre added a comment.

Friendly ping


https://reviews.llvm.org/D22069



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

[libcxx] r275904 - Bump version # to 4.0.0

[Marshall Clow via cfe-commits]

Author: marshall
Date: Mon Jul 18 15:27:19 2016
New Revision: 275904

URL: http://llvm.org/viewvc/llvm-project?rev=275904&view=rev
Log:
Bump version # to 4.0.0

Modified:
libcxx/trunk/include/__config

Modified: libcxx/trunk/include/__config
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__config?rev=275904&r1=275903&r2=275904&view=diff
==
--- libcxx/trunk/include/__config (original)
+++ libcxx/trunk/include/__config Mon Jul 18 15:27:19 2016
@@ -27,7 +27,7 @@
 #define _GNUC_VER 0
 #endif
 
-#define _LIBCPP_VERSION 3900
+#define _LIBCPP_VERSION 4000
 
 #ifndef _LIBCPP_ABI_VERSION
 #define _LIBCPP_ABI_VERSION 1


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

r275905 - Allow iOS and tvOS version numbers with 2-digit major version numbers.

[Bob Wilson via cfe-commits]

Author: bwilson
Date: Mon Jul 18 15:29:14 2016
New Revision: 275905

URL: http://llvm.org/viewvc/llvm-project?rev=275905&view=rev
Log:
Allow iOS and tvOS version numbers with 2-digit major version numbers.

rdar://problem/26921601

Modified:
cfe/trunk/lib/Basic/Targets.cpp
cfe/trunk/lib/Driver/ToolChains.cpp
cfe/trunk/test/Frontend/darwin-version.c

Modified: cfe/trunk/lib/Basic/Targets.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=275905&r1=275904&r2=275905&view=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Mon Jul 18 15:29:14 2016
@@ -158,14 +158,25 @@ static void getDarwinDefines(MacroBuilde
 
   // Set the appropriate OS version define.
   if (Triple.isiOS()) {
-assert(Maj < 10 && Min < 100 && Rev < 100 && "Invalid version!");
-char Str[6];
-Str[0] = '0' + Maj;
-Str[1] = '0' + (Min / 10);
-Str[2] = '0' + (Min % 10);
-Str[3] = '0' + (Rev / 10);
-Str[4] = '0' + (Rev % 10);
-Str[5] = '\0';
+assert(Maj < 100 && Min < 100 && Rev < 100 && "Invalid version!");
+char Str[7];
+if (Maj < 10) {
+  Str[0] = '0' + Maj;
+  Str[1] = '0' + (Min / 10);
+  Str[2] = '0' + (Min % 10);
+  Str[3] = '0' + (Rev / 10);
+  Str[4] = '0' + (Rev % 10);
+  Str[5] = '\0';
+} else {
+  // Handle versions >= 10.
+  Str[0] = '0' + (Maj / 10);
+  Str[1] = '0' + (Maj % 10);
+  Str[2] = '0' + (Min / 10);
+  Str[3] = '0' + (Min % 10);
+  Str[4] = '0' + (Rev / 10);
+  Str[5] = '0' + (Rev % 10);
+  Str[6] = '\0';
+}
 if (Triple.isTvOS())
   Builder.defineMacro("__ENVIRONMENT_TV_OS_VERSION_MIN_REQUIRED__", Str);
 else

Modified: cfe/trunk/lib/Driver/ToolChains.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains.cpp?rev=275905&r1=275904&r2=275905&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains.cpp Mon Jul 18 15:29:14 2016
@@ -687,13 +687,13 @@ void Darwin::AddDeploymentTarget(Derived
 assert(iOSVersion && "Unknown target platform!");
 if (!Driver::GetReleaseVersion(iOSVersion->getValue(), Major, Minor, Micro,
HadExtra) ||
-HadExtra || Major >= 10 || Minor >= 100 || Micro >= 100)
+HadExtra || Major >= 100 || Minor >= 100 || Micro >= 100)
   getDriver().Diag(diag::err_drv_invalid_version_number)
   << iOSVersion->getAsString(Args);
   } else if (Platform == TvOS) {
 if (!Driver::GetReleaseVersion(TvOSVersion->getValue(), Major, Minor,
Micro, HadExtra) || HadExtra ||
-Major >= 10 || Minor >= 100 || Micro >= 100)
+Major >= 100 || Minor >= 100 || Micro >= 100)
   getDriver().Diag(diag::err_drv_invalid_version_number)
   << TvOSVersion->getAsString(Args);
   } else if (Platform == WatchOS) {

Modified: cfe/trunk/test/Frontend/darwin-version.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/darwin-version.c?rev=275905&r1=275904&r2=275905&view=diff
==
--- cfe/trunk/test/Frontend/darwin-version.c (original)
+++ cfe/trunk/test/Frontend/darwin-version.c Mon Jul 18 15:29:14 2016
@@ -10,6 +10,8 @@
 // RUN: %clang_cc1 -triple armv6-apple-ios2.3.1 -dM -E -o %t %s
 // RUN: grep '__ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__' %t | grep 
'20301' | count 1
 // RUN: not grep '__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__' %t
+// RUN: %clang_cc1 -triple armv7-apple-ios10.1.2 -dM -E -o %t %s
+// RUN: grep '__ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__' %t | grep 
'100102' | count 1
 // RUN: %clang_cc1 -triple i386-apple-macosx10.4.0 -dM -E -o %t %s
 // RUN: grep '__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__' %t | grep '1040' 
| count 1
 // RUN: not grep '__ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__' %t
@@ -32,6 +34,8 @@
 // RUN: grep '__ENVIRONMENT_TV_OS_VERSION_MIN_REQUIRED__' %t | grep '80300' | 
count 1
 // RUN: not grep '__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__' %t
 // RUN: not grep '__ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__' %t
+// RUN: %clang_cc1 -triple arm64-apple-tvos10.2.3 -dM -E -o %t %s
+// RUN: grep '__ENVIRONMENT_TV_OS_VERSION_MIN_REQUIRED__' %t | grep '100203' | 
count 1
 
 // RUN: %clang_cc1 -triple x86_64-apple-tvos8.3 -dM -E -o %t %s
 // RUN: grep '__ENVIRONMENT_TV_OS_VERSION_MIN_REQUIRED__' %t | grep '80300' | 
count 1


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

Re: [PATCH] D18360: Add AIX Target/ToolChain to Clang Driver

[Andrew Paprocki via cfe-commits]

apaprocki added inline comments.


Comment at: lib/Basic/Targets.cpp:718
@@ +717,3 @@
+Builder.defineMacro("_LONG_LONG");
+Builder.defineMacro("_ALL_SOURCE");
+Builder.defineMacro("_REENTRANT");

majnemer wrote:
> apaprocki wrote:
> > majnemer wrote:
> > > Are we really supposed to define this macro?  Does GCC define this?  I 
> > > cannot find where it does so in the source.
> > I defined both `_ALL_SOURCE` and `_REENTRANT` because the 
> > `SolarisTargetInfo` defines them (`__EXTENSIONS__` is the Solaris 
> > equivalent of `_ALL_SOURCE`). If that is an oversight in the Solaris work, 
> > I'll remove `_ALL_SOURCE` here. GCC does not define it by default.
> After a closer examination of the gcc sources, it looks like `ALL_SOURCE` is 
> defined if gcc is being used for C++ code (via `CPLUSPLUS_CPP_SPEC`).
> 
> I don't see where `_REENTRANT` is defined for AIX though...
On AIX, when `gcc` is passed `-pthread`, it defines `_THREAD_SAFE`. I think 
this should be changed to

```
if (Opts.POSIXThreads)
  Builder.defineMacro("_THREAD_SAFE");
```

On Solaris, `gcc` defines `_REENTRANT` when `-pthread` is passed. I think it is 
a separate bug (and I can file a separate revision) to put the Solaris use of 
it also on an `Opts.POSIXThreads` check.


https://reviews.llvm.org/D18360



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

[PATCH] D22474: [CodeGen] Suppress C++ static destructor registration

[Bruno Cardoso Lopes via cfe-commits]

bruno created this revision.
bruno added reviewers: rsmith, doug.gregor.
bruno added subscribers: cfe-commits, dexonsmith.

C++ static destructors can be problematic in multi-threaded environment. Some 
of the issues users often complain about include:

1. Teardown ordering: crashes when one thread is exiting the process and 
calling destructors while another thread is still running and accessing the 
destructing variables
2. Shared code that is compiled both as an application and as a library. When 
library mode is chosen, goto (1).
3. Some projects currently override __cxa_atexit to avoid the behavior in 
question.

To get around that, I propose we add the compiler flag 
-fno-cxx-static-destructors, which allows clang to suppress static destructor 
registration (suppress emitting __cxa_atexit, atexit, etc).

https://reviews.llvm.org/D22474

Files:
  include/clang/Driver/Options.td
  include/clang/Frontend/CodeGenOptions.def
  lib/CodeGen/ItaniumCXXABI.cpp
  lib/Driver/Tools.cpp
  lib/Frontend/CompilerInvocation.cpp
  test/CodeGenCXX/static-destructor.cpp

Index: test/CodeGenCXX/static-destructor.cpp
===
--- test/CodeGenCXX/static-destructor.cpp
+++ test/CodeGenCXX/static-destructor.cpp
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 %s -triple=x86_64-pc-linux -emit-llvm -o - | FileCheck 
--check-prefix=X86 %s
+// RUN: %clang_cc1 %s -triple=x86_64-apple-darwin -emit-llvm 
-fno-cxx-static-destructors -o - | FileCheck --check-prefix=X86-NOATEXIT %s
 // RUN: %clang_cc1 %s -triple=wasm32 -emit-llvm -o - | FileCheck 
--check-prefix=WASM %s
 // RUN: %clang_cc1 %s -triple=armv7-apple-darwin9 -emit-llvm -o - | FileCheck 
--check-prefix=ARM %s
 
@@ -19,6 +20,11 @@
 // X86: define internal void @__cxx_global_var_init()
 // X86:   call i32 @__cxa_atexit(void (i8*)* bitcast (void (%class.Foo*)* 
@_ZN3FooD1Ev to void (i8*)*), i8* getelementptr inbounds (%class.Foo, 
%class.Foo* @global, i32 0, i32 0), i8* @__dso_handle)
 
+// X86 destructors have void return, and are registered directly with 
__cxa_atexit.
+// X86-NOATEXIT: define internal void @__cxx_global_var_init()
+// X86-NOATEXIT-NOT:   call i32 @__cxa_atexit(void (i8*)* bitcast (void 
(%class.Foo*)* @_ZN3FooD1Ev to void (i8*)*), i8* getelementptr inbounds 
(%class.Foo, %class.Foo* @global, i32 0, i32 0), i8* @__dso_handle)
+// X86-NOATEXIT-NOT:   declare i32 @__cxa_atexit(void (i8*)*, i8*, i8*)
+
 // ARM destructors return this, but can be registered directly with 
__cxa_atexit
 // because the calling conventions tolerate the mismatch.
 // ARM: define internal void @__cxx_global_var_init()
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -546,6 +546,7 @@
   Opts.AssumeSaneOperatorNew = !Args.hasArg(OPT_fno_assume_sane_operator_new);
   Opts.ObjCAutoRefCountExceptions = Args.hasArg(OPT_fobjc_arc_exceptions);
   Opts.CXAAtExit = !Args.hasArg(OPT_fno_use_cxa_atexit);
+  Opts.CXXNoExitTimeDtor = Args.hasArg(OPT_fno_cxx_static_destructors);
   Opts.CXXCtorDtorAliases = Args.hasArg(OPT_mconstructor_aliases);
   Opts.CodeModel = getCodeModel(Args, Diags);
   Opts.DebugPass = Args.getLastArgValue(OPT_mdebug_pass);
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -5963,6 +5963,9 @@
 CmdArgs.push_back("-fwhole-program-vtables");
   }
 
+  if (Args.hasArg(options::OPT_fno_cxx_static_destructors))
+CmdArgs.push_back("-fno-cxx-static-destructors");
+
   // Finally add the compile command to the compilation.
   if (Args.hasArg(options::OPT__SLASH_fallback) &&
   Output.getType() == types::TY_Object &&
Index: lib/CodeGen/ItaniumCXXABI.cpp
===
--- lib/CodeGen/ItaniumCXXABI.cpp
+++ lib/CodeGen/ItaniumCXXABI.cpp
@@ -2132,6 +2132,10 @@
const VarDecl &D,
llvm::Constant *dtor,
llvm::Constant *addr) {
+  // Do not register global dtor at all
+  if (CGM.getCodeGenOpts().CXXNoExitTimeDtor)
+return;
+
   // Use __cxa_atexit if available.
   if (CGM.getCodeGenOpts().CXAAtExit)
 return emitGlobalDtorWithCXAAtExit(CGF, dtor, addr, D.getTLSKind());
Index: include/clang/Frontend/CodeGenOptions.def
===
--- include/clang/Frontend/CodeGenOptions.def
+++ include/clang/Frontend/CodeGenOptions.def
@@ -40,6 +40,7 @@
 CODEGENOPT(CoverageNoFunctionNamesInData, 1, 0) ///< Do not include function 
names in GCDA files.
 CODEGENOPT(CoverageExitBlockBeforeBody, 1, 0) ///< Whether to emit the exit 
block before the body blocks in GCNO files.
 CODEGENOPT(CXAAtExit , 1, 1) ///< Use __cxa_atexit for calling 
destructors.
+CODEGENOPT(CXXNoExitTime

r275906 - Add missing header in ClangFuzzer (after r275882 cleanup)

[Mehdi Amini via cfe-commits]

Author: mehdi_amini
Date: Mon Jul 18 15:33:09 2016
New Revision: 275906

URL: http://llvm.org/viewvc/llvm-project?rev=275906&view=rev
Log:
Add missing header in ClangFuzzer (after r275882 cleanup)

Modified:
cfe/trunk/tools/clang-fuzzer/ClangFuzzer.cpp

Modified: cfe/trunk/tools/clang-fuzzer/ClangFuzzer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-fuzzer/ClangFuzzer.cpp?rev=275906&r1=275905&r2=275906&view=diff
==
--- cfe/trunk/tools/clang-fuzzer/ClangFuzzer.cpp (original)
+++ cfe/trunk/tools/clang-fuzzer/ClangFuzzer.cpp Mon Jul 18 15:33:09 2016
@@ -16,6 +16,7 @@
 #include "clang/Tooling/Tooling.h"
 #include "clang/Frontend/FrontendActions.h"
 #include "clang/Frontend/CompilerInstance.h"
+#include "clang/Lex/PreprocessorOptions.h"
 #include "llvm/Option/Option.h"
 
 using namespace clang;


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

Re: [PATCH] D18360: Add AIX Target/ToolChain to Clang Driver

[Andrew Paprocki via cfe-commits]

apaprocki updated this revision to Diff 64376.

https://reviews.llvm.org/D18360

Files:
  lib/Basic/Targets.cpp
  lib/Driver/Driver.cpp
  lib/Driver/ToolChains.cpp
  lib/Driver/ToolChains.h
  lib/Driver/Tools.cpp
  lib/Driver/Tools.h
  tools/libclang/CIndexer.cpp

Index: tools/libclang/CIndexer.cpp
===
--- tools/libclang/CIndexer.cpp
+++ tools/libclang/CIndexer.cpp
@@ -37,12 +37,71 @@
 
 #ifdef LLVM_ON_WIN32
 #include 
+#elif defined(_AIX)
+#include 
+#include 
+#include 
 #else
 #include 
 #endif
 
 using namespace clang;
 
+#ifdef _AIX
+static int
+test_dir(char ret[PATH_MAX], const char *dir, const char *bin)
+{
+  struct stat sb;
+  char fullpath[PATH_MAX];
+
+  snprintf(fullpath, PATH_MAX, "%s/%s", dir, bin);
+  if (!realpath(fullpath, ret))
+return 1;
+  if (stat(fullpath, &sb) != 0)
+return 1;
+
+  return 0;
+}
+
+static char *
+getprogpath(char ret[PATH_MAX], const char *bin)
+{
+  char *pv, *s, *t;
+
+  /* First approach: absolute path. */
+  if (bin[0] == '/') {
+if (test_dir(ret, "/", bin) == 0)
+  return ret;
+return nullptr;
+  }
+
+  /* Second approach: relative path. */
+  if (strchr(bin, '/')) {
+char cwd[PATH_MAX];
+if (!getcwd(cwd, PATH_MAX))
+  return nullptr;
+if (test_dir(ret, cwd, bin) == 0)
+  return ret;
+return nullptr;
+  }
+
+  /* Third approach: $PATH */
+  if ((pv = getenv("PATH")) == nullptr)
+return nullptr;
+  s = pv = strdup(pv);
+  if (!pv)
+return nullptr;
+  while ((t = strsep(&s, ":")) != nullptr) {
+if (test_dir(ret, t, bin) == 0) {
+  free(pv);
+  return ret;
+}
+  }
+  free(pv);
+  return nullptr;
+}
+#endif
+
 const std::string &CIndexer::getClangResourcesPath() {
   // Did we already compute the path?
   if (!ResourcesPath.empty())
@@ -69,6 +128,11 @@
 #endif
 
   LibClangPath += llvm::sys::path::parent_path(path);
+#elif defined(_AIX)
+  extern char **argv;
+  char exe_path[MAXPATHLEN];
+  if (getprogpath(exe_path, argv[0]) != NULL)
+LibClangPath += llvm::sys::path::parent_path(exe_path);
 #else
   // This silly cast below avoids a C++ warning.
   Dl_info info;
Index: lib/Driver/Tools.h
===
--- lib/Driver/Tools.h
+++ lib/Driver/Tools.h
@@ -652,6 +652,34 @@
 };
 } // end namespace solaris
 
+/// aix -- Directly call AIX assembler and linker
+namespace aix {
+class LLVM_LIBRARY_VISIBILITY Assembler : public Tool {
+public:
+  Assembler(const ToolChain &TC) : Tool("aix::Assembler", "assembler", TC) {}
+
+  bool hasIntegratedCPP() const override { return false; }
+
+  void ConstructJob(Compilation &C, const JobAction &JA,
+const InputInfo &Output, const InputInfoList &Inputs,
+const llvm::opt::ArgList &TCArgs,
+const char *LinkingOutput) const override;
+};
+
+class LLVM_LIBRARY_VISIBILITY Linker : public Tool {
+public:
+  Linker(const ToolChain &TC) : Tool("aix::Linker", "linker", TC) {}
+
+  bool hasIntegratedCPP() const override { return false; }
+  bool isLinkJob() const override { return true; }
+
+  void ConstructJob(Compilation &C, const JobAction &JA,
+const InputInfo &Output, const InputInfoList &Inputs,
+const llvm::opt::ArgList &TCArgs,
+const char *LinkingOutput) const override;
+};
+}  // end namespace aix
+
 /// dragonfly -- Directly call GNU Binutils assembler and linker
 namespace dragonfly {
 class LLVM_LIBRARY_VISIBILITY Assembler : public GnuTool {
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -5452,6 +5452,7 @@
   options::OPT_fuse_cxa_atexit, options::OPT_fno_use_cxa_atexit,
   !IsWindowsCygnus && !IsWindowsGNU &&
   getToolChain().getTriple().getOS() != llvm::Triple::Solaris &&
+  getToolChain().getTriple().getOS() != llvm::Triple::AIX &&
   getToolChain().getArch() != llvm::Triple::hexagon &&
   getToolChain().getArch() != llvm::Triple::xcore &&
   ((getToolChain().getTriple().getVendor() !=
@@ -8102,6 +8103,94 @@
   C.addCommand(llvm::make_unique(JA, *this, Exec, CmdArgs, Inputs));
 }
 
+void aix::Assembler::ConstructJob(Compilation &C, const JobAction &JA,
+  const InputInfo &Output,
+  const InputInfoList &Inputs,
+  const ArgList &Args,
+  const char *LinkingOutput) const {
+  claimNoWarnArgs(Args);
+  ArgStringList CmdArgs;
+
+  Args.AddAllArgValues(CmdArgs, options::OPT_Wa_COMMA, options::OPT_Xassembler);
+
+  CmdArgs.push_back("-o");
+  CmdArgs.push_back(Output.getFilename());
+
+  for (const auto &II : Inputs)
+CmdArgs.push_back(II.getFilename());
+
+  const char *Exec = Args.MakeArgString(getToolChain().GetProgramPat

r275907 - [Sema] Create a separate group for incompatible function pointer warning

[Bruno Cardoso Lopes via cfe-commits]

Author: bruno
Date: Mon Jul 18 15:37:06 2016
New Revision: 275907

URL: http://llvm.org/viewvc/llvm-project?rev=275907&view=rev
Log:
[Sema] Create a separate group for incompatible function pointer warning

Give incompatible function pointer warning its own diagnostic group
but still leave it as a subgroup of incompatible-pointer-types. This is in
preparation to promote -Wincompatible-function-pointer-types to error on
darwin.

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

rdar://problem/12907612

Added:
cfe/trunk/test/Sema/incompatible-function-pointer-types.c
Modified:
cfe/trunk/include/clang/Basic/DiagnosticGroups.td
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/Sema/SemaExpr.cpp
cfe/trunk/test/Sema/initialize-noreturn.c
cfe/trunk/test/Sema/overloadable.c

Modified: cfe/trunk/include/clang/Basic/DiagnosticGroups.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticGroups.td?rev=275907&r1=275906&r2=275907&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticGroups.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticGroups.td Mon Jul 18 15:37:06 2016
@@ -225,9 +225,12 @@ def GNUIncludeNext : DiagGroup<"gnu-incl
 def IncompatibleMSStruct : DiagGroup<"incompatible-ms-struct">;
 def IncompatiblePointerTypesDiscardsQualifiers 
   : DiagGroup<"incompatible-pointer-types-discards-qualifiers">;
+def IncompatibleFunctionPointerTypes
+  : DiagGroup<"incompatible-function-pointer-types">;
 def IncompatiblePointerTypes
   : DiagGroup<"incompatible-pointer-types",
-[IncompatiblePointerTypesDiscardsQualifiers]>;
+[IncompatiblePointerTypesDiscardsQualifiers,
+ IncompatibleFunctionPointerTypes]>;
 def IncompleteUmbrella : DiagGroup<"incomplete-umbrella">;
 def NonModularIncludeInFrameworkModule
   : DiagGroup<"non-modular-include-in-framework-module">;

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=275907&r1=275906&r2=275907&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Mon Jul 18 15:37:06 
2016
@@ -6351,6 +6351,24 @@ def ext_typecheck_convert_incompatible_p
   "; remove *|"
   "; remove &}3">,
   InGroup;
+def ext_typecheck_convert_incompatible_function_pointer : ExtWarn<
+  "incompatible function pointer types "
+  "%select{%diff{assigning to $ from $|assigning to different types}0,1"
+  "|%diff{passing $ to parameter of type $|"
+  "passing to parameter of different type}0,1"
+  "|%diff{returning $ from a function with result type $|"
+  "returning from function with different return type}0,1"
+  "|%diff{converting $ to type $|converting between types}0,1"
+  "|%diff{initializing $ with an expression of type $|"
+  "initializing with expression of different type}0,1"
+  "|%diff{sending $ to parameter of type $|"
+  "sending to parameter of different type}0,1"
+  "|%diff{casting $ to type $|casting between types}0,1}2"
+  "%select{|; dereference with *|"
+  "; take the address with &|"
+  "; remove *|"
+  "; remove &}3">,
+  InGroup;
 def ext_typecheck_convert_discards_qualifiers : ExtWarn<
   "%select{%diff{assigning to $ from $|assigning to different types}0,1"
   "|%diff{passing $ to parameter of type $|"

Modified: cfe/trunk/lib/Sema/SemaExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExpr.cpp?rev=275907&r1=275906&r2=275907&view=diff
==
--- cfe/trunk/lib/Sema/SemaExpr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExpr.cpp Mon Jul 18 15:37:06 2016
@@ -12423,10 +12423,14 @@ bool Sema::DiagnoseAssignmentResult(Assi
 MayHaveConvFixit = true;
 break;
   case IncompatiblePointer:
-  DiagKind =
-(Action == AA_Passing_CFAudited ?
-  diag::err_arc_typecheck_convert_incompatible_pointer :
-  diag::ext_typecheck_convert_incompatible_pointer);
+if (Action == AA_Passing_CFAudited)
+  DiagKind = diag::err_arc_typecheck_convert_incompatible_pointer;
+else if (SrcType->isFunctionPointerType() &&
+ DstType->isFunctionPointerType())
+  DiagKind = diag::ext_typecheck_convert_incompatible_function_pointer;
+else
+  DiagKind = diag::ext_typecheck_convert_incompatible_pointer;
+
 CheckInferredResultType = DstType->isObjCObjectPointerType() &&
   SrcType->isObjCObjectPointerType();
 if (Hint.isNull() && !CheckInferredResultType) {

Added: cfe/trunk/test/Sema/incompatible-function-pointer-types.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/incompatible-function-pointer-types.c?rev=275907&view=auto
==
--- cf

Re: [PATCH] D20748: Handle recursion in LLVMIRGeneration Timer

[Davide Italiano via cfe-commits]

davide added a comment.

Richard, can you please take a look at this? The more I look at it the more it 
seems weird that we can recurse in this case, but I may miss something


https://reviews.llvm.org/D20748



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

LLVM buildmaster will be restarted tonight

[Galina Kistanova via cfe-commits]

Hello everyone,

LLVM buildmaster will be updated and restarted after 7 PM Pacific time
today.

Thanks

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

Re: [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!

[Renato Golin via cfe-commits]

rengolin added inline comments.


Comment at: docs/Proposals/GitHub.rst:208
@@ +207,3 @@
+3. Make sure we have an llvm-project (with submodules) setup in the official
+   account, with all necessary hooks (history, update, merges).
+4. Make sure bisecting with llvm-project works.

mehdi_amini wrote:
> I'd like to see clearly mentioned somewhere else than in the plan that on top 
> of "hooks" hosted by github, we will need to maintain our own webservice on 
> our own server to answer updates from theses hooks and update the umbrella.
> That's a non-negligible drawback in face of the motivation exposed in the 
> "Why move at all?" section.
There are two types of hooks:

1. Pre-commit hooks that will stop anyone trying to merge/force push commits to 
the projects, in order to keep the history clean. These are install once, use 
forever. Zero maintenance after the initial period.

2. Post-commit hooks on the other projects / OR / external webservice/buildbot 
that will update the umbrella project like any existing Git mirror. Maintenance 
of this is either free (hooks) or very cheap (buildbot/cron jobs).

On both cases, the history is preserved at least within the update cycle, which 
shouldn't be more than 5 minutes, and will be the update cycle that buildbots 
will pick the commits anyway.


https://reviews.llvm.org/D22463



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

[PATCH] D22476: [AST] Make MemberExpr non-dependent according to core issue 224

[Matthias Gehre via cfe-commits]

mgehre created this revision.
mgehre added reviewers: klimek, aaron.ballman, rsmith.
mgehre added a subscriber: cfe-commits.

A MemberExpr is non-dependent if
1) it is a member of the current instantiation
2) the member is non-dependent

We check 1) by asserting that the base of the
MemberExpr is a CXXThisExpr. In addition,
the parent of the member needs to be the current
class or a base of it. (It can happen that the member
decl resolves to a member of an outer class, and later
on Sema prints an error about it. In this case, we keep
it type-dependent, and the error will only appear if it is
ODR-used.)

This changes makes clang reject certain source code that it previously accepted,
namely invalid use of members in functions that are never specialized
or ODR-used. The changes to the tests show examples of this.

https://reviews.llvm.org/D22476

Files:
  lib/AST/Expr.cpp
  lib/Sema/SemaOverload.cpp
  test/Analysis/stack-addr-ps.cpp
  test/CXX/class.access/class.access.dcl/p1.cpp
  test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p4.cpp
  test/CXX/drs/dr3xx.cpp
  test/SemaTemplate/dependent-names.cpp
  test/SemaTemplate/enum-argument.cpp
  test/SemaTemplate/member-access-expr.cpp

Index: test/SemaTemplate/member-access-expr.cpp
===
--- test/SemaTemplate/member-access-expr.cpp
+++ test/SemaTemplate/member-access-expr.cpp
@@ -154,9 +154,7 @@
   template  class Derived : public Base {
 A *field;
 void get(B **ptr) {
-  // It's okay if at some point we figure out how to diagnose this
-  // at instantiation time.
-  *ptr = field;
+  *ptr = field; // expected-error{{assigning to 'test6::B *' from incompatible type 'test6::A *'}}
 }
   };
 }
Index: test/SemaTemplate/enum-argument.cpp
===
--- test/SemaTemplate/enum-argument.cpp
+++ test/SemaTemplate/enum-argument.cpp
@@ -31,7 +31,7 @@
 unsigned long long bitfield : e0;
 
 void f(int j) {
-  bitfield + j;
+  (void)(bitfield + j);
 }
   };
 }
Index: test/SemaTemplate/dependent-names.cpp
===
--- test/SemaTemplate/dependent-names.cpp
+++ test/SemaTemplate/dependent-names.cpp
@@ -274,7 +274,7 @@
   int e[10];
 };
 void g() {
-  S().f(); // expected-note {{here}}
+  S().f();
 }
   }
 
Index: test/CXX/drs/dr3xx.cpp
===
--- test/CXX/drs/dr3xx.cpp
+++ test/CXX/drs/dr3xx.cpp
@@ -1167,8 +1167,8 @@
 namespace dr390 { // dr390: yes
   template
   struct A {
-A() { f(); } // expected-warning {{call to pure virt}}
-virtual void f() = 0; // expected-note {{here}}
+A() { f(); } // expected-warning {{call to pure virt}} expected-warning {{call to pure virt}}
+virtual void f() = 0; // expected-note {{here}} expected-note {{here}}
 virtual ~A() = 0;
   };
   template A::~A() { T::error; } // expected-error {{cannot be used prior to}}
Index: test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p4.cpp
===
--- test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p4.cpp
+++ test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p4.cpp
@@ -29,7 +29,10 @@
   };
 }
 
-struct Opaque0 {};
+struct Opaque0 {}; // expected-note {{no known conversion}}
+#if __cplusplus >= 201103L
+//  expected-note@-2 {{no known conversion}}
+#endif
 
 namespace test1 {
   struct A {
@@ -112,7 +115,7 @@
 }
 
 void test5() {
-  Opaque0 _ = hiding;
+  Opaque0 _ = hiding; // expected-error {{no viable conversion from 'int' to 'Opaque0'}}
 }
   };
 }
Index: test/CXX/class.access/class.access.dcl/p1.cpp
===
--- test/CXX/class.access/class.access.dcl/p1.cpp
+++ test/CXX/class.access/class.access.dcl/p1.cpp
@@ -56,7 +56,10 @@
   };
 }
 
-struct Opaque0 {};
+struct Opaque0 {}; // expected-note {{candidate constructor}}
+#if __cplusplus >= 201103L
+// expected-note@-2 {{candidate constructor}}
+#endif
 
 namespace test1 {
   struct A {
@@ -196,7 +199,7 @@
 }
 
 void test5() {
-  Opaque0 _ = hiding;
+  Opaque0 _ = hiding; // expected-error {{no viable conversion from 'int' to 'Opaque0'}}
 }
   };
 }
Index: test/Analysis/stack-addr-ps.cpp
===
--- test/Analysis/stack-addr-ps.cpp
+++ test/Analysis/stack-addr-ps.cpp
@@ -84,8 +84,8 @@
 struct TS {
   int *get();
   int *m() {
-int *&x = get();
-return x;
+int * const &x = get(); // expected-note {{binding reference variable 'x' here}}
+return x; // expected-warning {{returning address of local temporary object}}
   }
 };
 
Index: lib/Sema/SemaOverload.cpp
===
--- lib/Sema/SemaOverload.cpp
+++ lib/Sema/SemaOverload.cpp
@@ -4881,7 +4881,7 @@
 a

r275913 - [Coverage] Normalize '..' out of filename strings

[Vedant Kumar via cfe-commits]

Author: vedantk
Date: Mon Jul 18 16:01:27 2016
New Revision: 275913

URL: http://llvm.org/viewvc/llvm-project?rev=275913&view=rev
Log:
[Coverage] Normalize '..' out of filename strings

This fixes the issue of having duplicate entries for the same file in a
coverage report s.t none of the entries actually displayed the correct
coverage information.

Added:
cfe/trunk/test/CoverageMapping/abspath.cpp
Modified:
cfe/trunk/lib/CodeGen/CoverageMappingGen.cpp

Modified: cfe/trunk/lib/CodeGen/CoverageMappingGen.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CoverageMappingGen.cpp?rev=275913&r1=275912&r2=275913&view=diff
==
--- cfe/trunk/lib/CodeGen/CoverageMappingGen.cpp (original)
+++ cfe/trunk/lib/CodeGen/CoverageMappingGen.cpp Mon Jul 18 16:01:27 2016
@@ -23,6 +23,7 @@
 #include "llvm/ProfileData/Coverage/CoverageMappingWriter.h"
 #include "llvm/ProfileData/InstrProfReader.h"
 #include "llvm/Support/FileSystem.h"
+#include "llvm/Support/Path.h"
 
 using namespace clang;
 using namespace CodeGen;
@@ -920,16 +921,24 @@ struct CounterCoverageMappingBuilder
 // propagate counts into them.
   }
 };
-}
 
-static bool isMachO(const CodeGenModule &CGM) {
+bool isMachO(const CodeGenModule &CGM) {
   return CGM.getTarget().getTriple().isOSBinFormatMachO();
 }
 
-static StringRef getCoverageSection(const CodeGenModule &CGM) {
+StringRef getCoverageSection(const CodeGenModule &CGM) {
   return llvm::getInstrProfCoverageSectionName(isMachO(CGM));
 }
 
+std::string normalizeFilename(StringRef Filename) {
+  llvm::SmallString<256> Path(Filename);
+  llvm::sys::path::remove_dots(Path, /*remove_dot_dots=*/true);
+  llvm::sys::fs::make_absolute(Path);
+  return Path.str().str();
+}
+
+} // end anonymous namespace
+
 static void dump(llvm::raw_ostream &OS, StringRef FunctionName,
  ArrayRef Expressions,
  ArrayRef Regions) {
@@ -994,7 +1003,7 @@ void CoverageMappingModuleGen::addFuncti
 llvm::SmallVector FilenameRefs;
 FilenameRefs.resize(FileEntries.size());
 for (const auto &Entry : FileEntries)
-  FilenameRefs[Entry.second] = Entry.first->getName();
+  FilenameRefs[Entry.second] = normalizeFilename(Entry.first->getName());
 RawCoverageMappingReader Reader(CoverageMapping, FilenameRefs, Filenames,
 Expressions, Regions);
 if (Reader.read())
@@ -1015,11 +1024,8 @@ void CoverageMappingModuleGen::emit() {
   FilenameStrs.resize(FileEntries.size());
   FilenameRefs.resize(FileEntries.size());
   for (const auto &Entry : FileEntries) {
-llvm::SmallString<256> Path(Entry.first->getName());
-llvm::sys::fs::make_absolute(Path);
-
 auto I = Entry.second;
-FilenameStrs[I] = std::string(Path.begin(), Path.end());
+FilenameStrs[I] = normalizeFilename(Entry.first->getName());
 FilenameRefs[I] = FilenameStrs[I];
   }
 

Added: cfe/trunk/test/CoverageMapping/abspath.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CoverageMapping/abspath.cpp?rev=275913&view=auto
==
--- cfe/trunk/test/CoverageMapping/abspath.cpp (added)
+++ cfe/trunk/test/CoverageMapping/abspath.cpp Mon Jul 18 16:01:27 2016
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -fprofile-instrument=clang -fcoverage-mapping -emit-llvm 
-main-file-name abspath.cpp %S/Inputs/../abspath.cpp -o - | FileCheck %s
+
+// CHECK: @__llvm_coverage_mapping = {{.*}}"\01
+// CHECK-NOT: Inputs
+// CHECK: "
+
+void f1() {}


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

Re: [PATCH] D22248: [Sema] Create a separate group for incompatible function pointer warning

[Bruno Cardoso Lopes via cfe-commits]

bruno closed this revision.
bruno added a comment.

Thanks, r275907.


https://reviews.llvm.org/D22248



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

Re: [PATCH] D22183: [SemObjC] Fix TypoExpr handling in TransformObjCDictionaryLiteral

[Bruno Cardoso Lopes via cfe-commits]

bruno added a comment.

Ping!


https://reviews.llvm.org/D22183



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

Re: [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!

[Renato Golin via cfe-commits]

rengolin updated this revision to Diff 64383.
rengolin added a comment.

Expand step 2 to make sure we don't forget about the safety hooks on each 
project as well as the webhook to update the umbrella project. This could turn 
out to be a buildbot, but makes no difference at this stage.


https://reviews.llvm.org/D22463

Files:
  docs/Proposals/GitHub.rst

Index: docs/Proposals/GitHub.rst
===
--- /dev/null
+++ docs/Proposals/GitHub.rst
@@ -0,0 +1,242 @@
+==
+Moving LLVM Projects to GitHub
+==
+
+Introduction
+
+
+This is a proposal to move our current revision control system from our own
+hosted Subversion to GitHub. Below are the financial and technical arguments as
+to why we need such a move and how will people (and validation infrastructure)
+continue to work with a Git-based LLVM.
+
+There will be a survey pointing at this document when we'll know the community's
+reaction and, if we collectively decide to move, the time-frames. Be sure to make
+your views count.
+
+Essentially, the proposal is divided in the following parts:
+
+ * Outline of the reasons to move to Git and GitHub
+ * Description on how the work flow will look like (compared to SVN)
+ * Remaining issues and potential problems
+ * The proposed migration plan
+
+Why Git, and Why GitHub?
+
+
+Why move at all?
+
+
+The strongest reason for the move, and why this discussion started in the first
+place, is that we currently host our own Subversion server and Git mirror in a
+voluntary basis. The LLVM Foundation sponsors the server and provides limited
+support, but there is only so much it can do.
+
+The volunteers are not Sysadmins themselves, but compiler engineers that happen
+to know a thing or two about hosting servers. We also don't have 24/7 support,
+and we sometimes wake up to see that continuous integration is broken because
+the SVN server is either down or unresponsive.
+
+With time and money, the foundation and volunteers could improve our services,
+implement more functionality and provide around the clock support, so that we
+can have a first class infrastructure with which to work. But the cost is not
+small, both in money and time invested.
+
+On the other hand, there are multiple services out there (GitHub, GitLab,
+BitBucket among others) that offer that same service (24/7 stability, disk space,
+Git server, code browsing, forking facilities, etc) for the very affordable price
+of *FREE*.
+
+Why Git?
+
+
+Most new coders nowadays start with Git. A lot of them have never used SVN, CVS
+or anything else. Websites like GitHub have changed the landscape of open source
+contributions, reducing the cost of first contribution and fostering
+collaboration.
+
+Git is also the version control most LLVM developers use. Despite the sources
+being stored in an SVN server, most people develop using the Git-SVN integration,
+and that shows that Git is not only more powerful than SVN, but people have
+resorted to using a bridge because its features are now indispensable to their
+internal and external workflows.
+
+In essence, Git allows you to:
+ * Commit, squash, merge, fork locally without any penalty to the server
+ * Add as many branches as necessary to allow for multiple threads of development
+ * Collaborate with peers directly, even without access to the Internet
+ * Have multiple trees without multiplying disk space, multiple concurrent builds
+
+In addition, because Git seems to be replacing every project's version control
+system, there are many more tools that can use Git's enhanced feature set, so
+new tooling is much more likely to support Git first (if not only), than any
+other version control system.
+
+Why GitHub?
+---
+
+GitHub, like GitLab and BitBucket, provide FREE code hosting for open source
+projects. Essentially, they will completely replace *all* the infrastructure that
+we have today that serves code repository, mirroring, user control, etc.
+
+They also have a dedicated team to monitor, migrate, improve and distribute the
+contents of the repositories depending on region and load. A level of quality
+that we'd never have without spending money that would be better spent elsewhere,
+for example development meetings, sponsoring disadvantaged people to work on
+compilers and foster diversity and quality in our community.
+
+GitHub has the added benefit that we already have a presence there. Many
+developers use it already, and the mirror from our current repository is already
+set up.
+
+Furthermore, GitHub has an *SVN view* (https://github.com/blog/626-announcing-svn-support)
+where people that still have/want to use SVN infrastructure and tooling can
+slowly migrate or even stay working as if it was an SVN repository (including
+read-write access).
+
+So, any of the three solutions solve the cost and maintenance problem, but 

Re: [PATCH] D22476: [AST] Make MemberExpr non-dependent according to core issue 224

[Richard Smith via cfe-commits]

rsmith added inline comments.


Comment at: lib/AST/Expr.cpp:1425
@@ +1424,3 @@
+
+  if (E->isTypeDependent() && isa(base)) {
+bool MemberOfCurrentInstantiation = true;

The language rule for this says nothing about the base being a `this` 
expression; there are many other ways in which a `MemberExpr` could name a 
member of the current instantiation.

In general, the base expression should have (pointer to) `RecordType` or 
`InjectedClassNameType` as its type (that is, `getAsCXXRecordDecl()` should 
succeed) in all cases except when the member access denotes a member of an 
unknown specialization.


Comment at: lib/AST/Expr.cpp:1454
@@ +1453,3 @@
+if (MemberOfCurrentInstantiation && 
!memberdecl->getType()->isDependentType())
+  E->setTypeDependent(false);
+  }

Please assert that `ty` is not a dependent type here.


https://reviews.llvm.org/D22476



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

Re: [PATCH] D22474: [CodeGen] Suppress C++ static destructor registration

[Richard Smith via cfe-commits]

rsmith added a comment.

Interested reviewers, see also discussion here of whether we want this feature: 
http://lists.llvm.org/pipermail/cfe-dev/2016-July/050040.html


https://reviews.llvm.org/D22474



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

Re: [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!

[Mehdi AMINI via cfe-commits]

mehdi_amini added inline comments.


Comment at: docs/Proposals/GitHub.rst:209
@@ +208,3 @@
+   well as a webhook to update the umbrella project (see below).
+3. Make sure we have an llvm-project (with submodules) setup in the official
+   account, with all necessary hooks (history, update, merges).

> Pre-commit hooks

Won't handle the update of the umbrella.

> Post-commit hooks

Can't handle the update of the umbrella *because of GitHub*, this could be 
possible with our own hosting of git for instance.



https://reviews.llvm.org/D22463



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

Re: [libcxx] r275114 - Don't compute modulus of hash if it is smaller than the bucket count.

[Duncan P. N. Exon Smith via cfe-commits]

> On 2016-Jul-17, at 14:09, Eric Fiselier  wrote:
> 
> What I'm curious about if this performance regression was cause by (1) the 
> removal of this 2 week old optimization or (2) the implementation of "fast 
> mod". I suspect it's because of (1).
> 

BTW, definitely from the 2 week old optimization.  I finally figured out how to 
look at a larger graph; if you zoom in it makes it pretty clear:
  
http://llvm.org/perf/db_default/v4/nts/graph?hide_all_points=yes&moving_window_size=10&plot.0=42.1039.3&submit=Update

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

Re: [PATCH] D18360: Add AIX Target/ToolChain to Clang Driver

[David Majnemer via cfe-commits]

majnemer added a comment.

Could you please attach a diff with additional context?



Comment at: lib/Driver/ToolChains.cpp:3717-3735
@@ -3678,1 +3716,21 @@
 
+  // We need a detected GCC installation on Linux to provide libstdc++'s
+  // headers. We handled the libc++ case above.
+  if (!GCCInstallation.isValid())
+return;
+
+  // By default, look for the C++ headers in an include directory adjacent to
+  // the lib directory of the GCC installation. Note that this is expect to be
+  // equivalent to '/usr/include/c++/X.Y' in almost all cases.
+  StringRef LibDir = GCCInstallation.getParentLibPath();
+  StringRef TripleStr = GCCInstallation.getTriple().str();
+  const Multilib &Multilib = GCCInstallation.getMultilib();
+  const GCCVersion &Version = GCCInstallation.getVersion();
+
+  // The primary search for libstdc++ supports multiarch variants.
+  addLibStdCXXIncludePaths(LibDir.str() + "/../include",
+   "/c++/" + Version.Text, TripleStr,
+   /*GCCMultiarchTriple*/ "",
+   /*TargetMultiarchTriple*/ "",
+   Multilib.includeSuffix(), DriverArgs, CC1Args);
+}

If I am not mistaken, this change seem unrelated.


https://reviews.llvm.org/D18360



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

Re: r263019 - [OpenMP] Add support for multidimensional array sections in map clause SEMA.

[Richard Smith via cfe-commits]

On Wed, Mar 9, 2016 at 7:46 AM, Samuel Antao via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: sfantao
> Date: Wed Mar  9 09:46:05 2016
> New Revision: 263019
>
> URL: http://llvm.org/viewvc/llvm-project?rev=263019&view=rev
> Log:
> [OpenMP] Add support for multidimensional array sections in map clause
> SEMA.
>
> Summary: In some cases it can be proved statically that multidimensional
> array section refer to contiguous storage and can therefore be allowed in a
> map clause. This patch adds support for those cases in SEMA.
>
> Reviewers: hfinkel, carlo.bertolli, arpith-jacob, kkwli0, ABataev
>
> Subscribers: cfe-commits, fraggamuffin, caomhin
>
> Differential Revision: http://reviews.llvm.org/D17547
>
> Modified:
> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> cfe/trunk/lib/Sema/SemaOpenMP.cpp
> cfe/trunk/test/OpenMP/target_map_messages.cpp
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=263019&r1=263018&r2=263019&view=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Wed Mar  9
> 09:46:05 2016
> @@ -7825,8 +7825,8 @@ def err_omp_expected_named_var_member_or
>"expected expression containing only member accesses and/or array
> sections based on named variables">;
>  def err_omp_bit_fields_forbidden_in_map_clause : Error<
>"bit fields cannot be used to specify storage in a map clause">;
> -def err_omp_array_section_in_rightmost_expression : Error<
> -  "array section can only be associated with the rightmost variable in a
> map clause expression">;
> +def err_array_section_does_not_specify_contiguous_storage : Error<
> +  "array section does not specify contiguous storage">;
>  def err_omp_union_type_not_allowed : Error<
>"mapped storage cannot be derived from a union">;
>  def err_omp_expected_access_to_data_field : Error<
>
> Modified: cfe/trunk/lib/Sema/SemaOpenMP.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaOpenMP.cpp?rev=263019&r1=263018&r2=263019&view=diff
>
> ==
> --- cfe/trunk/lib/Sema/SemaOpenMP.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaOpenMP.cpp Wed Mar  9 09:46:05 2016
> @@ -9104,6 +9104,94 @@ static bool CheckTypeMappable(SourceLoca
>return true;
>  }
>
> +/// \brief Return true if it can be proven that the provided array
> expression
> +/// (array section or array subscript) does NOT specify the whole size of
> the
> +/// array whose base type is \a BaseQTy.
> +static bool CheckArrayExpressionDoesNotReferToWholeSize(Sema &SemaRef,
> +const Expr *E,
> +QualType BaseQTy)
> {
> +  auto *OASE = dyn_cast(E);
> +
> +  // If this is an array subscript, it refers to the whole size if the
> size of
> +  // the dimension is constant and equals 1. Also, an array section
> assumes the
> +  // format of an array subscript if no colon is used.
> +  if (isa(E) || (OASE &&
> OASE->getColonLoc().isInvalid())) {
> +if (auto *ATy = dyn_cast(BaseQTy.getTypePtr()))
> +  return ATy->getSize().getSExtValue() != 1;
> +// Size can't be evaluated statically.
> +return false;
> +  }
> +
> +  assert(OASE && "Expecting array section if not an array subscript.");
> +  auto *LowerBound = OASE->getLowerBound();
> +  auto *Length = OASE->getLength();
> +
> +  // If there is a lower bound that does not evaluates to zero, we are not
> +  // convering the whole dimension.
> +  if (LowerBound) {
> +llvm::APSInt ConstLowerBound;
> +if (!LowerBound->EvaluateAsInt(ConstLowerBound,
> SemaRef.getASTContext()))
> +  return false; // Can't get the integer value as a constant.
> +if (ConstLowerBound.getSExtValue())
> +  return true;
> +  }
> +
> +  // If we don't have a length we covering the whole dimension.
> +  if (!Length)
> +return false;
> +
> +  // If the base is a pointer, we don't have a way to get the size of the
> +  // pointee.
> +  if (BaseQTy->isPointerType())
> +return false;
> +
> +  // We can only check if the length is the same as the size of the
> dimension
> +  // if we have a constant array.
> +  auto *CATy = dyn_cast(BaseQTy.getTypePtr());
> +  if (!CATy)
> +return false;
> +
> +  llvm::APSInt ConstLength;
> +  if (!Length->EvaluateAsInt(ConstLength, SemaRef.getASTContext()))
> +return false; // Can't get the integer value as a constant.
> +
> +  return CATy->getSize().getSExtValue() != ConstLength.getSExtValue();
> +}
> +
> +// Return true if it can be proven that the provided array expression
> (array
> +// section or array subscript) does NOT specify a single element of the
> array
> +// whose base type is \a BaseQTy

Re: [PATCH] D22034: [MSVC][DLL] use local vftable mangling only exported classes with virtual destructor

[Reid Kleckner via cfe-commits]

rnk added a comment.

The approach makes sense to me, but the tests suggest it isn't doing what I'd 
expect.



Comment at: test/CodeGenCXX/dllimport-rtti.cpp:7
@@ -6,3 +6,1 @@
 } s;
-// MSVC: [[VF_S:.*]] = private unnamed_addr constant [2 x i8*]
-// MSVC-DAG: @"\01??_SS@@6B@" = unnamed_addr alias i8*, getelementptr inbounds 
([2 x i8*], [2 x i8*]* [[VF_S]], i32 0, i32 1)

I would've expected this to remain the same, since the implicit default ctor of 
'S' is constexpr by default in C++14. It seems a lot better to emit a local 
vftable here and get static initialization for 's' than dynamic initialization.


https://reviews.llvm.org/D22034



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

Re: r202329 - Add a 'use-external-names' option to VFS overlay files

[Richard Smith via cfe-commits]

On Wed, Feb 26, 2014 at 4:25 PM, Ben Langmuir  wrote:

> Author: benlangmuir
> Date: Wed Feb 26 18:25:12 2014
> New Revision: 202329
>
> URL: http://llvm.org/viewvc/llvm-project?rev=202329&view=rev
> Log:
> Add a 'use-external-names' option to VFS overlay files
>
> When true, sets the name of the file to be the name from
> 'external-contents'. Otherwise, you get the virtual path that the file
> was looked up by. This will not affect any non-virtual paths, or fully
> virtual paths (for which there is no reasonable 'external' name anyway).
>
> The setting is available globally, but can be overriden on a per-file
> basis.
>
> The goal is that this setting will control which path you see in debug
> info, diagnostics, etc. which are sensitive to which path is used. That
> will come in future patches that pass the name through to FileManager.
>
> Modified:
> cfe/trunk/include/clang/Basic/VirtualFileSystem.h
> cfe/trunk/lib/Basic/VirtualFileSystem.cpp
> cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp
>
> Modified: cfe/trunk/include/clang/Basic/VirtualFileSystem.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/VirtualFileSystem.h?rev=202329&r1=202328&r2=202329&view=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/VirtualFileSystem.h (original)
> +++ cfe/trunk/include/clang/Basic/VirtualFileSystem.h Wed Feb 26 18:25:12
> 2014
> @@ -29,7 +29,6 @@ namespace vfs {
>  /// \brief The result of a \p status operation.
>  class Status {
>std::string Name;
> -  std::string ExternalName;
>llvm::sys::fs::UniqueID UID;
>llvm::sys::TimeValue MTime;
>uint32_t User;
> @@ -46,16 +45,9 @@ public:
>   uint64_t Size, llvm::sys::fs::file_type Type,
>   llvm::sys::fs::perms Perms);
>
> -  /// \brief Returns the name this status was looked up by.
> +  /// \brief Returns the name that should be used for this file or
> directory.
>StringRef getName() const { return Name; }
> -
> -  /// \brief Returns the name to use outside the compiler.
> -  ///
> -  /// For example, in diagnostics or debug info we should use this name.
> -  StringRef getExternalName() const { return ExternalName; }
> -
>void setName(StringRef N) { Name = N; }
> -  void setExternalName(StringRef N) { ExternalName = N; }
>
>/// @name Status interface from llvm::sys::fs
>/// @{
>
> Modified: cfe/trunk/lib/Basic/VirtualFileSystem.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/VirtualFileSystem.cpp?rev=202329&r1=202328&r2=202329&view=diff
>
> ==
> --- cfe/trunk/lib/Basic/VirtualFileSystem.cpp (original)
> +++ cfe/trunk/lib/Basic/VirtualFileSystem.cpp Wed Feb 26 18:25:12 2014
> @@ -35,8 +35,8 @@ Status::Status(const file_status &Status
>  Status::Status(StringRef Name, StringRef ExternalName, UniqueID UID,
> sys::TimeValue MTime, uint32_t User, uint32_t Group,
> uint64_t Size, file_type Type, perms Perms)
> -: Name(Name), ExternalName(ExternalName), UID(UID), MTime(MTime),
> -  User(User), Group(Group), Size(Size), Type(Type), Perms(Perms) {}
> +: Name(Name), UID(UID), MTime(MTime), User(User), Group(Group),
> Size(Size),
> +  Type(Type), Perms(Perms) {}
>
>  bool Status::equivalent(const Status &Other) const {
>return getUniqueID() == Other.getUniqueID();
> @@ -145,7 +145,6 @@ ErrorOr RealFileSystem::status(c
>  return EC;
>Status Result(RealStatus);
>Result.setName(Path.str());
> -  Result.setExternalName(Path.str());
>return Result;
>  }
>
> @@ -253,12 +252,22 @@ public:
>  };
>
>  class FileEntry : public Entry {
> +public:
> +  enum NameKind {
> +NK_NotSet,
> +NK_External,
> +NK_Virtual
> +  };
> +private:
>std::string ExternalContentsPath;
> -
> +  NameKind UseName;
>  public:
> -  FileEntry(StringRef Name, StringRef ExternalContentsPath)
> -  : Entry(EK_File, Name), ExternalContentsPath(ExternalContentsPath)
> {}
> +  FileEntry(StringRef Name, StringRef ExternalContentsPath, NameKind
> UseName)
> +  : Entry(EK_File, Name), ExternalContentsPath(ExternalContentsPath),
> +UseName(UseName) {}
>StringRef getExternalContentsPath() const { return
> ExternalContentsPath; }
> +  /// \brief whether to use the external path as the name for this file.
> +  NameKind useName() const { return UseName; }
>static bool classof(const Entry *E) { return E->getKind() == EK_File; }
>  };
>
> @@ -280,6 +289,7 @@ public:
>  ///
>  /// All configuration options are optional.
>  ///   'case-sensitive': 
> +///   'use-external-names': 
>  ///
>  /// Virtual directories are represented as
>  /// \verbatim
> @@ -304,6 +314,7 @@ public:
>  /// {
>  ///   'type': 'file',
>  ///   'name': ,
> +///   'use-external-name':  # Optional
>  ///   'external-contents': )
>  /// }
>  /// \endverbatim
> @@ -324,14 +335,18 @@ class VFSFromYAML :

[PATCH] D22481: Allow negative lower bound in array sections based on pointers

[David S via cfe-commits]

davidsh created this revision.
davidsh added reviewers: carlo.bertolli, arpith-jacob, kkwli0, sfantao, ABataev.
davidsh added a subscriber: cfe-commits.

OpenMP 4.5 removed the restriction that array section lower bound must be non 
negative.
This change is to allow negative values for array section based on pointers.
For array section based on array type there is still a restriction: "The array 
section must be a subset of the original array."

https://reviews.llvm.org/D22481

Files:
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/Sema/SemaExpr.cpp
  test/OpenMP/target_depend_messages.cpp
  test/OpenMP/target_enter_data_depend_messages.cpp
  test/OpenMP/target_exit_data_depend_messages.cpp
  test/OpenMP/target_map_messages.cpp
  test/OpenMP/target_parallel_depend_messages.cpp
  test/OpenMP/target_parallel_for_depend_messages.cpp
  test/OpenMP/target_parallel_for_map_messages.cpp
  test/OpenMP/target_parallel_for_simd_depend_messages.cpp
  test/OpenMP/target_parallel_for_simd_map_messages.cpp
  test/OpenMP/target_parallel_map_messages.cpp
  test/OpenMP/target_update_depend_messages.cpp
  test/OpenMP/task_depend_messages.cpp

Index: test/OpenMP/task_depend_messages.cpp
===
--- test/OpenMP/task_depend_messages.cpp
+++ test/OpenMP/task_depend_messages.cpp
@@ -43,7 +43,7 @@
   #pragma omp task depend (in : argv[argc: // expected-error {{expected expression}} expected-error {{expected ']'}} expected-error {{expected ')'}} expected-note {{to match this '['}} expected-note {{to match this '('}}
   #pragma omp task depend (in : argv[argc:argc] // expected-error {{expected ')'}} expected-note {{to match this '('}}
   #pragma omp task depend (in : argv[0:-1]) // expected-error {{section length is evaluated to a negative value -1}}
-  #pragma omp task depend (in : argv[-1:0]) // expected-error {{section lower bound is evaluated to a negative value -1}}
+  #pragma omp task depend (in : argv[-1:0])
   #pragma omp task depend (in : argv[:]) // expected-error {{section length is unspecified and cannot be inferred because subscripted value is not an array}}
   #pragma omp task depend (in : argv[3:4:1]) // expected-error {{expected ']'}} expected-note {{to match this '['}}
   #pragma omp task depend(in:a[0:1]) // expected-error {{subscripted value is not an array or pointer}}
Index: test/OpenMP/target_update_depend_messages.cpp
===
--- test/OpenMP/target_update_depend_messages.cpp
+++ test/OpenMP/target_update_depend_messages.cpp
@@ -50,7 +50,7 @@
   #pragma omp target update to(z) depend(in : argv[argc: // expected-error {{expected expression}} expected-error {{expected ']'}} expected-error {{expected ')'}} expected-note {{to match this '['}} expected-note {{to match this '('}}
   #pragma omp target update to(z) depend(in : argv[argc:argc] // expected-error {{expected ')'}} expected-note {{to match this '('}}
   #pragma omp target update to(z) depend(in : argv[0:-1]) // expected-error {{section length is evaluated to a negative value -1}}
-  #pragma omp target update to(z) depend(in : argv[-1:0]) // expected-error {{section lower bound is evaluated to a negative value -1}}
+  #pragma omp target update to(z) depend(in : argv[-1:0])
   #pragma omp target update to(z) depend(in : argv[:]) // expected-error {{section length is unspecified and cannot be inferred because subscripted value is not an array}}
   #pragma omp target update to(z) depend(in : argv[3:4:1]) // expected-error {{expected ']'}} expected-note {{to match this '['}}
   #pragma omp target update to(z) depend(in:a[0:1]) // expected-error {{subscripted value is not an array or pointer}}
@@ -98,7 +98,7 @@
   #pragma omp target update to(z) depend(in : argv[argc: // expected-error {{expected expression}} expected-error {{expected ']'}} expected-error {{expected ')'}} expected-note {{to match this '['}} expected-note {{to match this '('}}
   #pragma omp target update to(z) depend(in : argv[argc:argc] // expected-error {{expected ')'}} expected-note {{to match this '('}}
   #pragma omp target update to(z) depend(in : argv[0:-1]) // expected-error {{section length is evaluated to a negative value -1}}
-  #pragma omp target update to(z) depend(in : argv[-1:0]) // expected-error {{section lower bound is evaluated to a negative value -1}}
+  #pragma omp target update to(z) depend(in : argv[-1:0])
   #pragma omp target update to(z) depend(in : argv[:]) // expected-error {{section length is unspecified and cannot be inferred because subscripted value is not an array}}
   #pragma omp target update to(z) depend(in : argv[3:4:1]) // expected-error {{expected ']'}} expected-note {{to match this '['}}
   #pragma omp target update to(z) depend(in:a[0:1]) // expected-error {{subscripted value is not an array or pointer}}
Index: test/OpenMP/target_parallel_map_messages.cpp
===
--- test/Op

r275924 - [Coverage] Remove '..' from filenames *after* getting an absolute path

[Vedant Kumar via cfe-commits]

Author: vedantk
Date: Mon Jul 18 17:32:02 2016
New Revision: 275924

URL: http://llvm.org/viewvc/llvm-project?rev=275924&view=rev
Log:
[Coverage] Remove '..' from filenames *after* getting an absolute path

Failure to do this breaks relative paths which begin with '..'.

This issue was caught by the (still nascent) coverage bot.

Modified:
cfe/trunk/lib/CodeGen/CoverageMappingGen.cpp
cfe/trunk/test/CoverageMapping/abspath.cpp

Modified: cfe/trunk/lib/CodeGen/CoverageMappingGen.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CoverageMappingGen.cpp?rev=275924&r1=275923&r2=275924&view=diff
==
--- cfe/trunk/lib/CodeGen/CoverageMappingGen.cpp (original)
+++ cfe/trunk/lib/CodeGen/CoverageMappingGen.cpp Mon Jul 18 17:32:02 2016
@@ -932,8 +932,8 @@ StringRef getCoverageSection(const CodeG
 
 std::string normalizeFilename(StringRef Filename) {
   llvm::SmallString<256> Path(Filename);
-  llvm::sys::path::remove_dots(Path, /*remove_dot_dots=*/true);
   llvm::sys::fs::make_absolute(Path);
+  llvm::sys::path::remove_dots(Path, /*remove_dot_dots=*/true);
   return Path.str().str();
 }
 

Modified: cfe/trunk/test/CoverageMapping/abspath.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CoverageMapping/abspath.cpp?rev=275924&r1=275923&r2=275924&view=diff
==
--- cfe/trunk/test/CoverageMapping/abspath.cpp (original)
+++ cfe/trunk/test/CoverageMapping/abspath.cpp Mon Jul 18 17:32:02 2016
@@ -1,7 +1,18 @@
-// RUN: %clang_cc1 -fprofile-instrument=clang -fcoverage-mapping -emit-llvm 
-main-file-name abspath.cpp %S/Inputs/../abspath.cpp -o - | FileCheck %s
+// This test requires mkdir.
+// REQUIRES: shell
+//
+// RUN: %clang_cc1 -fprofile-instrument=clang -fcoverage-mapping -emit-llvm 
-main-file-name abspath.cpp %S/Inputs/../abspath.cpp -o - | FileCheck 
-check-prefix=RMDOTS %s
 
-// CHECK: @__llvm_coverage_mapping = {{.*}}"\01
-// CHECK-NOT: Inputs
-// CHECK: "
+// RMDOTS: @__llvm_coverage_mapping = {{.*}}"\01
+// RMDOTS-NOT: Inputs
+// RMDOTS: "
+
+// RUN: cd %T && mkdir -p test && cd test
+// RUN: echo "void f1() {}" > f1.c
+// RUN: %clang_cc1 -fprofile-instrument=clang -fcoverage-mapping -emit-llvm 
-main-file-name abspath.cpp ../test/f1.c -o - | FileCheck -check-prefix=RELPATH 
%s
+
+// RELPATH: @__llvm_coverage_mapping = {{.*}}"\01
+// RELPATH: test{{.*}}f1.c
+// RELPATH: "
 
 void f1() {}


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

r275925 - Fix some minor issues found by Coverity.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Mon Jul 18 17:37:35 2016
New Revision: 275925

URL: http://llvm.org/viewvc/llvm-project?rev=275925&view=rev
Log:
Fix some minor issues found by Coverity.

Modified:
cfe/trunk/include/clang/AST/DeclCXX.h
cfe/trunk/lib/AST/ExprConstant.cpp
cfe/trunk/lib/AST/ItaniumMangle.cpp

Modified: cfe/trunk/include/clang/AST/DeclCXX.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclCXX.h?rev=275925&r1=275924&r2=275925&view=diff
==
--- cfe/trunk/include/clang/AST/DeclCXX.h (original)
+++ cfe/trunk/include/clang/AST/DeclCXX.h Mon Jul 18 17:37:35 2016
@@ -2964,7 +2964,9 @@ class ConstructorUsingShadowDecl final :
 }
   }
   ConstructorUsingShadowDecl(ASTContext &C, EmptyShell Empty)
-  : UsingShadowDecl(ConstructorUsingShadow, C, Empty) {}
+  : UsingShadowDecl(ConstructorUsingShadow, C, Empty),
+NominatedBaseClassShadowDecl(), ConstructedBaseClassShadowDecl(),
+IsVirtual(false) {}
 
 public:
   static ConstructorUsingShadowDecl *Create(ASTContext &C, DeclContext *DC,

Modified: cfe/trunk/lib/AST/ExprConstant.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ExprConstant.cpp?rev=275925&r1=275924&r2=275925&view=diff
==
--- cfe/trunk/lib/AST/ExprConstant.cpp (original)
+++ cfe/trunk/lib/AST/ExprConstant.cpp Mon Jul 18 17:37:35 2016
@@ -6872,6 +6872,8 @@ bool IntExprEvaluator::VisitCallExpr(con
   // Reduce it to a constant now.
   return Success((Type & 2) ? 0 : -1, E);
 }
+
+llvm_unreachable("unexpected EvalMode");
   }
 
   case Builtin::BI__builtin_bswap16:

Modified: cfe/trunk/lib/AST/ItaniumMangle.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ItaniumMangle.cpp?rev=275925&r1=275924&r2=275925&view=diff
==
--- cfe/trunk/lib/AST/ItaniumMangle.cpp (original)
+++ cfe/trunk/lib/AST/ItaniumMangle.cpp Mon Jul 18 17:37:35 2016
@@ -1471,7 +1471,7 @@ void CXXNameMangler::mangleLocalName(con
 // numbering will be local to the particular argument in which it appears
 // -- other default arguments do not affect its encoding.
 const CXXRecordDecl *CXXRD = dyn_cast(RD);
-if (CXXRD->isLambda()) {
+if (CXXRD && CXXRD->isLambda()) {
   if (const ParmVarDecl *Parm
   = dyn_cast_or_null(CXXRD->getLambdaContextDecl())) {
 if (const FunctionDecl *Func


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

Re: [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!

[Renato Golin via cfe-commits]

rengolin added inline comments.


Comment at: docs/Proposals/GitHub.rst:209
@@ +208,3 @@
+   well as a webhook to update the umbrella project (see below).
+3. Make sure we have an llvm-project (with submodules) setup in the official
+   account, with all necessary hooks (history, update, merges).

mehdi_amini wrote:
> > Pre-commit hooks
> 
> Won't handle the update of the umbrella.
> 
> > Post-commit hooks
> 
> Can't handle the update of the umbrella *because of GitHub*, this could be 
> possible with our own hosting of git for instance.
> 
Pre-commit hooks are not designed to update the umbrella. Webhooks will be able 
to update the umbrella with a small external service, as proposed in the IRC.


https://reviews.llvm.org/D22463



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

r275926 - [OpenMP] Fix incorrect diagnostics in map clause

[Kelvin Li via cfe-commits]

Author: kli
Date: Mon Jul 18 17:49:16 2016
New Revision: 275926

URL: http://llvm.org/viewvc/llvm-project?rev=275926&view=rev
Log:
[OpenMP] Fix incorrect diagnostics in map clause

Having the following code pattern will result in incorrect diagnostic

int main() {
  int arr[10];
#pragma omp target data map(arr[:])
#pragma omp target map(arr)
  {}
}

t.cpp:4:24: error: original storage of expression in data environment is shared
  but data environment do not fully contain mapped expression storage
#pragma omp target map(arr)
   ^~~
t.cpp:3:29: note: used here
#pragma omp target data map(arr[:])
^~
1 error generated.


Patch by David S.

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

Modified:
cfe/trunk/lib/Sema/SemaOpenMP.cpp
cfe/trunk/test/OpenMP/target_map_messages.cpp
cfe/trunk/test/OpenMP/target_parallel_for_map_messages.cpp
cfe/trunk/test/OpenMP/target_parallel_for_simd_map_messages.cpp
cfe/trunk/test/OpenMP/target_parallel_map_messages.cpp

Modified: cfe/trunk/lib/Sema/SemaOpenMP.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaOpenMP.cpp?rev=275926&r1=275925&r2=275926&view=diff
==
--- cfe/trunk/lib/Sema/SemaOpenMP.cpp (original)
+++ cfe/trunk/lib/Sema/SemaOpenMP.cpp Mon Jul 18 17:49:16 2016
@@ -10680,6 +10680,25 @@ static bool CheckMapConflicts(
   if (CI->getAssociatedDeclaration() != SI->getAssociatedDeclaration())
 break;
 }
+// Check if the extra components of the expressions in the enclosing
+// data environment are redundant for the current base declaration.
+// If they are, the maps completely overlap, which is legal.
+for (; SI != SE; ++SI) {
+  QualType Type;
+  if (auto *ASE =
+  dyn_cast(SI->getAssociatedExpression())) {
+Type = ASE->getBase()->IgnoreParenImpCasts()->getType();
+  } else if (auto *OASE =
+  dyn_cast(SI->getAssociatedExpression())) {
+auto *E = OASE->getBase()->IgnoreParenImpCasts();
+Type =
+OMPArraySectionExpr::getBaseOriginalType(E).getCanonicalType();
+  }
+  if (Type.isNull() || Type->isAnyPointerType() ||
+  CheckArrayExpressionDoesNotReferToWholeSize(
+  SemaRef, SI->getAssociatedExpression(), Type))
+break;
+}
 
 // OpenMP 4.5 [2.15.5.1, map Clause, Restrictions, p.4]
 //  List items of map clauses in the same construct must not share

Modified: cfe/trunk/test/OpenMP/target_map_messages.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/target_map_messages.cpp?rev=275926&r1=275925&r2=275926&view=diff
==
--- cfe/trunk/test/OpenMP/target_map_messages.cpp (original)
+++ cfe/trunk/test/OpenMP/target_map_messages.cpp Mon Jul 18 17:49:16 2016
@@ -284,6 +284,11 @@ void SAclient(int arg) {
 {}
   }
   }
+  #pragma omp target data map(marr[:][:][:])
+  {
+#pragma omp target data map(marr)
+{}
+  }
 
   #pragma omp target data map(to: t)
   {
@@ -419,10 +424,10 @@ T tmain(T argc) {
 #pragma omp target data map(j)
 #pragma omp target map(l) map(l[:5]) // expected-error 2 {{variable already 
marked as mapped in current construct}} expected-note 2 {{used here}}
   foo();
-#pragma omp target data map(k[:4], j, l[:5]) // expected-note 4 {{used here}}
+#pragma omp target data map(k[:4], j, l[:5]) // expected-note 2 {{used here}}
 #pragma omp target data map(k) // expected-error 2 {{pointer cannot be mapped 
along with a section derived from itself}}
 #pragma omp target data map(j)
-#pragma omp target map(l) // expected-error 2 {{original storage of expression 
in data environment is shared but data environment do not fully contain mapped 
expression storage}}
+#pragma omp target map(l)
   foo();
 
 #pragma omp target data map(always, tofrom: x)
@@ -488,10 +493,10 @@ int main(int argc, char **argv) {
 #pragma omp target data map(j)
 #pragma omp target map(l) map(l[:5]) // expected-error {{variable already 
marked as mapped in current construct}} expected-note {{used here}}
   foo();
-#pragma omp target data map(k[:4], j, l[:5]) // expected-note 2 {{used here}}
+#pragma omp target data map(k[:4], j, l[:5]) // expected-note {{used here}}
 #pragma omp target data map(k) // expected-error {{pointer cannot be mapped 
along with a section derived from itself}}
 #pragma omp target data map(j)
-#pragma omp target map(l) // expected-error {{original storage of expression 
in data environment is shared but data environment do not fully contain mapped 
expression storage}}
+#pragma omp target map(l)
   foo();
 
 #pragma omp target data map(always, tofrom: x)

Modified: cfe/trunk/test/OpenMP/target_parallel_for_map_messages.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk

Re: [PATCH] D22075: [OpenMP] Fix incorrect diagnostics in map clause

[Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL275926: [OpenMP] Fix incorrect diagnostics in map clause 
(authored by kli).

Changed prior to commit:
  https://reviews.llvm.org/D22075?vs=64353&id=64410#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D22075

Files:
  cfe/trunk/lib/Sema/SemaOpenMP.cpp
  cfe/trunk/test/OpenMP/target_map_messages.cpp
  cfe/trunk/test/OpenMP/target_parallel_for_map_messages.cpp
  cfe/trunk/test/OpenMP/target_parallel_for_simd_map_messages.cpp
  cfe/trunk/test/OpenMP/target_parallel_map_messages.cpp

Index: cfe/trunk/test/OpenMP/target_parallel_for_simd_map_messages.cpp
===
--- cfe/trunk/test/OpenMP/target_parallel_for_simd_map_messages.cpp
+++ cfe/trunk/test/OpenMP/target_parallel_for_simd_map_messages.cpp
@@ -143,13 +143,13 @@
   for (i = 0; i < argc; ++i) foo();
 #pragma omp target parallel for simd map(l) map(l[:5]) // expected-error 2 {{variable already marked as mapped in current construct}} expected-note 2 {{used here}}
   for (i = 0; i < argc; ++i) foo();
-#pragma omp target data map(k[:4], j, l[:5]) // expected-note 4 {{used here}}
+#pragma omp target data map(k[:4], j, l[:5]) // expected-note 2 {{used here}}
 {
 #pragma omp target parallel for simd map(k) // expected-error 2 {{pointer cannot be mapped along with a section derived from itself}}
   for (i = 0; i < argc; ++i) foo();
 #pragma omp target parallel for simd map(j)
   for (i = 0; i < argc; ++i) foo();
-#pragma omp target parallel for simd map(l) // expected-error 2 {{original storage of expression in data environment is shared but data environment do not fully contain mapped expression storage}}
+#pragma omp target parallel for simd map(l)
   for (i = 0; i < argc; ++i) foo();
 }
 
@@ -247,13 +247,13 @@
   for (i = 0; i < argc; ++i) foo();
 #pragma omp target parallel for simd map(l) map(l[:5]) // expected-error 1 {{variable already marked as mapped in current construct}} expected-note 1 {{used here}}
   for (i = 0; i < argc; ++i) foo();
-#pragma omp target data map(k[:4], j, l[:5]) // expected-note 2 {{used here}}
+#pragma omp target data map(k[:4], j, l[:5]) // expected-note {{used here}}
 {
 #pragma omp target parallel for simd map(k) // expected-error {{pointer cannot be mapped along with a section derived from itself}}
   for (i = 0; i < argc; ++i) foo();
 #pragma omp target parallel for simd map(j)
   for (i = 0; i < argc; ++i) foo();
-#pragma omp target parallel for simd map(l) // expected-error {{original storage of expression in data environment is shared but data environment do not fully contain mapped expression storage}}
+#pragma omp target parallel for simd map(l)
   for (i = 0; i < argc; ++i) foo();
 }
 
Index: cfe/trunk/test/OpenMP/target_parallel_map_messages.cpp
===
--- cfe/trunk/test/OpenMP/target_parallel_map_messages.cpp
+++ cfe/trunk/test/OpenMP/target_parallel_map_messages.cpp
@@ -143,13 +143,13 @@
   foo();
 #pragma omp target parallel map(l) map(l[:5]) // expected-error 2 {{variable already marked as mapped in current construct}} expected-note 2 {{used here}}
   foo();
-#pragma omp target data map(k[:4], j, l[:5]) // expected-note 4 {{used here}}
+#pragma omp target data map(k[:4], j, l[:5]) // expected-note 2 {{used here}}
 {
 #pragma omp target parallel map(k) // expected-error 2 {{pointer cannot be mapped along with a section derived from itself}}
   foo();
 #pragma omp target parallel map(j)
   foo();
-#pragma omp target parallel map(l) // expected-error 2 {{original storage of expression in data environment is shared but data environment do not fully contain mapped expression storage}}
+#pragma omp target parallel map(l)
   foo();
 }
 
@@ -246,13 +246,13 @@
   foo();
 #pragma omp target parallel map(l) map(l[:5]) // expected-error 1 {{variable already marked as mapped in current construct}} expected-note 1 {{used here}}
   foo();
-#pragma omp target data map(k[:4], j, l[:5]) // expected-note 2 {{used here}}
+#pragma omp target data map(k[:4], j, l[:5]) // expected-note 1 {{used here}}
 {
 #pragma omp target parallel map(k) // expected-error {{pointer cannot be mapped along with a section derived from itself}}
   foo();
 #pragma omp target parallel map(j)
   foo();
-#pragma omp target parallel map(l) // expected-error {{original storage of expression in data environment is shared but data environment do not fully contain mapped expression storage}}
+#pragma omp target parallel map(l)
   foo();
 }
 
Index: cfe/trunk/test/OpenMP/target_map_messages.cpp
===
--- cfe/trunk/test/OpenMP/target_map_messages.cpp
+++ cfe/trunk/test/OpenMP/target_map_messages.cpp
@@ -284,6 +284,11 @@
 {}
   }
   }
+  #pragma omp target data map(marr[:][:][:])
+  {
+#pragma omp target data map(marr)
+{}
+  }
 
   #pragma omp target data map(to: t)
   {
@@ -419,1

Re: [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!

[Chris Lattner via cfe-commits]

lattner added a subscriber: lattner.
lattner added a comment.

Please send this to llvm-dev for discussion when it converges, thanks!


https://reviews.llvm.org/D22463



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

r275930 - [OpenMP] Remove dead code in conditional of mappable expressions SEMA.

[Samuel Antao via cfe-commits]

Author: sfantao
Date: Mon Jul 18 18:22:11 2016
New Revision: 275930

URL: http://llvm.org/viewvc/llvm-project?rev=275930&view=rev
Log:
[OpenMP] Remove dead code in conditional of mappable expressions SEMA. 

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

Modified: cfe/trunk/lib/Sema/SemaOpenMP.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaOpenMP.cpp?rev=275930&r1=275929&r2=275930&view=diff
==
--- cfe/trunk/lib/Sema/SemaOpenMP.cpp (original)
+++ cfe/trunk/lib/Sema/SemaOpenMP.cpp Mon Jul 18 18:22:11 2016
@@ -10574,16 +10574,16 @@ static Expr *CheckMapClauseExpressionBas
   bool NotUnity =
   CheckArrayExpressionDoesNotReferToUnitySize(SemaRef, CurE, CurType);
 
-  if (AllowWholeSizeArraySection && AllowUnitySizeArraySection) {
-// Any array section is currently allowed.
+  if (AllowWholeSizeArraySection) {
+// Any array section is currently allowed. Allowing a whole size array
+// section implies allowing a unity array section as well.
 //
 // If this array section refers to the whole dimension we can still
 // accept other array sections before this one, except if the base is a
 // pointer. Otherwise, only unitary sections are accepted.
 if (NotWhole || IsPointer)
   AllowWholeSizeArraySection = false;
-  } else if ((AllowUnitySizeArraySection && NotUnity) ||
- (AllowWholeSizeArraySection && NotWhole)) {
+  } else if (AllowUnitySizeArraySection && NotUnity) {
 // A unity or whole array section is not allowed and that is not
 // compatible with the properties of the current array section.
 SemaRef.Diag(


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

Re: r263019 - [OpenMP] Add support for multidimensional array sections in map clause SEMA.

[Samuel F Antao via cfe-commits]

Hi Richard,
 
Thanks for catching that! Fixed in r275930.
 
Thanks again,
Samuel
 
- Original message -From: Richard Smith Sent by: meta...@gmail.comTo: Samuel F Antao/Watson/IBM@IBMUSCc: cfe-commits Subject: Re: r263019 - [OpenMP] Add support for multidimensional array sections in map clause SEMA.Date: Mon, Jul 18, 2016 6:03 PM 
On Wed, Mar 9, 2016 at 7:46 AM, Samuel Antao via cfe-commits  wrote:

Author: sfantaoDate: Wed Mar  9 09:46:05 2016New Revision: 263019URL: http://llvm.org/viewvc/llvm-project?rev=263019&view=revLog:[OpenMP] Add support for multidimensional array sections in map clause SEMA.Summary: In some cases it can be proved statically that multidimensional array section refer to contiguous storage and can therefore be allowed in a map clause. This patch adds support for those cases in SEMA.Reviewers: hfinkel, carlo.bertolli, arpith-jacob, kkwli0, ABataevSubscribers: cfe-commits, fraggamuffin, caomhinDifferential Revision: http://reviews.llvm.org/D17547Modified:    cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td    cfe/trunk/lib/Sema/SemaOpenMP.cpp    cfe/trunk/test/OpenMP/target_map_messages.cppModified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.tdURL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=263019&r1=263018&r2=263019&view=diff==--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Wed Mar  9 09:46:05 2016@@ -7825,8 +7825,8 @@ def err_omp_expected_named_var_member_or   "expected _expression_ containing only member accesses and/or array sections based on named variables">; def err_omp_bit_fields_forbidden_in_map_clause : Error<   "bit fields cannot be used to specify storage in a map clause">;-def err_omp_array_section_in_rightmost_expression : Error<-  "array section can only be associated with the rightmost variable in a map clause _expression_">;+def err_array_section_does_not_specify_contiguous_storage : Error<+  "array section does not specify contiguous storage">; def err_omp_union_type_not_allowed : Error<   "mapped storage cannot be derived from a union">; def err_omp_expected_access_to_data_field : ErrorgetColonLoc().isInvalid())) {+    if (auto *ATy = dyn_cast(BaseQTy.getTypePtr()))+      return ATy->getSize().getSExtValue() != 1;+    // Size can't be evaluated statically.+    return false;+  }++  assert(OASE && "Expecting array section if not an array subscript.");+  auto *LowerBound = OASE->getLowerBound();+  auto *Length = OASE->getLength();++  // If there is a lower bound that does not evaluates to zero, we are not+  // convering the whole dimension.+  if (LowerBound) {+    llvm::APSInt ConstLowerBound;+    if (!LowerBound->EvaluateAsInt(ConstLowerBound, SemaRef.getASTContext()))+      return false; // Can't get the integer value as a constant.+    if (ConstLowerBound.getSExtValue())+      return true;+  }++  // If we don't have a length we covering the whole dimension.+  if (!Length)+    return false;++  // If the base is a pointer, we don't have a way to get the size of the+  // pointee.+  if (BaseQTy->isPointerType())+    return false;++  // We can only check if the length is the same as the size of the dimension+  // if we have a constant array.+  auto *CATy = dyn_cast(BaseQTy.getTypePtr());+  if (!CATy)+    return false;++  llvm::APSInt ConstLength;+  if (!Length->EvaluateAsInt(ConstLength, SemaRef.getASTContext()))+    return false; // Can't get the integer value as a constant.++  return CATy->getSize().getSExtValue() != ConstLength.getSExtValue();+}++// Return true if it can be proven that the provided array _expression_ (array+// section or array subscript) does NOT specify a single element of the array+// whose base type is \a Ba

Re: [PATCH] D21954: [PM] Add some internal options for testing out the new PM.

[Sean Silva via cfe-commits]

silvas updated this revision to Diff 64420.
silvas added a comment.

Rebase after r275507.


https://reviews.llvm.org/D21954

Files:
  include/clang/Driver/CC1Options.td
  include/clang/Frontend/CodeGenOptions.h
  lib/CodeGen/BackendUtil.cpp
  lib/CodeGen/CMakeLists.txt
  lib/Frontend/CompilerInvocation.cpp
  test/CodeGen/middle-end-passes.c

Index: test/CodeGen/middle-end-passes.c
===
--- /dev/null
+++ test/CodeGen/middle-end-passes.c
@@ -0,0 +1,26 @@
+// Check that passes get run.
+
+// RUN: %clang_cc1 %s -emit-llvm -o /dev/null -middle-end-passes=mem2reg,aa-eval 2>&1 | FileCheck %s --check-prefix=NO-AA
+
+// NO-AA: = Alias Analysis Evaluator Report =
+// NO-AA: 0 must alias responses
+
+// RUN: %clang_cc1 %s -emit-llvm -o /dev/null -middle-end-passes=mem2reg,aa-eval -middle-end-aa-pipeline=basic-aa 2>&1 | FileCheck %s --check-prefix=WITH-AA
+
+// WITH-AA: = Alias Analysis Evaluator Report =
+// WITH-AA: 1 must alias responses
+
+
+// The actual output with -flto or -emit-llvm is generated by running a
+// pass in the old PM. Verify that that we still get output.
+
+// RUN: %clang -flto -c %s -o - -Xclang -middle-end-passes=mem2reg 2>&1 | opt -S | FileCheck %s --check-prefix=OUTPUT-IS-GENERATED
+// RUN: %clang -emit-llvm -S %s -o - -Xclang -middle-end-passes=mem2reg 2>&1 | FileCheck %s --check-prefix=OUTPUT-IS-GENERATED
+
+// OUTPUT-IS-GENERATED: @foo
+
+int foo(int *x) {
+  int *y = x + 1;
+  int *z = y - 1;
+  return *x + *z;
+}
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -845,6 +845,11 @@
   Opts.EmitCheckPathComponentsToStrip = getLastArgIntValue(
   Args, OPT_fsanitize_undefined_strip_path_components_EQ, 0, Diags);
 
+  if (Arg *A = Args.getLastArg(OPT_middle_end_passes_EQ))
+Opts.MiddleEndPasses = A->getValue();
+  if (Arg *A = Args.getLastArg(OPT_middle_end_aa_pipeline_EQ))
+Opts.MiddleEndAAPipeline = A->getValue();
+
   return Success;
 }
 
Index: lib/CodeGen/CMakeLists.txt
===
--- lib/CodeGen/CMakeLists.txt
+++ lib/CodeGen/CMakeLists.txt
@@ -12,6 +12,7 @@
   MC
   ObjCARCOpts
   Object
+  Passes
   ProfileData
   ScalarOpts
   Support
Index: lib/CodeGen/BackendUtil.cpp
===
--- lib/CodeGen/BackendUtil.cpp
+++ lib/CodeGen/BackendUtil.cpp
@@ -31,6 +31,7 @@
 #include "llvm/IR/Verifier.h"
 #include "llvm/MC/SubtargetFeature.h"
 #include "llvm/Object/ModuleSummaryIndexObjectFile.h"
+#include "llvm/Passes/PassBuilder.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/PrettyStackTrace.h"
 #include "llvm/Support/TargetRegistry.h"
@@ -643,6 +644,43 @@
   return true;
 }
 
+static void runMiddleEndPasses(Module &M, TargetMachine *TM, StringRef Passes,
+   StringRef AAPipeline) {
+  // This is a really low-level internal developer option.
+  // Use report_fatal_error if anything goes wrong.
+
+  PassBuilder PB(TM);
+  AAManager AA;
+  if (!PB.parseAAPipeline(AA, AAPipeline))
+report_fatal_error("Unable to parse AA pipeline description: " +
+   AAPipeline);
+
+  LoopAnalysisManager LAM;
+  FunctionAnalysisManager FAM;
+  CGSCCAnalysisManager CGAM;
+  ModuleAnalysisManager MAM;
+
+  // Register the AA manager first so that our version is the one used.
+  FAM.registerPass([&] { return std::move(AA); });
+
+  // Register all the basic analyses with the managers.
+  PB.registerModuleAnalyses(MAM);
+  PB.registerCGSCCAnalyses(CGAM);
+  PB.registerFunctionAnalyses(FAM);
+  PB.registerLoopAnalyses(LAM);
+  PB.crossRegisterProxies(LAM, FAM, CGAM, MAM);
+
+  ModulePassManager MPM;
+  MPM.addPass(VerifierPass());
+
+  // Now, add all the passes we've been requested to.
+  if (!PB.parsePassPipeline(MPM, Passes))
+report_fatal_error("Unable to parse pass pipeline description: " + Passes);
+
+  MPM.addPass(VerifierPass());
+  MPM.run(M, MAM);
+}
+
 void EmitAssemblyHelper::EmitAssembly(BackendAction Action,
   std::unique_ptr OS) {
   TimeRegion Region(llvm::TimePassesIsEnabled ? &CodeGenerationTime : nullptr);
@@ -687,7 +725,11 @@
   PerFunctionPasses.add(
   createTargetTransformInfoWrapperPass(getTargetIRAnalysis()));
 
-  CreatePasses(PerModulePasses, PerFunctionPasses, ModuleSummary.get());
+  bool UseCustomMiddleEndPasses = !CodeGenOpts.MiddleEndPasses.empty();
+  // If we are going to use a custom middle-end pass pipeline, don't add
+  // any of the usual passes.
+  if (!UseCustomMiddleEndPasses)
+CreatePasses(PerModulePasses, PerFunctionPasses, ModuleSummary.get());
 
   legacy::PassManager CodeGenPasses;
   CodeGenPasses.add(
@@ -716,6 +758,18 @@
   // Before executing passes, print the final values of the LLVM options.
   cl::PrintOpti

Re: [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!

[Dan Liew via cfe-commits]

delcypher added a subscriber: delcypher.


Comment at: docs/Proposals/GitHub.rst:102
@@ +101,3 @@
+
+How will the new workflow look like
+===

s/How will/What will/


Comment at: docs/Proposals/GitHub.rst:136
@@ +135,3 @@
+
+We will need additional server hooks to avoid non-fast-forwards commits (ex.
+merges, forced pushes, etc) in order to keep the linearity of the history.

@rengolin : I know GitHub enterprise has a "protected branch" feature to 
prevent forced pushed ( 
https://github.com/blog/2051-protected-branches-and-required-status-checks ). 
You might want to speak to them to see if they can offer us that feature. I 
think there's a limited support to do a merge as a squash and rebase too ( 
https://github.com/blog/2141-squash-your-commits )


Comment at: docs/Proposals/GitHub.rst:233
@@ +232,3 @@
+
+10. Collect peoples GitHub account information, adding them to the project.
+11. Switch SVN repository to read-only and allow pushes to the GitHub 
repository.

GitHub organizations support the notion of teams which can each have different 
permissions (for example you'll want to make sure only the right people have 
admin access and give the rest write/read access). You could also make a team 
per project so that write access in one project does not give write access to 
another. I think it would be good to decide on how teams will be organized and 
state this in the document.


https://reviews.llvm.org/D22463



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

[PATCH] D22487: [OpenMP] Ignore parens in atomic capture

[David S via cfe-commits]

davidsh created this revision.
davidsh added reviewers: carlo.bertolli, arpith-jacob, kkwli0, sfantao, ABataev.
davidsh added a subscriber: cfe-commits.

Clang misdiagnoses atomic captures cases that contains parens.
ie.
int v, int *p;
#pragma omp atomic capture
{ v = (*p); (*p)++; }

https://reviews.llvm.org/D22487

Files:
  lib/Sema/SemaOpenMP.cpp
  test/OpenMP/atomic_messages.c
  test/OpenMP/atomic_messages.cpp

Index: test/OpenMP/atomic_messages.cpp
===
--- test/OpenMP/atomic_messages.cpp
+++ test/OpenMP/atomic_messages.cpp
@@ -453,14 +453,18 @@
 #pragma omp atomic capture
   {c = a; a++;}
 #pragma omp atomic capture
+  {c = a; (a)++;}
+#pragma omp atomic capture
   {++a;c = a;}
 #pragma omp atomic capture
   {c = a;a--;}
 #pragma omp atomic capture
   {--a;c = a;}
 #pragma omp atomic capture
   {c = a; a += b;}
 #pragma omp atomic capture
+  {c = a; (a) += b;}
+#pragma omp atomic capture
   {a %= b; c = a;}
 #pragma omp atomic capture
   {c = a; a *= b;}
Index: test/OpenMP/atomic_messages.c
===
--- test/OpenMP/atomic_messages.c
+++ test/OpenMP/atomic_messages.c
@@ -313,14 +313,18 @@
 #pragma omp atomic capture
   {c = a; a++;}
 #pragma omp atomic capture
+  {c = a; (a)++;}
+#pragma omp atomic capture
   {++a;c = a;}
 #pragma omp atomic capture
   {c = a;a--;}
 #pragma omp atomic capture
   {--a;c = a;}
 #pragma omp atomic capture
   {c = a; a += b;}
 #pragma omp atomic capture
+  {c = a; (a) += b;}
+#pragma omp atomic capture
   {a %= b; c = a;}
 #pragma omp atomic capture
   {c = a; a *= b;}
Index: lib/Sema/SemaOpenMP.cpp
===
--- lib/Sema/SemaOpenMP.cpp
+++ lib/Sema/SemaOpenMP.cpp
@@ -6169,7 +6169,7 @@
 AtomicCompAssignOp->getOpcode());
 OpLoc = AtomicCompAssignOp->getOperatorLoc();
 E = AtomicCompAssignOp->getRHS();
-X = AtomicCompAssignOp->getLHS();
+X = AtomicCompAssignOp->getLHS()->IgnoreParens();
 IsXLHSInRHSPart = true;
   } else if (auto *AtomicBinOp = dyn_cast(
  AtomicBody->IgnoreParenImpCasts())) {
@@ -6183,7 +6183,7 @@
   IsPostfixUpdate = AtomicUnaryOp->isPostfix();
   Op = AtomicUnaryOp->isIncrementOp() ? BO_Add : BO_Sub;
   OpLoc = AtomicUnaryOp->getOperatorLoc();
-  X = AtomicUnaryOp->getSubExpr();
+  X = AtomicUnaryOp->getSubExpr()->IgnoreParens();
   E = SemaRef.ActOnIntegerConstant(OpLoc, /*uint64_t Val=*/1).get();
   IsXLHSInRHSPart = true;
 } else {


Index: test/OpenMP/atomic_messages.cpp
===
--- test/OpenMP/atomic_messages.cpp
+++ test/OpenMP/atomic_messages.cpp
@@ -453,14 +453,18 @@
 #pragma omp atomic capture
   {c = a; a++;}
 #pragma omp atomic capture
+  {c = a; (a)++;}
+#pragma omp atomic capture
   {++a;c = a;}
 #pragma omp atomic capture
   {c = a;a--;}
 #pragma omp atomic capture
   {--a;c = a;}
 #pragma omp atomic capture
   {c = a; a += b;}
 #pragma omp atomic capture
+  {c = a; (a) += b;}
+#pragma omp atomic capture
   {a %= b; c = a;}
 #pragma omp atomic capture
   {c = a; a *= b;}
Index: test/OpenMP/atomic_messages.c
===
--- test/OpenMP/atomic_messages.c
+++ test/OpenMP/atomic_messages.c
@@ -313,14 +313,18 @@
 #pragma omp atomic capture
   {c = a; a++;}
 #pragma omp atomic capture
+  {c = a; (a)++;}
+#pragma omp atomic capture
   {++a;c = a;}
 #pragma omp atomic capture
   {c = a;a--;}
 #pragma omp atomic capture
   {--a;c = a;}
 #pragma omp atomic capture
   {c = a; a += b;}
 #pragma omp atomic capture
+  {c = a; (a) += b;}
+#pragma omp atomic capture
   {a %= b; c = a;}
 #pragma omp atomic capture
   {c = a; a *= b;}
Index: lib/Sema/SemaOpenMP.cpp
===
--- lib/Sema/SemaOpenMP.cpp
+++ lib/Sema/SemaOpenMP.cpp
@@ -6169,7 +6169,7 @@
 AtomicCompAssignOp->getOpcode());
 OpLoc = AtomicCompAssignOp->getOperatorLoc();
 E = AtomicCompAssignOp->getRHS();
-X = AtomicCompAssignOp->getLHS();
+X = AtomicCompAssignOp->getLHS()->IgnoreParens();
 IsXLHSInRHSPart = true;
   } else if (auto *AtomicBinOp = dyn_cast(
  AtomicBody->IgnoreParenImpCasts())) {
@@ -6183,7 +6183,7 @@
   IsPostfixUpdate = AtomicUnaryOp->isPostfix();
   Op = AtomicUnaryOp->isIncrementOp() ? BO_Add : BO_Sub;
   OpLoc = AtomicUnaryOp->getOperatorLoc();
-  X = AtomicUnaryOp->getSubExpr();
+  X = AtomicUnaryOp->getSubExpr()->IgnoreParens();
   E = SemaRef.ActOnIntegerConstant(OpLoc, /*uint64_t Val=*/1).get();
   IsXLHSInRHSPart = true;
 } else {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.or

Re: [PATCH] D20168: [CodeGen] Handle structs directly in AMDGPUABIInfo

[Vedran Miletić via cfe-commits]

rivanvx updated this revision to Diff 64417.
rivanvx added a comment.

Specifically handle only kernels.


https://reviews.llvm.org/D20168

Files:
  lib/CodeGen/TargetInfo.cpp
  test/CodeGenOpenCL/amdgpu-abi-struct-coerce.cl

Index: test/CodeGenOpenCL/amdgpu-abi-struct-coerce.cl
===
--- /dev/null
+++ test/CodeGenOpenCL/amdgpu-abi-struct-coerce.cl
@@ -0,0 +1,65 @@
+// REQUIRES: amdgpu-registered-target
+// RUN: %clang_cc1 -triple amdgcn-unknown-unknown -S -emit-llvm -o - %s | FileCheck %s
+
+// CHECK-NOT: %struct.single_element_struct_arg = type { i32 }
+typedef struct single_element_struct_arg
+{
+int i;
+} single_element_struct_arg_t;
+
+// CHECK: %struct.struct_arg = type { i32, float, i32 }
+typedef struct struct_arg
+{
+int i1;
+float f;
+int i2;
+} struct_arg_t;
+
+// CHECK: %struct.struct_of_arrays_arg = type { [2 x i32], float, [4 x i32], [3 x float], i32 }
+typedef struct struct_of_arrays_arg
+{
+int i1[2];
+float f1;
+int i2[4];
+float f2[3];
+int i3;
+} struct_of_arrays_arg_t;
+
+// CHECK: %struct.struct_of_structs_arg = type { i32, float, %struct.struct_arg, i32 }
+typedef struct struct_of_structs_arg
+{
+int i1;
+float f1;
+struct_arg_t s1;
+int i2;
+} struct_of_structs_arg_t;
+
+// CHECK-LABEL: @test_single_element_struct_arg
+// CHECK: i32 %arg1.coerce
+__kernel void test_single_element_struct_arg(single_element_struct_arg_t arg1)
+{
+}
+
+// CHECK-LABEL: @test_struct_arg
+// CHECK: %struct.struct_arg %arg1.coerce
+__kernel void test_struct_arg(struct_arg_t arg1)
+{
+}
+
+// CHECK-LABEL: @test_struct_of_arrays_arg
+// CHECK: %struct.struct_of_arrays_arg %arg1.coerce
+__kernel void test_struct_of_arrays_arg(struct_of_arrays_arg_t arg1)
+{
+}
+
+// CHECK-LABEL: @test_struct_of_structs_arg
+// CHECK: %struct.struct_of_structs_arg %arg1.coerce
+__kernel void test_struct_of_structs_arg(struct_of_structs_arg_t arg1)
+{
+}
+
+// CHECK-LABEL: @test_non_kernel_struct_arg
+// CHECK-NOT: %struct.struct_arg %arg1.coerce
+void test_non_kernel_struct_arg(struct_arg_t arg1)
+{
+}
Index: lib/CodeGen/TargetInfo.cpp
===
--- lib/CodeGen/TargetInfo.cpp
+++ lib/CodeGen/TargetInfo.cpp
@@ -6825,10 +6825,49 @@
 
 namespace {
 
+class AMDGPUABIInfo final : public DefaultABIInfo {
+public:
+  explicit AMDGPUABIInfo(CodeGen::CodeGenTypes &CGT) : DefaultABIInfo(CGT) {}
+
+private:
+  ABIArgInfo classifyArgumentType(QualType Ty) const;
+
+  void computeInfo(CGFunctionInfo &FI) const override;
+};
+
+void AMDGPUABIInfo::computeInfo(CGFunctionInfo &FI) const {
+  if (!getCXXABI().classifyReturnType(FI))
+FI.getReturnInfo() = classifyReturnType(FI.getReturnType());
+
+  const unsigned CC = FI.getCallingConvention();
+  for (auto &Arg : FI.arguments())
+if (CC == llvm::CallingConv::AMDGPU_KERNEL)
+  Arg.info = classifyArgumentType(Arg.type);
+else
+  Arg.info = DefaultABIInfo::classifyArgumentType(Arg.type);
+}
+
+/// \brief Classify argument of given type \p Ty.
+ABIArgInfo AMDGPUABIInfo::classifyArgumentType(QualType Ty) const {
+  llvm::StructType *StrTy = dyn_cast(CGT.ConvertType(Ty));
+  if (!StrTy) {
+return DefaultABIInfo::classifyArgumentType(Ty);
+  }
+  else if (StrTy->getNumElements() == 1) {
+// Coerce single element structs to its element.
+return ABIArgInfo::getDirect();
+  }
+
+  // If we set CanBeFlattened to true, CodeGen will expand the struct to its
+  // individual elements, which confuses the Clover OpenCL backend; therefore we
+  // have to set it to false here. Other args of getDirect() are just defaults.
+  return ABIArgInfo::getDirect(nullptr, 0, nullptr, false);
+}
+
 class AMDGPUTargetCodeGenInfo : public TargetCodeGenInfo {
 public:
   AMDGPUTargetCodeGenInfo(CodeGenTypes &CGT)
-: TargetCodeGenInfo(new DefaultABIInfo(CGT)) {}
+: TargetCodeGenInfo(new AMDGPUABIInfo(CGT)) {}
   void setTargetAttributes(const Decl *D, llvm::GlobalValue *GV,
CodeGen::CodeGenModule &M) const override;
   unsigned getOpenCLKernelCallingConv() const override;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D22490: Append clang system include path for offloading tool chains.

[Samuel Antao via cfe-commits]

sfantao created this revision.
sfantao added reviewers: tra, rsmith.
sfantao added subscribers: cfe-commits, rsmith.

This patch adds clang system include path when offloading tool chains, e.g. 
CUDA, are used in the current compilation.

This fixes an issue detected by @rsmith in response to r275645.

https://reviews.llvm.org/D22490

Files:
  lib/Driver/Tools.cpp

Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -314,6 +314,24 @@
   // TODO: Add support for other programming models here.
 }
 
+/// Add the C include args of other offloading toolchains. If this is a host
+/// job, the device toolchains are added. If this is a device job, the host
+/// toolchains will be added.
+static void addExtraOffloadClangSystemIncludeArgs(Compilation &C,
+  const JobAction &JA,
+  const ArgList &Args,
+  ArgStringList &CmdArgs) {
+
+  if (JA.isHostOffloading(Action::OFK_Cuda))
+C.getSingleOffloadToolChain()->AddClangSystemIncludeArgs(
+Args, CmdArgs);
+  else if (JA.isDeviceOffloading(Action::OFK_Cuda))
+C.getSingleOffloadToolChain()->AddClangSystemIncludeArgs(
+Args, CmdArgs);
+
+  // TODO: Add support for other programming models here.
+}
+
 /// Add the include args that are specific of each offloading programming 
model.
 static void addExtraOffloadSpecificIncludeArgs(Compilation &C,
const JobAction &JA,
@@ -612,7 +630,7 @@
   // Add system include arguments for all targets but IAMCU.
   if (!IsIAMCU) {
 getToolChain().AddClangSystemIncludeArgs(Args, CmdArgs);
-addExtraOffloadCXXStdlibIncludeArgs(C, JA, Args, CmdArgs);
+addExtraOffloadClangSystemIncludeArgs(C, JA, Args, CmdArgs);
   } else {
 // For IAMCU add special include arguments.
 getToolChain().AddIAMCUIncludeArgs(Args, CmdArgs);


Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -314,6 +314,24 @@
   // TODO: Add support for other programming models here.
 }
 
+/// Add the C include args of other offloading toolchains. If this is a host
+/// job, the device toolchains are added. If this is a device job, the host
+/// toolchains will be added.
+static void addExtraOffloadClangSystemIncludeArgs(Compilation &C,
+  const JobAction &JA,
+  const ArgList &Args,
+  ArgStringList &CmdArgs) {
+
+  if (JA.isHostOffloading(Action::OFK_Cuda))
+C.getSingleOffloadToolChain()->AddClangSystemIncludeArgs(
+Args, CmdArgs);
+  else if (JA.isDeviceOffloading(Action::OFK_Cuda))
+C.getSingleOffloadToolChain()->AddClangSystemIncludeArgs(
+Args, CmdArgs);
+
+  // TODO: Add support for other programming models here.
+}
+
 /// Add the include args that are specific of each offloading programming model.
 static void addExtraOffloadSpecificIncludeArgs(Compilation &C,
const JobAction &JA,
@@ -612,7 +630,7 @@
   // Add system include arguments for all targets but IAMCU.
   if (!IsIAMCU) {
 getToolChain().AddClangSystemIncludeArgs(Args, CmdArgs);
-addExtraOffloadCXXStdlibIncludeArgs(C, JA, Args, CmdArgs);
+addExtraOffloadClangSystemIncludeArgs(C, JA, Args, CmdArgs);
   } else {
 // For IAMCU add special include arguments.
 getToolChain().AddIAMCUIncludeArgs(Args, CmdArgs);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r275645 - [CUDA][OpenMP] Create generic offload action

[Samuel F Antao via cfe-commits]

Art, Richard,
 
I posted https://reviews.llvm.org/D22490. Let me know if that is what you have in mind.
 
Thanks!
Samuel
 
- Original message -From: Artem Belevich To: Samuel F Antao/Watson/IBM@IBMUSCc: Richard Smith , Justin Lebar , cfe-commits Subject: Re: r275645 - [CUDA][OpenMP] Create generic offload actionDate: Mon, Jul 18, 2016 7:38 PM 
 
 
On Mon, Jul 18, 2016 at 4:28 PM, Artem Belevich  wrote:

CXX headers had to be added twice because we needed them for both host and device side of compilation, but only *host* toolchain knew where to find them. That's the part under "Add C++ include arguments."
 
The second copy under "isIAMCU" below was added in r272883 and should indeed be removed.
 
Correction - r272883 is *not* the culprit. My commit r253386 is the source of the mess.
I believe it was a copy/paste error and the intent was to call AuxToolChain->.AddClangSystemIncludeArgs(Args, CmdArgs) for non-C++ files.
 
--Artem
 
 
 
 
On Mon, Jul 18, 2016 at 4:03 PM, Samuel F Antao  wrote:

Hi Richard,
 
I agree, I don't think the second `addExtraOffloadCXXStdlibIncludeArgs` is required. When I did this change my focus was to maintain functionality of the existing code. I can confirm that removing that passes the existent tests successfully. It is possible, however, there is some use case for the existing CUDA implementation that requires C++ include paths to be included for non C++  input types? 
 
Art, Justin can you confirm that is the case? If not, should I go ahead and remove the duplicated code?
 
Thanks!
Samuel
 
On Mon, Jul 18, 2016 at 5:45 PM, Richard Smith via cfe-commits  wrote:

 
 
On Fri, Jul 15, 2016 at 4:13 PM, Samuel Antao via cfe-commits  wrote:
Author: sfantaoDate: Fri Jul 15 18:13:27 2016New Revision: 275645URL: http://llvm.org/viewvc/llvm-project?rev=275645&view=revLog:[CUDA][OpenMP] Create generic offload actionSummary:This patch replaces the CUDA specific action by a generic offload action. The offload action may have multiple dependences classier in “host” and “device”. The way this generic offloading action is used is very similar to what is done today by the CUDA implementation: it is used to set a specific toolchain and architecture to its dependences during the generation of jobs.This patch also proposes propagating the offloading information through the action graph so that that information can be easily retrieved at any time during the generation of commands. This allows e.g. the "clang tool” to evaluate whether CUDA should be supported for the device or host and ptas to easily retrieve the target architecture.This is an example of how the action graphs would look like (compilation of a single CUDA file with two GPU architectures)```0: input, "cudatests.cu", cuda, (host-cuda)1: preprocessor, {0}, cuda-cpp-output, (host-cuda)2: compiler, {1}, ir, (host-cuda)3: input, "cudatests.cu", cuda, (device-cuda, sm_35)4: preprocessor, {3}, cuda-cpp-output, (device-cuda, sm_35)5: compiler, {4}, ir, (device-cuda, sm_35)6: backend, {5}, assembler, (device-cuda, sm_35)7: assembler, {6}, object, (device-cuda, sm_35)8: offload, "device-cuda (nvptx64-nvidia-cuda:sm_35)" {7}, object9: offload, "device-cuda (nvptx64-nvidia-cuda:sm_35)" {6}, assembler10: input, "cudatests.cu", cuda, (device-cuda, sm_37)11: preprocessor, {10}, cuda-cpp-output, (device-cuda, sm_37)12: compiler, {11}, ir, (device-cuda, sm_37)13: backend, {12}, assembler, (device-cuda, sm_37)14: assembler, {13}, object, (device-cuda, sm_37)15: offload, "device-cuda (nvptx64-nvidia-cuda:sm_37)" {14}, object16: offload, "device-cuda (nvptx64-nvidia-cuda:sm_37)" {13}, assembler17: linker, {8, 9, 15, 16}, cuda-fatbin, (device-cuda)18: offload, "host-cuda (powerpc64le-unknown-linux-gnu)" {2}, "device-cuda (nvptx64-nvidia-cuda)" {17}, ir19: backend, {18}, assembler20: assembler, {19}, object21: input, "cuda", object22: input, "cudart", object23: linker, {20, 21, 22}, image```The changes in this patch pass the existent regression tests (keeps the existent functionality) and resulting binaries execute correctly in a Power8+K40 machine.Reviewers: echristo, hfinkel, jlebar, ABataev, traSubscribers: guansong, andreybokhanko, tcramer, mkuron, cfe-commits, arpith-jacob, carlo.bertolli, caomhinDifferential Revision: https://reviews.llvm.org/D18171Added:    cfe/trunk/test/Driver/cuda_phases.cuModified:    cfe/trunk/include/clang/Driver/Action.h    cfe/trunk/include/clang/Driver/Compilation.h    cfe/trunk/include/clang/Driver/Driver.h    cfe/trunk/lib/Driver/Action.cpp    cfe/trunk/lib/Driver/Driver.cpp    cfe/trunk/lib/Driver/ToolChain.cpp    cfe/trunk/lib/Driver/Tools.cpp    cfe/trunk/lib/Driver/Tools.h    cfe/trunk/lib/Frontend/CreateInvocationFromCommandLine.cppModified: cfe/trunk/include/clang/Driver/Action.hURL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Action.h?rev=275645&r1=275644&r2=275645&view=diff===

Re: [PATCH] D22490: Append clang system include path for offloading tool chains.

[Samuel Antao via cfe-commits]

sfantao updated this revision to Diff 64428.
sfantao added a comment.

- Add missing context for review.


https://reviews.llvm.org/D22490

Files:
  lib/Driver/Tools.cpp

Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -314,6 +314,24 @@
   // TODO: Add support for other programming models here.
 }
 
+/// Add the C include args of other offloading toolchains. If this is a host
+/// job, the device toolchains are added. If this is a device job, the host
+/// toolchains will be added.
+static void addExtraOffloadClangSystemIncludeArgs(Compilation &C,
+  const JobAction &JA,
+  const ArgList &Args,
+  ArgStringList &CmdArgs) {
+
+  if (JA.isHostOffloading(Action::OFK_Cuda))
+C.getSingleOffloadToolChain()->AddClangSystemIncludeArgs(
+Args, CmdArgs);
+  else if (JA.isDeviceOffloading(Action::OFK_Cuda))
+C.getSingleOffloadToolChain()->AddClangSystemIncludeArgs(
+Args, CmdArgs);
+
+  // TODO: Add support for other programming models here.
+}
+
 /// Add the include args that are specific of each offloading programming 
model.
 static void addExtraOffloadSpecificIncludeArgs(Compilation &C,
const JobAction &JA,
@@ -612,7 +630,7 @@
   // Add system include arguments for all targets but IAMCU.
   if (!IsIAMCU) {
 getToolChain().AddClangSystemIncludeArgs(Args, CmdArgs);
-addExtraOffloadCXXStdlibIncludeArgs(C, JA, Args, CmdArgs);
+addExtraOffloadClangSystemIncludeArgs(C, JA, Args, CmdArgs);
   } else {
 // For IAMCU add special include arguments.
 getToolChain().AddIAMCUIncludeArgs(Args, CmdArgs);


Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -314,6 +314,24 @@
   // TODO: Add support for other programming models here.
 }
 
+/// Add the C include args of other offloading toolchains. If this is a host
+/// job, the device toolchains are added. If this is a device job, the host
+/// toolchains will be added.
+static void addExtraOffloadClangSystemIncludeArgs(Compilation &C,
+  const JobAction &JA,
+  const ArgList &Args,
+  ArgStringList &CmdArgs) {
+
+  if (JA.isHostOffloading(Action::OFK_Cuda))
+C.getSingleOffloadToolChain()->AddClangSystemIncludeArgs(
+Args, CmdArgs);
+  else if (JA.isDeviceOffloading(Action::OFK_Cuda))
+C.getSingleOffloadToolChain()->AddClangSystemIncludeArgs(
+Args, CmdArgs);
+
+  // TODO: Add support for other programming models here.
+}
+
 /// Add the include args that are specific of each offloading programming model.
 static void addExtraOffloadSpecificIncludeArgs(Compilation &C,
const JobAction &JA,
@@ -612,7 +630,7 @@
   // Add system include arguments for all targets but IAMCU.
   if (!IsIAMCU) {
 getToolChain().AddClangSystemIncludeArgs(Args, CmdArgs);
-addExtraOffloadCXXStdlibIncludeArgs(C, JA, Args, CmdArgs);
+addExtraOffloadClangSystemIncludeArgs(C, JA, Args, CmdArgs);
   } else {
 // For IAMCU add special include arguments.
 getToolChain().AddIAMCUIncludeArgs(Args, CmdArgs);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D22490: Append clang system include path for offloading tool chains.

[Artem Belevich via cfe-commits]

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

LGTM.


https://reviews.llvm.org/D22490



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

r275931 - Append clang system include path for offloading tool chains.

[Samuel Antao via cfe-commits]

Author: sfantao
Date: Mon Jul 18 19:01:12 2016
New Revision: 275931

URL: http://llvm.org/viewvc/llvm-project?rev=275931&view=rev
Log:
Append clang system include path for offloading tool chains.

Summary:
This patch adds clang system include path when offloading tool chains, e.g. 
CUDA, are used in the current compilation.

This fixes an issue detected by @rsmith in response to r275645.

Reviewers: rsmith, tra

Subscribers: rsmith, cfe-commits

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

Modified:
cfe/trunk/lib/Driver/Tools.cpp

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=275931&r1=275930&r2=275931&view=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Mon Jul 18 19:01:12 2016
@@ -314,6 +314,24 @@ static void addExtraOffloadCXXStdlibIncl
   // TODO: Add support for other programming models here.
 }
 
+/// Add the C include args of other offloading toolchains. If this is a host
+/// job, the device toolchains are added. If this is a device job, the host
+/// toolchains will be added.
+static void addExtraOffloadClangSystemIncludeArgs(Compilation &C,
+  const JobAction &JA,
+  const ArgList &Args,
+  ArgStringList &CmdArgs) {
+
+  if (JA.isHostOffloading(Action::OFK_Cuda))
+C.getSingleOffloadToolChain()->AddClangSystemIncludeArgs(
+Args, CmdArgs);
+  else if (JA.isDeviceOffloading(Action::OFK_Cuda))
+C.getSingleOffloadToolChain()->AddClangSystemIncludeArgs(
+Args, CmdArgs);
+
+  // TODO: Add support for other programming models here.
+}
+
 /// Add the include args that are specific of each offloading programming 
model.
 static void addExtraOffloadSpecificIncludeArgs(Compilation &C,
const JobAction &JA,
@@ -612,7 +630,7 @@ void Clang::AddPreprocessingOptions(Comp
   // Add system include arguments for all targets but IAMCU.
   if (!IsIAMCU) {
 getToolChain().AddClangSystemIncludeArgs(Args, CmdArgs);
-addExtraOffloadCXXStdlibIncludeArgs(C, JA, Args, CmdArgs);
+addExtraOffloadClangSystemIncludeArgs(C, JA, Args, CmdArgs);
   } else {
 // For IAMCU add special include arguments.
 getToolChain().AddIAMCUIncludeArgs(Args, CmdArgs);


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

Re: [PATCH] D22490: Append clang system include path for offloading tool chains.

[Samuel Antao via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL275931: Append clang system include path for offloading tool 
chains. (authored by sfantao).

Changed prior to commit:
  https://reviews.llvm.org/D22490?vs=64428&id=64432#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D22490

Files:
  cfe/trunk/lib/Driver/Tools.cpp

Index: cfe/trunk/lib/Driver/Tools.cpp
===
--- cfe/trunk/lib/Driver/Tools.cpp
+++ cfe/trunk/lib/Driver/Tools.cpp
@@ -314,6 +314,24 @@
   // TODO: Add support for other programming models here.
 }
 
+/// Add the C include args of other offloading toolchains. If this is a host
+/// job, the device toolchains are added. If this is a device job, the host
+/// toolchains will be added.
+static void addExtraOffloadClangSystemIncludeArgs(Compilation &C,
+  const JobAction &JA,
+  const ArgList &Args,
+  ArgStringList &CmdArgs) {
+
+  if (JA.isHostOffloading(Action::OFK_Cuda))
+C.getSingleOffloadToolChain()->AddClangSystemIncludeArgs(
+Args, CmdArgs);
+  else if (JA.isDeviceOffloading(Action::OFK_Cuda))
+C.getSingleOffloadToolChain()->AddClangSystemIncludeArgs(
+Args, CmdArgs);
+
+  // TODO: Add support for other programming models here.
+}
+
 /// Add the include args that are specific of each offloading programming 
model.
 static void addExtraOffloadSpecificIncludeArgs(Compilation &C,
const JobAction &JA,
@@ -612,7 +630,7 @@
   // Add system include arguments for all targets but IAMCU.
   if (!IsIAMCU) {
 getToolChain().AddClangSystemIncludeArgs(Args, CmdArgs);
-addExtraOffloadCXXStdlibIncludeArgs(C, JA, Args, CmdArgs);
+addExtraOffloadClangSystemIncludeArgs(C, JA, Args, CmdArgs);
   } else {
 // For IAMCU add special include arguments.
 getToolChain().AddIAMCUIncludeArgs(Args, CmdArgs);


Index: cfe/trunk/lib/Driver/Tools.cpp
===
--- cfe/trunk/lib/Driver/Tools.cpp
+++ cfe/trunk/lib/Driver/Tools.cpp
@@ -314,6 +314,24 @@
   // TODO: Add support for other programming models here.
 }
 
+/// Add the C include args of other offloading toolchains. If this is a host
+/// job, the device toolchains are added. If this is a device job, the host
+/// toolchains will be added.
+static void addExtraOffloadClangSystemIncludeArgs(Compilation &C,
+  const JobAction &JA,
+  const ArgList &Args,
+  ArgStringList &CmdArgs) {
+
+  if (JA.isHostOffloading(Action::OFK_Cuda))
+C.getSingleOffloadToolChain()->AddClangSystemIncludeArgs(
+Args, CmdArgs);
+  else if (JA.isDeviceOffloading(Action::OFK_Cuda))
+C.getSingleOffloadToolChain()->AddClangSystemIncludeArgs(
+Args, CmdArgs);
+
+  // TODO: Add support for other programming models here.
+}
+
 /// Add the include args that are specific of each offloading programming model.
 static void addExtraOffloadSpecificIncludeArgs(Compilation &C,
const JobAction &JA,
@@ -612,7 +630,7 @@
   // Add system include arguments for all targets but IAMCU.
   if (!IsIAMCU) {
 getToolChain().AddClangSystemIncludeArgs(Args, CmdArgs);
-addExtraOffloadCXXStdlibIncludeArgs(C, JA, Args, CmdArgs);
+addExtraOffloadClangSystemIncludeArgs(C, JA, Args, CmdArgs);
   } else {
 // For IAMCU add special include arguments.
 getToolChain().AddIAMCUIncludeArgs(Args, CmdArgs);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r275645 - [CUDA][OpenMP] Create generic offload action

[Samuel F Antao via cfe-commits]

Fixed in r275931.
 
Thanks!
Samuel
 
- Original message -From: Artem Belevich To: Samuel F Antao/Watson/IBM@IBMUSCc: Richard Smith , Justin Lebar , cfe-commits Subject: Re: r275645 - [CUDA][OpenMP] Create generic offload actionDate: Mon, Jul 18, 2016 7:38 PM 
 
 
On Mon, Jul 18, 2016 at 4:28 PM, Artem Belevich  wrote:

CXX headers had to be added twice because we needed them for both host and device side of compilation, but only *host* toolchain knew where to find them. That's the part under "Add C++ include arguments."
 
The second copy under "isIAMCU" below was added in r272883 and should indeed be removed.
 
Correction - r272883 is *not* the culprit. My commit r253386 is the source of the mess.
I believe it was a copy/paste error and the intent was to call AuxToolChain->.AddClangSystemIncludeArgs(Args, CmdArgs) for non-C++ files.
 
--Artem
 
 
 
 
On Mon, Jul 18, 2016 at 4:03 PM, Samuel F Antao  wrote:

Hi Richard,
 
I agree, I don't think the second `addExtraOffloadCXXStdlibIncludeArgs` is required. When I did this change my focus was to maintain functionality of the existing code. I can confirm that removing that passes the existent tests successfully. It is possible, however, there is some use case for the existing CUDA implementation that requires C++ include paths to be included for non C++  input types? 
 
Art, Justin can you confirm that is the case? If not, should I go ahead and remove the duplicated code?
 
Thanks!
Samuel
 
On Mon, Jul 18, 2016 at 5:45 PM, Richard Smith via cfe-commits  wrote:

 
 
On Fri, Jul 15, 2016 at 4:13 PM, Samuel Antao via cfe-commits  wrote:
Author: sfantaoDate: Fri Jul 15 18:13:27 2016New Revision: 275645URL: http://llvm.org/viewvc/llvm-project?rev=275645&view=revLog:[CUDA][OpenMP] Create generic offload actionSummary:This patch replaces the CUDA specific action by a generic offload action. The offload action may have multiple dependences classier in “host” and “device”. The way this generic offloading action is used is very similar to what is done today by the CUDA implementation: it is used to set a specific toolchain and architecture to its dependences during the generation of jobs.This patch also proposes propagating the offloading information through the action graph so that that information can be easily retrieved at any time during the generation of commands. This allows e.g. the "clang tool” to evaluate whether CUDA should be supported for the device or host and ptas to easily retrieve the target architecture.This is an example of how the action graphs would look like (compilation of a single CUDA file with two GPU architectures)```0: input, "cudatests.cu", cuda, (host-cuda)1: preprocessor, {0}, cuda-cpp-output, (host-cuda)2: compiler, {1}, ir, (host-cuda)3: input, "cudatests.cu", cuda, (device-cuda, sm_35)4: preprocessor, {3}, cuda-cpp-output, (device-cuda, sm_35)5: compiler, {4}, ir, (device-cuda, sm_35)6: backend, {5}, assembler, (device-cuda, sm_35)7: assembler, {6}, object, (device-cuda, sm_35)8: offload, "device-cuda (nvptx64-nvidia-cuda:sm_35)" {7}, object9: offload, "device-cuda (nvptx64-nvidia-cuda:sm_35)" {6}, assembler10: input, "cudatests.cu", cuda, (device-cuda, sm_37)11: preprocessor, {10}, cuda-cpp-output, (device-cuda, sm_37)12: compiler, {11}, ir, (device-cuda, sm_37)13: backend, {12}, assembler, (device-cuda, sm_37)14: assembler, {13}, object, (device-cuda, sm_37)15: offload, "device-cuda (nvptx64-nvidia-cuda:sm_37)" {14}, object16: offload, "device-cuda (nvptx64-nvidia-cuda:sm_37)" {13}, assembler17: linker, {8, 9, 15, 16}, cuda-fatbin, (device-cuda)18: offload, "host-cuda (powerpc64le-unknown-linux-gnu)" {2}, "device-cuda (nvptx64-nvidia-cuda)" {17}, ir19: backend, {18}, assembler20: assembler, {19}, object21: input, "cuda", object22: input, "cudart", object23: linker, {20, 21, 22}, image```The changes in this patch pass the existent regression tests (keeps the existent functionality) and resulting binaries execute correctly in a Power8+K40 machine.Reviewers: echristo, hfinkel, jlebar, ABataev, traSubscribers: guansong, andreybokhanko, tcramer, mkuron, cfe-commits, arpith-jacob, carlo.bertolli, caomhinDifferential Revision: https://reviews.llvm.org/D18171Added:    cfe/trunk/test/Driver/cuda_phases.cuModified:    cfe/trunk/include/clang/Driver/Action.h    cfe/trunk/include/clang/Driver/Compilation.h    cfe/trunk/include/clang/Driver/Driver.h    cfe/trunk/lib/Driver/Action.cpp    cfe/trunk/lib/Driver/Driver.cpp    cfe/trunk/lib/Driver/ToolChain.cpp    cfe/trunk/lib/Driver/Tools.cpp    cfe/trunk/lib/Driver/Tools.h    cfe/trunk/lib/Frontend/CreateInvocationFromCommandLine.cppModified: cfe/trunk/include/clang/Driver/Action.hURL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Action.h?rev=275645&r1=275644&r2=275645&view=diff==--- cfe/trunk/include/clang

Re: [PATCH] D22183: [SemObjC] Fix TypoExpr handling in TransformObjCDictionaryLiteral

[Manman Ren via cfe-commits]

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

LGTM.

Manman



Comment at: lib/Parse/ParseObjc.cpp:3489
@@ -3478,3 +3488,3 @@
 
-// Parse the ellipsis that designates this as a pack expansion.
-SourceLocation EllipsisLoc;
+// Check the key and value for possible typos
+KeyExpr = Actions.CorrectDelayedTyposInExpr(KeyExpr.get());

Add a period at the end of the comment.


https://reviews.llvm.org/D22183



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