[PATCH] D38576: |libunwind] [docs] Mention that SjLj works on any OS on the archs where supported by the compiler

[Martin Storsjö via Phabricator via cfe-commits]

mstorsjo created this revision.

https://reviews.llvm.org/D38576

Files:
  docs/index.rst


Index: docs/index.rst
===
--- docs/index.rst
+++ docs/index.rst
@@ -50,6 +50,7 @@
 LinuxARM  Clang, GCC   EHABI
 Bare Metal   ARM  Clang, GCC   EHABI
 NetBSD   x86_64   Clang, GCC   DWARF CFI
+Any  i386, x86_64, ARMClangSjLj
    
 
 The following minimum compiler versions are strongly recommended.


Index: docs/index.rst
===
--- docs/index.rst
+++ docs/index.rst
@@ -50,6 +50,7 @@
 LinuxARM  Clang, GCC   EHABI
 Bare Metal   ARM  Clang, GCC   EHABI
 NetBSD   x86_64   Clang, GCC   DWARF CFI
+Any  i386, x86_64, ARMClangSjLj
    
 
 The following minimum compiler versions are strongly recommended.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D31363: [libc++] Remove cmake glob for source files

[Zachary Turner via cfe-commits]

It’s not, but the point is we’re already skirting the line
On Wed, Oct 4, 2017 at 9:37 PM Duncan P. N. Exon Smith 
wrote:

> I haven't looked at the patch.  If this is guarded behind NOT
> LIBCXX_STANDALONE_BUILD checks, then it's probably fine.
>
>
> On Oct 4, 2017, at 21:36, Zachary Turner  wrote:
>
> This doesn’t match up with what beanz said. While I assume Duncan is the
> final word, can we get some confirmation from beanz that everyone is on the
> same page?
>
> (Note that libcxx already uses some of LLVM’s cmake, but it’s behind some
> NOT LIBCXX_STANDALONE_BUILD checks)
>
> Assuming the answer remains no, what can we do to make code sharing and
> reuse easier? There’s clearly a need to reuse certain low level things and
> not keep reinventing the wheel
> On Wed, Oct 4, 2017 at 9:22 PM Duncan P. N. Exon Smith <
> dexonsm...@apple.com> wrote:
>
>> Thanks correct.
>>
>> > On Oct 4, 2017, at 18:49, Shoaib Meenai via Phabricator via cfe-commits
>>  wrote:
>> >
>> > smeenai added subscribers: zturner, rjmccall.
>> > smeenai added a comment.
>> >
>> > @rjmccall, this adds a libc++ build dependency on LLVM's cmake modules.
>> There were some issues when @zturner had added a similar dependency for his
>> work on lit. To confirm, Apple still cares about the use case of building
>> libc++ without having any LLVM cmake modules available (either from source
>> or from an LLVM installation), right?
>> >
>> >
>> > https://reviews.llvm.org/D31363
>> >
>> >
>> >
>> > ___
>> > 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] D31363: [libc++] Remove cmake glob for source files

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

I haven't looked at the patch.  If this is guarded behind NOT 
LIBCXX_STANDALONE_BUILD checks, then it's probably fine.

> On Oct 4, 2017, at 21:36, Zachary Turner  wrote:
> 
> This doesn’t match up with what beanz said. While I assume Duncan is the 
> final word, can we get some confirmation from beanz that everyone is on the 
> same page?
> 
> (Note that libcxx already uses some of LLVM’s cmake, but it’s behind some NOT 
> LIBCXX_STANDALONE_BUILD checks)
> 
> Assuming the answer remains no, what can we do to make code sharing and reuse 
> easier? There’s clearly a need to reuse certain low level things and not keep 
> reinventing the wheel 
> On Wed, Oct 4, 2017 at 9:22 PM Duncan P. N. Exon Smith  > wrote:
> Thanks correct.
> 
> > On Oct 4, 2017, at 18:49, Shoaib Meenai via Phabricator via cfe-commits 
> > mailto:cfe-commits@lists.llvm.org>> wrote:
> >
> > smeenai added subscribers: zturner, rjmccall.
> > smeenai added a comment.
> >
> > @rjmccall, this adds a libc++ build dependency on LLVM's cmake modules. 
> > There were some issues when @zturner had added a similar dependency for his 
> > work on lit. To confirm, Apple still cares about the use case of building 
> > libc++ without having any LLVM cmake modules available (either from source 
> > or from an LLVM installation), right?
> >
> >
> > https://reviews.llvm.org/D31363 
> >
> >
> >
> > ___
> > 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] D31363: [libc++] Remove cmake glob for source files

[Zachary Turner via cfe-commits]

This doesn’t match up with what beanz said. While I assume Duncan is the
final word, can we get some confirmation from beanz that everyone is on the
same page?

(Note that libcxx already uses some of LLVM’s cmake, but it’s behind some
NOT LIBCXX_STANDALONE_BUILD checks)

Assuming the answer remains no, what can we do to make code sharing and
reuse easier? There’s clearly a need to reuse certain low level things and
not keep reinventing the wheel
On Wed, Oct 4, 2017 at 9:22 PM Duncan P. N. Exon Smith 
wrote:

> Thanks correct.
>
> > On Oct 4, 2017, at 18:49, Shoaib Meenai via Phabricator via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
> >
> > smeenai added subscribers: zturner, rjmccall.
> > smeenai added a comment.
> >
> > @rjmccall, this adds a libc++ build dependency on LLVM's cmake modules.
> There were some issues when @zturner had added a similar dependency for his
> work on lit. To confirm, Apple still cares about the use case of building
> libc++ without having any LLVM cmake modules available (either from source
> or from an LLVM installation), right?
> >
> >
> > https://reviews.llvm.org/D31363
> >
> >
> >
> > ___
> > 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] D31363: [libc++] Remove cmake glob for source files

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

Thanks correct.

> On Oct 4, 2017, at 18:49, Shoaib Meenai via Phabricator via cfe-commits 
>  wrote:
> 
> smeenai added subscribers: zturner, rjmccall.
> smeenai added a comment.
> 
> @rjmccall, this adds a libc++ build dependency on LLVM's cmake modules. There 
> were some issues when @zturner had added a similar dependency for his work on 
> lit. To confirm, Apple still cares about the use case of building libc++ 
> without having any LLVM cmake modules available (either from source or from 
> an LLVM installation), right?
> 
> 
> https://reviews.llvm.org/D31363
> 
> 
> 
> ___
> 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] D37826: Refine generation of TBAA information in clang

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

In https://reviews.llvm.org/D37826#888086, @kosarev wrote:

> In https://reviews.llvm.org/D37826#887820, @rjmccall wrote:
>
> > I assume I should wait on reviewing this until all of these smaller TBAA 
> > patches land?
>
>
> These small patches are actually part of this diff. Generally, It depends on 
> how you would like it: if you can review this re-based version as a whole, 
> then that would save us some time.
>
> Otherwise, you may want to proceed by smaller pieces, in which case 
> https://reviews.llvm.org/D38503 is the next proposed piece to review.
>
> Alternatively, if https://reviews.llvm.org/D38503 looks too complicated, 
> please let me know and I will break it down into even smaller patches.
>
> Or, if acceptable, I could commit a series of really small and simple diffs 
> that all result in what is presented in https://reviews.llvm.org/D38126 and 
> rely on post-commit reviews.
>
> I'm fine with either way, provided the changes go to the mainline in time 
> manner.
>
> Thanks a lot for reviewing!


I'll let you rebase this on top of the https://reviews.llvm.org/D38503 when you 
commit it, and then I'll just review this directly.  Thanks a lot for splitting 
it up!

John.


https://reviews.llvm.org/D37826



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

[PATCH] D38503: [CodeGen] Unify generation of scalar and struct-path TBAA tags

[John McCall via Phabricator via cfe-commits]

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

LGTM with one comment fix that I noticed.




Comment at: lib/CodeGen/CodeGenModule.h:659
 
-  llvm::MDNode *getTBAAInfoForVTablePtr();
+  /// getTBAAAccessInfo - Get TBAA information that describes an accesses to
+  /// an object of the given type.

"an access"


Repository:
  rL LLVM

https://reviews.llvm.org/D38503



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

[PATCH] D35082: [OpenCL] Add LangAS::opencl_private to represent private address space in AST

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

Are you sure it's a good idea to not print the address space when it's 
implicit?  Won't that often lead to really confusing diagnostics?

Also, we do already have a way of expressing that an extended qualifier was 
explicit: AttributedType.  We have very similar sorts of superficial 
well-formedness checks to what I think you're trying to do in ObjC ARC.


https://reviews.llvm.org/D35082



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

[PATCH] D31363: [libc++] Remove cmake glob for source files

[John McCall via Phabricator via cfe-commits]

rjmccall added a reviewer: dexonsmith.
rjmccall added a comment.

I'll let Duncan answer that question.


https://reviews.llvm.org/D31363



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

[PATCH] D38473: Include getting generated struct offsets in CodegenABITypes

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

In https://reviews.llvm.org/D38473#888597, @rsmith wrote:

> In https://reviews.llvm.org/D38473#888159, @mppf wrote:
>
> > > You should also indicate *which* record layout (complete object type or 
> > > base subobject type) the field number is for. I don't think there's any 
> > > guarantee that the same indexes work in both.
> >
> > I added a comment about this - indicating that inherited fields are not 
> > supported by this function. My use case is just for C structs at the moment 
> > and I'm not actually sure what we'd need to do for the interface to support 
> > building GEPs for inherited fields. I'm sure it would complicate the API. I 
> > think we should leave that complexity to another function or a future 
> > function (when somebody actually needs it).
>
>
> I don't think your added comment is related to my request. There are two 
> (potentially) different LLVM types for a C++ class type in general, one for 
> the case where the object is a base class subobject (excluding vbases, and 
> where the tail padding could be reused) and one for where it is a complete 
> object (including vbases, and where the tail padding is known to be owned by 
> the object). I don't know whether we guarantee that field indexes for one 
> layout can be used for the other layout; in particular, I'm concerned that 
> one could be a packed struct when the other isn't, and thus the field indexes 
> could differ. (I think we generally use the complete object type within IR 
> generation, even though that may seem like an odd choice.)
>
> But perhaps we do guarantee the common prefixes are the same (@rjmccall: do 
> we?), or we only ever expose one of the two layouts to code outside Clang, 
> and in either case this wouldn't matter.


I think we should probably just document that they're only valid in the 
complete-object type, which also, yes, happens to be the only type we expose 
outside of Clang because it's the type returned by convertTypeForMemory.

> 
> 
>>> (Eg, if we move to an IR representation using something non-GEPable to 
>>> represent a source-level class type, we would remove this function as it 
>>> would be meaningless.)
>> 
>> In that event, I'd just want to have a way to build the appropriate field 
>> access. (e.g. a function to build an appropriate GEP; or a function that 
>> adds appropriate instructions to an IRBuilder and returns a Value* that 
>> points to the field, say). I'm open to trying to go directly to such an 
>> interface but I'd need significant help in designing/implementing it. (The 
>> interface I've proposed here meets my needs and I don't think I know enough 
>> about clang to design/implement a better one without help).
> 
> Given the generality of kinds of lvalues and rvalues that we support, this 
> would mean exposing a significant chunk of the CodeGen interface, I think -- 
> probably much more than we would be comfortable exposing.

I thought about making this sort of comment and decided that if we added more 
non-GEPable kinds of fields, we could always just put them after bit-fields in 
the exceptions list.


https://reviews.llvm.org/D38473



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

Re: [libcxx] r314949 - [libc++] Allow users to explicitly specify ABI

[Shoaib Meenai via cfe-commits]

Eric and I discussed this further on IRC, and r314965 implements his 
suggestions.

From: Eric Fiselier 
Date: Wednesday, October 4, 2017 at 6:11 PM
To: Shoaib Meenai 
Cc: cfe-commits 
Subject: Re: [libcxx] r314949 - [libc++] Allow users to explicitly specify ABI



On Wed, Oct 4, 2017 at 5:44 PM, Shoaib Meenai via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: smeenai
Date: Wed Oct  4 16:44:38 2017
New Revision: 314949

URL: 
http://llvm.org/viewvc/llvm-project?rev=314949&view=rev
Log:
[libc++] Allow users to explicitly specify ABI

libc++'s current heuristic for detecting Itanium vs. Microsoft ABI falls
short in some cases. For example, it will detect windows-itanium targets
as using the Microsoft ABI, since they set `_MSC_VER` (for compatibility
with Microsoft headers). Leave the current heuristic in place by default
but also allow users to explicitly specify the ABI if need be.

Modified:
libcxx/trunk/CMakeLists.txt
libcxx/trunk/include/__config

libcxx/trunk/include/__config_site.in

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=314949&r1=314948&r2=314949&view=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Wed Oct  4 16:44:38 2017
@@ -99,6 +99,8 @@ cmake_dependent_option(LIBCXX_INSTALL_EX
 "LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY;LIBCXX_INSTALL_LIBRARY" OFF)
 set(LIBCXX_ABI_VERSION 1 CACHE STRING "ABI version of libc++.")
 option(LIBCXX_ABI_UNSTABLE "Unstable ABI of libc++." OFF)
+option(LIBCXX_ABI_ITANIUM "Ignore auto-detection and force use of the Itanium 
ABI.")
+option(LIBCXX_ABI_MICROSOFT "Ignore auto-detection and force use of the 
Microsoft ABI.")

Shouldn't these specify a default option?

 option(LIBCXX_USE_COMPILER_RT "Use compiler-rt instead of libgcc" OFF)

 if (NOT LIBCXX_ENABLE_SHARED AND NOT LIBCXX_ENABLE_STATIC)
@@ -337,6 +339,10 @@ if (LIBCXX_HAS_MUSL_LIBC AND NOT LIBCXX_
   "when building for Musl with LIBCXX_HAS_MUSL_LIBC.")
 endif()

+if (LIBCXX_ABI_ITANIUM AND LIBCXX_ABI_MICROSOFT)
+  message(FATAL_ERROR "Only one of LIBCXX_ABI_ITANIUM and LIBCXX_ABI_MICROSOFT 
can be specified.")
+endif ()
+
 
#===
 # Configure System
 
#===
@@ -594,6 +600,8 @@ if (NOT LIBCXX_ABI_VERSION EQUAL "1")
   config_define(${LIBCXX_ABI_VERSION} _LIBCPP_ABI_VERSION)
 endif()
 config_define_if(LIBCXX_ABI_UNSTABLE _LIBCPP_ABI_UNSTABLE)
+config_define_if(LIBCXX_ABI_ITANIUM _LIBCPP_ABI_ITANIUM)
+config_define_if(LIBCXX_ABI_MICROSOFT _LIBCPP_ABI_MICROSOFT)
I'm not a fan of the direction this is going in. It seems to require the 
generation and use of a __config_site header
in all cases where it's used. I don't think we want to require that in the 
common case where you're using Itanium on
Linux or Windows.

However, like you said, the attempt of this is to override the automatic 
detection done in the headers. Maybe the name
should reflect that (Ex. _LIBCPP_ABI_ITANIUM_OVERRIDE)? And then the 
autodetection can operate by checking for an override first?

 config_define_if_not(LIBCXX_ENABLE_GLOBAL_FILESYSTEM_NAMESPACE 
_LIBCPP_HAS_NO_GLOBAL_FILESYSTEM_NAMESPACE)
 config_define_if_not(LIBCXX_ENABLE_STDIN _LIBCPP_HAS_NO_STDIN)

Modified: libcxx/trunk/include/__config
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__config?rev=314949&r1=314948&r2=314949&view=diff
==
--- libcxx/trunk/include/__config (original)
+++ libcxx/trunk/include/__config Wed Oct  4 16:44:38 2017
@@ -157,11 +157,15 @@

 // FIXME: ABI detection should be done

[libcxx] r314965 - [libc++] Clarify names of ABI forcing macros

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Wed Oct  4 19:18:08 2017
New Revision: 314965

URL: http://llvm.org/viewvc/llvm-project?rev=314965&view=rev
Log:
[libc++] Clarify names of ABI forcing macros

Make it clear that these are intended only to force a specific ABI when
the autodetection would give the wrong result by renaming the cmake
options and adding separate forcing macros, as suggested by EricWF in
the post-commit review of r314949 and further discussed on IRC.

Modified:
libcxx/trunk/CMakeLists.txt
libcxx/trunk/include/__config
libcxx/trunk/include/__config_site.in

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=314965&r1=314964&r2=314965&view=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Wed Oct  4 19:18:08 2017
@@ -99,8 +99,8 @@ cmake_dependent_option(LIBCXX_INSTALL_EX
 "LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY;LIBCXX_INSTALL_LIBRARY" OFF)
 set(LIBCXX_ABI_VERSION 1 CACHE STRING "ABI version of libc++.")
 option(LIBCXX_ABI_UNSTABLE "Unstable ABI of libc++." OFF)
-option(LIBCXX_ABI_ITANIUM "Ignore auto-detection and force use of the Itanium 
ABI.")
-option(LIBCXX_ABI_MICROSOFT "Ignore auto-detection and force use of the 
Microsoft ABI.")
+option(LIBCXX_ABI_FORCE_ITANIUM "Ignore auto-detection and force use of the 
Itanium ABI.")
+option(LIBCXX_ABI_FORCE_MICROSOFT "Ignore auto-detection and force use of the 
Microsoft ABI.")
 set(LIBCXX_ABI_DEFINES "" CACHE STRING "A semicolon separated list of ABI 
macros to define in the site config header.")
 option(LIBCXX_USE_COMPILER_RT "Use compiler-rt instead of libgcc" OFF)
 
@@ -340,8 +340,8 @@ if (LIBCXX_HAS_MUSL_LIBC AND NOT LIBCXX_
   "when building for Musl with LIBCXX_HAS_MUSL_LIBC.")
 endif()
 
-if (LIBCXX_ABI_ITANIUM AND LIBCXX_ABI_MICROSOFT)
-  message(FATAL_ERROR "Only one of LIBCXX_ABI_ITANIUM and LIBCXX_ABI_MICROSOFT 
can be specified.")
+if (LIBCXX_ABI_FORCE_ITANIUM AND LIBCXX_ABI_FORCE_MICROSOFT)
+  message(FATAL_ERROR "Only one of LIBCXX_ABI_FORCE_ITANIUM and 
LIBCXX_ABI_FORCE_MICROSOFT can be specified.")
 endif ()
 
 
#===
@@ -601,8 +601,8 @@ if (NOT LIBCXX_ABI_VERSION EQUAL "1")
   config_define(${LIBCXX_ABI_VERSION} _LIBCPP_ABI_VERSION)
 endif()
 config_define_if(LIBCXX_ABI_UNSTABLE _LIBCPP_ABI_UNSTABLE)
-config_define_if(LIBCXX_ABI_ITANIUM _LIBCPP_ABI_ITANIUM)
-config_define_if(LIBCXX_ABI_MICROSOFT _LIBCPP_ABI_MICROSOFT)
+config_define_if(LIBCXX_ABI_FORCE_ITANIUM _LIBCPP_ABI_FORCE_ITANIUM)
+config_define_if(LIBCXX_ABI_FORCE_MICROSOFT _LIBCPP_ABI_FORCE_MICROSOFT)
 
 config_define_if_not(LIBCXX_ENABLE_GLOBAL_FILESYSTEM_NAMESPACE 
_LIBCPP_HAS_NO_GLOBAL_FILESYSTEM_NAMESPACE)
 config_define_if_not(LIBCXX_ENABLE_STDIN _LIBCPP_HAS_NO_STDIN)

Modified: libcxx/trunk/include/__config
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__config?rev=314965&r1=314964&r2=314965&view=diff
==
--- libcxx/trunk/include/__config (original)
+++ libcxx/trunk/include/__config Wed Oct  4 19:18:08 2017
@@ -160,7 +160,13 @@
 // that Windows compilers pretending to be MSVC++ target the Microsoft ABI,
 // and allow the user to explicitly specify the ABI to handle cases where this
 // heuristic falls short.
-#if !defined(_LIBCPP_ABI_ITANIUM) && !defined(_LIBCPP_ABI_MICROSOFT)
+#if defined(_LIBCPP_ABI_FORCE_ITANIUM) && defined(_LIBCPP_ABI_FORCE_MICROSOFT)
+# error "Only one of _LIBCPP_ABI_FORCE_ITANIUM and _LIBCPP_ABI_FORCE_MICROSOFT 
can be defined"
+#elif defined(_LIBCPP_ABI_FORCE_ITANIUM)
+# define _LIBCPP_ABI_ITANIUM
+#elif defined(_LIBCPP_ABI_FORCE_MICROSOFT)
+# define _LIBCPP_ABI_MICROSOFT
+#else
 # if defined(_WIN32) && defined(_MSC_VER)
 #  define _LIBCPP_ABI_MICROSOFT
 # else

Modified: libcxx/trunk/include/__config_site.in
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__config_site.in?rev=314965&r1=314964&r2=314965&view=diff
==
--- libcxx/trunk/include/__config_site.in (original)
+++ libcxx/trunk/include/__config_site.in Wed Oct  4 19:18:08 2017
@@ -12,8 +12,8 @@
 
 #cmakedefine _LIBCPP_ABI_VERSION @_LIBCPP_ABI_VERSION@
 #cmakedefine _LIBCPP_ABI_UNSTABLE
-#cmakedefine _LIBCPP_ABI_ITANIUM
-#cmakedefine _LIBCPP_ABI_MICROSOFT
+#cmakedefine _LIBCPP_ABI_FORCE_ITANIUM
+#cmakedefine _LIBCPP_ABI_FORCE_MICROSOFT
 #cmakedefine _LIBCPP_HAS_NO_GLOBAL_FILESYSTEM_NAMESPACE
 #cmakedefine _LIBCPP_HAS_NO_STDIN
 #cmakedefine _LIBCPP_HAS_NO_STDOUT


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

[PATCH] D38517: Enabling new pass manager in LTO (and thinLTO) link step via -fexperimental-new-pass-manager option

[Sean Fertile via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL314964: Enabling new pass manager in LTO (and thinLTO) link 
step. (authored by sfertile).

Changed prior to commit:
  https://reviews.llvm.org/D38517?vs=117677&id=117771#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D38517

Files:
  cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp
  cfe/trunk/test/Driver/gold-lto-new-pass-man.c


Index: cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp
+++ cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp
@@ -454,6 +454,14 @@
   CmdArgs.push_back(
   Args.MakeArgString(Twine("-plugin-opt=sample-profile=") + FName));
   }
+
+  // Need this flag to turn on new pass manager via Gold plugin.
+  if (Args.hasFlag(options::OPT_fexperimental_new_pass_manager,
+   options::OPT_fno_experimental_new_pass_manager,
+   /* Default */ false)) {
+CmdArgs.push_back("-plugin-opt=new-pass-manager");
+  }
+
 }
 
 void tools::addArchSpecificRPath(const ToolChain &TC, const ArgList &Args,
Index: cfe/trunk/test/Driver/gold-lto-new-pass-man.c
===
--- cfe/trunk/test/Driver/gold-lto-new-pass-man.c
+++ cfe/trunk/test/Driver/gold-lto-new-pass-man.c
@@ -0,0 +1,7 @@
+// RUN: touch %t.o
+//
+// RUN: %clang -target ppc64le-unknown-linux -### %t.o -flto 2>&1 \
+// RUN: -Wl,-plugin-opt=foo -O3 \
+// RUN: -fexperimental-new-pass-manager \
+// RUN: | FileCheck %s
+// CHECK: "-plugin-opt=new-pass-manager"


Index: cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp
+++ cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp
@@ -454,6 +454,14 @@
   CmdArgs.push_back(
   Args.MakeArgString(Twine("-plugin-opt=sample-profile=") + FName));
   }
+
+  // Need this flag to turn on new pass manager via Gold plugin.
+  if (Args.hasFlag(options::OPT_fexperimental_new_pass_manager,
+   options::OPT_fno_experimental_new_pass_manager,
+   /* Default */ false)) {
+CmdArgs.push_back("-plugin-opt=new-pass-manager");
+  }
+
 }
 
 void tools::addArchSpecificRPath(const ToolChain &TC, const ArgList &Args,
Index: cfe/trunk/test/Driver/gold-lto-new-pass-man.c
===
--- cfe/trunk/test/Driver/gold-lto-new-pass-man.c
+++ cfe/trunk/test/Driver/gold-lto-new-pass-man.c
@@ -0,0 +1,7 @@
+// RUN: touch %t.o
+//
+// RUN: %clang -target ppc64le-unknown-linux -### %t.o -flto 2>&1 \
+// RUN: -Wl,-plugin-opt=foo -O3 \
+// RUN: -fexperimental-new-pass-manager \
+// RUN: | FileCheck %s
+// CHECK: "-plugin-opt=new-pass-manager"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r314964 - Enabling new pass manager in LTO (and thinLTO) link step.

[Sean Fertile via cfe-commits]

Author: sfertile
Date: Wed Oct  4 18:50:48 2017
New Revision: 314964

URL: http://llvm.org/viewvc/llvm-project?rev=314964&view=rev
Log:
Enabling new pass manager in LTO (and thinLTO) link step.

Passes 'new-pass-manager' option to the linker plugin when the new pass
manager is enabled.

Patch by Graham Yiu.

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

Added:
cfe/trunk/test/Driver/gold-lto-new-pass-man.c
Modified:
cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp

Modified: cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp?rev=314964&r1=314963&r2=314964&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp Wed Oct  4 18:50:48 2017
@@ -454,6 +454,14 @@ void tools::AddGoldPlugin(const ToolChai
   CmdArgs.push_back(
   Args.MakeArgString(Twine("-plugin-opt=sample-profile=") + FName));
   }
+
+  // Need this flag to turn on new pass manager via Gold plugin.
+  if (Args.hasFlag(options::OPT_fexperimental_new_pass_manager,
+   options::OPT_fno_experimental_new_pass_manager,
+   /* Default */ false)) {
+CmdArgs.push_back("-plugin-opt=new-pass-manager");
+  }
+
 }
 
 void tools::addArchSpecificRPath(const ToolChain &TC, const ArgList &Args,

Added: cfe/trunk/test/Driver/gold-lto-new-pass-man.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/gold-lto-new-pass-man.c?rev=314964&view=auto
==
--- cfe/trunk/test/Driver/gold-lto-new-pass-man.c (added)
+++ cfe/trunk/test/Driver/gold-lto-new-pass-man.c Wed Oct  4 18:50:48 2017
@@ -0,0 +1,7 @@
+// RUN: touch %t.o
+//
+// RUN: %clang -target ppc64le-unknown-linux -### %t.o -flto 2>&1 \
+// RUN: -Wl,-plugin-opt=foo -O3 \
+// RUN: -fexperimental-new-pass-manager \
+// RUN: | FileCheck %s
+// CHECK: "-plugin-opt=new-pass-manager"


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

[PATCH] D31363: [libc++] Remove cmake glob for source files

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added subscribers: zturner, rjmccall.
smeenai added a comment.

@rjmccall, this adds a libc++ build dependency on LLVM's cmake modules. There 
were some issues when @zturner had added a similar dependency for his work on 
lit. To confirm, Apple still cares about the use case of building libc++ 
without having any LLVM cmake modules available (either from source or from an 
LLVM installation), right?


https://reviews.llvm.org/D31363



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

[PATCH] D35082: [OpenCL] Add LangAS::opencl_private to represent private address space in AST

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added a comment.

In https://reviews.llvm.org/D35082#887855, @rjmccall wrote:

> Why is most of this patch necessary under the design of adding a 
> non-canonical __private address space?


There are two reasons that we need a flag to indicate an address space is 
simplicit:

1. We need a consistent way to print the address space qualifier depending on 
whether it is implicit or not.

We only print address space qualifier when it is explicit. This is not just for 
private address space. It is for all
address spaces.

2. In some rare situations we need to know whether an address space is implicit 
when doing the semantic

checking.

Since the implicit property is per address space qualifier, we need this flag 
to be on the qualifier.




Comment at: include/clang/AST/Type.h:336
+  /// space makes difference.
+  bool getImplicitAddressSpaceFlag() const { return Mask & IMask; }
+  void setImplicitAddressSpaceFlag(bool Value) {

rjmccall wrote:
> isAddressSpaceImplicit()
Will change.



Comment at: include/clang/AST/Type.h:337
+  bool getImplicitAddressSpaceFlag() const { return Mask & IMask; }
+  void setImplicitAddressSpaceFlag(bool Value) {
+Mask = (Mask & ~IMask) | (((uint32_t)Value) << IShift);

rjmccall wrote:
> setAddressSpaceImplicit
Will change.



Comment at: lib/AST/ItaniumMangle.cpp:2232
   case LangAS::opencl_constant: ASString = "CLconstant"; break;
+  case LangAS::opencl_private:  ASString = "CLprivate";  break;
   case LangAS::opencl_generic:  ASString = "CLgeneric";  break;

rjmccall wrote:
> In what situation is this mangled?  I thought we agree this was non-canonical.
OpenCL has overloaded builtin functions, e.g. `__attribute__((overloadable)) 
void f(private int*)` and  `__attribute__((overloadable)) void f(global int*)`. 
These functions need to be mangled so that the mangled names are different.



Comment at: test/SemaOpenCL/storageclass.cl:63
+  static float l_implicit_static_var = 0;  // expected-error 
{{variables in function scope cannot be declared static}}
+  static constant float l_constant_static_var = 0; // expected-error 
{{variables in function scope cannot be declared static}}
+  static global float l_global_static_var = 0; // expected-error 
{{variables in function scope cannot be declared static}}

Anastasia wrote:
> Does it make sense to put different address spaces here since this code is 
> rejected earlier anyway?
In Sema I saw code handling different address spaces in various places. I want 
to make sure that all address spaces are handled correctly.


https://reviews.llvm.org/D35082



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

[PATCH] D35082: [OpenCL] Add LangAS::opencl_private to represent private address space in AST

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl updated this revision to Diff 117770.
yaxunl marked 9 inline comments as done.
yaxunl added a comment.

Revised by John's comments.


https://reviews.llvm.org/D35082

Files:
  include/clang/AST/ASTContext.h
  include/clang/AST/Type.h
  include/clang/Basic/AddressSpaces.h
  lib/AST/ASTContext.cpp
  lib/AST/Expr.cpp
  lib/AST/ItaniumMangle.cpp
  lib/AST/TypePrinter.cpp
  lib/Basic/Targets/AMDGPU.cpp
  lib/Basic/Targets/NVPTX.h
  lib/Basic/Targets/SPIR.h
  lib/Basic/Targets/TCE.h
  lib/CodeGen/CGDecl.cpp
  lib/Sema/SemaChecking.cpp
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaType.cpp
  test/CodeGen/blocks-opencl.cl
  test/CodeGenOpenCL/address-spaces-mangling.cl
  test/CodeGenOpenCL/address-spaces.cl
  test/SemaOpenCL/address-spaces-conversions-cl2.0.cl
  test/SemaOpenCL/address-spaces.cl
  test/SemaOpenCL/atomic-ops.cl
  test/SemaOpenCL/cl20-device-side-enqueue.cl
  test/SemaOpenCL/extern.cl
  test/SemaOpenCL/invalid-block.cl
  test/SemaOpenCL/invalid-pipes-cl2.0.cl
  test/SemaOpenCL/null_literal.cl
  test/SemaOpenCL/storageclass-cl20.cl
  test/SemaOpenCL/storageclass.cl

Index: test/SemaOpenCL/storageclass.cl
===
--- test/SemaOpenCL/storageclass.cl
+++ test/SemaOpenCL/storageclass.cl
@@ -5,6 +5,20 @@
 int G3 = 0;// expected-error{{program scope variable must reside in constant address space}}
 global int G4 = 0; // expected-error{{program scope variable must reside in constant address space}}
 
+static float g_implicit_static_var = 0; // expected-error {{program scope variable must reside in constant address space}}
+static constant float g_constant_static_var = 0;
+static global float g_global_static_var = 0;   // expected-error {{program scope variable must reside in constant address space}}
+static local float g_local_static_var = 0; // expected-error {{program scope variable must reside in constant address space}}
+static private float g_private_static_var = 0; // expected-error {{program scope variable must reside in constant address space}}
+static generic float g_generic_static_var = 0; // expected-error{{OpenCL version 1.2 does not support the 'generic' type qualifier}} // expected-error {{program scope variable must reside in constant address space}}
+
+extern float g_implicit_extern_var; // expected-error {{extern variable must reside in constant address space}}
+extern constant float g_constant_extern_var;
+extern global float g_global_extern_var;   // expected-error {{extern variable must reside in constant address space}}
+extern local float g_local_extern_var; // expected-error {{extern variable must reside in constant address space}}
+extern private float g_private_extern_var; // expected-error {{extern variable must reside in constant address space}}
+extern generic float g_generic_extern_var; // expected-error{{OpenCL version 1.2 does not support the 'generic' type qualifier}} // expected-error {{extern variable must reside in constant address space}}
+
 void kernel foo(int x) {
   // static is not allowed at local scope before CL2.0
   static int S1 = 5;  // expected-error{{variables in function scope cannot be declared static}}
@@ -45,10 +59,17 @@
 __attribute__((address_space(100))) int L4; // expected-error{{automatic variable qualified with an invalid address space}}
   }
 
+  static float l_implicit_static_var = 0;  // expected-error {{variables in function scope cannot be declared static}}
+  static constant float l_constant_static_var = 0; // expected-error {{variables in function scope cannot be declared static}}
+  static global float l_global_static_var = 0; // expected-error {{variables in function scope cannot be declared static}}
+  static local float l_local_static_var = 0;   // expected-error {{variables in function scope cannot be declared static}}
+  static private float l_private_static_var = 0;   // expected-error {{variables in function scope cannot be declared static}}
+  static generic float l_generic_static_var = 0;   // expected-error{{OpenCL version 1.2 does not support the 'generic' type qualifier}} // expected-error {{variables in function scope cannot be declared static}}
 
-  extern constant float L5;
-  extern local float L6; // expected-error{{extern variable must reside in constant address space}}
-
-  static int L7 = 0; // expected-error{{variables in function scope cannot be declared static}}
-  static int L8; // expected-error{{variables in function scope cannot be declared static}}
+  extern float l_implicit_extern_var; // expected-error {{extern variable must reside in constant address space}}
+  extern constant float l_constant_extern_var;
+  extern global float l_global_extern_var;   // expected-error {{extern variable must reside in constant address space}}
+  extern local float l_local_extern_var; // expected-error {{extern variable must reside in constant address space}}
+  extern private float l_private_extern_var; // expec

Re: [libcxx] r314949 - [libc++] Allow users to explicitly specify ABI

[Eric Fiselier via cfe-commits]

On Wed, Oct 4, 2017 at 5:44 PM, Shoaib Meenai via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: smeenai
> Date: Wed Oct  4 16:44:38 2017
> New Revision: 314949
>
> URL: http://llvm.org/viewvc/llvm-project?rev=314949&view=rev
> Log:
> [libc++] Allow users to explicitly specify ABI
>
> libc++'s current heuristic for detecting Itanium vs. Microsoft ABI falls
> short in some cases. For example, it will detect windows-itanium targets
> as using the Microsoft ABI, since they set `_MSC_VER` (for compatibility
> with Microsoft headers). Leave the current heuristic in place by default
> but also allow users to explicitly specify the ABI if need be.
>
> Modified:
> libcxx/trunk/CMakeLists.txt
> libcxx/trunk/include/__config
> libcxx/trunk/include/__config_site.in
>
> Modified: libcxx/trunk/CMakeLists.txt
> URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/
> CMakeLists.txt?rev=314949&r1=314948&r2=314949&view=diff
> 
> ==
> --- libcxx/trunk/CMakeLists.txt (original)
> +++ libcxx/trunk/CMakeLists.txt Wed Oct  4 16:44:38 2017
> @@ -99,6 +99,8 @@ cmake_dependent_option(LIBCXX_INSTALL_EX
>  "LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY;LIBCXX_INSTALL_LIBRARY" OFF)
>  set(LIBCXX_ABI_VERSION 1 CACHE STRING "ABI version of libc++.")
>  option(LIBCXX_ABI_UNSTABLE "Unstable ABI of libc++." OFF)
> +option(LIBCXX_ABI_ITANIUM "Ignore auto-detection and force use of the
> Itanium ABI.")
> +option(LIBCXX_ABI_MICROSOFT "Ignore auto-detection and force use of the
> Microsoft ABI.")
>

Shouldn't these specify a default option?


>  option(LIBCXX_USE_COMPILER_RT "Use compiler-rt instead of libgcc" OFF)
>
>  if (NOT LIBCXX_ENABLE_SHARED AND NOT LIBCXX_ENABLE_STATIC)
> @@ -337,6 +339,10 @@ if (LIBCXX_HAS_MUSL_LIBC AND NOT LIBCXX_
>"when building for Musl with LIBCXX_HAS_MUSL_LIBC.")
>  endif()
>
> +if (LIBCXX_ABI_ITANIUM AND LIBCXX_ABI_MICROSOFT)
> +  message(FATAL_ERROR "Only one of LIBCXX_ABI_ITANIUM and
> LIBCXX_ABI_MICROSOFT can be specified.")
> +endif ()
> +
>  #===
> 
>  # Configure System
>  #===
> 
> @@ -594,6 +600,8 @@ if (NOT LIBCXX_ABI_VERSION EQUAL "1")
>config_define(${LIBCXX_ABI_VERSION} _LIBCPP_ABI_VERSION)
>  endif()
>  config_define_if(LIBCXX_ABI_UNSTABLE _LIBCPP_ABI_UNSTABLE)
> +config_define_if(LIBCXX_ABI_ITANIUM _LIBCPP_ABI_ITANIUM)
> +config_define_if(LIBCXX_ABI_MICROSOFT _LIBCPP_ABI_MICROSOFT)
>
> I'm not a fan of the direction this is going in. It seems to require the
generation and use of a __config_site header
in all cases where it's used. I don't think we want to require that in the
common case where you're using Itanium on
Linux or Windows.

However, like you said, the attempt of this is to override the automatic
detection done in the headers. Maybe the name
should reflect that (Ex. _LIBCPP_ABI_ITANIUM_OVERRIDE)? And then the
autodetection can operate by checking for an override first?


>  config_define_if_not(LIBCXX_ENABLE_GLOBAL_FILESYSTEM_NAMESPACE
> _LIBCPP_HAS_NO_GLOBAL_FILESYSTEM_NAMESPACE)
>  config_define_if_not(LIBCXX_ENABLE_STDIN _LIBCPP_HAS_NO_STDIN)
>
> Modified: libcxx/trunk/include/__config
> URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/_
> _config?rev=314949&r1=314948&r2=314949&view=diff
> 
> ==
> --- libcxx/trunk/include/__config (original)
> +++ libcxx/trunk/include/__config Wed Oct  4 16:44:38 2017
> @@ -157,11 +157,15 @@
>
>  // FIXME: ABI detection should be done via compiler builtin macros. This
>  // is just a placeholder until Clang implements such macros. For now
> assume
> -// that Windows compilers pretending to be MSVC++ target the microsoft
> ABI.
> -#if defined(_WIN32) && defined(_MSC_VER)
> -# define _LIBCPP_ABI_MICROSOFT
> -#else
> -# define _LIBCPP_ABI_ITANIUM
> +// that Windows compilers pretending to be MSVC++ target the Microsoft
> ABI,
> +// and allow the user to explicitly specify the ABI to handle cases where
> this
> +// heuristic falls short.
> +#if !defined(_LIBCPP_ABI_ITANIUM) && !defined(_LIBCPP_ABI_MICROSOFT)
> +# if defined(_WIN32) && defined(_MSC_VER)
> +#  define _LIBCPP_ABI_MICROSOFT
> +# else
> +#  define _LIBCPP_ABI_ITANIUM
> +# endif
>  #endif
>
>  // Need to detect which libc we're using if we're on Linux.
>
> Modified: libcxx/trunk/include/__config_site.in
> URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/_
> _config_site.in?rev=314949&r1=314948&r2=314949&view=diff
> 
> ==
> --- libcxx/trunk/include/__config_site.in (original)
> +++ libcxx/trunk/include/__config_site.in Wed Oct  4 16:44:38 2017
> @@ -12,6 +12,8 @@
>
>  #cmakedefine _LIBCPP_ABI_VERSION @_LIBCPP_ABI_VERSION@
>  #cmakedefine _LIBCPP_A

r314960 - [Analyzer Tests] Fix misc bugs in analyzer reference results updater.

[George Karpenkov via cfe-commits]

Author: george.karpenkov
Date: Wed Oct  4 18:02:20 2017
New Revision: 314960

URL: http://llvm.org/viewvc/llvm-project?rev=314960&view=rev
Log:
[Analyzer Tests] Fix misc bugs in analyzer reference results updater.

Modified:
cfe/trunk/utils/analyzer/SATestUpdateDiffs.py

Modified: cfe/trunk/utils/analyzer/SATestUpdateDiffs.py
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/utils/analyzer/SATestUpdateDiffs.py?rev=314960&r1=314959&r2=314960&view=diff
==
--- cfe/trunk/utils/analyzer/SATestUpdateDiffs.py (original)
+++ cfe/trunk/utils/analyzer/SATestUpdateDiffs.py Wed Oct  4 18:02:20 2017
@@ -34,8 +34,11 @@ def updateReferenceResults(ProjName, Pro
  "previously run?"
 sys.exit(-1)
 
-# Remove reference results.
-runCmd('git rm -r "%s"' % (RefResultsPath,))
+# Remove reference results: in git, and then again for a good measure
+# with rm, as git might not remove things fully if there are empty
+# directories involved.
+runCmd('git rm -r -q "%s"' % (RefResultsPath,))
+runCmd('rm -rf "%s"' % (RefResultsPath,))
 
 # Replace reference results with a freshly computed once.
 runCmd('cp -r "%s" "%s"' % (CreatedResultsPath, RefResultsPath,))
@@ -52,12 +55,21 @@ def updateReferenceResults(ProjName, Pro
 SATestBuild.cleanupReferenceResults(RefResultsPath)
 
 # Remove the created .diffs file before adding.
-runCmd('rm -f "%s/*/%s"' % (
-RefResultsPath, SATestBuild.DiffsSummaryFileName))
+removeDiffsSummaryFiles(RefResultsPath)
 
 runCmd('git add "%s"' % (RefResultsPath,))
 
 
+def removeDiffsSummaryFiles(RefResultsPath):
+"""
+Remove all auto-generated .diffs files in reference data.
+"""
+for (Dirpath, Dirnames, Filenames) in os.walk(RefResultsPath):
+if SATestBuild.DiffsSummaryFileName in Filenames:
+runCmd("rm '%s'" % os.path.join(
+Dirpath, SATestBuild.DiffsSummaryFileName))
+
+
 def main(argv):
 if len(argv) == 2 and argv[1] in ('-h', '--help'):
 print >> sys.stderr, "Update static analyzer reference results based "\


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

[PATCH] D38101: [Sema] Diagnose tautological comparison with type's min/max values

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

Thanks for the refactoring :)




Comment at: lib/Sema/SemaChecking.cpp:8697
+
+  return true;
 }

lebedev.ri wrote:
> If the diagnostic we are about to output is disabled, should we still `return 
> true;` and suppress potential `-Wsign-compare` warning?
The general principle is to behave as if we produced all diagnostics, and then 
filtered out the ones that aren't enabled. So if a more specialized (eg 
tautological comparison) diagnostic is disabled, the more general (eg sign 
compare) diagnostic should not appear. In short, this is fine :)



Comment at: lib/Sema/SemaChecking.cpp:8719
+  // Type limit values are handled later by CheckTautologicalComparison().
+  if (IsTypeLimit(S, Other, Constant, ConstValue) && (!OtherIsBooleanType))
 return;

Is this necessary? (Aren't the type limit values always within the range of the 
type in question?)

Can we avoid evaluating `Constant` a extra time here? (We already have its 
value in `Value`.)


Repository:
  rL LLVM

https://reviews.llvm.org/D38101



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

r314957 - Add testcase for r314956:

[Richard Smith via cfe-commits]

Author: rsmith
Date: Wed Oct  4 17:48:18 2017
New Revision: 314957

URL: http://llvm.org/viewvc/llvm-project?rev=314957&view=rev
Log:
Add testcase for r314956:

PR33924: Merge block-scope anonymous declarations if there are multiple 
definitions of the enclosing function.

Added:
cfe/trunk/test/Modules/merge-lambdas.cpp

Added: cfe/trunk/test/Modules/merge-lambdas.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/merge-lambdas.cpp?rev=314957&view=auto
==
--- cfe/trunk/test/Modules/merge-lambdas.cpp (added)
+++ cfe/trunk/test/Modules/merge-lambdas.cpp Wed Oct  4 17:48:18 2017
@@ -0,0 +1,43 @@
+// RUN: %clang_cc1 -std=c++11 -emit-llvm-only -fmodules %s
+
+// PR33924: ensure that we merge together local lambas in multiple definitions
+// of the same function.
+
+#pragma clang module build format
+module format {}
+#pragma clang module contents
+#pragma clang module begin format
+struct A { template void doFormat(T &&out) {} };
+template void format(T t) { A().doFormat([]{}); }
+#pragma clang module end
+#pragma clang module endbuild
+
+#pragma clang module build foo1
+module foo1 { export * }
+#pragma clang module contents
+#pragma clang module begin foo1
+#pragma clang module import format
+inline void foo1() {
+  format(0);
+}
+#pragma clang module end
+#pragma clang module endbuild
+
+#pragma clang module build foo2
+module foo2 { export * }
+#pragma clang module contents
+#pragma clang module begin foo2
+#pragma clang module import format
+inline void foo2() {
+  format(0);
+}
+#pragma clang module end
+#pragma clang module endbuild
+
+#pragma clang module import foo1
+#pragma clang module import foo2
+
+int main() {
+  foo1();
+  foo2();
+}


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

r314955 - Remove PendingBody mechanism for function and ObjC method deserialization.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Wed Oct  4 17:43:38 2017
New Revision: 314955

URL: http://llvm.org/viewvc/llvm-project?rev=314955&view=rev
Log:
Remove PendingBody mechanism for function and ObjC method deserialization.

In its place, track on the canonical function declaration whether there is a
declaration with a body (and if so, which one). This brings function definition
handling in line with what we do in all other contexts, and is necessary to
allow us to merge declarations within multiple definitions of the same function
(eg, PR33924).

No functionality change intended.

Modified:
cfe/trunk/include/clang/Serialization/ASTReader.h
cfe/trunk/lib/Serialization/ASTReader.cpp
cfe/trunk/lib/Serialization/ASTReaderDecl.cpp

Modified: cfe/trunk/include/clang/Serialization/ASTReader.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Serialization/ASTReader.h?rev=314955&r1=314954&r2=314955&view=diff
==
--- cfe/trunk/include/clang/Serialization/ASTReader.h (original)
+++ cfe/trunk/include/clang/Serialization/ASTReader.h Wed Oct  4 17:43:38 2017
@@ -559,13 +559,9 @@ private:
   /// declarations that have not yet been linked to their definitions.
   llvm::SmallPtrSet PendingDefinitions;
 
-  typedef llvm::MapVector,
-  SmallVector, 4> >
-PendingBodiesMap;
-
-  /// \brief Functions or methods that have bodies that will be attached.
-  PendingBodiesMap PendingBodies;
+  /// \brief Functions or methods that are known to already have a definition
+  /// (that might not yet be merged into the redeclaration chain).
+  llvm::SmallDenseMap FunctionDefinitions;
 
   /// \brief Definitions for which we have added merged definitions but not yet
   /// performed deduplication.
@@ -991,25 +987,13 @@ private:
   /// the last time we loaded information about this identifier.
   llvm::DenseMap IdentifierGeneration;
 
-  class InterestingDecl {
-Decl *D;
-bool DeclHasPendingBody;
-
-  public:
-InterestingDecl(Decl *D, bool HasBody)
-: D(D), DeclHasPendingBody(HasBody) {}
-Decl *getDecl() { return D; }
-/// Whether the declaration has a pending body.
-bool hasPendingBody() { return DeclHasPendingBody; }
-  };
-
   /// \brief Contains declarations and definitions that could be
   /// "interesting" to the ASTConsumer, when we get that AST consumer.
   ///
   /// "Interesting" declarations are those that have data that may
   /// need to be emitted, such as inline function definitions or
   /// Objective-C protocols.
-  std::deque PotentiallyInterestingDecls;
+  std::deque PotentiallyInterestingDecls;
 
   /// \brief The list of redeclaration chains that still need to be 
   /// reconstructed, and the local offset to the corresponding list

Modified: cfe/trunk/lib/Serialization/ASTReader.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTReader.cpp?rev=314955&r1=314954&r2=314955&view=diff
==
--- cfe/trunk/lib/Serialization/ASTReader.cpp (original)
+++ cfe/trunk/lib/Serialization/ASTReader.cpp Wed Oct  4 17:43:38 2017
@@ -9168,30 +9168,6 @@ void ASTReader::finishPendingActions() {
   }
   PendingDefinitions.clear();
 
-  // Load the bodies of any functions or methods we've encountered. We do
-  // this now (delayed) so that we can be sure that the declaration chains
-  // have been fully wired up (hasBody relies on this).
-  // FIXME: We shouldn't require complete redeclaration chains here.
-  for (PendingBodiesMap::iterator PB = PendingBodies.begin(),
-   PBEnd = PendingBodies.end();
-   PB != PBEnd; ++PB) {
-if (FunctionDecl *FD = dyn_cast(PB->first)) {
-  // FIXME: Check for =delete/=default?
-  // FIXME: Complain about ODR violations here?
-  const FunctionDecl *Defn = nullptr;
-  if (!getContext().getLangOpts().Modules || !FD->hasBody(Defn)) {
-FD->setLazyBody(PB->second);
-  } else
-mergeDefinitionVisibility(const_cast(Defn), FD);
-  continue;
-}
-
-ObjCMethodDecl *MD = cast(PB->first);
-if (!getContext().getLangOpts().Modules || !MD->hasBody())
-  MD->setLazyBody(PB->second);
-  }
-  PendingBodies.clear();
-
   // Do some cleanup.
   for (auto *ND : PendingMergedDefinitionsToDeduplicate)
 getContext().deduplicateMergedDefinitonsFor(ND);

Modified: cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTReaderDecl.cpp?rev=314955&r1=314954&r2=314955&view=diff
==
--- cfe/trunk/lib/Serialization/ASTReaderDecl.cpp (original)
+++ cfe/trunk/lib/Serialization/ASTReaderDecl.cpp Wed Oct  4 17:43:38 2017
@@ -45,8 +45,6 @@ namespace clang {
 GlobalDeclID NamedDeclForTagDecl;
 IdentifierInfo *TypedefNameForLinkage;
 
-bool HasPendingBody;
-
 

Re: r314262 - Emit section information for extern variables.

[Nico Weber via cfe-commits]

That does the trick. Thanks for the quick help, everyone!

On Wed, Oct 4, 2017 at 6:18 PM, Keane, Erich  wrote:

> Elizabeth gave me a patch, submitted it with a test in r314939
>
>
>
> *From:* Andrews, Elizabeth
> *Sent:* Wednesday, October 4, 2017 1:54 PM
> *To:* Friedman, Eli ; Keane, Erich <
> erich.ke...@intel.com>; Nico Weber 
> *Cc:* cfe-commits 
> *Subject:* RE: r314262 - Emit section information for extern variables.
>
>
>
> Alright. Will do. Thanks!
>
>
>
> *From:* Friedman, Eli [mailto:efrie...@codeaurora.org
> ]
> *Sent:* Wednesday, October 4, 2017 4:51 PM
> *To:* Keane, Erich ; Andrews, Elizabeth <
> elizabeth.andr...@intel.com>; Nico Weber 
> *Cc:* cfe-commits 
> *Subject:* Re: r314262 - Emit section information for extern variables.
>
>
>
> On 10/4/2017 1:48 PM, Keane, Erich wrote:
>
> Ah, cool!  I didn’t realize that, and that is actually exactly what
> Elizabeth is looking into now.
>
>
>
> Elizabeth, if you send me a diff, I’ll commit it as review-after-commit if
> Eli is alright with this.  It should be something like changing:
>
> +  if (VD->isThisDeclarationADefinition() != VarDecl::Definition) {
>
> To
>
> +  if (VD->isThisDeclarationADefinition() != VarDecl::Definition &&
> VD->isThsDeclarationADefinition() != VarDecl::TentativeDefinition) {
>
>
>
>
>
> Right?
>
>
> I'd probably just write it "if (VD->isThisDeclarationADefinition() ==
> VarDecl::DeclarationOnly)", but yes.  (And don't forget a testcase.)
>
> -Eli
>
>
>
> *From:* Friedman, Eli [mailto:efrie...@codeaurora.org
> ]
> *Sent:* Wednesday, October 4, 2017 1:46 PM
> *To:* Andrews, Elizabeth 
> ; Nico Weber 
> 
> *Cc:* cfe-commits 
> ; Keane, Erich 
> 
> *Subject:* Re: r314262 - Emit section information for extern variables.
>
>
>
> Oh, that's easy to explain; sorry, I didn't think of it when I was
> reviewing.
>
> DefinitionKind has three possible values: DeclarationOnly,
> TentativeDefinition, and Definition.  (Tentative definitions are C
> weirdness that allows you to write "int x; int x = 10;".)
>
> For the purpose of this warning, a TentativeDefinition should count as a
> definition.
>
> -Eli
>
> On 10/4/2017 1:38 PM, Andrews, Elizabeth wrote:
>
> Hello,
>
> I just spoke to Erich. The warning isn’t supposed to be emitted when the
> section attribute is specified on a definition. I’m not sure why struct
> r_debug _r_debug __attribute__((nocommon, section(".r_debug"))); failed
> the isThisDeclarationADefiniton check. I need to look into it.
>
> Thanks,
>
> Elizabeth
>
>
>
> *From:* tha...@google.com [mailto:tha...@google.com ] *On
> Behalf Of *Nico Weber
> *Sent:* Wednesday, October 4, 2017 4:29 PM
> *To:* Keane, Erich  
> *Cc:* Andrews, Elizabeth 
> ; Friedman, Eli 
> ; cfe-commits 
> 
> *Subject:* Re: r314262 - Emit section information for extern variables.
>
>
>
> All I know about this code that it used to build (and still builds with
> gcc) and now it doesn't, sorry :-) What that code does seems somewhat
> questionable, but also somewhat useful, and it feels like the behavior
> change from this change here for that code might have been unintentional.
>
>
>
> Your suggestion sounds reasonable to me.
>
>
>
> On Wed, Oct 4, 2017 at 4:18 PM, Keane, Erich 
> wrote:
>
> I saw that… I don’t see where it prevents the same change from being made
> in link.h.
>
>
>
> As I mentioned, there is a solution to make this Warning less aggressive
> (in the lib/Sema/SemaDecl.cpp changes, add a condition that Old->isUsed()
> before the warning.  I’m wondering if that solves your issue.
>
>
>
> It would result in
>
> extern struct r_debug _r_debug;
> struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));
>
> Compiling, but :
>
> extern struct r_debug _r_debug;
> r_debug = something();
> struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));
>
> NOT compiling (which is almost definitely a bug).
>
>
>
>
>
>
>
> *From:* tha...@google.com [mailto:tha...@google.com] *On Behalf Of *Nico
> Weber
> *Sent:* Wednesday, October 4, 2017 1:14 PM
> *To:* Keane, Erich 
> *Cc:* Andrews, Elizabeth ; Friedman, Eli <
> efrie...@codeaurora.org>; cfe-commits 
>
>
> *Subject:* Re: r314262 - Emit section information for extern variables.
>
>
>
> For why, here's the comment from the code I linked to:
>
>
>
> /*
>
>  * GDB looks for this symbol name when it cannot find PT_DYNAMIC->DT_DEBUG.
>
>  * We don't have a PT_DYNAMIC, so it will find this.  Now all we have to do
>
>  * is arrange for this space to be filled in with the dynamic linker's
>
>  * _r_debug contents after they're initialized.  That way, attaching GDB to
>
>  * this process or examining its core file will find the PIE we loaded, the
>
>  * dynamic linker, and all the shared libraries, making debugging pleasant.
>
>  */
>
>
>
> On Wed, Oct 4, 2017 at 4:11 PM, Keane, Erich 
> wrote:
>
> I’ve added Elizabeth, who is the original patch author.  Hopefully she can
> help out here.  Additionally, Eli did the original review, so hopefully he
> can chime in as well.

[PATCH] D38525: Cleanup and generalize -shared-libasan.

[Evgenii Stepanov via Phabricator via cfe-commits]

eugenis updated this revision to Diff 117767.
eugenis added a comment.

renamed flags to *-libsan


https://reviews.llvm.org/D38525

Files:
  clang/include/clang/Driver/Options.td
  clang/include/clang/Driver/SanitizerArgs.h
  clang/lib/Driver/SanitizerArgs.cpp
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Driver/ToolChains/Fuchsia.cpp
  clang/lib/Driver/ToolChains/MSVC.cpp
  clang/test/Driver/sanitizer-ld.c

Index: clang/test/Driver/sanitizer-ld.c
===
--- clang/test/Driver/sanitizer-ld.c
+++ clang/test/Driver/sanitizer-ld.c
@@ -16,11 +16,24 @@
 // CHECK-ASAN-LINUX: "-lrt"
 // CHECK-ASAN-LINUX: "-ldl"
 
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: -target i386-unknown-linux -fuse-ld=ld -fsanitize=address -shared-libsan \
+// RUN: -resource-dir=%S/Inputs/resource_dir \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-SHARED-ASAN-LINUX %s
+
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: -target i386-unknown-linux -fuse-ld=ld -fsanitize=address -shared-libasan \
 // RUN: -resource-dir=%S/Inputs/resource_dir \
 // RUN: --sysroot=%S/Inputs/basic_linux_tree \
 // RUN:   | FileCheck --check-prefix=CHECK-SHARED-ASAN-LINUX %s
+
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: -target i386-unknown-linux -fuse-ld=ld -fsanitize=address \
+// RUN: -shared-libsan -static-libsan -shared-libasan \
+// RUN: -resource-dir=%S/Inputs/resource_dir \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-SHARED-ASAN-LINUX %s
 //
 // CHECK-SHARED-ASAN-LINUX: "{{(.*[^-.0-9A-Z_a-z])?}}ld{{(.exe)?}}"
 // CHECK-SHARED-ASAN-LINUX-NOT: "-lc"
@@ -34,7 +47,7 @@
 // CHECK-SHARED-ASAN-LINUX-NOT: "--dynamic-list"
 
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.so -shared 2>&1 \
-// RUN: -target i386-unknown-linux -fuse-ld=ld -fsanitize=address -shared-libasan \
+// RUN: -target i386-unknown-linux -fuse-ld=ld -fsanitize=address -shared-libsan \
 // RUN: -resource-dir=%S/Inputs/resource_dir \
 // RUN: --sysroot=%S/Inputs/basic_linux_tree \
 // RUN:   | FileCheck --check-prefix=CHECK-DSO-SHARED-ASAN-LINUX %s
@@ -131,6 +144,39 @@
 // CHECK-ASAN-ANDROID-NOT: "-lpthread"
 // CHECK-ASAN-ANDROID: libclang_rt.asan-arm-android.so"
 // CHECK-ASAN-ANDROID-NOT: "-lpthread"
+
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: -target arm-linux-androideabi -fuse-ld=ld -fsanitize=address \
+// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
+// RUN: -static-libsan \
+// RUN:   | FileCheck --check-prefix=CHECK-ASAN-ANDROID-STATICLIBASAN %s
+//
+// CHECK-ASAN-ANDROID-STATICLIBASAN: "{{(.*[^.0-9A-Z_a-z])?}}ld{{(.exe)?}}"
+// CHECK-ASAN-ANDROID-STATICLIBASAN: libclang_rt.asan-arm-android.a"
+// CHECK-ASAN-ANDROID-STATICLIBASAN: "-lpthread"
+
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: -target arm-linux-androideabi -fuse-ld=ld -fsanitize=undefined \
+// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
+// RUN:   | FileCheck --check-prefix=CHECK-UBSAN-ANDROID %s
+//
+// CHECK-UBSAN-ANDROID: "{{(.*[^.0-9A-Z_a-z])?}}ld{{(.exe)?}}"
+// CHECK-UBSAN-ANDROID-NOT: "-lc"
+// CHECK-UBSAN-ANDROID-NOT: "-pie"
+// CHECK-UBSAN-ANDROID-NOT: "-lpthread"
+// CHECK-UBSAN-ANDROID: libclang_rt.ubsan_standalone-arm-android.so"
+// CHECK-UBSAN-ANDROID-NOT: "-lpthread"
+
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: -target arm-linux-androideabi -fuse-ld=ld -fsanitize=undefined \
+// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
+// RUN: -static-libsan \
+// RUN:   | FileCheck --check-prefix=CHECK-UBSAN-ANDROID-STATICLIBASAN %s
+//
+// CHECK-UBSAN-ANDROID-STATICLIBASAN: "{{(.*[^.0-9A-Z_a-z])?}}ld{{(.exe)?}}"
+// CHECK-UBSAN-ANDROID-STATICLIBASAN: libclang_rt.ubsan_standalone-arm-android.a"
+// CHECK-UBSAN-ANDROID-STATICLIBASAN: "-lpthread"
+
 //
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: -target i686-linux-android -fuse-ld=ld -fsanitize=address \
@@ -147,10 +193,10 @@
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: -target arm-linux-androideabi -fsanitize=address \
 // RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
-// RUN: -shared-libasan \
+// RUN: -shared-libsan \
 // RUN:   | FileCheck --check-prefix=CHECK-ASAN-ANDROID-SHARED-LIBASAN %s
 //
-// CHECK-ASAN-ANDROID-SHARED-LIBASAN-NOT: argument unused during compilation: '-shared-libasan'
+// CHECK-ASAN-ANDROID-SHARED-LIBASAN-NOT: argument unused during compilation: '-shared-libsan'
 //
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: -target arm-linux-androideabi -fuse-ld=ld -fsanitize=address \
@@ -214,6 +260,13 @@
 // RUN: -target i386-unknown-linux -fuse-ld=ld \
 // RUN: --sysroot=%S/Inputs/basic_linu

[libcxx] r314950 - [libc++] Move cache variable definition. NFC

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Wed Oct  4 16:51:57 2017
New Revision: 314950

URL: http://llvm.org/viewvc/llvm-project?rev=314950&view=rev
Log:
[libc++] Move cache variable definition. NFC

Move it to where the other ABI cache variables/options are defined.

Modified:
libcxx/trunk/CMakeLists.txt

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=314950&r1=314949&r2=314950&view=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Wed Oct  4 16:51:57 2017
@@ -101,6 +101,7 @@ set(LIBCXX_ABI_VERSION 1 CACHE STRING "A
 option(LIBCXX_ABI_UNSTABLE "Unstable ABI of libc++." OFF)
 option(LIBCXX_ABI_ITANIUM "Ignore auto-detection and force use of the Itanium 
ABI.")
 option(LIBCXX_ABI_MICROSOFT "Ignore auto-detection and force use of the 
Microsoft ABI.")
+set(LIBCXX_ABI_DEFINES "" CACHE STRING "A semicolon separated list of ABI 
macros to define in the site config header.")
 option(LIBCXX_USE_COMPILER_RT "Use compiler-rt instead of libgcc" OFF)
 
 if (NOT LIBCXX_ENABLE_SHARED AND NOT LIBCXX_ENABLE_STATIC)
@@ -615,7 +616,6 @@ config_define_if(LIBCXX_HAS_EXTERNAL_THR
 config_define_if(LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY 
_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL)
 config_define_if(LIBCXX_HAS_MUSL_LIBC _LIBCPP_HAS_MUSL_LIBC)
 
-set(LIBCXX_ABI_DEFINES "" CACHE STRING "A semicolon separated list of ABI 
macros to define in the site config header")
 if (LIBCXX_ABI_DEFINES)
   set(abi_defines)
   foreach (abi_define ${LIBCXX_ABI_DEFINES})


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

[libcxx] r314949 - [libc++] Allow users to explicitly specify ABI

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Wed Oct  4 16:44:38 2017
New Revision: 314949

URL: http://llvm.org/viewvc/llvm-project?rev=314949&view=rev
Log:
[libc++] Allow users to explicitly specify ABI

libc++'s current heuristic for detecting Itanium vs. Microsoft ABI falls
short in some cases. For example, it will detect windows-itanium targets
as using the Microsoft ABI, since they set `_MSC_VER` (for compatibility
with Microsoft headers). Leave the current heuristic in place by default
but also allow users to explicitly specify the ABI if need be.

Modified:
libcxx/trunk/CMakeLists.txt
libcxx/trunk/include/__config
libcxx/trunk/include/__config_site.in

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=314949&r1=314948&r2=314949&view=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Wed Oct  4 16:44:38 2017
@@ -99,6 +99,8 @@ cmake_dependent_option(LIBCXX_INSTALL_EX
 "LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY;LIBCXX_INSTALL_LIBRARY" OFF)
 set(LIBCXX_ABI_VERSION 1 CACHE STRING "ABI version of libc++.")
 option(LIBCXX_ABI_UNSTABLE "Unstable ABI of libc++." OFF)
+option(LIBCXX_ABI_ITANIUM "Ignore auto-detection and force use of the Itanium 
ABI.")
+option(LIBCXX_ABI_MICROSOFT "Ignore auto-detection and force use of the 
Microsoft ABI.")
 option(LIBCXX_USE_COMPILER_RT "Use compiler-rt instead of libgcc" OFF)
 
 if (NOT LIBCXX_ENABLE_SHARED AND NOT LIBCXX_ENABLE_STATIC)
@@ -337,6 +339,10 @@ if (LIBCXX_HAS_MUSL_LIBC AND NOT LIBCXX_
   "when building for Musl with LIBCXX_HAS_MUSL_LIBC.")
 endif()
 
+if (LIBCXX_ABI_ITANIUM AND LIBCXX_ABI_MICROSOFT)
+  message(FATAL_ERROR "Only one of LIBCXX_ABI_ITANIUM and LIBCXX_ABI_MICROSOFT 
can be specified.")
+endif ()
+
 
#===
 # Configure System
 
#===
@@ -594,6 +600,8 @@ if (NOT LIBCXX_ABI_VERSION EQUAL "1")
   config_define(${LIBCXX_ABI_VERSION} _LIBCPP_ABI_VERSION)
 endif()
 config_define_if(LIBCXX_ABI_UNSTABLE _LIBCPP_ABI_UNSTABLE)
+config_define_if(LIBCXX_ABI_ITANIUM _LIBCPP_ABI_ITANIUM)
+config_define_if(LIBCXX_ABI_MICROSOFT _LIBCPP_ABI_MICROSOFT)
 
 config_define_if_not(LIBCXX_ENABLE_GLOBAL_FILESYSTEM_NAMESPACE 
_LIBCPP_HAS_NO_GLOBAL_FILESYSTEM_NAMESPACE)
 config_define_if_not(LIBCXX_ENABLE_STDIN _LIBCPP_HAS_NO_STDIN)

Modified: libcxx/trunk/include/__config
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__config?rev=314949&r1=314948&r2=314949&view=diff
==
--- libcxx/trunk/include/__config (original)
+++ libcxx/trunk/include/__config Wed Oct  4 16:44:38 2017
@@ -157,11 +157,15 @@
 
 // FIXME: ABI detection should be done via compiler builtin macros. This
 // is just a placeholder until Clang implements such macros. For now assume
-// that Windows compilers pretending to be MSVC++ target the microsoft ABI.
-#if defined(_WIN32) && defined(_MSC_VER)
-# define _LIBCPP_ABI_MICROSOFT
-#else
-# define _LIBCPP_ABI_ITANIUM
+// that Windows compilers pretending to be MSVC++ target the Microsoft ABI,
+// and allow the user to explicitly specify the ABI to handle cases where this
+// heuristic falls short.
+#if !defined(_LIBCPP_ABI_ITANIUM) && !defined(_LIBCPP_ABI_MICROSOFT)
+# if defined(_WIN32) && defined(_MSC_VER)
+#  define _LIBCPP_ABI_MICROSOFT
+# else
+#  define _LIBCPP_ABI_ITANIUM
+# endif
 #endif
 
 // Need to detect which libc we're using if we're on Linux.

Modified: libcxx/trunk/include/__config_site.in
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__config_site.in?rev=314949&r1=314948&r2=314949&view=diff
==
--- libcxx/trunk/include/__config_site.in (original)
+++ libcxx/trunk/include/__config_site.in Wed Oct  4 16:44:38 2017
@@ -12,6 +12,8 @@
 
 #cmakedefine _LIBCPP_ABI_VERSION @_LIBCPP_ABI_VERSION@
 #cmakedefine _LIBCPP_ABI_UNSTABLE
+#cmakedefine _LIBCPP_ABI_ITANIUM
+#cmakedefine _LIBCPP_ABI_MICROSOFT
 #cmakedefine _LIBCPP_HAS_NO_GLOBAL_FILESYSTEM_NAMESPACE
 #cmakedefine _LIBCPP_HAS_NO_STDIN
 #cmakedefine _LIBCPP_HAS_NO_STDOUT


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

[libcxx] r314947 - Fix accidental assignment inside test asserts

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Wed Oct  4 16:21:18 2017
New Revision: 314947

URL: http://llvm.org/viewvc/llvm-project?rev=314947&view=rev
Log:
Fix accidental assignment inside test asserts

Modified:

libcxx/trunk/test/std/utilities/utility/pairs/pairs.pair/const_pair_U_V.pass.cpp

libcxx/trunk/test/std/utilities/utility/pairs/pairs.pair/rv_pair_U_V.pass.cpp

Modified: 
libcxx/trunk/test/std/utilities/utility/pairs/pairs.pair/const_pair_U_V.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/utilities/utility/pairs/pairs.pair/const_pair_U_V.pass.cpp?rev=314947&r1=314946&r2=314947&view=diff
==
--- 
libcxx/trunk/test/std/utilities/utility/pairs/pairs.pair/const_pair_U_V.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/utilities/utility/pairs/pairs.pair/const_pair_U_V.pass.cpp
 Wed Oct  4 16:21:18 2017
@@ -71,7 +71,7 @@ int main()
 P1 p1(42, 101);
 P2 p2(p1);
 assert(p2.first == 42);
-assert(p2.second = 101);
+assert(p2.second == 101);
 }
 {
 test_pair_const(); // copy construction

Modified: 
libcxx/trunk/test/std/utilities/utility/pairs/pairs.pair/rv_pair_U_V.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/utilities/utility/pairs/pairs.pair/rv_pair_U_V.pass.cpp?rev=314947&r1=314946&r2=314947&view=diff
==
--- 
libcxx/trunk/test/std/utilities/utility/pairs/pairs.pair/rv_pair_U_V.pass.cpp 
(original)
+++ 
libcxx/trunk/test/std/utilities/utility/pairs/pairs.pair/rv_pair_U_V.pass.cpp 
Wed Oct  4 16:21:18 2017
@@ -81,7 +81,7 @@ int main()
 P1 p1(42, 101);
 P2 p2(std::move(p1));
 assert(p2.first == 42);
-assert(p2.second = 101);
+assert(p2.second == 101);
 }
 {
 test_pair_rv();


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

[PATCH] D36719: [libc++] Add site config option for ABI macros

[Shoaib Meenai via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL314946: [libc++] Add site config option for ABI macros 
(authored by smeenai).

Changed prior to commit:
  https://reviews.llvm.org/D36719?vs=117758&id=117759#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D36719

Files:
  libcxx/trunk/CMakeLists.txt
  libcxx/trunk/docs/BuildingLibcxx.rst
  libcxx/trunk/include/__config_site.in
  libcxx/trunk/utils/libcxx/test/config.py


Index: libcxx/trunk/CMakeLists.txt
===
--- libcxx/trunk/CMakeLists.txt
+++ libcxx/trunk/CMakeLists.txt
@@ -607,6 +607,19 @@
 config_define_if(LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY 
_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL)
 config_define_if(LIBCXX_HAS_MUSL_LIBC _LIBCPP_HAS_MUSL_LIBC)
 
+set(LIBCXX_ABI_DEFINES "" CACHE STRING "A semicolon separated list of ABI 
macros to define in the site config header")
+if (LIBCXX_ABI_DEFINES)
+  set(abi_defines)
+  foreach (abi_define ${LIBCXX_ABI_DEFINES})
+if (NOT abi_define MATCHES "^_LIBCPP_ABI_")
+  message(SEND_ERROR "Invalid ABI macro ${abi_define} in 
LIBCXX_ABI_DEFINES")
+endif()
+list(APPEND abi_defines "#define ${abi_define}")
+  endforeach()
+  string(REPLACE ";" "\n" abi_defines "${abi_defines}")
+  config_define(${abi_defines} _LIBCPP_ABI_DEFINES)
+endif()
+
 # By default libc++ on Windows expects to use a shared library, which requires
 # the headers to use DLL import/export semantics. However when building a
 # static library only we modify the headers to disable DLL import/export.
Index: libcxx/trunk/utils/libcxx/test/config.py
===
--- libcxx/trunk/utils/libcxx/test/config.py
+++ libcxx/trunk/utils/libcxx/test/config.py
@@ -668,7 +668,7 @@
 self.config.available_features.add('libcpp-abi-version-v%s'
 % feature_macros[m])
 continue
-assert m.startswith('_LIBCPP_HAS_') or m == '_LIBCPP_ABI_UNSTABLE'
+assert m.startswith('_LIBCPP_HAS_') or m.startswith('_LIBCPP_ABI_')
 m = m.lower()[1:].replace('_', '-')
 self.config.available_features.add(m)
 return feature_macros
Index: libcxx/trunk/docs/BuildingLibcxx.rst
===
--- libcxx/trunk/docs/BuildingLibcxx.rst
+++ libcxx/trunk/docs/BuildingLibcxx.rst
@@ -347,6 +347,13 @@
   Build the "unstable" ABI version of libc++. Includes all ABI changing 
features
   on top of the current stable version.
 
+.. option:: LIBCXX_ABI_DEFINES:STRING
+
+  **Default**: ``""``
+
+  A semicolon-separated list of ABI macros to persist in the site config 
header.
+  See ``include/__config`` for the list of ABI macros.
+
 .. _LLVM-specific variables:
 
 LLVM-specific options
Index: libcxx/trunk/include/__config_site.in
===
--- libcxx/trunk/include/__config_site.in
+++ libcxx/trunk/include/__config_site.in
@@ -24,4 +24,6 @@
 #cmakedefine _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL
 #cmakedefine _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS
 
+@_LIBCPP_ABI_DEFINES@
+
 #endif // _LIBCPP_CONFIG_SITE


Index: libcxx/trunk/CMakeLists.txt
===
--- libcxx/trunk/CMakeLists.txt
+++ libcxx/trunk/CMakeLists.txt
@@ -607,6 +607,19 @@
 config_define_if(LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL)
 config_define_if(LIBCXX_HAS_MUSL_LIBC _LIBCPP_HAS_MUSL_LIBC)
 
+set(LIBCXX_ABI_DEFINES "" CACHE STRING "A semicolon separated list of ABI macros to define in the site config header")
+if (LIBCXX_ABI_DEFINES)
+  set(abi_defines)
+  foreach (abi_define ${LIBCXX_ABI_DEFINES})
+if (NOT abi_define MATCHES "^_LIBCPP_ABI_")
+  message(SEND_ERROR "Invalid ABI macro ${abi_define} in LIBCXX_ABI_DEFINES")
+endif()
+list(APPEND abi_defines "#define ${abi_define}")
+  endforeach()
+  string(REPLACE ";" "\n" abi_defines "${abi_defines}")
+  config_define(${abi_defines} _LIBCPP_ABI_DEFINES)
+endif()
+
 # By default libc++ on Windows expects to use a shared library, which requires
 # the headers to use DLL import/export semantics. However when building a
 # static library only we modify the headers to disable DLL import/export.
Index: libcxx/trunk/utils/libcxx/test/config.py
===
--- libcxx/trunk/utils/libcxx/test/config.py
+++ libcxx/trunk/utils/libcxx/test/config.py
@@ -668,7 +668,7 @@
 self.config.available_features.add('libcpp-abi-version-v%s'
 % feature_macros[m])
 continue
-assert m.startswith('_LIBCPP_HAS_') or m == '_LIBCPP_ABI_UNSTABLE'
+assert m.startswith('_LIBCPP_HAS_') or m.startswith('_LIBCPP_ABI_')
 m = m.lower()[1:].replace('_', '-')
 self.config.available_features.add(m)

[libcxx] r314946 - [libc++] Add site config option for ABI macros

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Wed Oct  4 16:17:12 2017
New Revision: 314946

URL: http://llvm.org/viewvc/llvm-project?rev=314946&view=rev
Log:
[libc++] Add site config option for ABI macros

Some ABI macros affect headers, so it's nice to have a site config
option for them. Add a LIBCXX_ABI_DEFINES cmake macro to allow
specifying a list of ABI macros to define in the site config.

The primary design constraint (as discussed with Eric on IRC a while
back) was to not have to repeat the ABI macro names in cmake, which only
leaves a free-form cmake list as an option. A somewhat unfortunate
consequence is that we can't verify that the ABI macros being defined
actually exist, though we can at least perform some basic sanity
checking, since all the ABI macros begin with _LIBCPP_ABI_.

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

Modified:
libcxx/trunk/CMakeLists.txt
libcxx/trunk/docs/BuildingLibcxx.rst
libcxx/trunk/include/__config_site.in
libcxx/trunk/utils/libcxx/test/config.py

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=314946&r1=314945&r2=314946&view=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Wed Oct  4 16:17:12 2017
@@ -607,6 +607,19 @@ config_define_if(LIBCXX_HAS_EXTERNAL_THR
 config_define_if(LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY 
_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL)
 config_define_if(LIBCXX_HAS_MUSL_LIBC _LIBCPP_HAS_MUSL_LIBC)
 
+set(LIBCXX_ABI_DEFINES "" CACHE STRING "A semicolon separated list of ABI 
macros to define in the site config header")
+if (LIBCXX_ABI_DEFINES)
+  set(abi_defines)
+  foreach (abi_define ${LIBCXX_ABI_DEFINES})
+if (NOT abi_define MATCHES "^_LIBCPP_ABI_")
+  message(SEND_ERROR "Invalid ABI macro ${abi_define} in 
LIBCXX_ABI_DEFINES")
+endif()
+list(APPEND abi_defines "#define ${abi_define}")
+  endforeach()
+  string(REPLACE ";" "\n" abi_defines "${abi_defines}")
+  config_define(${abi_defines} _LIBCPP_ABI_DEFINES)
+endif()
+
 # By default libc++ on Windows expects to use a shared library, which requires
 # the headers to use DLL import/export semantics. However when building a
 # static library only we modify the headers to disable DLL import/export.

Modified: libcxx/trunk/docs/BuildingLibcxx.rst
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/docs/BuildingLibcxx.rst?rev=314946&r1=314945&r2=314946&view=diff
==
--- libcxx/trunk/docs/BuildingLibcxx.rst (original)
+++ libcxx/trunk/docs/BuildingLibcxx.rst Wed Oct  4 16:17:12 2017
@@ -347,6 +347,13 @@ The following options allow building lib
   Build the "unstable" ABI version of libc++. Includes all ABI changing 
features
   on top of the current stable version.
 
+.. option:: LIBCXX_ABI_DEFINES:STRING
+
+  **Default**: ``""``
+
+  A semicolon-separated list of ABI macros to persist in the site config 
header.
+  See ``include/__config`` for the list of ABI macros.
+
 .. _LLVM-specific variables:
 
 LLVM-specific options

Modified: libcxx/trunk/include/__config_site.in
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__config_site.in?rev=314946&r1=314945&r2=314946&view=diff
==
--- libcxx/trunk/include/__config_site.in (original)
+++ libcxx/trunk/include/__config_site.in Wed Oct  4 16:17:12 2017
@@ -24,4 +24,6 @@
 #cmakedefine _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL
 #cmakedefine _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS
 
+@_LIBCPP_ABI_DEFINES@
+
 #endif // _LIBCPP_CONFIG_SITE

Modified: libcxx/trunk/utils/libcxx/test/config.py
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/utils/libcxx/test/config.py?rev=314946&r1=314945&r2=314946&view=diff
==
--- libcxx/trunk/utils/libcxx/test/config.py (original)
+++ libcxx/trunk/utils/libcxx/test/config.py Wed Oct  4 16:17:12 2017
@@ -668,7 +668,7 @@ class Configuration(object):
 self.config.available_features.add('libcpp-abi-version-v%s'
 % feature_macros[m])
 continue
-assert m.startswith('_LIBCPP_HAS_') or m == '_LIBCPP_ABI_UNSTABLE'
+assert m.startswith('_LIBCPP_HAS_') or m.startswith('_LIBCPP_ABI_')
 m = m.lower()[1:].replace('_', '-')
 self.config.available_features.add(m)
 return feature_macros


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

[PATCH] D36719: [libc++] Add site config option for ABI macros

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai updated this revision to Diff 117758.
smeenai added a comment.

Fix RST


https://reviews.llvm.org/D36719

Files:
  CMakeLists.txt
  docs/BuildingLibcxx.rst
  include/__config_site.in
  utils/libcxx/test/config.py


Index: utils/libcxx/test/config.py
===
--- utils/libcxx/test/config.py
+++ utils/libcxx/test/config.py
@@ -668,7 +668,7 @@
 self.config.available_features.add('libcpp-abi-version-v%s'
 % feature_macros[m])
 continue
-assert m.startswith('_LIBCPP_HAS_') or m == '_LIBCPP_ABI_UNSTABLE'
+assert m.startswith('_LIBCPP_HAS_') or m.startswith('_LIBCPP_ABI_')
 m = m.lower()[1:].replace('_', '-')
 self.config.available_features.add(m)
 return feature_macros
Index: include/__config_site.in
===
--- include/__config_site.in
+++ include/__config_site.in
@@ -24,4 +24,6 @@
 #cmakedefine _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL
 #cmakedefine _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS
 
+@_LIBCPP_ABI_DEFINES@
+
 #endif // _LIBCPP_CONFIG_SITE
Index: docs/BuildingLibcxx.rst
===
--- docs/BuildingLibcxx.rst
+++ docs/BuildingLibcxx.rst
@@ -347,6 +347,13 @@
   Build the "unstable" ABI version of libc++. Includes all ABI changing 
features
   on top of the current stable version.
 
+.. option:: LIBCXX_ABI_DEFINES:STRING
+
+  **Default**: ``""``
+
+  A semicolon-separated list of ABI macros which are persisted in the site
+  config header. See ``include/__config`` for the list of ABI macros.
+
 .. _LLVM-specific variables:
 
 LLVM-specific options
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -607,6 +607,19 @@
 config_define_if(LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY 
_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL)
 config_define_if(LIBCXX_HAS_MUSL_LIBC _LIBCPP_HAS_MUSL_LIBC)
 
+set(LIBCXX_ABI_DEFINES "" CACHE STRING "A semicolon separated list of ABI 
macros to define in the site config header")
+if (LIBCXX_ABI_DEFINES)
+  set(abi_defines)
+  foreach (abi_define ${LIBCXX_ABI_DEFINES})
+if (NOT abi_define MATCHES "^_LIBCPP_ABI_")
+  message(SEND_ERROR "Invalid ABI macro ${abi_define} in 
LIBCXX_ABI_DEFINES")
+endif()
+list(APPEND abi_defines "#define ${abi_define}")
+  endforeach()
+  string(REPLACE ";" "\n" abi_defines "${abi_defines}")
+  config_define(${abi_defines} _LIBCPP_ABI_DEFINES)
+endif()
+
 # By default libc++ on Windows expects to use a shared library, which requires
 # the headers to use DLL import/export semantics. However when building a
 # static library only we modify the headers to disable DLL import/export.


Index: utils/libcxx/test/config.py
===
--- utils/libcxx/test/config.py
+++ utils/libcxx/test/config.py
@@ -668,7 +668,7 @@
 self.config.available_features.add('libcpp-abi-version-v%s'
 % feature_macros[m])
 continue
-assert m.startswith('_LIBCPP_HAS_') or m == '_LIBCPP_ABI_UNSTABLE'
+assert m.startswith('_LIBCPP_HAS_') or m.startswith('_LIBCPP_ABI_')
 m = m.lower()[1:].replace('_', '-')
 self.config.available_features.add(m)
 return feature_macros
Index: include/__config_site.in
===
--- include/__config_site.in
+++ include/__config_site.in
@@ -24,4 +24,6 @@
 #cmakedefine _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL
 #cmakedefine _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS
 
+@_LIBCPP_ABI_DEFINES@
+
 #endif // _LIBCPP_CONFIG_SITE
Index: docs/BuildingLibcxx.rst
===
--- docs/BuildingLibcxx.rst
+++ docs/BuildingLibcxx.rst
@@ -347,6 +347,13 @@
   Build the "unstable" ABI version of libc++. Includes all ABI changing features
   on top of the current stable version.
 
+.. option:: LIBCXX_ABI_DEFINES:STRING
+
+  **Default**: ``""``
+
+  A semicolon-separated list of ABI macros which are persisted in the site
+  config header. See ``include/__config`` for the list of ABI macros.
+
 .. _LLVM-specific variables:
 
 LLVM-specific options
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -607,6 +607,19 @@
 config_define_if(LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL)
 config_define_if(LIBCXX_HAS_MUSL_LIBC _LIBCPP_HAS_MUSL_LIBC)
 
+set(LIBCXX_ABI_DEFINES "" CACHE STRING "A semicolon separated list of ABI macros to define in the site config header")
+if (LIBCXX_ABI_DEFINES)
+  set(abi_defines)
+  foreach (abi_define ${LIBCXX_ABI_DEFINES})
+if (NOT abi_define MATCHES "^_LIBCPP_ABI_")
+  message(SEND_ERROR "Invalid ABI macro ${abi_define}

[PATCH] D38525: Cleanup and generalize -shared-libasan.

[Vitaly Buka via Phabricator via cfe-commits]

vitalybuka added a comment.

In https://reviews.llvm.org/D38525#26, @rsmith wrote:

> Could we perhaps rename these flags to e.g. `-static-libsan` (with a 
> `-static-libasan` alias for compatibility)? It seems confusing that the way 
> to enable a static tsan runtime would be with `-static-libasan`.


I like this idea as well. If we go this way we need to deprecate 
"shared-libasan" and avoid adding "static-libasan.


https://reviews.llvm.org/D38525



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

[PATCH] D36719: [libc++] Add site config option for ABI macros

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai updated this revision to Diff 117757.
smeenai added a comment.

Address comments


https://reviews.llvm.org/D36719

Files:
  CMakeLists.txt
  docs/BuildingLibcxx.rst
  include/__config_site.in
  utils/libcxx/test/config.py


Index: utils/libcxx/test/config.py
===
--- utils/libcxx/test/config.py
+++ utils/libcxx/test/config.py
@@ -668,7 +668,7 @@
 self.config.available_features.add('libcpp-abi-version-v%s'
 % feature_macros[m])
 continue
-assert m.startswith('_LIBCPP_HAS_') or m == '_LIBCPP_ABI_UNSTABLE'
+assert m.startswith('_LIBCPP_HAS_') or m.startswith('_LIBCPP_ABI_')
 m = m.lower()[1:].replace('_', '-')
 self.config.available_features.add(m)
 return feature_macros
Index: include/__config_site.in
===
--- include/__config_site.in
+++ include/__config_site.in
@@ -24,4 +24,6 @@
 #cmakedefine _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL
 #cmakedefine _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS
 
+@_LIBCPP_ABI_DEFINES@
+
 #endif // _LIBCPP_CONFIG_SITE
Index: docs/BuildingLibcxx.rst
===
--- docs/BuildingLibcxx.rst
+++ docs/BuildingLibcxx.rst
@@ -347,6 +347,13 @@
   Build the "unstable" ABI version of libc++. Includes all ABI changing 
features
   on top of the current stable version.
 
+.. option:: LIBCXX_ABI_DEFINES:STRING
+
+  **Default**: 
+
+  A semicolon-separated list of ABI macros which are persisted in the site
+  config header. See `include/__config` for the list of ABI macros.
+
 .. _LLVM-specific variables:
 
 LLVM-specific options
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -607,6 +607,19 @@
 config_define_if(LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY 
_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL)
 config_define_if(LIBCXX_HAS_MUSL_LIBC _LIBCPP_HAS_MUSL_LIBC)
 
+set(LIBCXX_ABI_DEFINES "" CACHE STRING "A semicolon separated list of ABI 
macros to define in the site config header")
+if (LIBCXX_ABI_DEFINES)
+  set(abi_defines)
+  foreach (abi_define ${LIBCXX_ABI_DEFINES})
+if (NOT abi_define MATCHES "^_LIBCPP_ABI_")
+  message(SEND_ERROR "Invalid ABI macro ${abi_define} in 
LIBCXX_ABI_DEFINES")
+endif()
+list(APPEND abi_defines "#define ${abi_define}")
+  endforeach()
+  string(REPLACE ";" "\n" abi_defines "${abi_defines}")
+  config_define(${abi_defines} _LIBCPP_ABI_DEFINES)
+endif()
+
 # By default libc++ on Windows expects to use a shared library, which requires
 # the headers to use DLL import/export semantics. However when building a
 # static library only we modify the headers to disable DLL import/export.


Index: utils/libcxx/test/config.py
===
--- utils/libcxx/test/config.py
+++ utils/libcxx/test/config.py
@@ -668,7 +668,7 @@
 self.config.available_features.add('libcpp-abi-version-v%s'
 % feature_macros[m])
 continue
-assert m.startswith('_LIBCPP_HAS_') or m == '_LIBCPP_ABI_UNSTABLE'
+assert m.startswith('_LIBCPP_HAS_') or m.startswith('_LIBCPP_ABI_')
 m = m.lower()[1:].replace('_', '-')
 self.config.available_features.add(m)
 return feature_macros
Index: include/__config_site.in
===
--- include/__config_site.in
+++ include/__config_site.in
@@ -24,4 +24,6 @@
 #cmakedefine _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL
 #cmakedefine _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS
 
+@_LIBCPP_ABI_DEFINES@
+
 #endif // _LIBCPP_CONFIG_SITE
Index: docs/BuildingLibcxx.rst
===
--- docs/BuildingLibcxx.rst
+++ docs/BuildingLibcxx.rst
@@ -347,6 +347,13 @@
   Build the "unstable" ABI version of libc++. Includes all ABI changing features
   on top of the current stable version.
 
+.. option:: LIBCXX_ABI_DEFINES:STRING
+
+  **Default**: 
+
+  A semicolon-separated list of ABI macros which are persisted in the site
+  config header. See `include/__config` for the list of ABI macros.
+
 .. _LLVM-specific variables:
 
 LLVM-specific options
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -607,6 +607,19 @@
 config_define_if(LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL)
 config_define_if(LIBCXX_HAS_MUSL_LIBC _LIBCPP_HAS_MUSL_LIBC)
 
+set(LIBCXX_ABI_DEFINES "" CACHE STRING "A semicolon separated list of ABI macros to define in the site config header")
+if (LIBCXX_ABI_DEFINES)
+  set(abi_defines)
+  foreach (abi_define ${LIBCXX_ABI_DEFINES})
+if (NOT abi_define MATCHES "^_LIBCPP_ABI_")
+  message(SEND_ERROR "Invalid ABI macro ${abi_define

[PATCH] D35046: [coroutines] Include "this" type when looking up coroutine_traits

[Toby Allsopp via Phabricator via cfe-commits]

toby-allsopp abandoned this revision.
toby-allsopp added a comment.

Yes, @EricWF made a much more comprehensive change that has been in for a while 
now. Abandoning.


https://reviews.llvm.org/D35046



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

[PATCH] D36713: [libc++] Add a persistent way to disable availability

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai abandoned this revision.
smeenai added a comment.

I ended up handling this differently internally (via a custom site config). If 
someone else ends up needing the same functionality, they can revive it.


https://reviews.llvm.org/D36713



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

[PATCH] D38567: [config] Warn when POSIX_C_SOURCE breaks threading support on Darwin

[Vedant Kumar via Phabricator via cfe-commits]

vsk added a comment.

I'm not sure how to test the warning against anything but the macOS SDK. When I 
tried, I hit a -Wincompatible-sysroot issue. I can leave those changes out of 
this patch if we want to be more conservative.


https://reviews.llvm.org/D38567



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

[PATCH] D38567: [config] Warn when POSIX_C_SOURCE breaks threading support on Darwin

[Vedant Kumar via Phabricator via cfe-commits]

vsk created this revision.

Prior to macOS 10.13 and iOS 11, defining POSIX_C_SOURCE before
including  resulted in hard-to-understand errors. That
definition causes a bunch of important definitions from the system
headers to be skipped, so users see failures like "can't find
mach_port_t".

This patch adds a friendly warning message about the issue.

rdar://problem/31263056


https://reviews.llvm.org/D38567

Files:
  include/__config
  include/__threading_support
  test/libcxx/posix_source.sh.cpp


Index: test/libcxx/posix_source.sh.cpp
===
--- /dev/null
+++ test/libcxx/posix_source.sh.cpp
@@ -0,0 +1,29 @@
+// -*- C++ -*-
+//===--===//
+//
+// 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.
+//
+//===--===//
+
+// Test that we get a warning when using the threading support header without
+// the right defines present.
+
+// REQUIRES: apple-darwin
+// UNSUPPORTED: libcpp-has-no-threads
+
+// RUN: %cxx -c %s -o /dev/null %compile_flags -arch x86_64 
-mmacosx-version-min=10.12 -D_LIBCPP_DISABLE_AVAILABILITY 2>&1 | not grep 
"warning"
+// RUN: %cxx -c %s -o /dev/null %compile_flags -arch x86_64 
-mmacosx-version-min=10.12 -D_LIBCPP_DISABLE_AVAILABILITY 
-D_POSIX_C_SOURCE=200112L 2>&1 | grep "warning" | grep "Define _DARWIN_C_SOURCE"
+// RUN: %cxx -c %s -o /dev/null %compile_flags -arch x86_64 
-mmacosx-version-min=10.12 -D_LIBCPP_DISABLE_AVAILABILITY 
-D_POSIX_C_SOURCE=200112L -D_DARWIN_C_SOURCE 2>&1 | not grep "warning"
+
+// RUN: %cxx -c %s -o /dev/null %compile_flags -arch x86_64 
-mmacosx-version-min=10.13 -D_LIBCPP_DISABLE_AVAILABILITY 2>&1 | not grep 
"warning"
+// RUN: %cxx -c %s -o /dev/null %compile_flags -arch x86_64 
-mmacosx-version-min=10.13 -D_LIBCPP_DISABLE_AVAILABILITY 
-D_POSIX_C_SOURCE=200112L 2>&1 | not grep "warning"
+// RUN: %cxx -c %s -o /dev/null %compile_flags -arch x86_64 
-mmacosx-version-min=10.13 -D_LIBCPP_DISABLE_AVAILABILITY 
-D_POSIX_C_SOURCE=200112L -D_DARWIN_C_SOURCE 2>&1 | not grep "warning"
+
+#include 
+
+int main() {
+  return 0;
+}
Index: include/__threading_support
===
--- include/__threading_support
+++ include/__threading_support
@@ -23,6 +23,15 @@
 # include <__external_threading>
 #elif !defined(_LIBCPP_HAS_NO_THREADS)
 
+#if (defined(__MAC_OS_X_VERSION_MIN_REQUIRED) && 
(__MAC_OS_X_VERSION_MIN_REQUIRED < 101300)) \
+|| (defined(__IPHONE_OS_VERSION_MIN_REQUIRED) && 
(__IPHONE_OS_VERSION_MIN_REQUIRED < 11)) \
+|| (defined(__WATCH_OS_VERSION_MIN_REQUIRED) && 
(__WATCH_OS_VERSION_MIN_REQUIRED < 4)) \
+|| (defined(__TV_OS_VERSION_MIN_REQUIRED) && (__TV_OS_VERSION_MIN_REQUIRED 
< 11))
+# if defined(_POSIX_C_SOURCE) && !defined(_DARWIN_C_SOURCE)
+#  warning "Define _DARWIN_C_SOURCE (or undefine _POSIX_C_SOURCE) for 
threading support."
+# endif
+#endif
+
 #if defined(_LIBCPP_HAS_THREAD_API_PTHREAD)
 # include 
 # include 
Index: include/__config
===
--- include/__config
+++ include/__config
@@ -901,6 +901,18 @@
  defined(__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__)
 #   define __MAC_OS_X_VERSION_MIN_REQUIRED 
__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__
 # endif
+# if !defined(__IPHONE_OS_VERSION_MIN_REQUIRED) && \
+ defined(__ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__)
+#   define __IPHONE_OS_VERSION_MIN_REQUIRED 
__ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__
+# endif
+# if !defined(__WATCH_OS_VERSION_MIN_REQUIRED) && \
+ defined(__ENVIRONMENT_WATCH_OS_VERSION_MIN_REQUIRED__)
+#   define __WATCH_OS_VERSION_MIN_REQUIRED 
__ENVIRONMENT_WATCH_OS_VERSION_MIN_REQUIRED__
+# endif
+# if !defined(__TV_OS_VERSION_MIN_REQUIRED) && \
+ defined(__ENVIRONMENT_TV_OS_VERSION_MIN_REQUIRED__)
+#   define __TV_OS_VERSION_MIN_REQUIRED 
__ENVIRONMENT_TV_OS_VERSION_MIN_REQUIRED__
+# endif
 # if defined(__MAC_OS_X_VERSION_MIN_REQUIRED)
 #   if __MAC_OS_X_VERSION_MIN_REQUIRED < 1060
 # define _LIBCPP_HAS_NO_ALIGNED_ALLOCATION


Index: test/libcxx/posix_source.sh.cpp
===
--- /dev/null
+++ test/libcxx/posix_source.sh.cpp
@@ -0,0 +1,29 @@
+// -*- C++ -*-
+//===--===//
+//
+// 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.
+//
+//===--===//
+
+// Test that we get a warning when using the threading support header without
+// the right defines present.
+
+// R

[PATCH] D35216: [analyzer] Escape symbols when creating std::initializer_list.

[Devin Coughlin via Phabricator via cfe-commits]

dcoughlin added a comment.

In https://reviews.llvm.org/D35216#888506, @NoQ wrote:

> Do you think this patch should be blocked in favor of complete modeling?


Please, let's get this landed. We can add more precise modeling when the need 
arises.


https://reviews.llvm.org/D35216



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

[libcxx] r314940 - Initial cut at infastructure for fuzzing support for OSS-fuzz

[Marshall Clow via cfe-commits]

Author: marshall
Date: Wed Oct  4 15:23:03 2017
New Revision: 314940

URL: http://llvm.org/viewvc/llvm-project?rev=314940&view=rev
Log:
Initial cut at infastructure for fuzzing support for OSS-fuzz

Added:
libcxx/trunk/fuzzing/
libcxx/trunk/fuzzing/fuzzing.cpp
libcxx/trunk/fuzzing/fuzzing.h
libcxx/trunk/test/libcxx/fuzzing/
libcxx/trunk/test/libcxx/fuzzing/nth_element.cpp
libcxx/trunk/test/libcxx/fuzzing/partial_sort.cpp
libcxx/trunk/test/libcxx/fuzzing/partition.cpp
libcxx/trunk/test/libcxx/fuzzing/sort.cpp
libcxx/trunk/test/libcxx/fuzzing/stable_partition.cpp
libcxx/trunk/test/libcxx/fuzzing/stable_sort.cpp

Added: libcxx/trunk/fuzzing/fuzzing.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/fuzzing/fuzzing.cpp?rev=314940&view=auto
==
--- libcxx/trunk/fuzzing/fuzzing.cpp (added)
+++ libcxx/trunk/fuzzing/fuzzing.cpp Wed Oct  4 15:23:03 2017
@@ -0,0 +1,222 @@
+// -*- C++ -*-
+//===- fuzzing.cpp ---===//
+//
+// 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.
+//
+//===--===//
+
+// A set of routines to use when fuzzing the algorithms in libc++
+// Each one tests a single algorithm.
+//
+// They all have the form of:
+// int `algorithm`(const uint8_t *data, size_t size);
+//
+// They perform the operation, and then check to see if the results are 
correct.
+// If so, they return zero, and non-zero otherwise.
+//
+// For example, sort calls std::sort, then checks two things:
+// (1) The resulting vector is sorted
+// (2) The resulting vector contains the same elements as the 
original data.
+
+
+
+#include "fuzzing.h"
+#include 
+#include 
+
+#include 
+
+// If we had C++14, we could use the four iterator version of 
is_permutation
+
+namespace fuzzing {
+
+// This is a struct we can use to test the stable_XXX algorithms.
+// perform the operation on the key, then check the order of the payload.
+
+struct stable_test {
+   uint8_t key;
+   uint8_t payload;
+   
+   stable_test(uint8_t k) : key(k), payload(0) {}
+   stable_test(uint8_t k, uint8_t p) : key(k), payload(p) {}
+   };
+
+void swap(stable_test &lhs, stable_test &rhs)
+{
+   using std::swap;
+   swap(lhs.key, rhs.key);
+   swap(lhs.payload, rhs.payload);
+}
+
+struct key_less
+{
+   bool operator () (const stable_test &lhs, const stable_test &rhs) const
+   {
+   return lhs.key < rhs.key;
+   }
+};
+
+struct payload_less
+{
+   bool operator () (const stable_test &lhs, const stable_test &rhs) const
+   {
+   return lhs.payload < rhs.payload;
+   }
+};
+
+struct total_less
+{
+   bool operator () (const stable_test &lhs, const stable_test &rhs) const
+   {
+   return lhs.key == rhs.key ? lhs.payload < rhs.payload : lhs.key 
< rhs.key;
+   }
+};
+
+bool operator==(const stable_test &lhs, const stable_test &rhs)
+{ 
+   return lhs.key == rhs.key && lhs.payload == rhs.payload;
+}
+
+
+template
+struct is_even
+{
+   bool operator () (const T &t) const
+   {
+   return t % 2 == 0;
+   }
+};
+
+
+template<>
+struct is_even
+{
+   bool operator () (const stable_test &t) const
+   {
+   return t.key % 2 == 0;
+   }
+};
+
+// == sort ==
+
+int sort(const uint8_t *data, size_t size)
+{
+   std::vector working(data, data + size);
+   std::sort(working.begin(), working.end());
+
+   if (!std::is_sorted(working.begin(), working.end())) return 1;
+   if (!std::is_permutation(data, data + size, working.begin())) return 99;
+   return 0;
+}
+
+
+// == stable_sort ==
+
+int stable_sort(const uint8_t *data, size_t size)
+{
+   std::vector input;
+   for (size_t i = 0; i < size; ++i)
+   input.push_back(stable_test(data[i], i));
+   std::vector working = input;
+   std::stable_sort(working.begin(), working.end(), key_less());
+
+   if (!std::is_sorted(working.begin(), working.end(), key_less()))   
return 1;
+   auto iter = working.begin();
+   while (iter != working.end())
+   {
+   auto range = std::equal_range(iter, working.end(), *iter, 
key_less());
+   if (!std::is_sorted(range.first, range.second, total_less())) 
return 2; 
+   iter = range.second;
+   }
+   if (!std::is_permutation(input.begin(), input.end(), working.begin())) 
return 99;
+   return 0;
+}
+
+// == partition ==
+
+int partition(const uint8_t *data, size_t size)
+{
+   std::vector working(data, data + size);
+   auto iter = std::partition(w

RE: r314262 - Emit section information for extern variables.

[Keane, Erich via cfe-commits]

Elizabeth gave me a patch, submitted it with a test in r314939

From: Andrews, Elizabeth
Sent: Wednesday, October 4, 2017 1:54 PM
To: Friedman, Eli ; Keane, Erich 
; Nico Weber 
Cc: cfe-commits 
Subject: RE: r314262 - Emit section information for extern variables.

Alright. Will do. Thanks!

From: Friedman, Eli [mailto:efrie...@codeaurora.org]
Sent: Wednesday, October 4, 2017 4:51 PM
To: Keane, Erich mailto:erich.ke...@intel.com>>; 
Andrews, Elizabeth 
mailto:elizabeth.andr...@intel.com>>; Nico Weber 
mailto:tha...@chromium.org>>
Cc: cfe-commits mailto:cfe-commits@lists.llvm.org>>
Subject: Re: r314262 - Emit section information for extern variables.

On 10/4/2017 1:48 PM, Keane, Erich wrote:
Ah, cool!  I didn’t realize that, and that is actually exactly what Elizabeth 
is looking into now.

Elizabeth, if you send me a diff, I’ll commit it as review-after-commit if Eli 
is alright with this.  It should be something like changing:
+  if (VD->isThisDeclarationADefinition() != VarDecl::Definition) {
To
+  if (VD->isThisDeclarationADefinition() != VarDecl::Definition && 
VD->isThsDeclarationADefinition() != VarDecl::TentativeDefinition) {


Right?

I'd probably just write it "if (VD->isThisDeclarationADefinition() == 
VarDecl::DeclarationOnly)", but yes.  (And don't forget a testcase.)

-Eli


From: Friedman, Eli [mailto:efrie...@codeaurora.org]
Sent: Wednesday, October 4, 2017 1:46 PM
To: Andrews, Elizabeth 
; Nico Weber 

Cc: cfe-commits 
; Keane, Erich 

Subject: Re: r314262 - Emit section information for extern variables.

Oh, that's easy to explain; sorry, I didn't think of it when I was reviewing.

DefinitionKind has three possible values: DeclarationOnly, TentativeDefinition, 
and Definition.  (Tentative definitions are C weirdness that allows you to 
write "int x; int x = 10;".)

For the purpose of this warning, a TentativeDefinition should count as a 
definition.

-Eli

On 10/4/2017 1:38 PM, Andrews, Elizabeth wrote:
Hello,
I just spoke to Erich. The warning isn’t supposed to be emitted when the 
section attribute is specified on a definition. I’m not sure why struct r_debug 
_r_debug __attribute__((nocommon, section(".r_debug"))); failed the 
isThisDeclarationADefiniton check. I need to look into it.
Thanks,
Elizabeth

From: tha...@google.com [mailto:tha...@google.com] On 
Behalf Of Nico Weber
Sent: Wednesday, October 4, 2017 4:29 PM
To: Keane, Erich 
Cc: Andrews, Elizabeth 
; Friedman, 
Eli ; cfe-commits 

Subject: Re: r314262 - Emit section information for extern variables.

All I know about this code that it used to build (and still builds with gcc) 
and now it doesn't, sorry :-) What that code does seems somewhat questionable, 
but also somewhat useful, and it feels like the behavior change from this 
change here for that code might have been unintentional.

Your suggestion sounds reasonable to me.

On Wed, Oct 4, 2017 at 4:18 PM, Keane, Erich 
mailto:erich.ke...@intel.com>> wrote:
I saw that… I don’t see where it prevents the same change from being made in 
link.h.

As I mentioned, there is a solution to make this Warning less aggressive (in 
the lib/Sema/SemaDecl.cpp changes, add a condition that Old->isUsed() before 
the warning.  I’m wondering if that solves your issue.

It would result in
extern struct r_debug _r_debug;
struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));
Compiling, but :
extern struct r_debug _r_debug;
r_debug = something();
struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));
NOT compiling (which is almost definitely a bug).



From: tha...@google.com 
[mailto:tha...@google.com] On Behalf Of Nico Weber
Sent: Wednesday, October 4, 2017 1:14 PM
To: Keane, Erich mailto:erich.ke...@intel.com>>
Cc: Andrews, Elizabeth 
mailto:elizabeth.andr...@intel.com>>; Friedman, 
Eli mailto:efrie...@codeaurora.org>>; cfe-commits 
mailto:cfe-commits@lists.llvm.org>>

Subject: Re: r314262 - Emit section information for extern variables.

For why, here's the comment from the code I linked to:

/*
 * GDB looks for this symbol name when it cannot find PT_DYNAMIC->DT_DEBUG.
 * We don't have a PT_DYNAMIC, so it will find this.  Now all we have to do
 * is arrange for this space to be filled in with the dynamic linker's
 * _r_debug contents after they're initialized.  That way, attaching GDB to
 * this process or examining its core file will find the PIE we loaded, the
 * dynamic linker, and all the shared libraries, making debugging pleasant.
 */

On Wed, Oct 4, 2017 at 4:11 PM, Keane, Erich 
mailto:erich.ke...@intel.com>> wrote:
I’ve added Elizabeth, who is the original patch author.  Hopefully she can help 
out here.  

r314939 - Fix 'section' warning behavior with tentatively-defined values

[Erich Keane via cfe-commits]

Author: erichkeane
Date: Wed Oct  4 15:16:24 2017
New Revision: 314939

URL: http://llvm.org/viewvc/llvm-project?rev=314939&view=rev
Log:
Fix 'section' warning behavior with tentatively-defined values

As reported on cfe-commits, r314262 resulted in tentatively-defined
variables not being excluded for the warning.

Patch By: Elizabeth Andrews

Modified:
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/test/Sema/attr-section.c

Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=314939&r1=314938&r2=314939&view=diff
==
--- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDecl.cpp Wed Oct  4 15:16:24 2017
@@ -2627,7 +2627,7 @@ void Sema::mergeDeclAttributes(NamedDecl
   // This redeclaration adds a section attribute.
   if (New->hasAttr() && !Old->hasAttr()) {
 if (auto *VD = dyn_cast(New)) {
-  if (VD->isThisDeclarationADefinition() != VarDecl::Definition) {
+  if (VD->isThisDeclarationADefinition() == VarDecl::DeclarationOnly) {
 Diag(New->getLocation(), 
diag::warn_attribute_section_on_redeclaration);
 Diag(Old->getLocation(), diag::note_previous_declaration);
   }

Modified: cfe/trunk/test/Sema/attr-section.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/attr-section.c?rev=314939&r1=314938&r2=314939&view=diff
==
--- cfe/trunk/test/Sema/attr-section.c (original)
+++ cfe/trunk/test/Sema/attr-section.c Wed Oct  4 15:16:24 2017
@@ -23,3 +23,12 @@ enum __attribute__((section("NEAR,x")))
 extern int a; // expected-note {{previous declaration is here}}
 int *b = &a;
 extern int a __attribute__((section("foo,zed"))); // expected-warning 
{{section attribute is specified on redeclared variable}}
+
+// Not a warning.
+int c;
+int c __attribute__((section("foo,zed")));
+
+// Also OK.
+struct r_debug {};
+extern struct r_debug _r_debug;
+struct r_debug _r_debug __attribute__((nocommon, section(".r_debug,bar")));


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

[PATCH] D38525: Cleanup and generalize -shared-libasan.

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

Could we perhaps rename these flags to e.g. `-static-libsan` (with a 
`-static-libasan` alias for compatibility)? It seems confusing that the way to 
enable a static tsan runtime would be with `-static-libasan`.


https://reviews.llvm.org/D38525



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

[PATCH] D38134: [OpenCL] Emit enqueued block as kernel

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl updated this revision to Diff 117739.
yaxunl marked an inline comment as done.
yaxunl edited the summary of this revision.
yaxunl added a comment.

Emit enqueued block as a wrapper kernel which calls the block invoke function. 
Added test for calling and enqueue the same block.


https://reviews.llvm.org/D38134

Files:
  lib/CodeGen/CGBuiltin.cpp
  lib/CodeGen/CGOpenCLRuntime.cpp
  lib/CodeGen/CGOpenCLRuntime.h
  lib/CodeGen/CodeGenTypes.h
  lib/CodeGen/TargetInfo.cpp
  lib/CodeGen/TargetInfo.h
  test/CodeGenOpenCL/amdgpu-enqueue-kernel.cl
  test/CodeGenOpenCL/cl20-device-side-enqueue.cl

Index: test/CodeGenOpenCL/cl20-device-side-enqueue.cl
===
--- test/CodeGenOpenCL/cl20-device-side-enqueue.cl
+++ test/CodeGenOpenCL/cl20-device-side-enqueue.cl
@@ -6,10 +6,33 @@
 typedef void (^bl_t)(local void *);
 typedef struct {int a;} ndrange_t;
 
-// N.B. The check here only exists to set BL_GLOBAL
-// COMMON: @block_G =  addrspace(1) constant void (i8 addrspace(3)*) addrspace(4)* addrspacecast (void (i8 addrspace(3)*) addrspace(1)* bitcast ({ i32, i32, i8 addrspace(4)* } addrspace(1)* [[BL_GLOBAL:@__block_literal_global(\.[0-9]+)?]] to void (i8 addrspace(3)*) addrspace(1)*) to void (i8 addrspace(3)*) addrspace(4)*)
+// COMMON: %struct.__opencl_block_literal_generic = type { i32, i32, i8 addrspace(4)* }
+
+// For a block global variable, first emit the block literal as a global variable, then emit the block variable itself.
+// COMMON: [[BL_GLOBAL:@__block_literal_global[^ ]*]] = internal addrspace(1) constant { i32, i32, i8 addrspace(4)* } { i32 {{[0-9]+}}, i32 {{[0-9]+}}, i8 addrspace(4)* addrspacecast (i8* bitcast (void (i8 addrspace(4)*, i8 addrspace(3)*)* [[INV_G:@[^ ]+]] to i8*) to i8 addrspace(4)*) }
+// COMMON: @block_G =  addrspace(1) constant void (i8 addrspace(3)*) addrspace(4)* addrspacecast (void (i8 addrspace(3)*) addrspace(1)* bitcast ({ i32, i32, i8 addrspace(4)* } addrspace(1)* [[BL_GLOBAL]] to void (i8 addrspace(3)*) addrspace(1)*) to void (i8 addrspace(3)*) addrspace(4)*)
+
+// For anonymous blocks without captures, emit block literals as global variable.
+// COMMON: [[BLG1:@__opencl_enqueued_block_literal_global[^ ]*]] = internal addrspace(1) constant { i32, i32, i8 addrspace(4)* } { i32 {{[0-9]+}}, i32 {{[0-9]+}}, i8 addrspace(4)* addrspacecast (i8* bitcast (void (i8 addrspace(4)*, i8 addrspace(3)*)* [[INVG1:@[^ ]+_kernel]] to i8*) to i8 addrspace(4)*) }
+// COMMON: [[BLG2:@__opencl_enqueued_block_literal_global[^ ]*]] = internal addrspace(1) constant { i32, i32, i8 addrspace(4)* } { i32 {{[0-9]+}}, i32 {{[0-9]+}}, i8 addrspace(4)* addrspacecast (i8* bitcast (void (i8 addrspace(4)*, i8 addrspace(3)*)* [[INVG2:@[^ ]+_kernel]] to i8*) to i8 addrspace(4)*) }
+// COMMON: [[BLG3:@__opencl_enqueued_block_literal_global[^ ]*]] = internal addrspace(1) constant { i32, i32, i8 addrspace(4)* } { i32 {{[0-9]+}}, i32 {{[0-9]+}}, i8 addrspace(4)* addrspacecast (i8* bitcast (void (i8 addrspace(4)*, i8 addrspace(3)*)* [[INVG3:@[^ ]+_kernel]] to i8*) to i8 addrspace(4)*) }
+// COMMON: [[BLG4:@__opencl_enqueued_block_literal_global[^ ]*]] = internal addrspace(1) constant { i32, i32, i8 addrspace(4)* } { i32 {{[0-9]+}}, i32 {{[0-9]+}}, i8 addrspace(4)* addrspacecast (i8* bitcast (void (i8 addrspace(4)*, i8 addrspace(3)*)* [[INVG4:@[^ ]+_kernel]] to i8*) to i8 addrspace(4)*) }
+// COMMON: [[BLG5:@__opencl_enqueued_block_literal_global[^ ]*]] = internal addrspace(1) constant { i32, i32, i8 addrspace(4)* } { i32 {{[0-9]+}}, i32 {{[0-9]+}}, i8 addrspace(4)* addrspacecast (i8* bitcast (void (i8 addrspace(4)*, i8 addrspace(3)*)* [[INVG5:@[^ ]+_kernel]] to i8*) to i8 addrspace(4)*) }
+// COMMON: [[BLG6:@__opencl_enqueued_block_literal_global[^ ]*]] = internal addrspace(1) constant { i32, i32, i8 addrspace(4)* } { i32 {{[0-9]+}}, i32 {{[0-9]+}}, i8 addrspace(4)* addrspacecast (i8* bitcast (void (i8 addrspace(4)*, i8 addrspace(3)*, i8 addrspace(3)*, i8 addrspace(3)*)* [[INVG6:@[^ ]+_kernel]] to i8*) to i8 addrspace(4)*) }
+// COMMON: [[BLG7:@__opencl_enqueued_block_literal_global[^ ]*]] = internal addrspace(1) constant { i32, i32, i8 addrspace(4)* } { i32 {{[0-9]+}}, i32 {{[0-9]+}}, i8 addrspace(4)* addrspacecast (i8* bitcast (void (i8 addrspace(4)*, i8 addrspace(3)*)* [[INVG7:@[^ ]+_kernel]] to i8*) to i8 addrspace(4)*) }
+// COMMON: [[BLG8:@__block_literal_global[^ ]*]] = internal addrspace(1) constant { i32, i32, i8 addrspace(4)* } { i32 {{[0-9]+}}, i32 {{[0-9]+}}, i8 addrspace(4)* addrspacecast (i8* bitcast (void (i8 addrspace(4)*)* [[INVG8:@[^ ]+]] to i8*) to i8 addrspace(4)*) }
+// COMMON: [[BLG9:@__block_literal_global[^ ]*]] = internal addrspace(1) constant { i32, i32, i8 addrspace(4)* } { i32 {{[0-9]+}}, i32 {{[0-9]+}}, i8 addrspace(4)* addrspacecast (i8* bitcast (void (i8 addrspace(4)*, i8 addrspace(3)*)* [[INVG9:@[^ ]+]] to i8*) to i8 addrspace(4)*) }
+// COMMON: [[BLG8K:@__opencl_enqueued_block_literal_global[^ ]*]] = internal addrspace(1) c

RE: r314262 - Emit section information for extern variables.

[Andrews, Elizabeth via cfe-commits]

Alright. Will do. Thanks!

From: Friedman, Eli [mailto:efrie...@codeaurora.org]
Sent: Wednesday, October 4, 2017 4:51 PM
To: Keane, Erich ; Andrews, Elizabeth 
; Nico Weber 
Cc: cfe-commits 
Subject: Re: r314262 - Emit section information for extern variables.

On 10/4/2017 1:48 PM, Keane, Erich wrote:
Ah, cool!  I didn’t realize that, and that is actually exactly what Elizabeth 
is looking into now.

Elizabeth, if you send me a diff, I’ll commit it as review-after-commit if Eli 
is alright with this.  It should be something like changing:
+  if (VD->isThisDeclarationADefinition() != VarDecl::Definition) {
To
+  if (VD->isThisDeclarationADefinition() != VarDecl::Definition && 
VD->isThsDeclarationADefinition() != VarDecl::TentativeDefinition) {


Right?

I'd probably just write it "if (VD->isThisDeclarationADefinition() == 
VarDecl::DeclarationOnly)", but yes.  (And don't forget a testcase.)

-Eli



From: Friedman, Eli [mailto:efrie...@codeaurora.org]
Sent: Wednesday, October 4, 2017 1:46 PM
To: Andrews, Elizabeth 
; Nico Weber 

Cc: cfe-commits 
; Keane, Erich 

Subject: Re: r314262 - Emit section information for extern variables.

Oh, that's easy to explain; sorry, I didn't think of it when I was reviewing.

DefinitionKind has three possible values: DeclarationOnly, TentativeDefinition, 
and Definition.  (Tentative definitions are C weirdness that allows you to 
write "int x; int x = 10;".)

For the purpose of this warning, a TentativeDefinition should count as a 
definition.

-Eli

On 10/4/2017 1:38 PM, Andrews, Elizabeth wrote:
Hello,
I just spoke to Erich. The warning isn’t supposed to be emitted when the 
section attribute is specified on a definition. I’m not sure why struct r_debug 
_r_debug __attribute__((nocommon, section(".r_debug"))); failed the 
isThisDeclarationADefiniton check. I need to look into it.
Thanks,
Elizabeth

From: tha...@google.com [mailto:tha...@google.com] On 
Behalf Of Nico Weber
Sent: Wednesday, October 4, 2017 4:29 PM
To: Keane, Erich 
Cc: Andrews, Elizabeth 
; Friedman, 
Eli ; cfe-commits 

Subject: Re: r314262 - Emit section information for extern variables.

All I know about this code that it used to build (and still builds with gcc) 
and now it doesn't, sorry :-) What that code does seems somewhat questionable, 
but also somewhat useful, and it feels like the behavior change from this 
change here for that code might have been unintentional.

Your suggestion sounds reasonable to me.

On Wed, Oct 4, 2017 at 4:18 PM, Keane, Erich 
mailto:erich.ke...@intel.com>> wrote:
I saw that… I don’t see where it prevents the same change from being made in 
link.h.

As I mentioned, there is a solution to make this Warning less aggressive (in 
the lib/Sema/SemaDecl.cpp changes, add a condition that Old->isUsed() before 
the warning.  I’m wondering if that solves your issue.

It would result in
extern struct r_debug _r_debug;
struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));
Compiling, but :
extern struct r_debug _r_debug;
r_debug = something();
struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));
NOT compiling (which is almost definitely a bug).



From: tha...@google.com 
[mailto:tha...@google.com] On Behalf Of Nico Weber
Sent: Wednesday, October 4, 2017 1:14 PM
To: Keane, Erich mailto:erich.ke...@intel.com>>
Cc: Andrews, Elizabeth 
mailto:elizabeth.andr...@intel.com>>; Friedman, 
Eli mailto:efrie...@codeaurora.org>>; cfe-commits 
mailto:cfe-commits@lists.llvm.org>>

Subject: Re: r314262 - Emit section information for extern variables.

For why, here's the comment from the code I linked to:

/*
 * GDB looks for this symbol name when it cannot find PT_DYNAMIC->DT_DEBUG.
 * We don't have a PT_DYNAMIC, so it will find this.  Now all we have to do
 * is arrange for this space to be filled in with the dynamic linker's
 * _r_debug contents after they're initialized.  That way, attaching GDB to
 * this process or examining its core file will find the PIE we loaded, the
 * dynamic linker, and all the shared libraries, making debugging pleasant.
 */

On Wed, Oct 4, 2017 at 4:11 PM, Keane, Erich 
mailto:erich.ke...@intel.com>> wrote:
I’ve added Elizabeth, who is the original patch author.  Hopefully she can help 
out here.  Additionally, Eli did the original review, so hopefully he can chime 
in as well.

I believe the necessity for this warning came out of the discussion on fixing 
the section behavior.  The issue here is that redeclaring with a different 
‘section’ can cause some pretty nasty issues, since it isn’t terribly clear 
what happens if the variable is used in the meantime.

There is 1 change that I c

Re: r314262 - Emit section information for extern variables.

[Friedman, Eli via cfe-commits]

On 10/4/2017 1:48 PM, Keane, Erich wrote:


Ah, cool!  I didn’t realize that, and that is actually exactly what 
Elizabeth is looking into now.


Elizabeth, if you send me a diff, I’ll commit it as 
review-after-commit if Eli is alright with this.  It should be 
something like changing:


+      if (VD->isThisDeclarationADefinition() != VarDecl::Definition) {

To

+      if (VD->isThisDeclarationADefinition() != VarDecl::Definition 
&& VD->isThsDeclarationADefinition() != VarDecl::TentativeDefinition) {


Right?



I'd probably just write it "if (VD->isThisDeclarationADefinition() == 
VarDecl::DeclarationOnly)", but yes.  (And don't forget a testcase.)


-Eli


*From:*Friedman, Eli [mailto:efrie...@codeaurora.org]
*Sent:* Wednesday, October 4, 2017 1:46 PM
*To:* Andrews, Elizabeth ; Nico Weber 

*Cc:* cfe-commits ; Keane, Erich 


*Subject:* Re: r314262 - Emit section information for extern variables.

Oh, that's easy to explain; sorry, I didn't think of it when I was 
reviewing.


DefinitionKind has three possible values: DeclarationOnly, 
TentativeDefinition, and Definition.  (Tentative definitions are C 
weirdness that allows you to write "int x; int x = 10;".)


For the purpose of this warning, a TentativeDefinition should count as 
a definition.


-Eli

On 10/4/2017 1:38 PM, Andrews, Elizabeth wrote:

Hello,

I just spoke to Erich. The warning isn’t supposed to be emitted
when the section attribute is specified on a definition. I’m not
sure why struct r_debug _r_debug __attribute__((nocommon,
section(".r_debug"))); failed the isThisDeclarationADefiniton
check. I need to look into it.

Thanks,

Elizabeth

*From:*tha...@google.com 
[mailto:tha...@google.com] *On Behalf Of *Nico Weber
*Sent:* Wednesday, October 4, 2017 4:29 PM
*To:* Keane, Erich 

*Cc:* Andrews, Elizabeth 
; Friedman, Eli
 ;
cfe-commits 

*Subject:* Re: r314262 - Emit section information for extern
variables.

All I know about this code that it used to build (and still builds
with gcc) and now it doesn't, sorry :-) What that code does seems
somewhat questionable, but also somewhat useful, and it feels like
the behavior change from this change here for that code might have
been unintentional.

Your suggestion sounds reasonable to me.

On Wed, Oct 4, 2017 at 4:18 PM, Keane, Erich
mailto:erich.ke...@intel.com>> wrote:

I saw that… I don’t see where it prevents the same change from
being made in link.h.

As I mentioned, there is a solution to make this Warning less
aggressive (in the lib/Sema/SemaDecl.cpp changes, add a
condition that Old->isUsed() before the warning.  I’m
wondering if that solves your issue.

It would result in

extern struct r_debug _r_debug;
struct r_debug _r_debug __attribute__((nocommon,
section(".r_debug")));

Compiling, but :

extern struct r_debug _r_debug;
r_debug = something();
struct r_debug _r_debug __attribute__((nocommon,
section(".r_debug")));

NOT compiling (which is almost definitely a bug).

*From:*tha...@google.com
[mailto:tha...@google.com
] *On Behalf Of *Nico Weber
*Sent:* Wednesday, October 4, 2017 1:14 PM
*To:* Keane, Erich mailto:erich.ke...@intel.com>>
*Cc:* Andrews, Elizabeth mailto:elizabeth.andr...@intel.com>>; Friedman, Eli
mailto:efrie...@codeaurora.org>>;
cfe-commits mailto:cfe-commits@lists.llvm.org>>


*Subject:* Re: r314262 - Emit section information for extern
variables.

For why, here's the comment from the code I linked to:

/*

 * GDB looks for this symbol name when it cannot find
PT_DYNAMIC->DT_DEBUG.

 * We don't have a PT_DYNAMIC, so it will find this.  Now all
we have to do

 * is arrange for this space to be filled in with the dynamic
linker's

 * _r_debug contents after they're initialized.  That way,
attaching GDB to

 * this process or examining its core file will find the PIE
we loaded, the

 * dynamic linker, and all the shared libraries, making
debugging pleasant.

 */

On Wed, Oct 4, 2017 at 4:11 PM, Keane, Erich
mailto:erich.ke...@intel.com>> wrote:

I’ve added Elizabeth, who is the original patch author.
Hopefully she can help out here.  Additionally, Eli did
the original review, so hopefully he can chime in as well.


I believe the necessity for this warning came out of the
discussion on fixing the section behavior. The issue here
is that redecla

RE: r314262 - Emit section information for extern variables.

[Keane, Erich via cfe-commits]

Ah, cool!  I didn’t realize that, and that is actually exactly what Elizabeth 
is looking into now.

Elizabeth, if you send me a diff, I’ll commit it as review-after-commit if Eli 
is alright with this.  It should be something like changing:
+  if (VD->isThisDeclarationADefinition() != VarDecl::Definition) {
To
+  if (VD->isThisDeclarationADefinition() != VarDecl::Definition && 
VD->isThsDeclarationADefinition() != VarDecl::TentativeDefinition) {


Right?

From: Friedman, Eli [mailto:efrie...@codeaurora.org]
Sent: Wednesday, October 4, 2017 1:46 PM
To: Andrews, Elizabeth ; Nico Weber 

Cc: cfe-commits ; Keane, Erich 

Subject: Re: r314262 - Emit section information for extern variables.

Oh, that's easy to explain; sorry, I didn't think of it when I was reviewing.

DefinitionKind has three possible values: DeclarationOnly, TentativeDefinition, 
and Definition.  (Tentative definitions are C weirdness that allows you to 
write "int x; int x = 10;".)

For the purpose of this warning, a TentativeDefinition should count as a 
definition.

-Eli

On 10/4/2017 1:38 PM, Andrews, Elizabeth wrote:
Hello,
I just spoke to Erich. The warning isn’t supposed to be emitted when the 
section attribute is specified on a definition. I’m not sure why struct r_debug 
_r_debug __attribute__((nocommon, section(".r_debug"))); failed the 
isThisDeclarationADefiniton check. I need to look into it.
Thanks,
Elizabeth

From: tha...@google.com [mailto:tha...@google.com] On 
Behalf Of Nico Weber
Sent: Wednesday, October 4, 2017 4:29 PM
To: Keane, Erich 
Cc: Andrews, Elizabeth 
; Friedman, 
Eli ; cfe-commits 

Subject: Re: r314262 - Emit section information for extern variables.

All I know about this code that it used to build (and still builds with gcc) 
and now it doesn't, sorry :-) What that code does seems somewhat questionable, 
but also somewhat useful, and it feels like the behavior change from this 
change here for that code might have been unintentional.

Your suggestion sounds reasonable to me.

On Wed, Oct 4, 2017 at 4:18 PM, Keane, Erich 
mailto:erich.ke...@intel.com>> wrote:
I saw that… I don’t see where it prevents the same change from being made in 
link.h.

As I mentioned, there is a solution to make this Warning less aggressive (in 
the lib/Sema/SemaDecl.cpp changes, add a condition that Old->isUsed() before 
the warning.  I’m wondering if that solves your issue.

It would result in
extern struct r_debug _r_debug;
struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));
Compiling, but :
extern struct r_debug _r_debug;
r_debug = something();
struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));
NOT compiling (which is almost definitely a bug).



From: tha...@google.com 
[mailto:tha...@google.com] On Behalf Of Nico Weber
Sent: Wednesday, October 4, 2017 1:14 PM
To: Keane, Erich mailto:erich.ke...@intel.com>>
Cc: Andrews, Elizabeth 
mailto:elizabeth.andr...@intel.com>>; Friedman, 
Eli mailto:efrie...@codeaurora.org>>; cfe-commits 
mailto:cfe-commits@lists.llvm.org>>

Subject: Re: r314262 - Emit section information for extern variables.

For why, here's the comment from the code I linked to:

/*
 * GDB looks for this symbol name when it cannot find PT_DYNAMIC->DT_DEBUG.
 * We don't have a PT_DYNAMIC, so it will find this.  Now all we have to do
 * is arrange for this space to be filled in with the dynamic linker's
 * _r_debug contents after they're initialized.  That way, attaching GDB to
 * this process or examining its core file will find the PIE we loaded, the
 * dynamic linker, and all the shared libraries, making debugging pleasant.
 */

On Wed, Oct 4, 2017 at 4:11 PM, Keane, Erich 
mailto:erich.ke...@intel.com>> wrote:
I’ve added Elizabeth, who is the original patch author.  Hopefully she can help 
out here.  Additionally, Eli did the original review, so hopefully he can chime 
in as well.

I believe the necessity for this warning came out of the discussion on fixing 
the section behavior.  The issue here is that redeclaring with a different 
‘section’ can cause some pretty nasty issues, since it isn’t terribly clear 
what happens if the variable is used in the meantime.

There is 1 change that I can think of that Elizabeth and I discussed, which was 
to only warn in the case where there was a USAGE between these two 
redeclarations.  I’m not sure that will allow na_cl to compile, however it is 
my belief that if there IS a usage between link.h:64 and nacl_bootstrap.c:434, 
that this is a bug in nacl that is simply being uncovered thanks to this new 
warning.

Is there a good/reasonable reason the source of nacl wants to redeclare this 
with a different ‘section’?


From: tha...@google.com 
[mailto:tha...@google.com] On

[PATCH] D38134: [OpenCL] Emit enqueued block as kernel

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl marked 10 inline comments as done.
yaxunl added a comment.

In https://reviews.llvm.org/D38134#880133, @Anastasia wrote:

> I think we should add a test case when the same block is both called and 
> enqueued.


Will do.




Comment at: test/CodeGenOpenCL/amdgpu-enqueue-kernel.cl:3
+
+// CHECK: %[[S1:struct.__amdgpu_block_arg_t.*]] = type { [3 x i64], [1 x i8] }
+// CHECK: %[[S2:struct.__amdgpu_block_arg_t.*]] = type { [5 x i64], [1 x i8] }

Anastasia wrote:
> yaxunl wrote:
> > Anastasia wrote:
> > > This struct is not identical to block literal struct?
> > The LLVM type of the first argument of block invoke function is created 
> > directly with sorting and rearrangement. There is no AST type corresponding 
> > to it. However, the function codegen requires AST type of this argument. I 
> > feel it is unnecessary to create the corresponding AST type. For 
> > simplicity, just create an AST type with the same size and alignment as the 
> > LLVM type. In the function code, it will be bitcasted to the correct LLVM 
> > struct type and get the captured variables.
> So `void ptr` won't be possible here? Since it is cast to a right struct 
> inside the block anyway. Once again a block is a special type object with 
> known semantic to compiler and runtime in contract to kernels that can be 
> written with any arbitrary type of arguments.
> 
> I just don't like the idea of duplicating the block invoke function in case 
> it's being both called and enqueued. Also the login in blocks code generation 
> becomes difficult to understand. So I am wondering if we could perhaps create 
> a separate kernel function (as a wrapper) for enqueue_kernel which would call 
> a block instead. What do you think about it? I think the kernel prototype 
> would be fairly generic as it would just have a block call inside and pass 
> the arguments into it... We won't need to modify block generation then at 
> all. 
Will emit a wrapper kernel which calls the block invoke function and keep the 
block invoke function unchanged.


https://reviews.llvm.org/D38134



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

Re: r314262 - Emit section information for extern variables.

[Friedman, Eli via cfe-commits]

Oh, that's easy to explain; sorry, I didn't think of it when I was 
reviewing.


DefinitionKind has three possible values: DeclarationOnly, 
TentativeDefinition, and Definition.  (Tentative definitions are C 
weirdness that allows you to write "int x; int x = 10;".)


For the purpose of this warning, a TentativeDefinition should count as a 
definition.


-Eli

On 10/4/2017 1:38 PM, Andrews, Elizabeth wrote:


Hello,

I just spoke to Erich. The warning isn’t supposed to be emitted when 
the section attribute is specified on a definition. I’m not sure why 
struct r_debug _r_debug __attribute__((nocommon, 
section(".r_debug"))); failed the isThisDeclarationADefiniton check. I 
need to look into it.


Thanks,

Elizabeth

*From:*tha...@google.com [mailto:tha...@google.com] *On Behalf Of 
*Nico Weber

*Sent:* Wednesday, October 4, 2017 4:29 PM
*To:* Keane, Erich 
*Cc:* Andrews, Elizabeth ; Friedman, Eli 
; cfe-commits 

*Subject:* Re: r314262 - Emit section information for extern variables.

All I know about this code that it used to build (and still builds 
with gcc) and now it doesn't, sorry :-) What that code does seems 
somewhat questionable, but also somewhat useful, and it feels like the 
behavior change from this change here for that code might have been 
unintentional.


Your suggestion sounds reasonable to me.

On Wed, Oct 4, 2017 at 4:18 PM, Keane, Erich > wrote:


I saw that… I don’t see where it prevents the same change from
being made in link.h.

As I mentioned, there is a solution to make this Warning less
aggressive (in the lib/Sema/SemaDecl.cpp changes, add a condition
that Old->isUsed() before the warning.  I’m wondering if that
solves your issue.

It would result in

extern struct r_debug _r_debug;
struct r_debug _r_debug __attribute__((nocommon,
section(".r_debug")));

Compiling, but :

extern struct r_debug _r_debug;
r_debug = something();
struct r_debug _r_debug __attribute__((nocommon,
section(".r_debug")));

NOT compiling (which is almost definitely a bug).

*From:*tha...@google.com
[mailto:tha...@google.com
] *On Behalf Of *Nico Weber
*Sent:* Wednesday, October 4, 2017 1:14 PM
*To:* Keane, Erich mailto:erich.ke...@intel.com>>
*Cc:* Andrews, Elizabeth mailto:elizabeth.andr...@intel.com>>; Friedman, Eli
mailto:efrie...@codeaurora.org>>;
cfe-commits mailto:cfe-commits@lists.llvm.org>>


*Subject:* Re: r314262 - Emit section information for extern
variables.

For why, here's the comment from the code I linked to:

/*

 * GDB looks for this symbol name when it cannot find
PT_DYNAMIC->DT_DEBUG.

 * We don't have a PT_DYNAMIC, so it will find this.  Now all we
have to do

 * is arrange for this space to be filled in with the dynamic linker's

 * _r_debug contents after they're initialized.  That way,
attaching GDB to

 * this process or examining its core file will find the PIE we
loaded, the

 * dynamic linker, and all the shared libraries, making debugging
pleasant.

 */

On Wed, Oct 4, 2017 at 4:11 PM, Keane, Erich
mailto:erich.ke...@intel.com>> wrote:

I’ve added Elizabeth, who is the original patch author. 
Hopefully she can help out here. Additionally, Eli did the
original review, so hopefully he can chime in as well.


I believe the necessity for this warning came out of the
discussion on fixing the section behavior.  The issue here is
that redeclaring with a different ‘section’ can cause some
pretty nasty issues, since it isn’t terribly clear what
happens if the variable is used in the meantime.

There is 1 change that I can think of that Elizabeth and I
discussed, which was to only warn in the case where there was
a USAGE between these two redeclarations.  I’m not sure that
will allow na_cl to compile, however it is my belief that if
there IS a usage between link.h:64 and nacl_bootstrap.c:434,
that this is a bug in nacl that is simply being uncovered
thanks to this new warning.

Is there a good/reasonable reason the source of nacl wants to
redeclare this with a different ‘section’?

*From:*tha...@google.com
[mailto:tha...@google.com
] *On Behalf Of *Nico Weber
*Sent:* Wednesday, October 4, 2017 12:59 PM
*To:* Keane, Erich mailto:erich.ke...@intel.com>>
*Cc:* cfe-commits mailto:cfe-commits@lists.llvm.org>>
*Subject:* Re: r314262 - Emit section information for extern
variables.

Hi Erich,

this breaks existing code. NaCl does this:

#include 

struct r_debug _r_debug __attribute__((nocommon,
section(".r_debug")));

(There's a lengthy-ish comment for

RE: r314262 - Emit section information for extern variables.

[Andrews, Elizabeth via cfe-commits]

Hello,
I just spoke to Erich. The warning isn’t supposed to be emitted when the 
section attribute is specified on a definition. I’m not sure why struct r_debug 
_r_debug __attribute__((nocommon, section(".r_debug"))); failed the 
isThisDeclarationADefiniton check. I need to look into it.
Thanks,
Elizabeth

From: tha...@google.com [mailto:tha...@google.com] On Behalf Of Nico Weber
Sent: Wednesday, October 4, 2017 4:29 PM
To: Keane, Erich 
Cc: Andrews, Elizabeth ; Friedman, Eli 
; cfe-commits 
Subject: Re: r314262 - Emit section information for extern variables.

All I know about this code that it used to build (and still builds with gcc) 
and now it doesn't, sorry :-) What that code does seems somewhat questionable, 
but also somewhat useful, and it feels like the behavior change from this 
change here for that code might have been unintentional.

Your suggestion sounds reasonable to me.

On Wed, Oct 4, 2017 at 4:18 PM, Keane, Erich 
mailto:erich.ke...@intel.com>> wrote:
I saw that… I don’t see where it prevents the same change from being made in 
link.h.

As I mentioned, there is a solution to make this Warning less aggressive (in 
the lib/Sema/SemaDecl.cpp changes, add a condition that Old->isUsed() before 
the warning.  I’m wondering if that solves your issue.

It would result in
extern struct r_debug _r_debug;
struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));
Compiling, but :
extern struct r_debug _r_debug;
r_debug = something();
struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));
NOT compiling (which is almost definitely a bug).



From: tha...@google.com 
[mailto:tha...@google.com] On Behalf Of Nico Weber
Sent: Wednesday, October 4, 2017 1:14 PM
To: Keane, Erich mailto:erich.ke...@intel.com>>
Cc: Andrews, Elizabeth 
mailto:elizabeth.andr...@intel.com>>; Friedman, 
Eli mailto:efrie...@codeaurora.org>>; cfe-commits 
mailto:cfe-commits@lists.llvm.org>>

Subject: Re: r314262 - Emit section information for extern variables.

For why, here's the comment from the code I linked to:

/*
 * GDB looks for this symbol name when it cannot find PT_DYNAMIC->DT_DEBUG.
 * We don't have a PT_DYNAMIC, so it will find this.  Now all we have to do
 * is arrange for this space to be filled in with the dynamic linker's
 * _r_debug contents after they're initialized.  That way, attaching GDB to
 * this process or examining its core file will find the PIE we loaded, the
 * dynamic linker, and all the shared libraries, making debugging pleasant.
 */

On Wed, Oct 4, 2017 at 4:11 PM, Keane, Erich 
mailto:erich.ke...@intel.com>> wrote:
I’ve added Elizabeth, who is the original patch author.  Hopefully she can help 
out here.  Additionally, Eli did the original review, so hopefully he can chime 
in as well.

I believe the necessity for this warning came out of the discussion on fixing 
the section behavior.  The issue here is that redeclaring with a different 
‘section’ can cause some pretty nasty issues, since it isn’t terribly clear 
what happens if the variable is used in the meantime.

There is 1 change that I can think of that Elizabeth and I discussed, which was 
to only warn in the case where there was a USAGE between these two 
redeclarations.  I’m not sure that will allow na_cl to compile, however it is 
my belief that if there IS a usage between link.h:64 and nacl_bootstrap.c:434, 
that this is a bug in nacl that is simply being uncovered thanks to this new 
warning.

Is there a good/reasonable reason the source of nacl wants to redeclare this 
with a different ‘section’?


From: tha...@google.com 
[mailto:tha...@google.com] On Behalf Of Nico Weber
Sent: Wednesday, October 4, 2017 12:59 PM
To: Keane, Erich mailto:erich.ke...@intel.com>>
Cc: cfe-commits mailto:cfe-commits@lists.llvm.org>>
Subject: Re: r314262 - Emit section information for extern variables.

Hi Erich,

this breaks existing code. NaCl does this:

#include 
struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));

(There's a lengthy-ish comment for why in 
https://cs.chromium.org/chromium/src/native_client/src/trusted/service_runtime/linux/nacl_bootstrap.c?q=nacl_bootstrap.c&sq=package:chromium&dr&l=424)

link.h in e.g. the debian jessie sysroot says:
extern struct r_debug _r_debug;

After this change, clang complains:

../../native_client/src/trusted/service_runtime/linux/nacl_bootstrap.c:434:16: 
error: section attribute is specified on redeclared variable [-Werror,-Wsection]
struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));
   ^
../../build/linux/debian_jessie_amd64-sysroot/usr/include/link.h:67:23: note: 
previous declaration is here
extern struct r_debug _r_debug;


This code used to work in clang, and continues to work in gcc. So this patch 
probably isn't quite the right approach. Ideas?

On Tue, Sep 26, 2017 at 7:42 PM, Erich Keane via cfe-commits 
mailto:c

RE: r314262 - Emit section information for extern variables.

[Keane, Erich via cfe-commits]

Elizabeth pointed out to me separately that the “isDeclarationADefinition” 
check ought to have prevented this from happening, so she’s taking a look I 
believe.  The usage proposal I mentioned below might be handy as well.

My fear is that this is a case where the existing functionality in Chromium 
works ‘by chance’ and isn’t terribly guaranteed by the code generation of 
either compiler.  IF this is the case, it could be a situation where this 
warning has found a bug.

As I’m not convinced that this is actually a clang bug, I would like to give 
Elizabeth a chance to poke around and make that determination first before a 
revert, if that is acceptable to you.

-Erich

From: tha...@google.com [mailto:tha...@google.com] On Behalf Of Nico Weber
Sent: Wednesday, October 4, 2017 1:29 PM
To: Keane, Erich 
Cc: Andrews, Elizabeth ; Friedman, Eli 
; cfe-commits 
Subject: Re: r314262 - Emit section information for extern variables.

All I know about this code that it used to build (and still builds with gcc) 
and now it doesn't, sorry :-) What that code does seems somewhat questionable, 
but also somewhat useful, and it feels like the behavior change from this 
change here for that code might have been unintentional.

Your suggestion sounds reasonable to me.

On Wed, Oct 4, 2017 at 4:18 PM, Keane, Erich 
mailto:erich.ke...@intel.com>> wrote:
I saw that… I don’t see where it prevents the same change from being made in 
link.h.

As I mentioned, there is a solution to make this Warning less aggressive (in 
the lib/Sema/SemaDecl.cpp changes, add a condition that Old->isUsed() before 
the warning.  I’m wondering if that solves your issue.

It would result in
extern struct r_debug _r_debug;
struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));
Compiling, but :
extern struct r_debug _r_debug;
r_debug = something();
struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));
NOT compiling (which is almost definitely a bug).



From: tha...@google.com 
[mailto:tha...@google.com] On Behalf Of Nico Weber
Sent: Wednesday, October 4, 2017 1:14 PM
To: Keane, Erich mailto:erich.ke...@intel.com>>
Cc: Andrews, Elizabeth 
mailto:elizabeth.andr...@intel.com>>; Friedman, 
Eli mailto:efrie...@codeaurora.org>>; cfe-commits 
mailto:cfe-commits@lists.llvm.org>>

Subject: Re: r314262 - Emit section information for extern variables.

For why, here's the comment from the code I linked to:

/*
 * GDB looks for this symbol name when it cannot find PT_DYNAMIC->DT_DEBUG.
 * We don't have a PT_DYNAMIC, so it will find this.  Now all we have to do
 * is arrange for this space to be filled in with the dynamic linker's
 * _r_debug contents after they're initialized.  That way, attaching GDB to
 * this process or examining its core file will find the PIE we loaded, the
 * dynamic linker, and all the shared libraries, making debugging pleasant.
 */

On Wed, Oct 4, 2017 at 4:11 PM, Keane, Erich 
mailto:erich.ke...@intel.com>> wrote:
I’ve added Elizabeth, who is the original patch author.  Hopefully she can help 
out here.  Additionally, Eli did the original review, so hopefully he can chime 
in as well.

I believe the necessity for this warning came out of the discussion on fixing 
the section behavior.  The issue here is that redeclaring with a different 
‘section’ can cause some pretty nasty issues, since it isn’t terribly clear 
what happens if the variable is used in the meantime.

There is 1 change that I can think of that Elizabeth and I discussed, which was 
to only warn in the case where there was a USAGE between these two 
redeclarations.  I’m not sure that will allow na_cl to compile, however it is 
my belief that if there IS a usage between link.h:64 and nacl_bootstrap.c:434, 
that this is a bug in nacl that is simply being uncovered thanks to this new 
warning.

Is there a good/reasonable reason the source of nacl wants to redeclare this 
with a different ‘section’?


From: tha...@google.com 
[mailto:tha...@google.com] On Behalf Of Nico Weber
Sent: Wednesday, October 4, 2017 12:59 PM
To: Keane, Erich mailto:erich.ke...@intel.com>>
Cc: cfe-commits mailto:cfe-commits@lists.llvm.org>>
Subject: Re: r314262 - Emit section information for extern variables.

Hi Erich,

this breaks existing code. NaCl does this:

#include 
struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));

(There's a lengthy-ish comment for why in 
https://cs.chromium.org/chromium/src/native_client/src/trusted/service_runtime/linux/nacl_bootstrap.c?q=nacl_bootstrap.c&sq=package:chromium&dr&l=424)

link.h in e.g. the debian jessie sysroot says:
extern struct r_debug _r_debug;

After this change, clang complains:

../../native_client/src/trusted/service_runtime/linux/nacl_bootstrap.c:434:16: 
error: section attribute is specified on redeclared variable [-Werror,-Wsection]
struct r_debug _r_debug __attribute__((nocommon, section

[PATCH] D37822: [OpenCL] Clean up and add missing fields for block struct

[Yaxun Liu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
yaxunl marked an inline comment as done.
Closed by commit rL314932: [OpenCL] Clean up and add missing fields for block 
struct (authored by yaxunl).

Changed prior to commit:
  https://reviews.llvm.org/D37822?vs=116877&id=117732#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D37822

Files:
  cfe/trunk/lib/CodeGen/CGBlocks.cpp
  cfe/trunk/lib/CodeGen/CGOpenCLRuntime.cpp
  cfe/trunk/lib/CodeGen/CGOpenCLRuntime.h
  cfe/trunk/lib/CodeGen/TargetInfo.h
  cfe/trunk/test/CodeGen/blocks-opencl.cl
  cfe/trunk/test/CodeGenOpenCL/blocks.cl
  cfe/trunk/test/CodeGenOpenCL/cl20-device-side-enqueue.cl

Index: cfe/trunk/test/CodeGenOpenCL/cl20-device-side-enqueue.cl
===
--- cfe/trunk/test/CodeGenOpenCL/cl20-device-side-enqueue.cl
+++ cfe/trunk/test/CodeGenOpenCL/cl20-device-side-enqueue.cl
@@ -7,7 +7,7 @@
 typedef struct {int a;} ndrange_t;
 
 // N.B. The check here only exists to set BL_GLOBAL
-// COMMON: @block_G =  addrspace(1) constant void (i8 addrspace(3)*) addrspace(4)* addrspacecast (void (i8 addrspace(3)*) addrspace(1)* bitcast ({ i8**, i32, i32, i8*, %struct.__block_descriptor addrspace(2)* } addrspace(1)* [[BL_GLOBAL:@__block_literal_global(\.[0-9]+)?]] to void (i8 addrspace(3)*) addrspace(1)*) to void (i8 addrspace(3)*) addrspace(4)*)
+// COMMON: @block_G =  addrspace(1) constant void (i8 addrspace(3)*) addrspace(4)* addrspacecast (void (i8 addrspace(3)*) addrspace(1)* bitcast ({ i32, i32, i8 addrspace(4)* } addrspace(1)* [[BL_GLOBAL:@__block_literal_global(\.[0-9]+)?]] to void (i8 addrspace(3)*) addrspace(1)*) to void (i8 addrspace(3)*) addrspace(4)*)
 const bl_t block_G = (bl_t) ^ (local void *a) {};
 
 kernel void device_side_enqueue(global int *a, global int *b, int i) {
@@ -27,9 +27,10 @@
   // COMMON: [[NDR:%[a-z0-9]+]] = alloca %struct.ndrange_t, align 4
   // COMMON: [[DEF_Q:%[0-9]+]] = load %opencl.queue_t{{.*}}*, %opencl.queue_t{{.*}}** %default_queue
   // COMMON: [[FLAGS:%[0-9]+]] = load i32, i32* %flags
-  // COMMON: [[BL:%[0-9]+]] = bitcast <{ i8*, i32, i32, i8*, %struct.__block_descriptor addrspace(2)*, i32{{.*}}, i32{{.*}}, i32{{.*}} }>* %block to void ()*
+  // B32: [[BL:%[0-9]+]] = bitcast <{ i32, i32, i8 addrspace(4)*, i32 addrspace(1)*, i32, i32 addrspace(1)* }>* %block to void ()*
+  // B64: [[BL:%[0-9]+]] = bitcast <{ i32, i32, i8 addrspace(4)*, i32 addrspace(1)*, i32 addrspace(1)*, i32 }>* %block to void ()*
   // COMMON: [[BL_I8:%[0-9]+]] = addrspacecast void ()* [[BL]] to i8 addrspace(4)*
-  // COMMON: call i32 @__enqueue_kernel_basic(%opencl.queue_t{{.*}}* [[DEF_Q]], i32 [[FLAGS]], %struct.ndrange_t* byval [[NDR]]{{(.[0-9]+)?}}, i8 addrspace(4)* [[BL_I8]])
+  // COMMON: call i32 @__enqueue_kernel_basic(%opencl.queue_t{{.*}}* [[DEF_Q]], i32 [[FLAGS]], %struct.ndrange_t* byval [[NDR]]{{([0-9]+)?}}, i8 addrspace(4)* [[BL_I8]])
   enqueue_kernel(default_queue, flags, ndrange,
  ^(void) {
a[i] = b[i];
@@ -39,7 +40,7 @@
   // COMMON: [[FLAGS:%[0-9]+]] = load i32, i32* %flags
   // COMMON: [[WAIT_EVNT:%[0-9]+]] = addrspacecast %opencl.clk_event_t{{.*}}** %event_wait_list to %opencl.clk_event_t{{.*}}* addrspace(4)*
   // COMMON: [[EVNT:%[0-9]+]] = addrspacecast %opencl.clk_event_t{{.*}}** %clk_event to %opencl.clk_event_t{{.*}}* addrspace(4)*
-  // COMMON: [[BL:%[0-9]+]] = bitcast <{ i8*, i32, i32, i8*, %struct.__block_descriptor addrspace(2)*, i32{{.*}}, i32{{.*}}, i32{{.*}} }>* %block3 to void ()*
+  // COMMON: [[BL:%[0-9]+]] = bitcast <{ i32, i32, i8 addrspace(4)*, i32{{.*}}, i32{{.*}}, i32{{.*}} }>* %block3 to void ()*
   // COMMON: [[BL_I8:%[0-9]+]] = addrspacecast void ()* [[BL]] to i8 addrspace(4)*
   // COMMON: call i32 @__enqueue_kernel_basic_events(%opencl.queue_t{{.*}}* [[DEF_Q]], i32 [[FLAGS]],  %struct.ndrange_t* {{.*}}, i32 2, %opencl.clk_event_t{{.*}}* addrspace(4)* [[WAIT_EVNT]], %opencl.clk_event_t{{.*}}* addrspace(4)* [[EVNT]], i8 addrspace(4)* [[BL_I8]])
   enqueue_kernel(default_queue, flags, ndrange, 2, &event_wait_list, &clk_event,
@@ -52,11 +53,11 @@
   // B32: %[[TMP:.*]] = alloca [1 x i32]
   // B32: %[[TMP1:.*]] = getelementptr [1 x i32], [1 x i32]* %[[TMP]], i32 0, i32 0
   // B32: store i32 256, i32* %[[TMP1]], align 4
-  // B32: call i32 @__enqueue_kernel_vaargs(%opencl.queue_t{{.*}}* [[DEF_Q]], i32 [[FLAGS]], %struct.ndrange_t* [[NDR]]{{(.[0-9]+)?}}, i8 addrspace(4)* addrspacecast (i8 addrspace(1)* bitcast ({ i8**, i32, i32, i8*, %struct.__block_descriptor addrspace(2)* } addrspace(1)* @__block_literal_global{{(.[0-9]+)?}} to i8 addrspace(1)*) to i8 addrspace(4)*), i32 1, i32* %[[TMP1]])
+  // B32: call i32 @__enqueue_kernel_vaargs(%opencl.queue_t{{.*}}* [[DEF_Q]], i32 [[FLAGS]], %struct.ndrange_t* [[NDR]]{{([0-9]+)?}}, i8 addrspace(4)* addrspacecast (i8 addrspace(1)* bitcast ({ i32, i32, i8 addrspace(4)* } addrspace(1)* @__block_literal_global{{(.[0-9]+)?}} to i8 addrspace(1)*) to i8 ad

r314932 - [OpenCL] Clean up and add missing fields for block struct

[Yaxun Liu via cfe-commits]

Author: yaxunl
Date: Wed Oct  4 13:32:17 2017
New Revision: 314932

URL: http://llvm.org/viewvc/llvm-project?rev=314932&view=rev
Log:
[OpenCL] Clean up and add missing fields for block struct

Currently block is translated to a structure equivalent to

struct Block {
  void *isa;
  int flags;
  int reserved;
  void *invoke;
  void *descriptor;
};
Except invoke, which is the pointer to the block invoke function,
all other fields are useless for OpenCL, which clutter the IR and
also waste memory since the block struct is passed to the block
invoke function as argument.

On the other hand, the size and alignment of the block struct is
not stored in the struct, which causes difficulty to implement
__enqueue_kernel as library function, since the library function
needs to know the size and alignment of the argument which needs
to be passed to the kernel.

This patch removes the useless fields from the block struct and adds
size and align fields. The equivalent block struct will become

struct Block {
  int size;
  int align;
  generic void *invoke;
 /* custom fields */
};
It also changes the pointer to the invoke function to be
a generic pointer since the address space of a function
may not be private on certain targets.

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

Removed:
cfe/trunk/test/CodeGen/blocks-opencl.cl
Modified:
cfe/trunk/lib/CodeGen/CGBlocks.cpp
cfe/trunk/lib/CodeGen/CGOpenCLRuntime.cpp
cfe/trunk/lib/CodeGen/CGOpenCLRuntime.h
cfe/trunk/lib/CodeGen/TargetInfo.h
cfe/trunk/test/CodeGenOpenCL/blocks.cl
cfe/trunk/test/CodeGenOpenCL/cl20-device-side-enqueue.cl

Modified: cfe/trunk/lib/CodeGen/CGBlocks.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBlocks.cpp?rev=314932&r1=314931&r2=314932&view=diff
==
--- cfe/trunk/lib/CodeGen/CGBlocks.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBlocks.cpp Wed Oct  4 13:32:17 2017
@@ -14,11 +14,13 @@
 #include "CGBlocks.h"
 #include "CGDebugInfo.h"
 #include "CGObjCRuntime.h"
+#include "CGOpenCLRuntime.h"
 #include "CodeGenFunction.h"
 #include "CodeGenModule.h"
 #include "ConstantEmitter.h"
-#include "clang/CodeGen/ConstantInitBuilder.h"
+#include "TargetInfo.h"
 #include "clang/AST/DeclObjC.h"
+#include "clang/CodeGen/ConstantInitBuilder.h"
 #include "llvm/ADT/SmallSet.h"
 #include "llvm/IR/CallSite.h"
 #include "llvm/IR/DataLayout.h"
@@ -302,21 +304,55 @@ static CharUnits getLowBit(CharUnits v)
 
 static void initializeForBlockHeader(CodeGenModule &CGM, CGBlockInfo &info,
  SmallVectorImpl &elementTypes) {
-  // The header is basically 'struct { void *; int; int; void *; void *; }'.
-  // Assert that that struct is packed.
-  assert(CGM.getIntSize() <= CGM.getPointerSize());
-  assert(CGM.getIntAlign() <= CGM.getPointerAlign());
-  assert((2 * CGM.getIntSize()).isMultipleOf(CGM.getPointerAlign()));
-
-  info.BlockAlign = CGM.getPointerAlign();
-  info.BlockSize = 3 * CGM.getPointerSize() + 2 * CGM.getIntSize();
 
   assert(elementTypes.empty());
-  elementTypes.push_back(CGM.VoidPtrTy);
-  elementTypes.push_back(CGM.IntTy);
-  elementTypes.push_back(CGM.IntTy);
-  elementTypes.push_back(CGM.VoidPtrTy);
-  elementTypes.push_back(CGM.getBlockDescriptorType());
+  if (CGM.getLangOpts().OpenCL) {
+// The header is basically 'struct { int; int; generic void *;
+// custom_fields; }'. Assert that struct is packed.
+auto GenPtrAlign = CharUnits::fromQuantity(
+CGM.getTarget().getPointerAlign(LangAS::opencl_generic) / 8);
+auto GenPtrSize = CharUnits::fromQuantity(
+CGM.getTarget().getPointerWidth(LangAS::opencl_generic) / 8);
+assert(CGM.getIntSize() <= GenPtrSize);
+assert(CGM.getIntAlign() <= GenPtrAlign);
+assert((2 * CGM.getIntSize()).isMultipleOf(GenPtrAlign));
+elementTypes.push_back(CGM.IntTy); /* total size */
+elementTypes.push_back(CGM.IntTy); /* align */
+elementTypes.push_back(
+CGM.getOpenCLRuntime()
+.getGenericVoidPointerType()); /* invoke function */
+unsigned Offset =
+2 * CGM.getIntSize().getQuantity() + GenPtrSize.getQuantity();
+unsigned BlockAlign = GenPtrAlign.getQuantity();
+if (auto *Helper =
+CGM.getTargetCodeGenInfo().getTargetOpenCLBlockHelper()) {
+  for (auto I : Helper->getCustomFieldTypes()) /* custom fields */ {
+// TargetOpenCLBlockHelp needs to make sure the struct is packed.
+// If necessary, add padding fields to the custom fields.
+unsigned Align = CGM.getDataLayout().getABITypeAlignment(I);
+if (BlockAlign < Align)
+  BlockAlign = Align;
+assert(Offset % Align == 0);
+Offset += CGM.getDataLayout().getTypeAllocSize(I);
+elementTypes.push_back(I);
+  }
+}
+info.BlockAlign = CharUnits::fromQuantity(BlockAlign);
+info.BlockSize = CharUnits::fromQuantity(Offset);
+  } else {
+// The header 

Re: r314262 - Emit section information for extern variables.

[Nico Weber via cfe-commits]

All I know about this code that it used to build (and still builds with
gcc) and now it doesn't, sorry :-) What that code does seems somewhat
questionable, but also somewhat useful, and it feels like the behavior
change from this change here for that code might have been unintentional.

Your suggestion sounds reasonable to me.

On Wed, Oct 4, 2017 at 4:18 PM, Keane, Erich  wrote:

> I saw that… I don’t see where it prevents the same change from being made
> in link.h.
>
>
>
> As I mentioned, there is a solution to make this Warning less aggressive
> (in the lib/Sema/SemaDecl.cpp changes, add a condition that Old->isUsed()
> before the warning.  I’m wondering if that solves your issue.
>
>
>
> It would result in
>
> extern struct r_debug _r_debug;
> struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));
>
> Compiling, but :
>
> extern struct r_debug _r_debug;
> r_debug = something();
> struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));
>
> NOT compiling (which is almost definitely a bug).
>
>
>
>
>
>
>
> *From:* tha...@google.com [mailto:tha...@google.com] *On Behalf Of *Nico
> Weber
> *Sent:* Wednesday, October 4, 2017 1:14 PM
> *To:* Keane, Erich 
> *Cc:* Andrews, Elizabeth ; Friedman, Eli <
> efrie...@codeaurora.org>; cfe-commits 
>
> *Subject:* Re: r314262 - Emit section information for extern variables.
>
>
>
> For why, here's the comment from the code I linked to:
>
>
>
> /*
>
>  * GDB looks for this symbol name when it cannot find PT_DYNAMIC->DT_DEBUG.
>
>  * We don't have a PT_DYNAMIC, so it will find this.  Now all we have to do
>
>  * is arrange for this space to be filled in with the dynamic linker's
>
>  * _r_debug contents after they're initialized.  That way, attaching GDB to
>
>  * this process or examining its core file will find the PIE we loaded, the
>
>  * dynamic linker, and all the shared libraries, making debugging pleasant.
>
>  */
>
>
>
> On Wed, Oct 4, 2017 at 4:11 PM, Keane, Erich 
> wrote:
>
> I’ve added Elizabeth, who is the original patch author.  Hopefully she can
> help out here.  Additionally, Eli did the original review, so hopefully he
> can chime in as well.
>
>
> I believe the necessity for this warning came out of the discussion on
> fixing the section behavior.  The issue here is that redeclaring with a
> different ‘section’ can cause some pretty nasty issues, since it isn’t
> terribly clear what happens if the variable is used in the meantime.
>
>
>
> There is 1 change that I can think of that Elizabeth and I discussed,
> which was to only warn in the case where there was a USAGE between these
> two redeclarations.  I’m not sure that will allow na_cl to compile, however
> it is my belief that if there IS a usage between link.h:64 and
> nacl_bootstrap.c:434, that this is a bug in nacl that is simply being
> uncovered thanks to this new warning.
>
>
>
> Is there a good/reasonable reason the source of nacl wants to redeclare
> this with a different ‘section’?
>
>
>
>
>
> *From:* tha...@google.com [mailto:tha...@google.com] *On Behalf Of *Nico
> Weber
> *Sent:* Wednesday, October 4, 2017 12:59 PM
> *To:* Keane, Erich 
> *Cc:* cfe-commits 
> *Subject:* Re: r314262 - Emit section information for extern variables.
>
>
>
> Hi Erich,
>
>
>
> this breaks existing code. NaCl does this:
>
>
>
> #include 
>
> struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));
>
>
>
> (There's a lengthy-ish comment for why in https://cs.chromium.org/
> chromium/src/native_client/src/trusted/service_runtime/
> linux/nacl_bootstrap.c?q=nacl_bootstrap.c&sq=package:chromium&dr&l=424)
>
>
>
> link.h in e.g. the debian jessie sysroot says:
>
> extern struct r_debug _r_debug;
>
>
>
> After this change, clang complains:
>
>
>
> ../../native_client/src/trusted/service_runtime/linux/nacl_bootstrap.c:434:16:
> error: section attribute is specified on redeclared variable
> [-Werror,-Wsection]
>
> struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));
>
>^
>
> ../../build/linux/debian_jessie_amd64-sysroot/usr/include/link.h:67:23:
> note: previous declaration is here
>
> extern struct r_debug _r_debug;
>
>
>
>
>
> This code used to work in clang, and continues to work in gcc. So this
> patch probably isn't quite the right approach. Ideas?
>
>
>
> On Tue, Sep 26, 2017 at 7:42 PM, Erich Keane via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> Author: erichkeane
> Date: Tue Sep 26 16:42:34 2017
> New Revision: 314262
>
> URL: http://llvm.org/viewvc/llvm-project?rev=314262&view=rev
> Log:
> Emit section information for extern variables.
>
> Currently, if _attribute_((section())) is used for extern variables,
> section information is not emitted in generated IR when the variables are
> used.
> This is expected since sections are not generated for external linkage
> objects.
> However NiosII requires this information as it uses special GP-relative
> accesses
> for any objects that use attribute section (.sdata). GCC kee

RE: r314262 - Emit section information for extern variables.

[Keane, Erich via cfe-commits]

I saw that… I don’t see where it prevents the same change from being made in 
link.h.

As I mentioned, there is a solution to make this Warning less aggressive (in 
the lib/Sema/SemaDecl.cpp changes, add a condition that Old->isUsed() before 
the warning.  I’m wondering if that solves your issue.

It would result in
extern struct r_debug _r_debug;
struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));
Compiling, but :
extern struct r_debug _r_debug;
r_debug = something();
struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));
NOT compiling (which is almost definitely a bug).



From: tha...@google.com [mailto:tha...@google.com] On Behalf Of Nico Weber
Sent: Wednesday, October 4, 2017 1:14 PM
To: Keane, Erich 
Cc: Andrews, Elizabeth ; Friedman, Eli 
; cfe-commits 
Subject: Re: r314262 - Emit section information for extern variables.

For why, here's the comment from the code I linked to:

/*
 * GDB looks for this symbol name when it cannot find PT_DYNAMIC->DT_DEBUG.
 * We don't have a PT_DYNAMIC, so it will find this.  Now all we have to do
 * is arrange for this space to be filled in with the dynamic linker's
 * _r_debug contents after they're initialized.  That way, attaching GDB to
 * this process or examining its core file will find the PIE we loaded, the
 * dynamic linker, and all the shared libraries, making debugging pleasant.
 */

On Wed, Oct 4, 2017 at 4:11 PM, Keane, Erich 
mailto:erich.ke...@intel.com>> wrote:
I’ve added Elizabeth, who is the original patch author.  Hopefully she can help 
out here.  Additionally, Eli did the original review, so hopefully he can chime 
in as well.

I believe the necessity for this warning came out of the discussion on fixing 
the section behavior.  The issue here is that redeclaring with a different 
‘section’ can cause some pretty nasty issues, since it isn’t terribly clear 
what happens if the variable is used in the meantime.

There is 1 change that I can think of that Elizabeth and I discussed, which was 
to only warn in the case where there was a USAGE between these two 
redeclarations.  I’m not sure that will allow na_cl to compile, however it is 
my belief that if there IS a usage between link.h:64 and nacl_bootstrap.c:434, 
that this is a bug in nacl that is simply being uncovered thanks to this new 
warning.

Is there a good/reasonable reason the source of nacl wants to redeclare this 
with a different ‘section’?


From: tha...@google.com 
[mailto:tha...@google.com] On Behalf Of Nico Weber
Sent: Wednesday, October 4, 2017 12:59 PM
To: Keane, Erich mailto:erich.ke...@intel.com>>
Cc: cfe-commits mailto:cfe-commits@lists.llvm.org>>
Subject: Re: r314262 - Emit section information for extern variables.

Hi Erich,

this breaks existing code. NaCl does this:

#include 
struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));

(There's a lengthy-ish comment for why in 
https://cs.chromium.org/chromium/src/native_client/src/trusted/service_runtime/linux/nacl_bootstrap.c?q=nacl_bootstrap.c&sq=package:chromium&dr&l=424)

link.h in e.g. the debian jessie sysroot says:
extern struct r_debug _r_debug;

After this change, clang complains:

../../native_client/src/trusted/service_runtime/linux/nacl_bootstrap.c:434:16: 
error: section attribute is specified on redeclared variable [-Werror,-Wsection]
struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));
   ^
../../build/linux/debian_jessie_amd64-sysroot/usr/include/link.h:67:23: note: 
previous declaration is here
extern struct r_debug _r_debug;


This code used to work in clang, and continues to work in gcc. So this patch 
probably isn't quite the right approach. Ideas?

On Tue, Sep 26, 2017 at 7:42 PM, Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Tue Sep 26 16:42:34 2017
New Revision: 314262

URL: http://llvm.org/viewvc/llvm-project?rev=314262&view=rev
Log:
Emit section information for extern variables.

Currently, if _attribute_((section())) is used for extern variables,
section information is not emitted in generated IR when the variables are used.
This is expected since sections are not generated for external linkage objects.
However NiosII requires this information as it uses special GP-relative accesses
for any objects that use attribute section (.sdata). GCC keeps this attribute in
  middle-end.

This change emits the section information for all targets.

Patch By: Elizabeth Andrews

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


Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/test/Sema/attr-section.c

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=314262&r1=314261&r2=314262&view=diff
=

Re: r314262 - Emit section information for extern variables.

[Nico Weber via cfe-commits]

For why, here's the comment from the code I linked to:

/*
 * GDB looks for this symbol name when it cannot find PT_DYNAMIC->DT_DEBUG.
 * We don't have a PT_DYNAMIC, so it will find this.  Now all we have to do
 * is arrange for this space to be filled in with the dynamic linker's
 * _r_debug contents after they're initialized.  That way, attaching GDB to
 * this process or examining its core file will find the PIE we loaded, the
 * dynamic linker, and all the shared libraries, making debugging pleasant.
 */

On Wed, Oct 4, 2017 at 4:11 PM, Keane, Erich  wrote:

> I’ve added Elizabeth, who is the original patch author.  Hopefully she can
> help out here.  Additionally, Eli did the original review, so hopefully he
> can chime in as well.
>
>
> I believe the necessity for this warning came out of the discussion on
> fixing the section behavior.  The issue here is that redeclaring with a
> different ‘section’ can cause some pretty nasty issues, since it isn’t
> terribly clear what happens if the variable is used in the meantime.
>
>
>
> There is 1 change that I can think of that Elizabeth and I discussed,
> which was to only warn in the case where there was a USAGE between these
> two redeclarations.  I’m not sure that will allow na_cl to compile, however
> it is my belief that if there IS a usage between link.h:64 and
> nacl_bootstrap.c:434, that this is a bug in nacl that is simply being
> uncovered thanks to this new warning.
>
>
>
> Is there a good/reasonable reason the source of nacl wants to redeclare
> this with a different ‘section’?
>
>
>
>
>
> *From:* tha...@google.com [mailto:tha...@google.com] *On Behalf Of *Nico
> Weber
> *Sent:* Wednesday, October 4, 2017 12:59 PM
> *To:* Keane, Erich 
> *Cc:* cfe-commits 
> *Subject:* Re: r314262 - Emit section information for extern variables.
>
>
>
> Hi Erich,
>
>
>
> this breaks existing code. NaCl does this:
>
>
>
> #include 
>
> struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));
>
>
>
> (There's a lengthy-ish comment for why in https://cs.chromium.org/
> chromium/src/native_client/src/trusted/service_runtime/
> linux/nacl_bootstrap.c?q=nacl_bootstrap.c&sq=package:chromium&dr&l=424)
>
>
>
> link.h in e.g. the debian jessie sysroot says:
>
> extern struct r_debug _r_debug;
>
>
>
> After this change, clang complains:
>
>
>
> ../../native_client/src/trusted/service_runtime/linux/nacl_bootstrap.c:434:16:
> error: section attribute is specified on redeclared variable
> [-Werror,-Wsection]
>
> struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));
>
>^
>
> ../../build/linux/debian_jessie_amd64-sysroot/usr/include/link.h:67:23:
> note: previous declaration is here
>
> extern struct r_debug _r_debug;
>
>
>
>
>
> This code used to work in clang, and continues to work in gcc. So this
> patch probably isn't quite the right approach. Ideas?
>
>
>
> On Tue, Sep 26, 2017 at 7:42 PM, Erich Keane via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> Author: erichkeane
> Date: Tue Sep 26 16:42:34 2017
> New Revision: 314262
>
> URL: http://llvm.org/viewvc/llvm-project?rev=314262&view=rev
> Log:
> Emit section information for extern variables.
>
> Currently, if _attribute_((section())) is used for extern variables,
> section information is not emitted in generated IR when the variables are
> used.
> This is expected since sections are not generated for external linkage
> objects.
> However NiosII requires this information as it uses special GP-relative
> accesses
> for any objects that use attribute section (.sdata). GCC keeps this
> attribute in
>   middle-end.
>
> This change emits the section information for all targets.
>
> Patch By: Elizabeth Andrews
>
> Differential Revision:https://reviews.llvm.org/D36487
>
>
> Modified:
> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> cfe/trunk/lib/Sema/SemaDecl.cpp
> cfe/trunk/test/Sema/attr-section.c
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/
> DiagnosticSemaKinds.td?rev=314262&r1=314261&r2=314262&view=diff
> 
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Tue Sep 26
> 16:42:34 2017
> @@ -2620,6 +2620,8 @@ def err_attribute_section_invalid_for_ta
>"argument to 'section' attribute is not valid for this target: %0">;
>  def warn_mismatched_section : Warning<
>"section does not match previous declaration">, InGroup;
> +def warn_attribute_section_on_redeclaration : Warning<
> +  "section attribute is specified on redeclared variable">,
> InGroup;
>
>  def err_anonymous_property: Error<
>"anonymous property is not supported">;
>
> Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/
>

RE: r314262 - Emit section information for extern variables.

[Keane, Erich via cfe-commits]

I’ve added Elizabeth, who is the original patch author.  Hopefully she can help 
out here.  Additionally, Eli did the original review, so hopefully he can chime 
in as well.

I believe the necessity for this warning came out of the discussion on fixing 
the section behavior.  The issue here is that redeclaring with a different 
‘section’ can cause some pretty nasty issues, since it isn’t terribly clear 
what happens if the variable is used in the meantime.

There is 1 change that I can think of that Elizabeth and I discussed, which was 
to only warn in the case where there was a USAGE between these two 
redeclarations.  I’m not sure that will allow na_cl to compile, however it is 
my belief that if there IS a usage between link.h:64 and nacl_bootstrap.c:434, 
that this is a bug in nacl that is simply being uncovered thanks to this new 
warning.

Is there a good/reasonable reason the source of nacl wants to redeclare this 
with a different ‘section’?


From: tha...@google.com [mailto:tha...@google.com] On Behalf Of Nico Weber
Sent: Wednesday, October 4, 2017 12:59 PM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r314262 - Emit section information for extern variables.

Hi Erich,

this breaks existing code. NaCl does this:

#include 
struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));

(There's a lengthy-ish comment for why in 
https://cs.chromium.org/chromium/src/native_client/src/trusted/service_runtime/linux/nacl_bootstrap.c?q=nacl_bootstrap.c&sq=package:chromium&dr&l=424)

link.h in e.g. the debian jessie sysroot says:
extern struct r_debug _r_debug;

After this change, clang complains:

../../native_client/src/trusted/service_runtime/linux/nacl_bootstrap.c:434:16: 
error: section attribute is specified on redeclared variable [-Werror,-Wsection]
struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));
   ^
../../build/linux/debian_jessie_amd64-sysroot/usr/include/link.h:67:23: note: 
previous declaration is here
extern struct r_debug _r_debug;


This code used to work in clang, and continues to work in gcc. So this patch 
probably isn't quite the right approach. Ideas?

On Tue, Sep 26, 2017 at 7:42 PM, Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Tue Sep 26 16:42:34 2017
New Revision: 314262

URL: http://llvm.org/viewvc/llvm-project?rev=314262&view=rev
Log:
Emit section information for extern variables.

Currently, if _attribute_((section())) is used for extern variables,
section information is not emitted in generated IR when the variables are used.
This is expected since sections are not generated for external linkage objects.
However NiosII requires this information as it uses special GP-relative accesses
for any objects that use attribute section (.sdata). GCC keeps this attribute in
  middle-end.

This change emits the section information for all targets.

Patch By: Elizabeth Andrews

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


Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/test/Sema/attr-section.c

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=314262&r1=314261&r2=314262&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Tue Sep 26 16:42:34 
2017
@@ -2620,6 +2620,8 @@ def err_attribute_section_invalid_for_ta
   "argument to 'section' attribute is not valid for this target: %0">;
 def warn_mismatched_section : Warning<
   "section does not match previous declaration">, InGroup;
+def warn_attribute_section_on_redeclaration : Warning<
+  "section attribute is specified on redeclared variable">, InGroup;

 def err_anonymous_property: Error<
   "anonymous property is not supported">;

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=314262&r1=314261&r2=314262&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Tue Sep 26 16:42:34 2017
@@ -2432,6 +2432,12 @@ CodeGenModule::GetOrCreateLLVMGlobal(Str
   EmitGlobalVarDefinition(D);
 }

+// Emit section information for extern variables.
+if (D->hasExternalStorage()) {
+  if (const SectionAttr *SA = D->getAttr())
+GV->setSection(SA->getName());
+}
+
 // Handle XCore specific ABI requirements.
 if (getTriple().getArch() == llvm::Triple::xcore &&
 D->getLanguageLinkage() == CLanguageLinkage &&

Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/Sema

[PATCH] D36471: [StaticAnalyzer] Try to calculate arithmetic result when operand has a range of possible values

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

danielmarjamaki added a comment.

ping


Repository:
  rL LLVM

https://reviews.llvm.org/D36471



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

[PATCH] D30295: [analyzer] clarify undef shift result when shift count is negative or exceeds the bit width

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

danielmarjamaki added a comment.

ping


Repository:
  rL LLVM

https://reviews.llvm.org/D30295



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

Re: r314262 - Emit section information for extern variables.

[Nico Weber via cfe-commits]

Hi Erich,

this breaks existing code. NaCl does this:

#include 
struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));

(There's a lengthy-ish comment for why in
https://cs.chromium.org/chromium/src/native_client/src/trusted/service_runtime/linux/nacl_bootstrap.c?q=nacl_bootstrap.c&sq=package:chromium&dr&l=424
)

link.h in e.g. the debian jessie sysroot says:
extern struct r_debug _r_debug;

After this change, clang complains:

../../native_client/src/trusted/service_runtime/linux/nacl_bootstrap.c:434:16:
error: section attribute is specified on redeclared variable
[-Werror,-Wsection]
struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));
   ^
../../build/linux/debian_jessie_amd64-sysroot/usr/include/link.h:67:23:
note: previous declaration is here
extern struct r_debug _r_debug;


This code used to work in clang, and continues to work in gcc. So this
patch probably isn't quite the right approach. Ideas?

On Tue, Sep 26, 2017 at 7:42 PM, Erich Keane via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: erichkeane
> Date: Tue Sep 26 16:42:34 2017
> New Revision: 314262
>
> URL: http://llvm.org/viewvc/llvm-project?rev=314262&view=rev
> Log:
> Emit section information for extern variables.
>
> Currently, if _attribute_((section())) is used for extern variables,
> section information is not emitted in generated IR when the variables are
> used.
> This is expected since sections are not generated for external linkage
> objects.
> However NiosII requires this information as it uses special GP-relative
> accesses
> for any objects that use attribute section (.sdata). GCC keeps this
> attribute in
>   middle-end.
>
> This change emits the section information for all targets.
>
> Patch By: Elizabeth Andrews
>
> Differential Revision:https://reviews.llvm.org/D36487
>
>
> Modified:
> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> cfe/trunk/lib/Sema/SemaDecl.cpp
> cfe/trunk/test/Sema/attr-section.c
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/
> DiagnosticSemaKinds.td?rev=314262&r1=314261&r2=314262&view=diff
> 
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Tue Sep 26
> 16:42:34 2017
> @@ -2620,6 +2620,8 @@ def err_attribute_section_invalid_for_ta
>"argument to 'section' attribute is not valid for this target: %0">;
>  def warn_mismatched_section : Warning<
>"section does not match previous declaration">, InGroup;
> +def warn_attribute_section_on_redeclaration : Warning<
> +  "section attribute is specified on redeclared variable">,
> InGroup;
>
>  def err_anonymous_property: Error<
>"anonymous property is not supported">;
>
> Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/
> CodeGenModule.cpp?rev=314262&r1=314261&r2=314262&view=diff
> 
> ==
> --- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Tue Sep 26 16:42:34 2017
> @@ -2432,6 +2432,12 @@ CodeGenModule::GetOrCreateLLVMGlobal(Str
>EmitGlobalVarDefinition(D);
>  }
>
> +// Emit section information for extern variables.
> +if (D->hasExternalStorage()) {
> +  if (const SectionAttr *SA = D->getAttr())
> +GV->setSection(SA->getName());
> +}
> +
>  // Handle XCore specific ABI requirements.
>  if (getTriple().getArch() == llvm::Triple::xcore &&
>  D->getLanguageLinkage() == CLanguageLinkage &&
>
> Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/
> SemaDecl.cpp?rev=314262&r1=314261&r2=314262&view=diff
> 
> ==
> --- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaDecl.cpp Tue Sep 26 16:42:34 2017
> @@ -2607,6 +2607,16 @@ void Sema::mergeDeclAttributes(NamedDecl
>  }
>}
>
> +  // This redeclaration adds a section attribute.
> +  if (New->hasAttr() && !Old->hasAttr()) {
> +if (auto *VD = dyn_cast(New)) {
> +  if (VD->isThisDeclarationADefinition() != VarDecl::Definition) {
> +Diag(New->getLocation(), diag::warn_attribute_section_
> on_redeclaration);
> +Diag(Old->getLocation(), diag::note_previous_declaration);
> +  }
> +}
> +  }
> +
>if (!Old->hasAttrs())
>  return;
>
>
> Modified: cfe/trunk/test/Sema/attr-section.c
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/
> attr-section.c?rev=314262&r1=314261&r2=314262&view=diff
> 
> ==
> --- cfe/trunk/test/Sema/attr

[PATCH] D38430: Enable -pie and --enable-new-dtags by default on Android.

[Evgenii Stepanov via Phabricator via cfe-commits]

eugenis added a comment.

ping


https://reviews.llvm.org/D38430



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

[PATCH] D38101: [Sema] Diagnose tautological comparison with type's min/max values

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added inline comments.



Comment at: lib/Sema/SemaChecking.cpp:8697
+
+  return true;
 }

If the diagnostic we are about to output is disabled, should we still `return 
true;` and suppress potential `-Wsign-compare` warning?


Repository:
  rL LLVM

https://reviews.llvm.org/D38101



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

[PATCH] D38101: [Sema] Diagnose tautological comparison with type's min/max values

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri updated this revision to Diff 117710.
lebedev.ri marked 6 inline comments as done.
lebedev.ri edited the summary of this revision.
lebedev.ri added a comment.

@rsmith thank you for the review!

Address review notes:

1. Merge `CheckTautologicalComparisonWithZero()` and 
`CheckTautologicalComparisonWithMinMax()`
2. Significantly deduplicate the code, hopefully not at the cost of readability.
3. Slightly cleanup/move around/update relevant tests for these three types of 
tautological comparisons.


Repository:
  rL LLVM

https://reviews.llvm.org/D38101

Files:
  docs/ReleaseNotes.rst
  include/clang/Basic/DiagnosticGroups.td
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/Sema/SemaChecking.cpp
  test/Sema/outof-range-constant-compare.c
  test/Sema/tautological-constant-compare.c
  test/Sema/tautological-unsigned-zero-compare.c

Index: test/Sema/tautological-unsigned-zero-compare.c
===
--- test/Sema/tautological-unsigned-zero-compare.c
+++ test/Sema/tautological-unsigned-zero-compare.c
@@ -1,47 +1,340 @@
 // RUN: %clang_cc1 -fsyntax-only -DTEST -verify %s
 // RUN: %clang_cc1 -fsyntax-only -Wno-tautological-unsigned-zero-compare -verify %s
+// RUN: %clang_cc1 -fsyntax-only -DTEST -verify -x c++ %s
+// RUN: %clang_cc1 -fsyntax-only -Wno-tautological-unsigned-zero-compare -verify -x c++ %s
 
-unsigned value(void);
+unsigned uvalue(void);
+signed int svalue(void);
 
 int main() {
-  unsigned un = value();
+  unsigned un = uvalue();
 
 #ifdef TEST
+  if (un == 0)
+  return 0;
+  if (un != 0)
+  return 0;
   if (un < 0) // expected-warning {{comparison of unsigned expression < 0 is always false}}
-return 0;
+  return 0;
+  if (un <= 0)
+  return 0;
+  if (un > 0)
+  return 0;
   if (un >= 0) // expected-warning {{comparison of unsigned expression >= 0 is always true}}
-return 0;
+  return 0;
+
+  if (0 == un)
+  return 0;
+  if (0 != un)
+  return 0;
+  if (0 < un)
+  return 0;
   if (0 <= un) // expected-warning {{comparison of 0 <= unsigned expression is always true}}
-return 0;
+  return 0;
   if (0 > un) // expected-warning {{comparison of 0 > unsigned expression is always false}}
-return 0;
-  if (un < 0U) // expected-warning {{comparison of unsigned expression < 0 is always false}}
-return 0;
-  if (un >= 0U) // expected-warning {{comparison of unsigned expression >= 0 is always true}}
-return 0;
-  if (0U <= un) // expected-warning {{comparison of 0 <= unsigned expression is always true}}
-return 0;
-  if (0U > un) // expected-warning {{comparison of 0 > unsigned expression is always false}}
-return 0;
+  return 0;
+  if (0 >= un)
+  return 0;
+
+  if (un == 0UL)
+  return 0;
+  if (un != 0UL)
+  return 0;
+  if (un < 0UL) // expected-warning {{comparison of unsigned expression < 0 is always false}}
+  return 0;
+  if (un <= 0UL)
+  return 0;
+  if (un > 0UL)
+  return 0;
+  if (un >= 0UL) // expected-warning {{comparison of unsigned expression >= 0 is always true}}
+  return 0;
+
+  if (0UL == un)
+  return 0;
+  if (0UL != un)
+  return 0;
+  if (0UL < un)
+  return 0;
+  if (0UL <= un) // expected-warning {{comparison of 0 <= unsigned expression is always true}}
+  return 0;
+  if (0UL > un) // expected-warning {{comparison of 0 > unsigned expression is always false}}
+  return 0;
+  if (0UL >= un)
+  return 0;
 #else
 // expected-no-diagnostics
+  if (un == 0)
+  return 0;
+  if (un != 0)
+  return 0;
   if (un < 0)
-return 0;
+  return 0;
+  if (un <= 0)
+  return 0;
+  if (un > 0)
+  return 0;
   if (un >= 0)
-return 0;
+  return 0;
+
+  if (0 == un)
+  return 0;
+  if (0 != un)
+  return 0;
+  if (0 < un)
+  return 0;
   if (0 <= un)
-return 0;
+  return 0;
   if (0 > un)
-return 0;
-  if (un < 0U)
-return 0;
-  if (un >= 0U)
-return 0;
-  if (0U <= un)
-return 0;
-  if (0U > un)
-return 0;
+  return 0;
+  if (0 >= un)
+  return 0;
+
+  if (un == 0UL)
+  return 0;
+  if (un != 0UL)
+  return 0;
+  if (un < 0UL)
+  return 0;
+  if (un <= 0UL)
+  return 0;
+  if (un > 0UL)
+  return 0;
+  if (un >= 0UL)
+  return 0;
+
+  if (0UL == un)
+  return 0;
+  if (0UL != un)
+  return 0;
+  if (0UL < un)
+  return 0;
+  if (0UL <= un)
+  return 0;
+  if (0UL > un)
+  return 0;
+  if (0UL >= un)
+  return 0;
 #endif
 
+
+  signed int a = svalue();
+
+#ifdef TEST
+  if (a == 0)
+  return 0;
+  if (a != 0)
+  return 0;
+  if (a < 0)
+  return 0;
+  if (a <= 0)
+  return 0;
+  if (a > 0)
+  return 0;
+  if (a >= 0)
+  return 0;
+
+  if (0 == a)
+  return 0;
+  if (0 != a)
+  return 0;
+  if (0 < a)
+  return 0;
+  if (0 <= a)
+  return 0;
+  if (0 > a)
+  return 0;
+  if (0 >= a)
+  return 0;
+
+  if (a == 0UL)
+  return 0;
+  if (a != 

[PATCH] D38473: Include getting generated struct offsets in CodegenABITypes

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

In https://reviews.llvm.org/D38473#888159, @mppf wrote:

> > You should also indicate *which* record layout (complete object type or 
> > base subobject type) the field number is for. I don't think there's any 
> > guarantee that the same indexes work in both.
>
> I added a comment about this - indicating that inherited fields are not 
> supported by this function. My use case is just for C structs at the moment 
> and I'm not actually sure what we'd need to do for the interface to support 
> building GEPs for inherited fields. I'm sure it would complicate the API. I 
> think we should leave that complexity to another function or a future 
> function (when somebody actually needs it).


I don't think your added comment is related to my request. There are two 
(potentially) different LLVM types for a C++ class type in general, one for the 
case where the object is a base class subobject (excluding vbases, and where 
the tail padding could be reused) and one for where it is a complete object 
(including vbases, and where the tail padding is known to be owned by the 
object). I don't know whether we guarantee that field indexes for one layout 
can be used for the other layout; in particular, I'm concerned that one could 
be a packed struct when the other isn't, and thus the field indexes could 
differ. (I think we generally use the complete object type within IR 
generation, even though that may seem like an odd choice.)

But perhaps we do guarantee the common prefixes are the same (@rjmccall: do 
we?), or we only ever expose one of the two layouts to code outside Clang, and 
in either case this wouldn't matter.

>> (Eg, if we move to an IR representation using something non-GEPable to 
>> represent a source-level class type, we would remove this function as it 
>> would be meaningless.)
> 
> In that event, I'd just want to have a way to build the appropriate field 
> access. (e.g. a function to build an appropriate GEP; or a function that adds 
> appropriate instructions to an IRBuilder and returns a Value* that points to 
> the field, say). I'm open to trying to go directly to such an interface but 
> I'd need significant help in designing/implementing it. (The interface I've 
> proposed here meets my needs and I don't think I know enough about clang to 
> design/implement a better one without help).

Given the generality of kinds of lvalues and rvalues that we support, this 
would mean exposing a significant chunk of the CodeGen interface, I think -- 
probably much more than we would be comfortable exposing.


https://reviews.llvm.org/D38473



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

[PATCH] D38548: Hexagon] Move getHexagonTargetFeatures to Hexagon.cpp (NFC)

[Sumanth Gundapaneni via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL314926: [Hexagon] Move getHexagonTargetFeatures to 
Hexagon.cpp (NFC) (authored by sgundapa).

Changed prior to commit:
  https://reviews.llvm.org/D38548?vs=117686&id=117709#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D38548

Files:
  cfe/trunk/lib/Driver/ToolChains/Clang.cpp
  cfe/trunk/lib/Driver/ToolChains/Hexagon.cpp
  cfe/trunk/lib/Driver/ToolChains/Hexagon.h


Index: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/Clang.cpp
+++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp
@@ -273,21 +273,6 @@
   OutStrings.push_back(Args.MakeArgString(Out));
 }
 
-static void getHexagonTargetFeatures(const ArgList &Args,
- std::vector &Features) {
-  handleTargetFeaturesGroup(Args, Features,
-options::OPT_m_hexagon_Features_Group);
-
-  bool UseLongCalls = false;
-  if (Arg *A = Args.getLastArg(options::OPT_mlong_calls,
-   options::OPT_mno_long_calls)) {
-if (A->getOption().matches(options::OPT_mlong_calls))
-  UseLongCalls = true;
-  }
-
-  Features.push_back(UseLongCalls ? "+long-calls" : "-long-calls");
-}
-
 static void getWebAssemblyTargetFeatures(const ArgList &Args,
  std::vector &Features) {
   handleTargetFeaturesGroup(Args, Features, 
options::OPT_m_wasm_Features_Group);
@@ -349,7 +334,7 @@
 x86::getX86TargetFeatures(D, Triple, Args, Features);
 break;
   case llvm::Triple::hexagon:
-getHexagonTargetFeatures(Args, Features);
+hexagon::getHexagonTargetFeatures(Args, Features);
 break;
   case llvm::Triple::wasm32:
   case llvm::Triple::wasm64:
Index: cfe/trunk/lib/Driver/ToolChains/Hexagon.h
===
--- cfe/trunk/lib/Driver/ToolChains/Hexagon.h
+++ cfe/trunk/lib/Driver/ToolChains/Hexagon.h
@@ -50,6 +50,10 @@
 const llvm::opt::ArgList &TCArgs,
 const char *LinkingOutput) const override;
 };
+
+void getHexagonTargetFeatures(const llvm::opt::ArgList &Args,
+  std::vector &Features);
+
 } // end namespace hexagon.
 } // end namespace tools
 
Index: cfe/trunk/lib/Driver/ToolChains/Hexagon.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/Hexagon.cpp
+++ cfe/trunk/lib/Driver/ToolChains/Hexagon.cpp
@@ -27,6 +27,22 @@
 using namespace clang;
 using namespace llvm::opt;
 
+// Hexagon target features.
+void hexagon::getHexagonTargetFeatures(const ArgList &Args,
+   std::vector &Features) {
+  handleTargetFeaturesGroup(Args, Features,
+options::OPT_m_hexagon_Features_Group);
+
+  bool UseLongCalls = false;
+  if (Arg *A = Args.getLastArg(options::OPT_mlong_calls,
+   options::OPT_mno_long_calls)) {
+if (A->getOption().matches(options::OPT_mlong_calls))
+  UseLongCalls = true;
+  }
+
+  Features.push_back(UseLongCalls ? "+long-calls" : "-long-calls");
+}
+
 // Hexagon tools start.
 void hexagon::Assembler::RenderExtraToolArgs(const JobAction &JA,
  ArgStringList &CmdArgs) const {


Index: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/Clang.cpp
+++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp
@@ -273,21 +273,6 @@
   OutStrings.push_back(Args.MakeArgString(Out));
 }
 
-static void getHexagonTargetFeatures(const ArgList &Args,
- std::vector &Features) {
-  handleTargetFeaturesGroup(Args, Features,
-options::OPT_m_hexagon_Features_Group);
-
-  bool UseLongCalls = false;
-  if (Arg *A = Args.getLastArg(options::OPT_mlong_calls,
-   options::OPT_mno_long_calls)) {
-if (A->getOption().matches(options::OPT_mlong_calls))
-  UseLongCalls = true;
-  }
-
-  Features.push_back(UseLongCalls ? "+long-calls" : "-long-calls");
-}
-
 static void getWebAssemblyTargetFeatures(const ArgList &Args,
  std::vector &Features) {
   handleTargetFeaturesGroup(Args, Features, options::OPT_m_wasm_Features_Group);
@@ -349,7 +334,7 @@
 x86::getX86TargetFeatures(D, Triple, Args, Features);
 break;
   case llvm::Triple::hexagon:
-getHexagonTargetFeatures(Args, Features);
+hexagon::getHexagonTargetFeatures(Args, Features);
 break;
   case llvm::Triple::wasm32:
   case llvm::Triple::wasm64:
Index: cfe/trunk/lib/Driver/ToolChains/Hexagon.h
===
--- cfe/trunk/lib/Driver/ToolChains/Hexagon.h
+++ cfe/trunk/lib/Driver/ToolChains/Hexagon.h
@@ -50,6 +50,10 @@
  

r314926 - [Hexagon] Move getHexagonTargetFeatures to Hexagon.cpp (NFC)

[Sumanth Gundapaneni via cfe-commits]

Author: sgundapa
Date: Wed Oct  4 12:09:29 2017
New Revision: 314926

URL: http://llvm.org/viewvc/llvm-project?rev=314926&view=rev
Log:
[Hexagon] Move getHexagonTargetFeatures to Hexagon.cpp (NFC)

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

Modified:
cfe/trunk/lib/Driver/ToolChains/Clang.cpp
cfe/trunk/lib/Driver/ToolChains/Hexagon.cpp
cfe/trunk/lib/Driver/ToolChains/Hexagon.h

Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=314926&r1=314925&r2=314926&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Clang.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp Wed Oct  4 12:09:29 2017
@@ -273,21 +273,6 @@ static void ParseMRecip(const Driver &D,
   OutStrings.push_back(Args.MakeArgString(Out));
 }
 
-static void getHexagonTargetFeatures(const ArgList &Args,
- std::vector &Features) {
-  handleTargetFeaturesGroup(Args, Features,
-options::OPT_m_hexagon_Features_Group);
-
-  bool UseLongCalls = false;
-  if (Arg *A = Args.getLastArg(options::OPT_mlong_calls,
-   options::OPT_mno_long_calls)) {
-if (A->getOption().matches(options::OPT_mlong_calls))
-  UseLongCalls = true;
-  }
-
-  Features.push_back(UseLongCalls ? "+long-calls" : "-long-calls");
-}
-
 static void getWebAssemblyTargetFeatures(const ArgList &Args,
  std::vector &Features) {
   handleTargetFeaturesGroup(Args, Features, 
options::OPT_m_wasm_Features_Group);
@@ -349,7 +334,7 @@ static void getTargetFeatures(const Tool
 x86::getX86TargetFeatures(D, Triple, Args, Features);
 break;
   case llvm::Triple::hexagon:
-getHexagonTargetFeatures(Args, Features);
+hexagon::getHexagonTargetFeatures(Args, Features);
 break;
   case llvm::Triple::wasm32:
   case llvm::Triple::wasm64:

Modified: cfe/trunk/lib/Driver/ToolChains/Hexagon.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Hexagon.cpp?rev=314926&r1=314925&r2=314926&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Hexagon.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Hexagon.cpp Wed Oct  4 12:09:29 2017
@@ -27,6 +27,22 @@ using namespace clang::driver::toolchain
 using namespace clang;
 using namespace llvm::opt;
 
+// Hexagon target features.
+void hexagon::getHexagonTargetFeatures(const ArgList &Args,
+   std::vector &Features) {
+  handleTargetFeaturesGroup(Args, Features,
+options::OPT_m_hexagon_Features_Group);
+
+  bool UseLongCalls = false;
+  if (Arg *A = Args.getLastArg(options::OPT_mlong_calls,
+   options::OPT_mno_long_calls)) {
+if (A->getOption().matches(options::OPT_mlong_calls))
+  UseLongCalls = true;
+  }
+
+  Features.push_back(UseLongCalls ? "+long-calls" : "-long-calls");
+}
+
 // Hexagon tools start.
 void hexagon::Assembler::RenderExtraToolArgs(const JobAction &JA,
  ArgStringList &CmdArgs) const {

Modified: cfe/trunk/lib/Driver/ToolChains/Hexagon.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Hexagon.h?rev=314926&r1=314925&r2=314926&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Hexagon.h (original)
+++ cfe/trunk/lib/Driver/ToolChains/Hexagon.h Wed Oct  4 12:09:29 2017
@@ -50,6 +50,10 @@ public:
 const llvm::opt::ArgList &TCArgs,
 const char *LinkingOutput) const override;
 };
+
+void getHexagonTargetFeatures(const llvm::opt::ArgList &Args,
+  std::vector &Features);
+
 } // end namespace hexagon.
 } // end namespace tools
 


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

[libclc] r314925 - Add vstore_half helpers for ptx

[Jeroen Ketema via cfe-commits]

Author: jketema
Date: Wed Oct  4 12:07:48 2017
New Revision: 314925

URL: http://llvm.org/viewvc/llvm-project?rev=314925&view=rev
Log:
Add vstore_half helpers for ptx

Reviewed-by: Jan Vesely 

Added:
libclc/trunk/ptx/lib/SOURCES_3.9
libclc/trunk/ptx/lib/SOURCES_4.0
libclc/trunk/ptx/lib/SOURCES_5.0
libclc/trunk/ptx/lib/shared/
libclc/trunk/ptx/lib/shared/vstore_half_helpers.ll

Added: libclc/trunk/ptx/lib/SOURCES_3.9
URL: 
http://llvm.org/viewvc/llvm-project/libclc/trunk/ptx/lib/SOURCES_3.9?rev=314925&view=auto
==
--- libclc/trunk/ptx/lib/SOURCES_3.9 (added)
+++ libclc/trunk/ptx/lib/SOURCES_3.9 Wed Oct  4 12:07:48 2017
@@ -0,0 +1 @@
+shared/vstore_half_helpers.ll

Added: libclc/trunk/ptx/lib/SOURCES_4.0
URL: 
http://llvm.org/viewvc/llvm-project/libclc/trunk/ptx/lib/SOURCES_4.0?rev=314925&view=auto
==
--- libclc/trunk/ptx/lib/SOURCES_4.0 (added)
+++ libclc/trunk/ptx/lib/SOURCES_4.0 Wed Oct  4 12:07:48 2017
@@ -0,0 +1 @@
+shared/vstore_half_helpers.ll

Added: libclc/trunk/ptx/lib/SOURCES_5.0
URL: 
http://llvm.org/viewvc/llvm-project/libclc/trunk/ptx/lib/SOURCES_5.0?rev=314925&view=auto
==
--- libclc/trunk/ptx/lib/SOURCES_5.0 (added)
+++ libclc/trunk/ptx/lib/SOURCES_5.0 Wed Oct  4 12:07:48 2017
@@ -0,0 +1 @@
+shared/vstore_half_helpers.ll

Added: libclc/trunk/ptx/lib/shared/vstore_half_helpers.ll
URL: 
http://llvm.org/viewvc/llvm-project/libclc/trunk/ptx/lib/shared/vstore_half_helpers.ll?rev=314925&view=auto
==
--- libclc/trunk/ptx/lib/shared/vstore_half_helpers.ll (added)
+++ libclc/trunk/ptx/lib/shared/vstore_half_helpers.ll Wed Oct  4 12:07:48 2017
@@ -0,0 +1,35 @@
+define void @__clc_vstore_half_float_helper__private(float %data, half 
addrspace(0)* nocapture %ptr) nounwind alwaysinline {
+  %res = fptrunc float %data to half
+  store half %res, half addrspace(0)* %ptr
+  ret void
+}
+
+define void @__clc_vstore_half_float_helper__global(float %data, half 
addrspace(1)* nocapture %ptr) nounwind alwaysinline {
+  %res = fptrunc float %data to half
+  store half %res, half addrspace(1)* %ptr
+  ret void
+}
+
+define void @__clc_vstore_half_float_helper__local(float %data, half 
addrspace(3)* nocapture %ptr) nounwind alwaysinline {
+  %res = fptrunc float %data to half
+  store half %res, half addrspace(3)* %ptr
+  ret void
+}
+
+define void @__clc_vstore_half_double_helper__private(double %data, half 
addrspace(0)* nocapture %ptr) nounwind alwaysinline {
+  %res = fptrunc double %data to half
+  store half %res, half addrspace(0)* %ptr
+  ret void
+}
+
+define void @__clc_vstore_half_double_helper__global(double %data, half 
addrspace(1)* nocapture %ptr) nounwind alwaysinline {
+  %res = fptrunc double %data to half
+  store half %res, half addrspace(1)* %ptr
+  ret void
+}
+
+define void @__clc_vstore_half_double_helper__local(double %data, half 
addrspace(3)* nocapture %ptr) nounwind alwaysinline {
+  %res = fptrunc double %data to half
+  store half %res, half addrspace(3)* %ptr
+  ret void
+}


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

[PATCH] Ensure std::getline always 0-terminates string.

[Reimar Döffinger via cfe-commits]

If the sentinel failed (e.g. due to having reached
EOF before) or an exception was caught it failed to
do that.
The C++14 standard says:
"In any case, if n is greater than zero, it then stores
a null character (using charT()) into the next
successive location of the array."
Other implementations like libstdc++ do 0-terminate and
not doing so may lead security issues in applications.
---
 include/istream | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/include/istream b/include/istream
index 0b8e05d95..5c73df38f 100644
--- a/include/istream
+++ b/include/istream
@@ -1069,16 +1069,18 @@ basic_istream<_CharT, _Traits>::getline(char_type* __s, 
streamsize __n, char_typ
 this->rdbuf()->sbumpc();
 ++__gc_;
 }
-if (__n > 0)
-*__s = char_type();
 if (__gc_ == 0)
__err |= ios_base::failbit;
 this->setstate(__err);
 }
+if (__n > 0)
+*__s = char_type();
 #ifndef _LIBCPP_NO_EXCEPTIONS
 }
 catch (...)
 {
+if (__n > 0)
+*__s = char_type();
 this->__set_badbit_and_consider_rethrow();
 }
 #endif  // _LIBCPP_NO_EXCEPTIONS
-- 
2.14.2

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

[PATCH] D37822: [OpenCL] Clean up and add missing fields for block struct

[Yaxun Liu via Phabricator via cfe-commits]

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



Comment at: test/CodeGenOpenCL/blocks.cl:30
+  // COMMON: %[[block_captured:.*]] = getelementptr inbounds <{ i32, i32, i8 
addrspace(4)*, i32 }>, <{ i32, i32, i8 addrspace(4)*, i32 }>* %[[block]], i32 
0, i32 3
+  // COMMON: %[[r0:.*]] = load i32, i32* %i
+  // COMMON: store i32 %[[r0]], i32* %[[block_captured]],

Anastasia wrote:
> It might be better to give those r0-r7 some names for readability if possible!
Will fix it when committing.


https://reviews.llvm.org/D37822



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

[PATCH] D35216: [analyzer] Escape symbols when creating std::initializer_list.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

In https://reviews.llvm.org/D35216#886212, @rsmith wrote:

> This is precisely how the rest of the compiler handles 
> `CXXStdInitializerListExpr`


Wow. Cool. I'd see what I can do. Yeah, it seems that this is a great case for 
us to pattern-match the implementations as well (the problems are still there 
for other STL stuff).

Do you think this patch should be blocked? Or i can land that and follow up 
with complete modeling later; it'd be larger.




Comment at: lib/StaticAnalyzer/Core/ExprEngine.cpp:1132
+  for (auto Child : Ex->children()) {
+if (!Child)
+  continue;

dcoughlin wrote:
> Is this 'if' needed?
Not sure, wanted to be defensive. It seems that `CXXStdInitializerList` always 
contains a single child (`InitListExpr`) so it's irrelevant if the list is 
empty, while boxed expressions contain no children when empty, and hanging 
commas are ignored. Replaced with an assertion just in case.


https://reviews.llvm.org/D35216



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

[PATCH] D35216: [analyzer] Escape symbols when creating std::initializer_list.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added inline comments.



Comment at: test/Analysis/objc-for.m:328
   for (id key in array)
 clang_analyzer_eval(0); // expected-warning{{FALSE}}
 }

I guess these old tests should be replaced with `warnIfReached()`.


https://reviews.llvm.org/D35216



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

[PATCH] D35216: [analyzer] Escape symbols when creating std::initializer_list.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ updated this revision to Diff 117699.
NoQ added a comment.
Herald added a subscriber: szepet.

Escape into array and dictionary literals, add relevant tests. Fix the null 
statement check.


https://reviews.llvm.org/D35216

Files:
  lib/StaticAnalyzer/Core/ExprEngine.cpp
  test/Analysis/initializer.cpp
  test/Analysis/objc-boxing.m
  test/Analysis/objc-for.m

Index: test/Analysis/objc-for.m
===
--- test/Analysis/objc-for.m
+++ test/Analysis/objc-for.m
@@ -1,6 +1,7 @@
 // RUN: %clang_analyze_cc1 -analyzer-checker=core,osx.cocoa.Loops,debug.ExprInspection -verify %s
 
 void clang_analyzer_eval(int);
+void clang_analyzer_warnIfReached();
 
 #define nil ((id)0)
 
@@ -20,11 +21,13 @@
 @interface NSArray : NSObject 
 - (NSUInteger)count;
 - (NSEnumerator *)objectEnumerator;
++ (NSArray *)arrayWithObjects:(const id [])objects count:(NSUInteger)count;
 @end
 
 @interface NSDictionary : NSObject 
 - (NSUInteger)count;
 - (id)objectForKey:(id)key;
++ (id)dictionaryWithObjects:(const id [])objects forKeys:(const id /*  */ [])keys count:(NSUInteger)count;
 @end
 
 @interface NSDictionary (SomeCategory)
@@ -324,3 +327,19 @@
   for (id key in array)
 clang_analyzer_eval(0); // expected-warning{{FALSE}}
 }
+
+NSArray *globalArray;
+NSDictionary *globalDictionary;
+void boxedArrayEscape(NSMutableArray *array) {
+  if ([array count])
+return;
+  globalArray = @[array];
+  for (id key in array)
+clang_analyzer_warnIfReached(); // expected-warning{{REACHABLE}}
+
+  if ([array count])
+return;
+  globalDictionary = @{ @"array" : array };
+  for (id key in array)
+clang_analyzer_warnIfReached(); // expected-warning{{REACHABLE}}
+}
Index: test/Analysis/objc-boxing.m
===
--- test/Analysis/objc-boxing.m
+++ test/Analysis/objc-boxing.m
@@ -5,6 +5,16 @@
 typedef signed char BOOL;
 typedef long NSInteger;
 typedef unsigned long NSUInteger;
+
+@protocol NSObject
+@end
+@interface NSObject  {}
+@end
+@protocol NSCopying
+@end
+@protocol NSCoding
+@end
+
 @interface NSString @end
 @interface NSString (NSStringExtensionMethods)
 + (id)stringWithUTF8String:(const char *)nullTerminatedCString;
@@ -28,7 +38,15 @@
 + (NSNumber *)numberWithUnsignedInteger:(NSUInteger)value ;
 @end
 
+@interface NSValue : NSObject 
+- (void)getValue:(void *)value;
++ (NSValue *)valueWithBytes:(const void *)value
+   objCType:(const char *)type;
+@end
 
+typedef typeof(sizeof(int)) size_t;
+extern void *malloc(size_t);
+extern void free(void *);
 extern char *strdup(const char *str);
 
 id constant_string() {
@@ -39,6 +57,23 @@
 return @(strdup("boxed dynamic string")); // expected-warning{{Potential memory leak}}
 }
 
+typedef struct __attribute__((objc_boxable)) {
+  const char *str;
+} BoxableStruct;
+
+id leak_within_boxed_struct() {
+  BoxableStruct bs;
+  bs.str = strdup("dynamic string"); // The duped string shall be owned by val.
+  NSValue *val = @(bs); // no-warning
+  return val;
+}
+
+id leak_of_boxed_struct() {
+  BoxableStruct *bs = malloc(sizeof(BoxableStruct)); // The pointer stored in bs isn't owned by val.
+  NSValue *val = @(*bs); // expected-warning{{Potential leak of memory pointed to by 'bs'}}
+  return val;
+}
+
 id const_char_pointer(int *x) {
   if (x)
 return @(3);
Index: test/Analysis/initializer.cpp
===
--- test/Analysis/initializer.cpp
+++ test/Analysis/initializer.cpp
@@ -1,7 +1,9 @@
-// RUN: %clang_analyze_cc1 -analyzer-checker=core,unix.Malloc,debug.ExprInspection -analyzer-config c++-inlining=constructors -std=c++11 -verify %s
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,unix.Malloc,cplusplus.NewDeleteLeaks,debug.ExprInspection -analyzer-config c++-inlining=constructors -std=c++11 -verify %s
 
 void clang_analyzer_eval(bool);
 
+#include "Inputs/system-header-simulator-cxx.h"
+
 class A {
   int x;
 public:
@@ -204,3 +206,17 @@
const char(&f)[2];
 };
 }
+
+namespace CXX_initializer_lists {
+struct C {
+  C(std::initializer_list list);
+};
+void foo() {
+  C empty{}; // no-crash
+
+  // Do not warn that 'x' leaks. It might have been deleted by
+  // the destructor of 'c'.
+  int *x = new int;
+  C c{x}; // no-warning
+}
+}
Index: lib/StaticAnalyzer/Core/ExprEngine.cpp
===
--- lib/StaticAnalyzer/Core/ExprEngine.cpp
+++ lib/StaticAnalyzer/Core/ExprEngine.cpp
@@ -827,6 +827,21 @@
   }
 }
 
+namespace {
+class CollectReachableSymbolsCallback final : public SymbolVisitor {
+  InvalidatedSymbols Symbols;
+
+public:
+  explicit CollectReachableSymbolsCallback(ProgramStateRef State) {}
+  const InvalidatedSymbols &getSymbols() const { return Symbols; }
+
+  bool VisitSymbol(SymbolRef Sym) override {
+Symbols.insert(Sym);
+return true;
+  }
+};
+} // end anonymous namespace
+
 void ExprEngine::Visit(const Stmt *S, Explode

[PATCH] D35216: [analyzer] Escape symbols when creating std::initializer_list.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ marked 3 inline comments as done.
NoQ added a comment.

In https://reviews.llvm.org/D35216#886212, @rsmith wrote:

> This is precisely how the rest of the compiler handles 
> `CXXStdInitializerListExpr`


Wow. Cool. I'd see what I can do. Yeah, it seems that this is a great case for 
us to pattern-match the implementations as well (the problems are still there 
for other STL stuff).

Do you think this patch should be blocked in favor of complete modeling?
Or i can land that and follow up with complete modeling later; it'd be a 
larger, but not much to discuss indeed.
Or i can try always "inlining" initializer_list constructor and methods during 
analysis, if all methods are available in the header in all implementations.


https://reviews.llvm.org/D35216



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

[PATCH] D38358: [analyzer] Fix autodetection of getSVal()'s type argument.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added inline comments.



Comment at: lib/StaticAnalyzer/Core/RegionStore.cpp:1404
+  // When trying to dereference a void pointer, read the first byte.
+  T = Ctx.CharTy;
+}

dcoughlin wrote:
> NoQ wrote:
> > dcoughlin wrote:
> > > Nit: It seems a bit odd to read the first byte here since (unless I'm 
> > > misunderstanding) this would never be triggered by actual C semantics, 
> > > only by a checker. Did you consider just returning UnknownVal() in this 
> > > case?
> > `UnknownVal` seems to be quite similar to assertion failure: in both cases 
> > we'd have to force the checker to specify `CharTy` explicitly. But 
> > assertions are better because the author of the checker would instantly 
> > know that he needs to specify the type, instead of never noticing the 
> > problem, or spending a lot of time in the debugger trying to understand why 
> > he gets an `UnknownVal`.
>  I think having an assertion with a helpful message indicating how the 
> checker author could fix the problem would be great! But you're not 
> triggering an assertion failure here since you're changing T to be CharTy. 
> Instead, you're papering over the problem by making up a fake value that 
> doesn't correspond to the program semantics. If you're going to paper over 
> the the problem and return a value, I think it is far preferable to use 
> UnknownVal. This would signal "we don't know what is going here" rather than 
> just making up a value that is likely wrong.
> If you're going to paper over the the problem and return a value, I think it 
> is far preferable to use UnknownVal.

If we return an UnknownVal, the user would never figure out what's wrong by 
looking at the value, i.e. what limitation of the analyzer he's stepping on (in 
fact he isn't, he's just using the APIs incorrectly, while we know very well 
what's going on). Additionally, returning the first byte makes API simpler in 
cases the type actually doesn't matter (which is why it's not provided), unlike 
returning UnknownVal. This makes me think that returning UnknownVal is worse 
than both returning first byte and stepping on assertion. However, yeah, if we 
try to model an API that manipulates objects of well-defined types through void 
pointers, returning bytes might cause issues when the user doesn't realize he 
needs to specify his types, especially when RegionStore would often ignore the 
type and only take the offset, unless it has no bindings and needs to return 
region value or derived symbol (so the user may easily fail to test this case).

I guess i'd follow up with a patch to remove the defensive behavior and bring 
back the assertion and modify checkers to provide types when necessary, and 
later see if it's worth it to remove auto-detection completely.


Repository:
  rL LLVM

https://reviews.llvm.org/D38358



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

[PATCH] D38548: Hexagon] Move getHexagonTargetFeatures to Hexagon.cpp (NFC)

[Krzysztof Parzyszek via Phabricator via cfe-commits]

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

Thanks!


Repository:
  rL LLVM

https://reviews.llvm.org/D38548



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

[PATCH] D38048: [clangd] Add textDocument/signatureHelp

[Francisco Lopes da Silva via Phabricator via cfe-commits]

francisco.lopes added a comment.

In https://reviews.llvm.org/D38048#887960, @ilya-biryukov wrote:

> Another case where this might be bad is overloaded functions. I may choose 
> one overload in completion, but `signatureHelp` will initially point into a 
> different one.


Hi,  I'd just like to comment on this aspect to inform how  this is done is 
different ways for Vim.

Original YouCompleteMe, for example, still doesn't support parameter hints, so 
it just offers function prototypes in the completion menu, for functions 
foo(int, char) and
foo(void *, int), the two prototypes gets listed and not mattering what 
function the user selects the text to be inserted will always just be the same 
function name, foo.

I didn't find this useful because it cluttered the menu with many overloads 
that the user may not be in fact looking for, it may be targeting for another 
function but it gets
like ten long overloads of another function that's ranked first according to 
what the user typed.

I also didn't find it useful, in Vim, to show full prototypes in  the pop up 
menu because for C++ they tend to be rather long.

So I changed YouCompleteMe this way:

- Just show unique function names in the popup menu (they're tagged as 
functions).
- When the user selects a given function, the overloads are shown in a separate 
preview window instead, which for me is more sane for showing long information.
- When the user goes about filling the call site with arguments, the overloads 
in the preview window are dynamically updated showing the current argument the 
user is at, for the remaining compatible overloads.
- The overloads get reduced while the user fill arguments as well as there's 
type resolution of generic functions along the way.

These pictures show how this happens:

- https://s3.amazonaws.com/f.cl.ly/items/1e2F0A123h331c1G0L0R/SadBart.gif
- https://imgur.com/a/OqFaI

They just don't happen illustrate the reduction of multiple overloads because I 
didn't put multiple ones at the time.

This is just to illustrate some different completion approach that tries to be 
inline with libclang offerings.


https://reviews.llvm.org/D38048



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

[PATCH] D38358: [analyzer] Fix autodetection of getSVal()'s type argument.

[Devin Coughlin via Phabricator via cfe-commits]

dcoughlin added inline comments.



Comment at: lib/StaticAnalyzer/Core/RegionStore.cpp:1404
+  // When trying to dereference a void pointer, read the first byte.
+  T = Ctx.CharTy;
+}

NoQ wrote:
> dcoughlin wrote:
> > Nit: It seems a bit odd to read the first byte here since (unless I'm 
> > misunderstanding) this would never be triggered by actual C semantics, only 
> > by a checker. Did you consider just returning UnknownVal() in this case?
> `UnknownVal` seems to be quite similar to assertion failure: in both cases 
> we'd have to force the checker to specify `CharTy` explicitly. But assertions 
> are better because the author of the checker would instantly know that he 
> needs to specify the type, instead of never noticing the problem, or spending 
> a lot of time in the debugger trying to understand why he gets an 
> `UnknownVal`.
 I think having an assertion with a helpful message indicating how the checker 
author could fix the problem would be great! But you're not triggering an 
assertion failure here since you're changing T to be CharTy. Instead, you're 
papering over the problem by making up a fake value that doesn't correspond to 
the program semantics. If you're going to paper over the the problem and return 
a value, I think it is far preferable to use UnknownVal. This would signal "we 
don't know what is going here" rather than just making up a value that is 
likely wrong.


Repository:
  rL LLVM

https://reviews.llvm.org/D38358



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

[PATCH] D35082: [OpenCL] Add LangAS::opencl_private to represent private address space in AST

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added inline comments.



Comment at: lib/Sema/SemaType.cpp:6872
+  ImpAddr = LangAS::opencl_private;
+else if (IsStatic)
+  ImpAddr = LangAS::opencl_global;

yaxunl wrote:
> Anastasia wrote:
> > I think we can't have this case for CL1.2 see s6.8. But I think it could 
> > happen for `extern` though.
> Right. I will remove setting implicit addr space for static var for CL1.2.
> 
> For extern var, for CL2.0 I will set implicit addr space to global.
> 
> However, for CL1.2 since only constant addr space is supported for file-scope 
> var, I can only set the implicit addr space of an extern var to be constant. 
> However I feel this may cause more confusion than convenience, therefore I 
> will not set implicit addr space for extern var for CL1.2. If user does not 
> use constant addr space with extern var explicitly, they will see diagnostics 
> that extern var must have constant addr space. This is also the current 
> behavior before my change.
Makes sense!



Comment at: test/SemaOpenCL/storageclass.cl:63
+  static float l_implicit_static_var = 0;  // expected-error 
{{variables in function scope cannot be declared static}}
+  static constant float l_constant_static_var = 0; // expected-error 
{{variables in function scope cannot be declared static}}
+  static global float l_global_static_var = 0; // expected-error 
{{variables in function scope cannot be declared static}}

Does it make sense to put different address spaces here since this code is 
rejected earlier anyway?


https://reviews.llvm.org/D35082



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

[PATCH] D38549: [clang-tidy] Link targets and Asm parsers

[Zachary Turner via Phabricator via cfe-commits]

zturner created this revision.
Herald added subscribers: xazax.hun, mgorny.

Currently clang-tidy fails on any file that includes inline assembly.  This is 
not a great out-of-the-box experience since many system headers include inline 
assembly, particularly on Windows.

I checked through the various other clang tools and they all have similar logic 
to link in a minimal amount of backend stuff to get a target registry, so this 
patch does the same for clang-tidy


https://reviews.llvm.org/D38549

Files:
  clang-tools-extra/clang-tidy/CMakeLists.txt
  clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp


Index: clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
===
--- clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
+++ clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
@@ -18,6 +18,7 @@
 #include "../ClangTidy.h"
 #include "clang/Tooling/CommonOptionsParser.h"
 #include "llvm/Support/Process.h"
+#include "llvm/Support/TargetSelect.h"
 
 using namespace clang::ast_matchers;
 using namespace clang::driver;
@@ -401,6 +402,10 @@
 return 0;
   }
 
+  llvm::InitializeAllTargetInfos();
+  llvm::InitializeAllTargetMCs();
+  llvm::InitializeAllAsmParsers();
+
   ProfileData Profile;
 
   ClangTidyContext Context(std::move(OwningOptionsProvider));
Index: clang-tools-extra/clang-tidy/CMakeLists.txt
===
--- clang-tools-extra/clang-tidy/CMakeLists.txt
+++ clang-tools-extra/clang-tidy/CMakeLists.txt
@@ -1,5 +1,7 @@
 set(LLVM_LINK_COMPONENTS
   Support
+  AllTargetsAsmParsers
+  AllTargetsInfos
   )
 
 add_clang_library(clangTidy


Index: clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
===
--- clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
+++ clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
@@ -18,6 +18,7 @@
 #include "../ClangTidy.h"
 #include "clang/Tooling/CommonOptionsParser.h"
 #include "llvm/Support/Process.h"
+#include "llvm/Support/TargetSelect.h"
 
 using namespace clang::ast_matchers;
 using namespace clang::driver;
@@ -401,6 +402,10 @@
 return 0;
   }
 
+  llvm::InitializeAllTargetInfos();
+  llvm::InitializeAllTargetMCs();
+  llvm::InitializeAllAsmParsers();
+
   ProfileData Profile;
 
   ClangTidyContext Context(std::move(OwningOptionsProvider));
Index: clang-tools-extra/clang-tidy/CMakeLists.txt
===
--- clang-tools-extra/clang-tidy/CMakeLists.txt
+++ clang-tools-extra/clang-tidy/CMakeLists.txt
@@ -1,5 +1,7 @@
 set(LLVM_LINK_COMPONENTS
   Support
+  AllTargetsAsmParsers
+  AllTargetsInfos
   )
 
 add_clang_library(clangTidy
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] r314913 - [clang-tidy] Emit note for variable declaration that are later deleted

[Jonas Toth via cfe-commits]

Author: jonastoth
Date: Wed Oct  4 09:49:20 2017
New Revision: 314913

URL: http://llvm.org/viewvc/llvm-project?rev=314913&view=rev
Log:
[clang-tidy] Emit note for variable declaration that are later deleted

This patch introduces a note for variable declaration that are later deleted.
Adds FIXME notes for possible automatic type-rewriting positions as well.

Reviewed by aaron.ballman
Differential: https://reviews.llvm.org/D38411

Modified:
clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/OwningMemoryCheck.cpp
clang-tools-extra/trunk/test/clang-tidy/cppcoreguidelines-owning-memory.cpp

Modified: 
clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/OwningMemoryCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/OwningMemoryCheck.cpp?rev=314913&r1=314912&r2=314913&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/OwningMemoryCheck.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/OwningMemoryCheck.cpp 
Wed Oct  4 09:49:20 2017
@@ -156,6 +156,13 @@ bool OwningMemoryCheck::handleDeletion(c
  "not marked 'gsl::owner<>'; consider using a "
  "smart pointer instead")
 << DeletedVariable->getSourceRange();
+
+// FIXME: The declaration of the variable that was deleted can be
+// rewritten.
+const ValueDecl *Decl = DeletedVariable->getDecl();
+diag(Decl->getLocStart(), "variable declared here", DiagnosticIDs::Note)
+<< Decl->getSourceRange();
+
 return true;
   }
   return false;
@@ -244,7 +251,9 @@ bool OwningMemoryCheck::handleAssignment
  "initializing non-owner %0 with a newly created 'gsl::owner<>'")
 << BadOwnerInitialization->getType()
 << BadOwnerInitialization->getSourceRange();
-// FIXME: FixitHint to rewrite the type if possible.
+
+// FIXME: FixitHint to rewrite the type of the initialized variable
+// as 'gsl::owner'
 
 // If the type of the variable was deduced, the wrapping owner typedef is
 // eliminated, therefore the check emits a special note for that case.
@@ -277,14 +286,15 @@ bool OwningMemoryCheck::handleReturnValu
 
   // Function return values, that should be owners but aren't.
   if (BadReturnType) {
-// The returned value is of type owner, but not the declared return type.
+// The returned value is a resource or variable that was not annotated with
+// owner<> and the function return type is not owner<>.
 diag(BadReturnType->getLocStart(),
  "returning a newly created resource of "
  "type %0 or 'gsl::owner<>' from a "
  "function whose return type is not 'gsl::owner<>'")
 << Function->getReturnType() << BadReturnType->getSourceRange();
-// The returned value is a resource that was not annotated with owner<> and
-// the function return type is not owner<>.
+
+// FIXME: Rewrite the return type as 'gsl::owner'
 return true;
   }
   return false;

Modified: 
clang-tools-extra/trunk/test/clang-tidy/cppcoreguidelines-owning-memory.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/cppcoreguidelines-owning-memory.cpp?rev=314913&r1=314912&r2=314913&view=diff
==
--- clang-tools-extra/trunk/test/clang-tidy/cppcoreguidelines-owning-memory.cpp 
(original)
+++ clang-tools-extra/trunk/test/clang-tidy/cppcoreguidelines-owning-memory.cpp 
Wed Oct  4 09:49:20 2017
@@ -142,11 +142,13 @@ void test_deletion() {
   // CHECK-MESSAGES: [[@LINE-1]]:3: warning: initializing non-owner 'int *' 
with a newly created 'gsl::owner<>'
   delete unowned_int1; // BAD, since no owner
   // CHECK-MESSAGES: [[@LINE-1]]:3: warning: deleting a pointer through a type 
that is not marked 'gsl::owner<>'; consider using a smart pointer instead
+  // CHECK-MESSAGES: [[@LINE-4]]:3: note: variable declared here
 
   int *unowned_int2 = new int[42]; // BAD, since new creates and owner
   // CHECK-MESSAGES: [[@LINE-1]]:3: warning: initializing non-owner 'int *' 
with a newly created 'gsl::owner<>'
   delete[] unowned_int2; // BAD since no owner
   // CHECK-MESSAGES: [[@LINE-1]]:3: warning: deleting a pointer through a type 
that is not marked 'gsl::owner<>'; consider using a smart pointer instead
+  // CHECK-MESSAGES: [[@LINE-4]]:3: note: variable declared here
 
   delete new int(42);   // Technically ok, but stupid
   delete[] new int[42]; // Technically ok, but stupid


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

[PATCH] D37822: [OpenCL] Clean up and add missing fields for block struct

[Anastasia Stulova via Phabricator via cfe-commits]

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

LGTM! Thanks!




Comment at: test/CodeGenOpenCL/blocks.cl:30
+  // COMMON: %[[block_captured:.*]] = getelementptr inbounds <{ i32, i32, i8 
addrspace(4)*, i32 }>, <{ i32, i32, i8 addrspace(4)*, i32 }>* %[[block]], i32 
0, i32 3
+  // COMMON: %[[r0:.*]] = load i32, i32* %i
+  // COMMON: store i32 %[[r0]], i32* %[[block_captured]],

It might be better to give those r0-r7 some names for readability if possible!


https://reviews.llvm.org/D37822



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

[PATCH] D38358: [analyzer] Fix autodetection of getSVal()'s type argument.

[Phabricator via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL314910: [analyzer] Fix autodetection of binding types. 
(authored by dergachev).

Changed prior to commit:
  https://reviews.llvm.org/D38358?vs=117360&id=117681#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D38358

Files:
  cfe/trunk/lib/StaticAnalyzer/Core/RegionStore.cpp
  cfe/trunk/test/Analysis/ctor.mm
  cfe/trunk/test/Analysis/exercise-ps.c
  cfe/trunk/test/Analysis/gtest.cpp


Index: cfe/trunk/lib/StaticAnalyzer/Core/RegionStore.cpp
===
--- cfe/trunk/lib/StaticAnalyzer/Core/RegionStore.cpp
+++ cfe/trunk/lib/StaticAnalyzer/Core/RegionStore.cpp
@@ -1393,16 +1393,19 @@
 return UnknownVal();
   }
 
-  if (isa(MR) ||
-  isa(MR) ||
-  isa(MR)) {
+  if (!isa(MR)) {
 if (T.isNull()) {
   if (const TypedRegion *TR = dyn_cast(MR))
-T = TR->getLocationType();
-  else {
-const SymbolicRegion *SR = cast(MR);
-T = SR->getSymbol()->getType();
-  }
+T = TR->getLocationType()->getPointeeType();
+  else if (const SymbolicRegion *SR = dyn_cast(MR))
+T = SR->getSymbol()->getType()->getPointeeType();
+  else if (isa(MR))
+T = Ctx.VoidTy;
+}
+assert(!T.isNull() && "Unable to auto-detect binding type!");
+if (T->isVoidType()) {
+  // When trying to dereference a void pointer, read the first byte.
+  T = Ctx.CharTy;
 }
 MR = GetElementZeroRegion(cast(MR), T);
   }
Index: cfe/trunk/test/Analysis/ctor.mm
===
--- cfe/trunk/test/Analysis/ctor.mm
+++ cfe/trunk/test/Analysis/ctor.mm
@@ -199,7 +199,7 @@
 Inner p;
   };
 
-  void testPOD() {
+  void testPOD(const POD &pp) {
 POD p;
 p.x = 1;
 POD p2 = p; // no-warning
@@ -210,6 +210,15 @@
 // Use rvalues as well.
 clang_analyzer_eval(POD(p3).x == 1); // expected-warning{{TRUE}}
 
+// Copy from symbolic references correctly.
+POD p4 = pp;
+// Make sure that p4.x contains a symbol after copy.
+if (p4.x > 0)
+  clang_analyzer_eval(p4.x > 0); // expected-warning{{TRUE}}
+// FIXME: Element region gets in the way, so these aren't the same symbols
+// as they should be.
+clang_analyzer_eval(pp.x == p4.x); // expected-warning{{UNKNOWN}}
+
 PODWrapper w;
 w.p.y = 1;
 PODWrapper w2 = w; // no-warning
Index: cfe/trunk/test/Analysis/exercise-ps.c
===
--- cfe/trunk/test/Analysis/exercise-ps.c
+++ cfe/trunk/test/Analysis/exercise-ps.c
@@ -21,3 +21,11 @@
   memcpy((&x[1]), (buf), 1); // expected-warning{{implicitly declaring library 
function 'memcpy' with type 'void *(void *, const void *}} \
   // expected-note{{include the header  or explicitly provide a 
declaration for 'memcpy'}}
 }
+
+// AllocaRegion is untyped. Void pointer isn't of much help either. Before
+// realizing that the value is undefined, we need to somehow figure out
+// what type of value do we expect.
+void f3(void *dest) {
+  void *src = __builtin_alloca(5);
+  memcpy(dest, src, 1); // expected-warning{{2nd function call argument is a 
pointer to uninitialized value}}
+}
Index: cfe/trunk/test/Analysis/gtest.cpp
===
--- cfe/trunk/test/Analysis/gtest.cpp
+++ cfe/trunk/test/Analysis/gtest.cpp
@@ -151,3 +151,17 @@
   ASSERT_TRUE(false);
   clang_analyzer_warnIfReached(); // no-warning
 }
+
+void testAssertSymbolicPtr(const bool *b) {
+  ASSERT_TRUE(*b); // no-crash
+
+  // FIXME: Our solver doesn't handle this well yet.
+  clang_analyzer_eval(*b); // expected-warning{{UNKNOWN}}
+}
+
+void testAssertSymbolicRef(const bool &b) {
+  ASSERT_TRUE(b); // no-crash
+
+  // FIXME: Our solver doesn't handle this well yet.
+  clang_analyzer_eval(b); // expected-warning{{UNKNOWN}}
+}


Index: cfe/trunk/lib/StaticAnalyzer/Core/RegionStore.cpp
===
--- cfe/trunk/lib/StaticAnalyzer/Core/RegionStore.cpp
+++ cfe/trunk/lib/StaticAnalyzer/Core/RegionStore.cpp
@@ -1393,16 +1393,19 @@
 return UnknownVal();
   }
 
-  if (isa(MR) ||
-  isa(MR) ||
-  isa(MR)) {
+  if (!isa(MR)) {
 if (T.isNull()) {
   if (const TypedRegion *TR = dyn_cast(MR))
-T = TR->getLocationType();
-  else {
-const SymbolicRegion *SR = cast(MR);
-T = SR->getSymbol()->getType();
-  }
+T = TR->getLocationType()->getPointeeType();
+  else if (const SymbolicRegion *SR = dyn_cast(MR))
+T = SR->getSymbol()->getType()->getPointeeType();
+  else if (isa(MR))
+T = Ctx.VoidTy;
+}
+assert(!T.isNull() && "Unable to auto-detect binding type!");
+if (T->isVoidType()) {
+  // When trying to dereference a void pointer, read the first byte.
+  T = Ctx.CharTy;
 }
 MR = GetElementZeroRegion(cast(MR), T

r314910 - [analyzer] Fix autodetection of binding types.

[Artem Dergachev via cfe-commits]

Author: dergachev
Date: Wed Oct  4 08:59:40 2017
New Revision: 314910

URL: http://llvm.org/viewvc/llvm-project?rev=314910&view=rev
Log:
[analyzer] Fix autodetection of binding types.

In ProgramState::getSVal(Location, Type) API which dereferences a pointer value,
when the optional Type parameter is not supplied and the Location is not typed,
type should have been guessed on a best-effort basis by inspecting the Location
more deeply. However, this never worked; the auto-detected type was instead
a pointer type to the correct type.

Fixed the issue and added various test cases to demonstrate which parts of the
analyzer were affected (uninitialized pointer argument checker, C++ trivial copy
modeling, Google test API modeling checker).

Additionally, autodetected void types are automatically replaced with char,
in order to simplify checker APIs. Which means that if the location is a void
pointer, getSVal() would read the first byte through this pointer
and return its symbolic value.

Fixes pr34305.

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

Modified:
cfe/trunk/lib/StaticAnalyzer/Core/RegionStore.cpp
cfe/trunk/test/Analysis/ctor.mm
cfe/trunk/test/Analysis/exercise-ps.c
cfe/trunk/test/Analysis/gtest.cpp

Modified: cfe/trunk/lib/StaticAnalyzer/Core/RegionStore.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/RegionStore.cpp?rev=314910&r1=314909&r2=314910&view=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Core/RegionStore.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Core/RegionStore.cpp Wed Oct  4 08:59:40 2017
@@ -1393,16 +1393,19 @@ SVal RegionStoreManager::getBinding(Regi
 return UnknownVal();
   }
 
-  if (isa(MR) ||
-  isa(MR) ||
-  isa(MR)) {
+  if (!isa(MR)) {
 if (T.isNull()) {
   if (const TypedRegion *TR = dyn_cast(MR))
-T = TR->getLocationType();
-  else {
-const SymbolicRegion *SR = cast(MR);
-T = SR->getSymbol()->getType();
-  }
+T = TR->getLocationType()->getPointeeType();
+  else if (const SymbolicRegion *SR = dyn_cast(MR))
+T = SR->getSymbol()->getType()->getPointeeType();
+  else if (isa(MR))
+T = Ctx.VoidTy;
+}
+assert(!T.isNull() && "Unable to auto-detect binding type!");
+if (T->isVoidType()) {
+  // When trying to dereference a void pointer, read the first byte.
+  T = Ctx.CharTy;
 }
 MR = GetElementZeroRegion(cast(MR), T);
   }

Modified: cfe/trunk/test/Analysis/ctor.mm
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/ctor.mm?rev=314910&r1=314909&r2=314910&view=diff
==
--- cfe/trunk/test/Analysis/ctor.mm (original)
+++ cfe/trunk/test/Analysis/ctor.mm Wed Oct  4 08:59:40 2017
@@ -199,7 +199,7 @@ namespace PODUninitialized {
 Inner p;
   };
 
-  void testPOD() {
+  void testPOD(const POD &pp) {
 POD p;
 p.x = 1;
 POD p2 = p; // no-warning
@@ -210,6 +210,15 @@ namespace PODUninitialized {
 // Use rvalues as well.
 clang_analyzer_eval(POD(p3).x == 1); // expected-warning{{TRUE}}
 
+// Copy from symbolic references correctly.
+POD p4 = pp;
+// Make sure that p4.x contains a symbol after copy.
+if (p4.x > 0)
+  clang_analyzer_eval(p4.x > 0); // expected-warning{{TRUE}}
+// FIXME: Element region gets in the way, so these aren't the same symbols
+// as they should be.
+clang_analyzer_eval(pp.x == p4.x); // expected-warning{{UNKNOWN}}
+
 PODWrapper w;
 w.p.y = 1;
 PODWrapper w2 = w; // no-warning

Modified: cfe/trunk/test/Analysis/exercise-ps.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/exercise-ps.c?rev=314910&r1=314909&r2=314910&view=diff
==
--- cfe/trunk/test/Analysis/exercise-ps.c (original)
+++ cfe/trunk/test/Analysis/exercise-ps.c Wed Oct  4 08:59:40 2017
@@ -21,3 +21,11 @@ static void f2(void *buf) {
   memcpy((&x[1]), (buf), 1); // expected-warning{{implicitly declaring library 
function 'memcpy' with type 'void *(void *, const void *}} \
   // expected-note{{include the header  or explicitly provide a 
declaration for 'memcpy'}}
 }
+
+// AllocaRegion is untyped. Void pointer isn't of much help either. Before
+// realizing that the value is undefined, we need to somehow figure out
+// what type of value do we expect.
+void f3(void *dest) {
+  void *src = __builtin_alloca(5);
+  memcpy(dest, src, 1); // expected-warning{{2nd function call argument is a 
pointer to uninitialized value}}
+}

Modified: cfe/trunk/test/Analysis/gtest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/gtest.cpp?rev=314910&r1=314909&r2=314910&view=diff
==
--- cfe/trunk/test/Analysis/gtest.cpp (original)
+++ cfe/trunk/test/Ana

[PATCH] D38358: [analyzer] Fix autodetection of getSVal()'s type argument.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

Whoops forgot to submit inline comments.




Comment at: lib/StaticAnalyzer/Core/RegionStore.cpp:1404
+  // When trying to dereference a void pointer, read the first byte.
+  T = Ctx.CharTy;
+}

dcoughlin wrote:
> Nit: It seems a bit odd to read the first byte here since (unless I'm 
> misunderstanding) this would never be triggered by actual C semantics, only 
> by a checker. Did you consider just returning UnknownVal() in this case?
`UnknownVal` seems to be quite similar to assertion failure: in both cases we'd 
have to force the checker to specify `CharTy` explicitly. But assertions are 
better because the author of the checker would instantly know that he needs to 
specify the type, instead of never noticing the problem, or spending a lot of 
time in the debugger trying to understand why he gets an `UnknownVal`.



Comment at: lib/StaticAnalyzer/Core/RegionStore.cpp:1408
 }
+assert(!T.isNull() && "Unable to auto-detect binding type!");
+assert(!T->isVoidType() && "Attempted to retrieve a void value!");

dcoughlin wrote:
> I think you missed handling the AllocaRegion case from the old version in 
> your new version. This means the assert will fire on the following when 
> core.alpha is enabled:
> ```
> void foo(void *dest) {
>   void *src = __builtin_alloca(5);
>   memcpy(dest, src, 1);
> }
> ```
Nice one!

Always been that way though. In the old code, if `AllocaRegion` is supplied and 
no type is explicitly specified, `cast(MR)` would fail. Also 
`ElementRegion` is created in both old and new code if the type was specified.


https://reviews.llvm.org/D38358



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

[PATCH] D38517: Enabling new pass manager in LTO (and thinLTO) link step via -fexperimental-new-pass-manager option

[Teresa Johnson via Phabricator via cfe-commits]

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

LGTM
thanks!


Repository:
  rL LLVM

https://reviews.llvm.org/D38517



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

[PATCH] D38517: Enabling new pass manager in LTO (and thinLTO) link step via -fexperimental-new-pass-manager option

[Graham Yiu via Phabricator via cfe-commits]

gyiu updated this revision to Diff 117677.
gyiu added a comment.

Add new testcase to make sure plugin-opt is passed to gold linker to enable new 
pass manager.


Repository:
  rL LLVM

https://reviews.llvm.org/D38517

Files:
  lib/Driver/ToolChains/CommonArgs.cpp
  test/Driver/gold-lto-new-pass-man.c
  tools/gold/gold-plugin.cpp


Index: test/Driver/gold-lto-new-pass-man.c
===
--- /dev/null
+++ test/Driver/gold-lto-new-pass-man.c
@@ -0,0 +1,7 @@
+// RUN: touch %t.o
+//
+// RUN: %clang -target ppc64le-unknown-linux -### %t.o -flto 2>&1 \
+// RUN: -Wl,-plugin-opt=foo -O3 \
+// RUN: -fexperimental-new-pass-manager \
+// RUN: | FileCheck %s
+// CHECK: "-plugin-opt=new-pass-manager"
Index: lib/Driver/ToolChains/CommonArgs.cpp
===
--- lib/Driver/ToolChains/CommonArgs.cpp
+++ lib/Driver/ToolChains/CommonArgs.cpp
@@ -454,6 +454,14 @@
   CmdArgs.push_back(
   Args.MakeArgString(Twine("-plugin-opt=sample-profile=") + FName));
   }
+
+  // Need this flag to turn on new pass manager via Gold plugin.
+  if (Args.hasFlag(options::OPT_fexperimental_new_pass_manager,
+   options::OPT_fno_experimental_new_pass_manager,
+   /* Default */ false)) {
+CmdArgs.push_back("-plugin-opt=new-pass-manager");
+  }
+
 }
 
 void tools::addArchSpecificRPath(const ToolChain &TC, const ArgList &Args,
Index: tools/gold/gold-plugin.cpp
===
--- tools/gold/gold-plugin.cpp
+++ tools/gold/gold-plugin.cpp
@@ -183,6 +183,8 @@
   static std::vector extra;
   // Sample profile file path
   static std::string sample_profile;
+  // New pass manager
+  static bool new_pass_manager = false;
 
   static void process_plugin_option(const char *opt_)
   {
@@ -242,6 +244,8 @@
   DisableVerify = true;
 } else if (opt.startswith("sample-profile=")) {
   sample_profile= opt.substr(strlen("sample-profile="));
+} else if (opt == "new-pass-manager") {
+  new_pass_manager = true;
 } else {
   // Save this option to pass to the code generator.
   // ParseCommandLineOptions() expects argv[0] to be program name. Lazily
@@ -810,6 +814,9 @@
   if (!options::sample_profile.empty())
 Conf.SampleProfile = options::sample_profile;
 
+  // Use new pass manager if set in driver
+  Conf.UseNewPM = options::new_pass_manager;
+
   return llvm::make_unique(std::move(Conf), Backend,
 options::ParallelCodeGenParallelismLevel);
 }


Index: test/Driver/gold-lto-new-pass-man.c
===
--- /dev/null
+++ test/Driver/gold-lto-new-pass-man.c
@@ -0,0 +1,7 @@
+// RUN: touch %t.o
+//
+// RUN: %clang -target ppc64le-unknown-linux -### %t.o -flto 2>&1 \
+// RUN: -Wl,-plugin-opt=foo -O3 \
+// RUN: -fexperimental-new-pass-manager \
+// RUN: | FileCheck %s
+// CHECK: "-plugin-opt=new-pass-manager"
Index: lib/Driver/ToolChains/CommonArgs.cpp
===
--- lib/Driver/ToolChains/CommonArgs.cpp
+++ lib/Driver/ToolChains/CommonArgs.cpp
@@ -454,6 +454,14 @@
   CmdArgs.push_back(
   Args.MakeArgString(Twine("-plugin-opt=sample-profile=") + FName));
   }
+
+  // Need this flag to turn on new pass manager via Gold plugin.
+  if (Args.hasFlag(options::OPT_fexperimental_new_pass_manager,
+   options::OPT_fno_experimental_new_pass_manager,
+   /* Default */ false)) {
+CmdArgs.push_back("-plugin-opt=new-pass-manager");
+  }
+
 }
 
 void tools::addArchSpecificRPath(const ToolChain &TC, const ArgList &Args,
Index: tools/gold/gold-plugin.cpp
===
--- tools/gold/gold-plugin.cpp
+++ tools/gold/gold-plugin.cpp
@@ -183,6 +183,8 @@
   static std::vector extra;
   // Sample profile file path
   static std::string sample_profile;
+  // New pass manager
+  static bool new_pass_manager = false;
 
   static void process_plugin_option(const char *opt_)
   {
@@ -242,6 +244,8 @@
   DisableVerify = true;
 } else if (opt.startswith("sample-profile=")) {
   sample_profile= opt.substr(strlen("sample-profile="));
+} else if (opt == "new-pass-manager") {
+  new_pass_manager = true;
 } else {
   // Save this option to pass to the code generator.
   // ParseCommandLineOptions() expects argv[0] to be program name. Lazily
@@ -810,6 +814,9 @@
   if (!options::sample_profile.empty())
 Conf.SampleProfile = options::sample_profile;
 
+  // Use new pass manager if set in driver
+  Conf.UseNewPM = options::new_pass_manager;
+
   return llvm::make_unique(std::move(Conf), Backend,
 options::ParallelCodeGenParallelismLevel);
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org

r314905 - [OpenMP] Initial implementation of teams distribute code generation

[Carlo Bertolli via cfe-commits]

Author: cbertol
Date: Wed Oct  4 07:12:09 2017
New Revision: 314905

URL: http://llvm.org/viewvc/llvm-project?rev=314905&view=rev
Log:
[OpenMP] Initial implementation of teams distribute code generation

https://reviews.llvm.org/D38371

This patch implements codegen for the combined 'teams distribute" OpenMP pragma 
and adds regression tests for all its clauses.



Added:
cfe/trunk/test/OpenMP/teams_distribute_codegen.cpp
cfe/trunk/test/OpenMP/teams_distribute_collapse_codegen.cpp
cfe/trunk/test/OpenMP/teams_distribute_dist_schedule_codegen.cpp
cfe/trunk/test/OpenMP/teams_distribute_firstprivate_codegen.cpp
cfe/trunk/test/OpenMP/teams_distribute_lastprivate_codegen.cpp
cfe/trunk/test/OpenMP/teams_distribute_private_codegen.cpp
cfe/trunk/test/OpenMP/teams_distribute_reduction_codegen.cpp
Modified:
cfe/trunk/lib/Basic/OpenMPKinds.cpp
cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
cfe/trunk/lib/Sema/SemaOpenMP.cpp

Modified: cfe/trunk/lib/Basic/OpenMPKinds.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/OpenMPKinds.cpp?rev=314905&r1=314904&r2=314905&view=diff
==
--- cfe/trunk/lib/Basic/OpenMPKinds.cpp (original)
+++ cfe/trunk/lib/Basic/OpenMPKinds.cpp Wed Oct  4 07:12:09 2017
@@ -890,6 +890,9 @@ void clang::getOpenMPCaptureRegions(
 CaptureRegions.push_back(OMPD_target);
 CaptureRegions.push_back(OMPD_teams);
 break;
+  case OMPD_teams_distribute:
+CaptureRegions.push_back(OMPD_teams);
+break;
   case OMPD_teams:
   case OMPD_simd:
   case OMPD_for:
@@ -913,7 +916,6 @@ void clang::getOpenMPCaptureRegions(
   case OMPD_taskloop_simd:
   case OMPD_distribute_parallel_for_simd:
   case OMPD_distribute_simd:
-  case OMPD_teams_distribute:
   case OMPD_teams_distribute_simd:
   case OMPD_teams_distribute_parallel_for_simd:
   case OMPD_teams_distribute_parallel_for:

Modified: cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp?rev=314905&r1=314904&r2=314905&view=diff
==
--- cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp Wed Oct  4 07:12:09 2017
@@ -2041,18 +2041,6 @@ void CodeGenFunction::EmitOMPTargetSimdD
   });
 }
 
-void CodeGenFunction::EmitOMPTeamsDistributeDirective(
-const OMPTeamsDistributeDirective &S) {
-  OMPLexicalScope Scope(*this, S, /*AsInlined=*/true);
-  CGM.getOpenMPRuntime().emitInlinedDirective(
-  *this, OMPD_teams_distribute,
-  [&S](CodeGenFunction &CGF, PrePostActionTy &) {
-OMPLoopScope PreInitScope(CGF, S);
-CGF.EmitStmt(
-cast(S.getAssociatedStmt())->getCapturedStmt());
-  });
-}
-
 void CodeGenFunction::EmitOMPTeamsDistributeSimdDirective(
 const OMPTeamsDistributeSimdDirective &S) {
   OMPLexicalScope Scope(*this, S, /*AsInlined=*/true);
@@ -3847,6 +3835,28 @@ void CodeGenFunction::EmitOMPTargetTeams
   emitCommonOMPTargetDirective(*this, S, CodeGen);
 }
 
+void CodeGenFunction::EmitOMPTeamsDistributeDirective(
+const OMPTeamsDistributeDirective &S) {
+
+  auto &&CodeGenDistribute = [&S](CodeGenFunction &CGF, PrePostActionTy &) {
+CGF.EmitOMPDistributeLoop(S, emitOMPLoopBodyWithStopPoint, S.getInc());
+  };
+
+  // Emit teams region as a standalone region.
+  auto &&CodeGen = [&S, &CodeGenDistribute](CodeGenFunction &CGF,
+PrePostActionTy &) {
+OMPPrivateScope PrivateScope(CGF);
+CGF.EmitOMPReductionClauseInit(S, PrivateScope);
+(void)PrivateScope.Privatize();
+CGF.CGM.getOpenMPRuntime().emitInlinedDirective(CGF, OMPD_distribute,
+CodeGenDistribute);
+CGF.EmitOMPReductionClauseFinal(S, /*ReductionKind=*/OMPD_teams);
+  };
+  emitCommonOMPTeamsDirective(*this, S, OMPD_teams, CodeGen);
+  emitPostUpdateForReductionClause(*this, S,
+   [](CodeGenFunction &) { return nullptr; });
+}
+
 void CodeGenFunction::EmitOMPCancellationPointDirective(
 const OMPCancellationPointDirective &S) {
   CGM.getOpenMPRuntime().emitCancellationPointCall(*this, S.getLocStart(),

Modified: cfe/trunk/lib/Sema/SemaOpenMP.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaOpenMP.cpp?rev=314905&r1=314904&r2=314905&view=diff
==
--- cfe/trunk/lib/Sema/SemaOpenMP.cpp (original)
+++ cfe/trunk/lib/Sema/SemaOpenMP.cpp Wed Oct  4 07:12:09 2017
@@ -2043,7 +2043,8 @@ void Sema::ActOnOpenMPRegionStart(OpenMP
   case OMPD_parallel_for:
   case OMPD_parallel_for_simd:
   case OMPD_parallel_sections:
-  case OMPD_teams: {
+  case OMPD_teams:
+  case OMPD_teams_distribute: {
 QualType KmpInt32Ty = Context.getIntTypeForBitwidth(32, 1);
 QualType KmpInt32PtrTy =
 Context.getPointerT

[PATCH] D38371: [OpenMP] Initial implementation of teams distribute code generation

[Carlo Bertolli via Phabricator via cfe-commits]

carlo.bertolli closed this revision.
carlo.bertolli added a comment.

Committed revision 314905.


Repository:
  rL LLVM

https://reviews.llvm.org/D38371



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

[PATCH] D38473: Include getting generated struct offsets in CodegenABITypes

[Michael Ferguson via Phabricator via cfe-commits]

mppf added a comment.

Thanks for the feedback!

> "Given a non-bitfield struct field, return its index within the elements of 
> the struct's converted type."

Done

> I think "getLLVMFieldNumber" is probably the right name for this.

Great suggestion, done.

> This interface does not seem to be sufficient to support bit-fields.

Right, supporting bit fields would make it more complex & isn't something I 
need right now anyway. With rjmccal's suggested comment, it's clear that bit 
fields won't work with this function. (Given a non-bitfield struct field...)

> You should also indicate *which* record layout (complete object type or base 
> subobject type) the field number is for. I don't think there's any guarantee 
> that the same indexes work in both.

I added a comment about this - indicating that inherited fields are not 
supported by this function. My use case is just for C structs at the moment and 
I'm not actually sure what we'd need to do for the interface to support 
building GEPs for inherited fields. I'm sure it would complicate the API. I 
think we should leave that complexity to another function or a future function 
(when somebody actually needs it).

> (Eg, if we move to an IR representation using something non-GEPable to 
> represent a source-level class type, we would remove this function as it 
> would be meaningless.)

In that event, I'd just want to have a way to build the appropriate field 
access. (e.g. a function to build an appropriate GEP; or a function that adds 
appropriate instructions to an IRBuilder and returns a Value* that points to 
the field, say). I'm open to trying to go directly to such an interface but I'd 
need significant help in designing/implementing it. (The interface I've 
proposed here meets my needs and I don't think I know enough about clang to 
design/implement a better one without help).


https://reviews.llvm.org/D38473



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

r314904 - [test] Pass in fixed triple for openmp-offload.c

[Jonas Hahnfeld via cfe-commits]

Author: hahnfeld
Date: Wed Oct  4 06:54:09 2017
New Revision: 314904

URL: http://llvm.org/viewvc/llvm-project?rev=314904&view=rev
Log:
[test] Pass in fixed triple for openmp-offload.c

This should fix the test on other architectures.

Related to: https://reviews.llvm.org/D38372

Modified:
cfe/trunk/test/Driver/openmp-offload.c

Modified: cfe/trunk/test/Driver/openmp-offload.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/openmp-offload.c?rev=314904&r1=314903&r2=314904&view=diff
==
--- cfe/trunk/test/Driver/openmp-offload.c (original)
+++ cfe/trunk/test/Driver/openmp-offload.c Wed Oct  4 06:54:09 2017
@@ -64,7 +64,7 @@
 /// ##
 
 /// Check -march=pwr7 is NOT passed to nvptx64-nvidia-cuda.
-// RUN:%clang -### -no-canonical-prefixes -fopenmp=libomp 
-fopenmp-targets=nvptx64-nvidia-cuda -march=pwr7 %s 2>&1 \
+// RUN:%clang -### -no-canonical-prefixes -fopenmp=libomp 
-fopenmp-targets=nvptx64-nvidia-cuda -target powerpc64le-ibm-linux-gnu 
-march=pwr7 %s 2>&1 \
 // RUN:| FileCheck -check-prefix=CHK-FOPENMP-MARCH-TO-GPU %s
 
 // CHK-FOPENMP-MARCH-TO-GPU-NOT: clang{{.*}} "-target-cpu" "pwr7" 
{{.*}}"-fopenmp-is-device"
@@ -72,7 +72,7 @@
 /// ###
 
 /// Check -march=pwr7 is NOT passed to x86_64-unknown-linux-gnu.
-// RUN:%clang -### -no-canonical-prefixes -fopenmp=libomp 
-fopenmp-targets=x86_64-unknown-linux-gnu -march=pwr7 %s 2>&1 \
+// RUN:%clang -### -no-canonical-prefixes -fopenmp=libomp 
-fopenmp-targets=x86_64-unknown-linux-gnu -target powerpc64le-ibm-linux-gnu 
-march=pwr7 %s 2>&1 \
 // RUN:| FileCheck -check-prefix=CHK-FOPENMP-MARCH-TO-X86 %s
 
 // CHK-FOPENMP-MARCH-TO-X86-NOT: clang{{.*}} "-target-cpu" "pwr7" 
{{.*}}"-fopenmp-is-device"


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

[PATCH] D38473: Include getting generated struct offsets in CodegenABITypes

[Michael Ferguson via Phabricator via cfe-commits]

mppf updated this revision to Diff 117665.
mppf added a comment.

- Improve comments, rename to getLLVMFieldNumber


https://reviews.llvm.org/D38473

Files:
  include/clang/CodeGen/CodeGenABITypes.h
  lib/CodeGen/CodeGenABITypes.cpp
  unittests/CodeGen/CMakeLists.txt
  unittests/CodeGen/CodeGenExternalTest.cpp

Index: unittests/CodeGen/CodeGenExternalTest.cpp
===
--- /dev/null
+++ unittests/CodeGen/CodeGenExternalTest.cpp
@@ -0,0 +1,302 @@
+//===- unittests/CodeGen/CodeGenExternalTest.cpp - test external CodeGen -===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "clang/AST/ASTConsumer.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/AST/GlobalDecl.h"
+#include "clang/AST/RecursiveASTVisitor.h"
+#include "clang/Basic/TargetInfo.h"
+#include "clang/CodeGen/CodeGenABITypes.h"
+#include "clang/CodeGen/ModuleBuilder.h"
+#include "clang/Frontend/CompilerInstance.h"
+#include "clang/Lex/Preprocessor.h"
+#include "clang/Parse/ParseAST.h"
+#include "clang/Sema/Sema.h"
+#include "llvm/ADT/Triple.h"
+#include "llvm/IR/Instructions.h"
+#include "llvm/IR/LLVMContext.h"
+#include "llvm/Support/Debug.h"
+#include "llvm/Support/Host.h"
+#include "llvm/Support/MemoryBuffer.h"
+#include "gtest/gtest.h"
+
+using namespace llvm;
+using namespace clang;
+
+namespace {
+
+// Mocks up a language using Clang code generation as a library and
+// tests some basic functionality there.
+//   - CodeGen->GetAddrOfGlobal
+//   - CodeGen::convertTypeForMemory
+//   - CodeGen::getLLVMFieldNumber
+
+static const bool DebugThisTest = false;
+
+// forward declarations
+struct MyASTConsumer;
+static void test_codegen_fns(MyASTConsumer *my);
+static bool test_codegen_fns_ran;
+
+// This forwards the calls to the Clang CodeGenerator
+// so that we can test CodeGen functions while it is open.
+// It accumulates toplevel decls in HandleTopLevelDecl and
+// calls test_codegen_fns() in HandleTranslationUnit
+// before forwarding that function to the CodeGenerator.
+
+struct MyASTConsumer : public ASTConsumer {
+  std::unique_ptr Builder;
+  std::vector toplevel_decls;
+
+  MyASTConsumer(std::unique_ptr Builder_in)
+: ASTConsumer(), Builder(std::move(Builder_in))
+  {
+  }
+
+  ~MyASTConsumer() { }
+
+  void Initialize(ASTContext &Context) override;
+  void HandleCXXStaticMemberVarInstantiation(VarDecl *VD) override;
+  bool HandleTopLevelDecl(DeclGroupRef D) override;
+  void HandleInlineFunctionDefinition(FunctionDecl *D) override;
+  void HandleInterestingDecl(DeclGroupRef D) override;
+  void HandleTranslationUnit(ASTContext &Ctx) override;
+  void HandleTagDeclDefinition(TagDecl *D) override;
+  void HandleTagDeclRequiredDefinition(const TagDecl *D) override;
+  void HandleCXXImplicitFunctionInstantiation(FunctionDecl *D) override;
+  void HandleTopLevelDeclInObjCContainer(DeclGroupRef D) override;
+  void HandleImplicitImportDecl(ImportDecl *D) override;
+  void CompleteTentativeDefinition(VarDecl *D) override;
+  void AssignInheritanceModel(CXXRecordDecl *RD) override;
+  void HandleVTable(CXXRecordDecl *RD) override;
+  ASTMutationListener *GetASTMutationListener() override;
+  ASTDeserializationListener *GetASTDeserializationListener() override;
+  void PrintStats() override;
+  bool shouldSkipFunctionBody(Decl *D) override;
+};
+
+void MyASTConsumer::Initialize(ASTContext &Context) {
+  Builder->Initialize(Context);
+}
+
+bool MyASTConsumer::HandleTopLevelDecl(DeclGroupRef DG) {
+
+  for (DeclGroupRef::iterator I = DG.begin(), E = DG.end(); I != E; ++I) {
+toplevel_decls.push_back(*I);
+  }
+
+  return Builder->HandleTopLevelDecl(DG);
+}
+
+void MyASTConsumer::HandleInlineFunctionDefinition(FunctionDecl *D) {
+  Builder->HandleInlineFunctionDefinition(D);
+}
+
+void MyASTConsumer::HandleInterestingDecl(DeclGroupRef D) {
+  Builder->HandleInterestingDecl(D);
+}
+
+void MyASTConsumer::HandleTranslationUnit(ASTContext &Context) {
+  test_codegen_fns(this);
+  // HandleTranslationUnit can close the module
+  Builder->HandleTranslationUnit(Context);
+}
+
+void MyASTConsumer::HandleTagDeclDefinition(TagDecl *D) {
+  Builder->HandleTagDeclDefinition(D);
+}
+
+void MyASTConsumer::HandleTagDeclRequiredDefinition(const TagDecl *D) {
+  Builder->HandleTagDeclRequiredDefinition(D);
+}
+
+void MyASTConsumer::HandleCXXImplicitFunctionInstantiation(FunctionDecl *D) {
+  Builder->HandleCXXImplicitFunctionInstantiation(D);
+}
+
+void MyASTConsumer::HandleTopLevelDeclInObjCContainer(DeclGroupRef D) {
+  Builder->HandleTopLevelDeclInObjCContainer(D);
+}
+
+void MyASTConsumer::HandleImplicitImportDecl(ImportDecl *D) {
+  Builder->HandleImplicitImportDecl(D);
+}
+
+void MyASTConsumer::CompleteTentativeDefinition(VarDecl *D) {
+  Builder->CompleteTentati

r314902 - [OpenMP] Fix passing of -m arguments correctly

[Jonas Hahnfeld via cfe-commits]

Author: hahnfeld
Date: Wed Oct  4 06:32:59 2017
New Revision: 314902

URL: http://llvm.org/viewvc/llvm-project?rev=314902&view=rev
Log:
[OpenMP] Fix passing of -m arguments correctly

The recent fix in D38258 was wrong: getAuxTriple() only returns
non-null values for the CUDA toolchain. That is why the now added
test for PPC and X86 failed.

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

Modified:
cfe/trunk/include/clang/Driver/ToolChain.h
cfe/trunk/lib/Driver/Compilation.cpp
cfe/trunk/lib/Driver/ToolChain.cpp
cfe/trunk/test/Driver/openmp-offload.c

Modified: cfe/trunk/include/clang/Driver/ToolChain.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/ToolChain.h?rev=314902&r1=314901&r2=314902&view=diff
==
--- cfe/trunk/include/clang/Driver/ToolChain.h (original)
+++ cfe/trunk/include/clang/Driver/ToolChain.h Wed Oct  4 06:32:59 2017
@@ -245,14 +245,9 @@ public:
   /// TranslateOpenMPTargetArgs - Create a new derived argument list for
   /// that contains the OpenMP target specific flags passed via
   /// -Xopenmp-target -opt=val OR -Xopenmp-target= -opt=val
-  /// Translation occurs only when the \p DeviceOffloadKind is specified.
-  ///
-  /// \param DeviceOffloadKind - The device offload kind used for the
-  /// translation.
   virtual llvm::opt::DerivedArgList *TranslateOpenMPTargetArgs(
-  const llvm::opt::DerivedArgList &Args,
-  Action::OffloadKind DeviceOffloadKind,
-  SmallVector &AllocatedArgs) const;
+  const llvm::opt::DerivedArgList &Args, bool SameTripleAsHost,
+  SmallVectorImpl &AllocatedArgs) const;
 
   /// Choose a tool to use to handle the action \p JA.
   ///

Modified: cfe/trunk/lib/Driver/Compilation.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Compilation.cpp?rev=314902&r1=314901&r2=314902&view=diff
==
--- cfe/trunk/lib/Driver/Compilation.cpp (original)
+++ cfe/trunk/lib/Driver/Compilation.cpp Wed Oct  4 06:32:59 2017
@@ -52,9 +52,15 @@ Compilation::getArgsForToolChain(const T
   DerivedArgList *&Entry = TCArgs[{TC, BoundArch, DeviceOffloadKind}];
   if (!Entry) {
 SmallVector AllocatedArgs;
+DerivedArgList *OpenMPArgs = nullptr;
 // Translate OpenMP toolchain arguments provided via the -Xopenmp-target 
flags.
-DerivedArgList *OpenMPArgs = TC->TranslateOpenMPTargetArgs(
-*TranslatedArgs, DeviceOffloadKind, AllocatedArgs);
+if (DeviceOffloadKind == Action::OFK_OpenMP) {
+  const ToolChain *HostTC = getSingleOffloadToolChain();
+  bool SameTripleAsHost = (TC->getTriple() == HostTC->getTriple());
+  OpenMPArgs = TC->TranslateOpenMPTargetArgs(
+  *TranslatedArgs, SameTripleAsHost, AllocatedArgs);
+}
+
 if (!OpenMPArgs) {
   Entry = TC->TranslateArgs(*TranslatedArgs, BoundArch, DeviceOffloadKind);
   if (!Entry)

Modified: cfe/trunk/lib/Driver/ToolChain.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChain.cpp?rev=314902&r1=314901&r2=314902&view=diff
==
--- cfe/trunk/lib/Driver/ToolChain.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChain.cpp Wed Oct  4 06:32:59 2017
@@ -801,74 +801,68 @@ ToolChain::computeMSVCVersion(const Driv
 }
 
 llvm::opt::DerivedArgList *ToolChain::TranslateOpenMPTargetArgs(
-const llvm::opt::DerivedArgList &Args,
-Action::OffloadKind DeviceOffloadKind,
-SmallVector &AllocatedArgs) const {
-  if (DeviceOffloadKind == Action::OFK_OpenMP) {
-DerivedArgList *DAL = new DerivedArgList(Args.getBaseArgs());
-const OptTable &Opts = getDriver().getOpts();
-bool Modified = false;
-
-// Handle -Xopenmp-target flags
-for (Arg *A : Args) {
-  // Exclude flags which may only apply to the host toolchain.
-  // Do not exclude flags when the host triple (AuxTriple)
-  // matches the current toolchain triple. If it is not present
-  // at all, target and host share a toolchain.
-  if (A->getOption().matches(options::OPT_m_Group)) {
-if (!getAuxTriple() || getAuxTriple()->str() == getTriple().str())
-  DAL->append(A);
-else
-  Modified = true;
-continue;
-  }
-
-  unsigned Index;
-  unsigned Prev;
-  bool XOpenMPTargetNoTriple = A->getOption().matches(
-  options::OPT_Xopenmp_target);
-
-  if (A->getOption().matches(options::OPT_Xopenmp_target_EQ)) {
-// Passing device args: -Xopenmp-target= -opt=val.
-if (A->getValue(0) == getTripleString())
-  Index = Args.getBaseArgs().MakeIndex(A->getValue(1));
-else
-  continue;
-  } else if (XOpenMPTargetNoTriple) {
-// Passing device args: -Xopenmp-target -opt=val.
-Index = Args.getBaseArgs().MakeIndex(A->getValue(0));
-  } else {
+const llvm::opt::DerivedArgList 

[PATCH] D38372: [OpenMP] Fix passing of -m arguments correctly

[Jonas Hahnfeld via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL314902: [OpenMP] Fix passing of -m arguments correctly 
(authored by Hahnfeld).

Changed prior to commit:
  https://reviews.llvm.org/D38372?vs=117023&id=117664#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D38372

Files:
  cfe/trunk/include/clang/Driver/ToolChain.h
  cfe/trunk/lib/Driver/Compilation.cpp
  cfe/trunk/lib/Driver/ToolChain.cpp
  cfe/trunk/test/Driver/openmp-offload.c

Index: cfe/trunk/lib/Driver/ToolChain.cpp
===
--- cfe/trunk/lib/Driver/ToolChain.cpp
+++ cfe/trunk/lib/Driver/ToolChain.cpp
@@ -801,74 +801,68 @@
 }
 
 llvm::opt::DerivedArgList *ToolChain::TranslateOpenMPTargetArgs(
-const llvm::opt::DerivedArgList &Args,
-Action::OffloadKind DeviceOffloadKind,
-SmallVector &AllocatedArgs) const {
-  if (DeviceOffloadKind == Action::OFK_OpenMP) {
-DerivedArgList *DAL = new DerivedArgList(Args.getBaseArgs());
-const OptTable &Opts = getDriver().getOpts();
-bool Modified = false;
-
-// Handle -Xopenmp-target flags
-for (Arg *A : Args) {
-  // Exclude flags which may only apply to the host toolchain.
-  // Do not exclude flags when the host triple (AuxTriple)
-  // matches the current toolchain triple. If it is not present
-  // at all, target and host share a toolchain.
-  if (A->getOption().matches(options::OPT_m_Group)) {
-if (!getAuxTriple() || getAuxTriple()->str() == getTriple().str())
-  DAL->append(A);
-else
-  Modified = true;
-continue;
-  }
-
-  unsigned Index;
-  unsigned Prev;
-  bool XOpenMPTargetNoTriple = A->getOption().matches(
-  options::OPT_Xopenmp_target);
-
-  if (A->getOption().matches(options::OPT_Xopenmp_target_EQ)) {
-// Passing device args: -Xopenmp-target= -opt=val.
-if (A->getValue(0) == getTripleString())
-  Index = Args.getBaseArgs().MakeIndex(A->getValue(1));
-else
-  continue;
-  } else if (XOpenMPTargetNoTriple) {
-// Passing device args: -Xopenmp-target -opt=val.
-Index = Args.getBaseArgs().MakeIndex(A->getValue(0));
-  } else {
+const llvm::opt::DerivedArgList &Args, bool SameTripleAsHost,
+SmallVectorImpl &AllocatedArgs) const {
+  DerivedArgList *DAL = new DerivedArgList(Args.getBaseArgs());
+  const OptTable &Opts = getDriver().getOpts();
+  bool Modified = false;
+
+  // Handle -Xopenmp-target flags
+  for (Arg *A : Args) {
+// Exclude flags which may only apply to the host toolchain.
+// Do not exclude flags when the host triple (AuxTriple)
+// matches the current toolchain triple. If it is not present
+// at all, target and host share a toolchain.
+if (A->getOption().matches(options::OPT_m_Group)) {
+  if (SameTripleAsHost)
 DAL->append(A);
-continue;
-  }
+  else
+Modified = true;
+  continue;
+}
 
-  // Parse the argument to -Xopenmp-target.
-  Prev = Index;
-  std::unique_ptr XOpenMPTargetArg(Opts.ParseOneArg(Args, Index));
-  if (!XOpenMPTargetArg || Index > Prev + 1) {
-getDriver().Diag(diag::err_drv_invalid_Xopenmp_target_with_args)
-<< A->getAsString(Args);
-continue;
-  }
-  if (XOpenMPTargetNoTriple && XOpenMPTargetArg &&
-  Args.getAllArgValues(
-  options::OPT_fopenmp_targets_EQ).size() != 1) {
-getDriver().Diag(diag::err_drv_Xopenmp_target_missing_triple);
+unsigned Index;
+unsigned Prev;
+bool XOpenMPTargetNoTriple =
+A->getOption().matches(options::OPT_Xopenmp_target);
+
+if (A->getOption().matches(options::OPT_Xopenmp_target_EQ)) {
+  // Passing device args: -Xopenmp-target= -opt=val.
+  if (A->getValue(0) == getTripleString())
+Index = Args.getBaseArgs().MakeIndex(A->getValue(1));
+  else
 continue;
-  }
-  XOpenMPTargetArg->setBaseArg(A);
-  A = XOpenMPTargetArg.release();
-  AllocatedArgs.push_back(A);
+} else if (XOpenMPTargetNoTriple) {
+  // Passing device args: -Xopenmp-target -opt=val.
+  Index = Args.getBaseArgs().MakeIndex(A->getValue(0));
+} else {
   DAL->append(A);
-  Modified = true;
+  continue;
 }
 
-if (Modified) {
-  return DAL;
-} else {
-  delete DAL;
+// Parse the argument to -Xopenmp-target.
+Prev = Index;
+std::unique_ptr XOpenMPTargetArg(Opts.ParseOneArg(Args, Index));
+if (!XOpenMPTargetArg || Index > Prev + 1) {
+  getDriver().Diag(diag::err_drv_invalid_Xopenmp_target_with_args)
+  << A->getAsString(Args);
+  continue;
 }
+if (XOpenMPTargetNoTriple && XOpenMPTargetArg &&
+Args.getAllArgValues(options::OPT_fopenmp_targets_EQ).size() != 1) {
+  getDriver().Diag(diag::err_drv_Xopenmp_target_missing_triple);
+  continue;
+}
+XOpenMPTargetArg->setBaseArg(

[PATCH] D38284: [clang-tidy] Fix google-readability-namespace-comments handling of C++17 nested namespaces

[Aaron Ballman via Phabricator via cfe-commits]

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

Aside from a small nit, this LGTM, thanks!




Comment at: clang-tidy/readability/NamespaceCommentCheck.cpp:102-105
+  auto TextRange =
+  Lexer::getAsCharRange(SourceRange(NestedNamespaceBegin, 
LBracketLocation),
+Sources, getLangOpts());
+  auto NestedNamespaceName =

These should not use `auto` since the type is not explicitly spelled out in the 
initialization.


https://reviews.llvm.org/D38284



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

[PATCH] D38538: Avoid printing some redundant name qualifiers in completion

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added inline comments.



Comment at: test/CodeCompletion/enum-switch-case-qualified.cpp:25
 // RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:23:8 %s -o - | 
FileCheck -check-prefix=CHECK-CC1 %s
-// CHECK-CC1: Blue : [#M::N::C::Color#]N::C::Blue
-// CHECK-CC1-NEXT: Green : [#M::N::C::Color#]N::C::Green
-// CHECK-CC1-NEXT: Indigo : [#M::N::C::Color#]N::C::Indigo
-// CHECK-CC1-NEXT: Orange : [#M::N::C::Color#]N::C::Orange
-// CHECK-CC1-NEXT: Red : [#M::N::C::Color#]N::C::Red
-// CHECK-CC1-NEXT: Violet : [#M::N::C::Color#]N::C::Violet
-// CHECK-CC1: Yellow : [#M::N::C::Color#]N::C::Yellow
+// CHECK-CC1: Blue : [#Color#]N::C::Blue
+// CHECK-CC1-NEXT: Green : [#Color#]N::C::Green

This may be a somewhat unwanted part of this change.
Enum type is now written without qualifier here. I would argue that's ok, since 
the actual enum values are always properly qualified (they have to be, as they 
are actually inserted by completion) and those qualifiers provide all the 
necessary context for the user.


https://reviews.llvm.org/D38538



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

[PATCH] D38479: Make -mgeneral-regs-only more like GCC's

[Renato Golin via Phabricator via cfe-commits]

rengolin added a comment.

In https://reviews.llvm.org/D38479#886587, @efriedma wrote:

> 1. We don't correctly ignore inline asm clobbers for registers which aren't 
> allocatable (https://bugs.llvm.org/show_bug.cgi?id=30792)


This looks like a different (but related) issue. That should be fixed in the 
back-end, regardless of the new error messages.

> 2. We don't diagnose calls which need vector registers according to the C 
> calling convention.

The function that checks for it returns true for vectors 
(`lib/Sema/SemaExprCXX.cpp:7487`). However, the tests cover floating point, but 
they don't cover vector calls (arm_neon.h).

> 3. We don't diagnose operations which have to be lowered to libcalls which 
> need vector registers according to the C calling convention (fptosi, 
> @llvm.sin.*, etc.).

Yup. That's bad.

> All three of these could be addressesed in the AArch64 backend in a 
> straightforward manner.

I worry about declarations and front-end optimisations, which may move the line 
info to a completely different place (where it's used, for example). But I have 
no basis for that worry. :)

> Diagnosing floating-point operations in Sema in addition to whatever backend 
> fixes we might want is fine, I guess, but I don't really like making 
> "-mgeneral-regs-only" into "-mno-implicit-float" plus some diagnostics; other 
> frontends don't benefit from this checking, and using no-implicit-float is 
> asking for an obscure miscompile if IR generation or an optimization 
> accidentally produces a floating-point value.

I agree with both statements. But it would be good to have the errors in Sema 
in addition to the back-end fixes, if there are cases where Clang's diagnostics 
is more precise on line info and carat position.




Comment at: lib/Sema/SemaExprCXX.cpp:7477
+static bool typeHasFloatingOrVectorComponent(
+QualType Ty, llvm::SmallDenseMap &TypeCache) {
+  if (Ty.isNull())

The `TypeCache` object seems local.

It doesn't look like it needs to survive outside of this function, as per its 
usage and the comment:

// We may see recursive types in broken code.

and it just adds another argument passing.


https://reviews.llvm.org/D38479



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

[PATCH] D38538: Avoid printing some redundant name qualifiers in completion

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov created this revision.
Herald added a subscriber: eraman.

Adjusted PrintingPolicy inside code completion to avoid printing some
redundant name qualifiers.

Before this change, typedefs that were written unqualified in source
code were printed with qualifiers in completion. For example, in the
following code

  struct foo {
  typedef int type;
  type method();
  };

completion item for `method` had return type of `foo::type`, even
though the original code used `type` without qualifiers.
After this change, the completion item has return type `type`, as
originally written in the source code.

Note that this change does not suppress qualifiers written by the
user. For example, in the following code

  typedef int type;
  struct foo {
  typedef int type;
  ::type method(foo::type);
  };

completion item for `method` has return type of `::type` and
parameter type of `foo::type`, as originally written in the source
code.


https://reviews.llvm.org/D38538

Files:
  lib/Sema/SemaCodeComplete.cpp
  test/CodeCompletion/call.cpp
  test/CodeCompletion/enum-switch-case-qualified.cpp
  test/CodeCompletion/enum-switch-case.cpp
  test/CodeCompletion/qualifiers-as-written.cpp
  test/CodeCompletion/uninstantiated_params.cpp
  test/Index/code-completion.cpp
  test/Index/complete-cxx-inline-methods.cpp
  test/Index/complete-documentation-templates.cpp

Index: test/Index/complete-documentation-templates.cpp
===
--- test/Index/complete-documentation-templates.cpp
+++ test/Index/complete-documentation-templates.cpp
@@ -119,7 +119,7 @@
 // CHECK-CC3: FieldDecl:{ResultType int}{TypedText T7}{{.*}}(brief comment: This is T7.)
 
 // RUN: env CINDEXTEST_COMPLETION_BRIEF_COMMENTS=1 c-index-test -code-completion-at=%s:59:12 %s | FileCheck -check-prefix=CHECK-CC4 %s
-// CHECK-CC4: EnumConstantDecl:{ResultType T3::T9}{TypedText T10}{{.*}}(brief comment: This is T10.)
+// CHECK-CC4: EnumConstantDecl:{ResultType T9}{TypedText T10}{{.*}}(brief comment: This is T10.)
 // FIXME: after we implement propagating comments through typedefs, this
 // typedef for implicit instantiation should pick up the documentation
 // comment from class template.
@@ -140,7 +140,7 @@
 // RUN: env CINDEXTEST_COMPLETION_BRIEF_COMMENTS=1 c-index-test -code-completion-at=%s:105:20 %s | FileCheck -check-prefix=CHECK-CC7 %s
 // CHECK-CC7: ClassDecl:{TypedText T105}{{.*}}(brief comment: This is T105.)
 // CHECK-CC7: EnumDecl:{TypedText T106}{{.*}}(brief comment: This is T106.)
-// CHECK-CC7: EnumConstantDecl:{ResultType T100::T106}{TypedText T107}{{.*}}(brief comment: This is T107.)
+// CHECK-CC7: EnumConstantDecl:{ResultType T106}{TypedText T107}{{.*}}(brief comment: This is T107.)
 // FIXME: after we implement propagating comments through typedefs, these two
 // typedefs for implicit instantiations should pick up the documentation
 // comment from class template.
Index: test/Index/complete-cxx-inline-methods.cpp
===
--- test/Index/complete-cxx-inline-methods.cpp
+++ test/Index/complete-cxx-inline-methods.cpp
@@ -25,7 +25,7 @@
 
 // RUN: c-index-test -code-completion-at=%s:4:9 -std=c++98 %s | FileCheck %s
 // RUN: c-index-test -code-completion-at=%s:13:7 -std=c++98 %s | FileCheck %s
-// CHECK:  CXXMethod:{ResultType MyCls::Vec &}{TypedText operator=}{LeftParen (}{Placeholder const MyCls::Vec &}{RightParen )} (79)
+// CHECK:  CXXMethod:{ResultType Vec &}{TypedText operator=}{LeftParen (}{Placeholder const Vec &}{RightParen )} (79)
 // CHECK-NEXT: StructDecl:{TypedText Vec}{Text ::} (75)
 // CHECK-NEXT: FieldDecl:{ResultType int}{TypedText x} (35)
 // CHECK-NEXT: FieldDecl:{ResultType int}{TypedText y} (35)
Index: test/Index/code-completion.cpp
===
--- test/Index/code-completion.cpp
+++ test/Index/code-completion.cpp
@@ -55,7 +55,7 @@
 // CHECK-MEMBER: CXXMethod:{ResultType Z &}{TypedText operator=}{LeftParen (}{Placeholder const Z &}{RightParen )}
 // CHECK-MEMBER: CXXMethod:{ResultType X &}{Text X::}{TypedText operator=}{LeftParen (}{Placeholder const X &}{RightParen )}
 // CHECK-MEMBER: CXXMethod:{ResultType Y &}{Text Y::}{TypedText operator=}{LeftParen (}{Placeholder const Y &}{RightParen )}
-// CHECK-MEMBER: EnumConstantDecl:{ResultType X::E}{Informative E::}{TypedText Val1}
+// CHECK-MEMBER: EnumConstantDecl:{ResultType E}{Informative E::}{TypedText Val1}
 // CHECK-MEMBER: StructDecl:{TypedText X}{Text ::}
 // CHECK-MEMBER: StructDecl:{TypedText Y}{Text ::}
 // CHECK-MEMBER: StructDecl:{TypedText Z}{Text ::}
Index: test/CodeCompletion/uninstantiated_params.cpp
===
--- test/CodeCompletion/uninstantiated_params.cpp
+++ test/CodeCompletion/uninstantiated_params.cpp
@@ -9,5 +9,5 @@
   unique_ptr x;
   x.
   // RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:10:5 %s -o - | Fil

[PATCH] D33765: Show correct column nr. when multi-byte utf8 chars are used.

[Erik Verbruggen via Phabricator via cfe-commits]

erikjv updated this revision to Diff 117660.
erikjv edited the summary of this revision.

https://reviews.llvm.org/D33765

Files:
  include/clang/Basic/SourceManager.h
  lib/Basic/SourceManager.cpp
  test/Misc/diag-utf8.cpp

Index: test/Misc/diag-utf8.cpp
===
--- /dev/null
+++ test/Misc/diag-utf8.cpp
@@ -0,0 +1,10 @@
+// RUN: not %clang_cc1 -fsyntax-only %s 2>&1 | FileCheck %s
+
+struct Foo { int member; };
+
+void f(Foo foo)
+{
+"ideeen" << foo; // CHECK: {{.*[/\\]}}diag-utf8.cpp:7:14: error: invalid operands to binary expression ('const char *' and 'Foo')
+"ideëen" << foo; // CHECK: {{.*[/\\]}}diag-utf8.cpp:8:14: error: invalid operands to binary expression ('const char *' and 'Foo')
+"idez̈en" << foo; // CHECK: {{.*[/\\]}}diag-utf8.cpp:9:14: error: invalid operands to binary expression ('const char *' and 'Foo')
+}
Index: lib/Basic/SourceManager.cpp
===
--- lib/Basic/SourceManager.cpp
+++ lib/Basic/SourceManager.cpp
@@ -1084,11 +1084,50 @@
   return Buffer->getBufferStart() + (CharDataInvalid? 0 : LocInfo.second);
 }
 
+static unsigned correctForMultiByteChars(const char *Buf, unsigned LineStart,
+ unsigned Column) {
+  auto isDiacriticMark = [Buf, LineStart, Column](unsigned I) -> bool {
+if (I + 1 >= Column)
+  return false;
+unsigned char FirstByte = static_cast(Buf[LineStart + I]);
+unsigned char SecondByte =
+static_cast(Buf[LineStart + I + 1]);
+if (FirstByte == 0xcc) {
+  return SecondByte >= 0x80;
+} else if (FirstByte == 0xcd) {
+  return SecondByte < 0xaf;
+}
+return false;
+  };
+
+  unsigned CorrectedColumn = Column;
+  unsigned char FirstByte;
+  for (unsigned I = 0; I < Column; ++I) {
+FirstByte = static_cast(Buf[LineStart + I]);
+if (FirstByte < 0xc0)
+  continue;
+if (isDiacriticMark(I)) {
+  CorrectedColumn -= 2;
+  ++I;
+} else if (FirstByte < 0xe0) {
+  --CorrectedColumn;
+  ++I;
+} else if (FirstByte < 0xf0) {
+  CorrectedColumn -= 2;
+  I += 2;
+} else {
+  CorrectedColumn -= 3;
+  I += 3;
+}
+  }
+  return CorrectedColumn;
+}
 
 /// getColumnNumber - Return the column # for the specified file position.
 /// this is significantly cheaper to compute than the line number.
 unsigned SourceManager::getColumnNumber(FileID FID, unsigned FilePos,
-bool *Invalid) const {
+bool *Invalid,
+bool BytePosition) const {
   bool MyInvalid = false;
   llvm::MemoryBuffer *MemBuf = getBuffer(FID, &MyInvalid);
   if (Invalid)
@@ -1122,14 +1161,18 @@
 if (Buf[FilePos - 1] == '\r' || Buf[FilePos - 1] == '\n')
   --FilePos;
   }
-  return FilePos - LineStart + 1;
+  unsigned Column = FilePos - LineStart + 1;
+  return BytePosition ? Column
+  : correctForMultiByteChars(Buf, LineStart, Column);
 }
   }
 
   unsigned LineStart = FilePos;
   while (LineStart && Buf[LineStart-1] != '\n' && Buf[LineStart-1] != '\r')
 --LineStart;
-  return FilePos-LineStart+1;
+  unsigned Column = FilePos - LineStart + 1;
+  return BytePosition ? Column
+  : correctForMultiByteChars(Buf, LineStart, Column);
 }
 
 // isInvalid - Return the result of calling loc.isInvalid(), and
@@ -1454,7 +1497,8 @@
   unsigned LineNo = getLineNumber(LocInfo.first, LocInfo.second, &Invalid);
   if (Invalid)
 return PresumedLoc();
-  unsigned ColNo  = getColumnNumber(LocInfo.first, LocInfo.second, &Invalid);
+  unsigned ColNo = getColumnNumber(LocInfo.first, LocInfo.second, &Invalid,
+   /*BytePosition=*/false);
   if (Invalid)
 return PresumedLoc();
   
Index: include/clang/Basic/SourceManager.h
===
--- include/clang/Basic/SourceManager.h
+++ include/clang/Basic/SourceManager.h
@@ -1300,7 +1300,8 @@
   /// on a file sloc, so you must choose a spelling or expansion location
   /// before calling this method.
   unsigned getColumnNumber(FileID FID, unsigned FilePos,
-   bool *Invalid = nullptr) const;
+   bool *Invalid = nullptr,
+   bool BytePosition = true) const;
   unsigned getSpellingColumnNumber(SourceLocation Loc,
bool *Invalid = nullptr) const;
   unsigned getExpansionColumnNumber(SourceLocation Loc,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D37826: Refine generation of TBAA information in clang

[Ivan A. Kosarev via Phabricator via cfe-commits]

kosarev added a comment.

In https://reviews.llvm.org/D37826#887820, @rjmccall wrote:

> I assume I should wait on reviewing this until all of these smaller TBAA 
> patches land?


These small patches are actually part of this diff. Generally, It depends on 
how you would like it: if you can review this re-based version as a whole, then 
that would save us some time.

Otherwise, you may want to proceed by smaller pieces, in which case 
https://reviews.llvm.org/D38503 is the next proposed piece to review.

Alternatively, if https://reviews.llvm.org/D38503 looks too complicated, please 
let me know and I will break it down into even smaller patches.

Or, if acceptable, I could commit a series of really small and simple diffs 
that all result in what is presented in https://reviews.llvm.org/D38126 and 
rely on post-commit reviews.

I'm fine with either way, provided the changes go to the mainline in time 
manner.

Thanks a lot for reviewing!


https://reviews.llvm.org/D37826



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

[PATCH] D37826: Refine generation of TBAA information in clang

[Ivan A. Kosarev via Phabricator via cfe-commits]

kosarev updated this revision to Diff 117653.
kosarev added a comment.

Rebased.

This is how how the rebased patch differs from the mainline:

- It incorporates changes from (not landed yet) https://reviews.llvm.org/D38503.
- Simplifies generation of TBAA info in EmitLValueForField().
- Replaces TBAAPathTag with TBAAAccessInfo for caching purposes.
- Decorated atomic accesses with complete TBAA info and not just final access 
types (propagation of TBAA info for atomic accesses is already fixed in 
https://reviews.llvm.org/D38460).
- Fixes the bug with writing to a wrong cache in getTBAAStructTypeInfo() / 
getBaseTypeInfo().


https://reviews.llvm.org/D37826

Files:
  lib/CodeGen/CGAtomic.cpp
  lib/CodeGen/CGClass.cpp
  lib/CodeGen/CGExpr.cpp
  lib/CodeGen/CGValue.h
  lib/CodeGen/CodeGenFunction.cpp
  lib/CodeGen/CodeGenFunction.h
  lib/CodeGen/CodeGenModule.cpp
  lib/CodeGen/CodeGenModule.h
  lib/CodeGen/CodeGenTBAA.cpp
  lib/CodeGen/CodeGenTBAA.h

Index: lib/CodeGen/CodeGenTBAA.h
===
--- lib/CodeGen/CodeGenTBAA.h
+++ lib/CodeGen/CodeGenTBAA.h
@@ -32,22 +32,15 @@
 namespace CodeGen {
 class CGRecordLayout;
 
-struct TBAAPathTag {
-  TBAAPathTag(const Type *B, const llvm::MDNode *A, uint64_t O)
-: BaseT(B), AccessN(A), Offset(O) {}
-  const Type *BaseT;
-  const llvm::MDNode *AccessN;
-  uint64_t Offset;
-};
-
 // TBAAAccessInfo - Describes a memory access in terms of TBAA.
 struct TBAAAccessInfo {
-  TBAAAccessInfo(QualType BaseType, llvm::MDNode *AccessType, uint64_t Offset)
+  TBAAAccessInfo(llvm::MDNode *BaseType, llvm::MDNode *AccessType,
+ uint64_t Offset)
 : BaseType(BaseType), AccessType(AccessType), Offset(Offset)
   {}
 
   explicit TBAAAccessInfo(llvm::MDNode *AccessType)
-: TBAAAccessInfo(/* BaseType= */ QualType(), AccessType, /* Offset= */ 0)
+: TBAAAccessInfo(/* BaseType= */ nullptr, AccessType, /* Offset= */ 0)
   {}
 
   TBAAAccessInfo()
@@ -57,7 +50,7 @@
   /// BaseType - The base/leading access type. May be null if this access
   /// descriptor represents an access that is not considered to be an access
   /// to an aggregate or union member.
-  QualType BaseType;
+  llvm::MDNode *BaseType;
 
   /// AccessType - The final access type. May be null if there is no TBAA
   /// information available about this access.
@@ -82,12 +75,10 @@
   /// MetadataCache - This maps clang::Types to scalar llvm::MDNodes describing
   /// them.
   llvm::DenseMap MetadataCache;
-  /// This maps clang::Types to a struct node in the type DAG.
-  llvm::DenseMap StructTypeMetadataCache;
-  /// This maps TBAAPathTags to a tag node.
-  llvm::DenseMap StructTagMetadataCache;
-  /// This maps a scalar type to a scalar tag node.
-  llvm::DenseMap ScalarTagMetadataCache;
+  /// This maps clang::Types to a base access type in the type DAG.
+  llvm::DenseMap BaseTypeMetadataCache;
+  /// This maps TBAA access descriptors to tag nodes.
+  llvm::DenseMap AccessTagMetadataCache;
 
   /// StructMetadataCache - This maps clang::Types to llvm::MDNodes describing
   /// them for struct assignments.
@@ -127,58 +118,57 @@
   /// given type.
   llvm::MDNode *getTypeInfo(QualType QTy);
 
-  /// getTBAAInfoForVTablePtr - Get the TBAA MDNode to be used for a
-  /// dereference of a vtable pointer.
-  llvm::MDNode *getTBAAInfoForVTablePtr();
+  /// getVTablePtrAccessInfo - Get the TBAA information that describes an
+  /// access to a virtual table pointer.
+  TBAAAccessInfo getVTablePtrAccessInfo();
 
   /// getTBAAStructInfo - Get the TBAAStruct MDNode to be used for a memcpy of
   /// the given type.
   llvm::MDNode *getTBAAStructInfo(QualType QTy);
 
-  /// Get the MDNode in the type DAG for given struct type QType.
-  llvm::MDNode *getTBAAStructTypeInfo(QualType QType);
-
-  /// Get path-aware TBAA tag for a given memory access.
-  llvm::MDNode *getTBAAStructTagInfo(TBAAAccessInfo Info);
+  /// getTBAABaseTypeMetadata - Get metadata that describes the given base
+  /// access type. Return null if the type is not suitable for use in TBAA
+  /// access tags.
+  llvm::MDNode *getBaseTypeInfo(QualType QTy);
 
-  /// Get the scalar tag MDNode for a given scalar type.
-  llvm::MDNode *getTBAAScalarTagInfo(llvm::MDNode *AccessNode);
+  /// getAccessTagInfo - Get TBAA tag for a given memory access.
+  llvm::MDNode *getAccessTagInfo(TBAAAccessInfo Info);
 
-  /// getMayAliasTypeInfo - Get TBAA information that represents may-alias
+  /// getMayAliasAccessInfo - Get TBAA information that represents may-alias
   /// accesses.
-  llvm::MDNode *getMayAliasTypeInfo();
+  TBAAAccessInfo getMayAliasAccessInfo();
 };
 
 }  // end namespace CodeGen
 }  // end namespace clang
 
 namespace llvm {
 
-template<> struct DenseMapInfo {
-  static clang::CodeGen::TBAAPathTag getEmptyKey() {
-return clang::CodeGen::TBAAPathTag(
-  DenseMapInfo::getEmptyKey(),
-  DenseMapInfo::getEmptyKey(),
+template<> struct DenseMapInfo {
+  static clang::CodeGen::

[PATCH] D38458: Fix assertion failure in thread safety analysis (PR34800).

[Alexander Kornienko via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL314895: Fix assertion failure in thread safety analysis 
(PR34800). (authored by alexfh).

Repository:
  rL LLVM

https://reviews.llvm.org/D38458

Files:
  cfe/trunk/include/clang/Analysis/Analyses/ThreadSafetyTIL.h
  cfe/trunk/test/SemaCXX/warn-thread-safety-analysis.cpp


Index: cfe/trunk/include/clang/Analysis/Analyses/ThreadSafetyTIL.h
===
--- cfe/trunk/include/clang/Analysis/Analyses/ThreadSafetyTIL.h
+++ cfe/trunk/include/clang/Analysis/Analyses/ThreadSafetyTIL.h
@@ -909,15 +909,10 @@
 public:
   static bool classof(const SExpr *E) { return E->opcode() == COP_Project; }
 
-  Project(SExpr *R, StringRef SName)
-  : SExpr(COP_Project), Rec(R), SlotName(SName), Cvdecl(nullptr)
-  { }
   Project(SExpr *R, const clang::ValueDecl *Cvd)
-  : SExpr(COP_Project), Rec(R), SlotName(Cvd->getName()), Cvdecl(Cvd)
-  { }
-  Project(const Project &P, SExpr *R)
-  : SExpr(P), Rec(R), SlotName(P.SlotName), Cvdecl(P.Cvdecl)
-  { }
+  : SExpr(COP_Project), Rec(R), Cvdecl(Cvd) {
+assert(Cvd && "ValueDecl must not be null");
+  }
 
   SExpr *record() { return Rec; }
   const SExpr *record() const { return Rec; }
@@ -931,10 +926,14 @@
   }
 
   StringRef slotName() const {
-if (Cvdecl)
+if (Cvdecl->getDeclName().isIdentifier())
   return Cvdecl->getName();
-else
-  return SlotName;
+if (!SlotName) {
+  SlotName = "";
+  llvm::raw_string_ostream OS(*SlotName);
+  Cvdecl->printName(OS);
+}
+return *SlotName;
   }
 
   template 
@@ -953,7 +952,7 @@
 
 private:
   SExpr* Rec;
-  StringRef SlotName;
+  mutable llvm::Optional SlotName;
   const clang::ValueDecl *Cvdecl;
 };
 
Index: cfe/trunk/test/SemaCXX/warn-thread-safety-analysis.cpp
===
--- cfe/trunk/test/SemaCXX/warn-thread-safety-analysis.cpp
+++ cfe/trunk/test/SemaCXX/warn-thread-safety-analysis.cpp
@@ -5233,3 +5233,18 @@
   } // expected-warning {{mutex 'lock_' is still held at the end of function}}
   Mutex lock_ ACQUIRED_BEFORE("");
 };
+
+namespace PR34800 {
+struct A {
+  operator int() const;
+};
+struct B {
+  bool g() __attribute__((locks_excluded(h))); // expected-warning 
{{'locks_excluded' attribute requires arguments whose type is annotated with 
'capability' attribute; type here is 'int'}}
+  int h;
+};
+struct C {
+  B *operator[](int);
+};
+C c;
+void f() { c[A()]->g(); }
+} // namespace PR34800


Index: cfe/trunk/include/clang/Analysis/Analyses/ThreadSafetyTIL.h
===
--- cfe/trunk/include/clang/Analysis/Analyses/ThreadSafetyTIL.h
+++ cfe/trunk/include/clang/Analysis/Analyses/ThreadSafetyTIL.h
@@ -909,15 +909,10 @@
 public:
   static bool classof(const SExpr *E) { return E->opcode() == COP_Project; }
 
-  Project(SExpr *R, StringRef SName)
-  : SExpr(COP_Project), Rec(R), SlotName(SName), Cvdecl(nullptr)
-  { }
   Project(SExpr *R, const clang::ValueDecl *Cvd)
-  : SExpr(COP_Project), Rec(R), SlotName(Cvd->getName()), Cvdecl(Cvd)
-  { }
-  Project(const Project &P, SExpr *R)
-  : SExpr(P), Rec(R), SlotName(P.SlotName), Cvdecl(P.Cvdecl)
-  { }
+  : SExpr(COP_Project), Rec(R), Cvdecl(Cvd) {
+assert(Cvd && "ValueDecl must not be null");
+  }
 
   SExpr *record() { return Rec; }
   const SExpr *record() const { return Rec; }
@@ -931,10 +926,14 @@
   }
 
   StringRef slotName() const {
-if (Cvdecl)
+if (Cvdecl->getDeclName().isIdentifier())
   return Cvdecl->getName();
-else
-  return SlotName;
+if (!SlotName) {
+  SlotName = "";
+  llvm::raw_string_ostream OS(*SlotName);
+  Cvdecl->printName(OS);
+}
+return *SlotName;
   }
 
   template 
@@ -953,7 +952,7 @@
 
 private:
   SExpr* Rec;
-  StringRef SlotName;
+  mutable llvm::Optional SlotName;
   const clang::ValueDecl *Cvdecl;
 };
 
Index: cfe/trunk/test/SemaCXX/warn-thread-safety-analysis.cpp
===
--- cfe/trunk/test/SemaCXX/warn-thread-safety-analysis.cpp
+++ cfe/trunk/test/SemaCXX/warn-thread-safety-analysis.cpp
@@ -5233,3 +5233,18 @@
   } // expected-warning {{mutex 'lock_' is still held at the end of function}}
   Mutex lock_ ACQUIRED_BEFORE("");
 };
+
+namespace PR34800 {
+struct A {
+  operator int() const;
+};
+struct B {
+  bool g() __attribute__((locks_excluded(h))); // expected-warning {{'locks_excluded' attribute requires arguments whose type is annotated with 'capability' attribute; type here is 'int'}}
+  int h;
+};
+struct C {
+  B *operator[](int);
+};
+C c;
+void f() { c[A()]->g(); }
+} // namespace PR34800
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r314895 - Fix assertion failure in thread safety analysis (PR34800).

[Alexander Kornienko via cfe-commits]

Author: alexfh
Date: Wed Oct  4 03:24:36 2017
New Revision: 314895

URL: http://llvm.org/viewvc/llvm-project?rev=314895&view=rev
Log:
Fix assertion failure in thread safety analysis (PR34800).

Summary:
Fix an assertion failure (http://llvm.org/PR34800) and clean up unused code 
relevant to the fixed logic.

A bit of context: when `SExprBuilder::translateMemberExpr` is called on a 
member expression that involves a conversion operator, for example, 
`til::Project` constructor can't just call `getName()` on it, since the name is 
not a simple identifier. In order to handle this case I've introduced an 
optional string to print the member name to. I discovered that the other two 
`til::Project` constructors are not used, so it was better to delete them 
instead of ensuring they work correctly with the new logic.

Reviewers: aaron.ballman

Reviewed By: aaron.ballman

Subscribers: cfe-commits

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

Modified:
cfe/trunk/include/clang/Analysis/Analyses/ThreadSafetyTIL.h
cfe/trunk/test/SemaCXX/warn-thread-safety-analysis.cpp

Modified: cfe/trunk/include/clang/Analysis/Analyses/ThreadSafetyTIL.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Analysis/Analyses/ThreadSafetyTIL.h?rev=314895&r1=314894&r2=314895&view=diff
==
--- cfe/trunk/include/clang/Analysis/Analyses/ThreadSafetyTIL.h (original)
+++ cfe/trunk/include/clang/Analysis/Analyses/ThreadSafetyTIL.h Wed Oct  4 
03:24:36 2017
@@ -909,15 +909,10 @@ class Project : public SExpr {
 public:
   static bool classof(const SExpr *E) { return E->opcode() == COP_Project; }
 
-  Project(SExpr *R, StringRef SName)
-  : SExpr(COP_Project), Rec(R), SlotName(SName), Cvdecl(nullptr)
-  { }
   Project(SExpr *R, const clang::ValueDecl *Cvd)
-  : SExpr(COP_Project), Rec(R), SlotName(Cvd->getName()), Cvdecl(Cvd)
-  { }
-  Project(const Project &P, SExpr *R)
-  : SExpr(P), Rec(R), SlotName(P.SlotName), Cvdecl(P.Cvdecl)
-  { }
+  : SExpr(COP_Project), Rec(R), Cvdecl(Cvd) {
+assert(Cvd && "ValueDecl must not be null");
+  }
 
   SExpr *record() { return Rec; }
   const SExpr *record() const { return Rec; }
@@ -931,10 +926,14 @@ public:
   }
 
   StringRef slotName() const {
-if (Cvdecl)
+if (Cvdecl->getDeclName().isIdentifier())
   return Cvdecl->getName();
-else
-  return SlotName;
+if (!SlotName) {
+  SlotName = "";
+  llvm::raw_string_ostream OS(*SlotName);
+  Cvdecl->printName(OS);
+}
+return *SlotName;
   }
 
   template 
@@ -953,7 +952,7 @@ public:
 
 private:
   SExpr* Rec;
-  StringRef SlotName;
+  mutable llvm::Optional SlotName;
   const clang::ValueDecl *Cvdecl;
 };
 

Modified: cfe/trunk/test/SemaCXX/warn-thread-safety-analysis.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/warn-thread-safety-analysis.cpp?rev=314895&r1=314894&r2=314895&view=diff
==
--- cfe/trunk/test/SemaCXX/warn-thread-safety-analysis.cpp (original)
+++ cfe/trunk/test/SemaCXX/warn-thread-safety-analysis.cpp Wed Oct  4 03:24:36 
2017
@@ -5233,3 +5233,18 @@ class acquired_before_empty_str {
   } // expected-warning {{mutex 'lock_' is still held at the end of function}}
   Mutex lock_ ACQUIRED_BEFORE("");
 };
+
+namespace PR34800 {
+struct A {
+  operator int() const;
+};
+struct B {
+  bool g() __attribute__((locks_excluded(h))); // expected-warning 
{{'locks_excluded' attribute requires arguments whose type is annotated with 
'capability' attribute; type here is 'int'}}
+  int h;
+};
+struct C {
+  B *operator[](int);
+};
+C c;
+void f() { c[A()]->g(); }
+} // namespace PR34800


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