Re: [llvm-dev] Permissions for llvm-mirror - Setting up Libc++ Appveyor builders

[Eric Fiselier via cfe-commits]

On Wed, Apr 19, 2017 at 11:19 PM, Mehdi Amini  wrote:

> What would be the status of these buildbots? Is it for your private usage?
>

I intend for them to be public Windows buildbots for libc++.

Otherwise having “project' bots” using a non-official mirror may sound like
> a strange situation to me.
>

I agree it isn't ideal, but when/if LLVM moves to github it will be trivial
to re-configure for the official repositories.
I considered a number of other ways to setup Appveyor but I concluded this
was the best/easiest way to do it.
The other options I considered for configuring Appveyor are:

(1) Use the official LLVM github mirrors.

This has the issue of requiring the implementation of custom Git webhooks,
which would require
modifying and maintaining changes to the existing LLVM Git infrastructure,
which in itself
would require getting access to the LLVM servers to make the changes.

(2) Setup my own ever more unofficial github mirror

This has all the same problems as using the existing github mirrors but it
requires
me to configure and maintain my own mirror, which is non-trivial.

(3) Don't use Appveyor at all

This requires finding Windows hardware to host the bots, which is the main
reason
I chose Appveyor to begin with. Even if hardware was available I would
prefer using
Appveyor since it provides more dominion over the environment than I think
donated hardware could.

/Eric


> —
> Mehdi
>
> On Apr 19, 2017, at 5:04 PM, Eric Fiselier via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
>
> Adding cfe-dev list...
>
> On Wed, Apr 19, 2017 at 5:50 PM, Eric Fiselier  wrote:
>
>> Hi Will,
>>
>> I would like to request collaborator permissions for the Libc++ github
>> mirror.
>>
>> I plan to use the access to setup Appveyor buildbots for libc++. In order
>> to do this I need to be listed as a collaborator on Github.
>>
>> The alternative to Github access would be setting up the correct webhooks
>> for llvm.org/git/libcxx.git, but this seems harder to both do and
>> maintain.
>>
>> /Eric
>>
>
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D32265: Add __CLANG_ATOMIC__LOCK_FREE macros for use in MSVC compatibility mode.

[JF Bastien via Phabricator via cfe-commits]

jfb added a comment.

Is it a goal to support Microsoft's STL with this? If so, how does MSVC's STL 
implement `is_always_lock_free` at the moment? CL 19 2017 RTW doesn't seem to 
have anything ? Presumably they'll have to do 
*something*.


https://reviews.llvm.org/D32265



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

[PATCH] D32265: Add __CLANG_ATOMIC__LOCK_FREE macros for use in MSVC compatibility mode.

[Eric Fiselier via Phabricator via cfe-commits]

EricWF added a comment.

In https://reviews.llvm.org/D32265#731709, @jfb wrote:

> Is it a goal to support Microsoft's STL with this? If so, how does MSVC's STL 
> implement `is_always_lock_free` at the moment? CL 19 2017 RTW doesn't seem to 
> have anything ? Presumably they'll have to do 
> *something*.


The goal is to allow libc++ to implement`ATOMIC__LOCK_FREE` on Windows 
using Clang. As you know libc++ currently uses the `__GCC_ATOMIC_FOO` macros, 
but those aren't available on Windows.

Also AFAIK MSVC leaves the implementation of atomics up to the library, not the 
frontend. So W/E MSVC's STL does it's likely not sane or desirable.


https://reviews.llvm.org/D32265



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

[PATCH] D31975: [Analyzer] Iterator Checkers

[Balogh , Ádám via Phabricator via cfe-commits]

baloghadamsoftware added a comment.

Hello! I am not sure how to split it to incremental patches. As I mentioned in 
the description, the state of the iterator position is always tracked. So if I 
remove some of the checks it does not make the patch much smaller, since the 
checking part is quite small. If I remove parts of the tracking, I introduce 
lots of false positives and uncaught bugs.

Container and offset tracking is needed for both range and validity checks. 
Match check does not need the offset, but removing it means lots of work, and 
does not help either because the second patch (adding range and validity checks 
incrementally) will remain huge.

Doing the rename in a separate patch is useless, because this checker is 
totally new: the whole position tracking uses a new concept. What I reused is 
the method of transferring the position between various SVals. Doing the rename 
separately would mean the same amount of green and lots of red.

What I could do is to rearrange of the functions a bit (separate tracking and 
checking) and adding more comments to the function. Would it help?


https://reviews.llvm.org/D31975



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

[PATCH] D29904: [OpenMP] Prevent emission of exception handling code when using OpenMP to offload to NVIDIA devices.

[Jonas Hahnfeld via Phabricator via cfe-commits]

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

LGTM unless Alexey still has objections


Repository:
  rL LLVM

https://reviews.llvm.org/D29904



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

[PATCH] D32113: Add path from clang to doxygen document include header

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev accepted this revision.
v.g.vassilev added a comment.
This revision is now accepted and ready to land.

LGTM!


https://reviews.llvm.org/D32113



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

r300825 - PR19260: Teach doxygen to spell correctly the include paths.

[Vassil Vassilev via cfe-commits]

Author: vvassilev
Date: Thu Apr 20 03:57:41 2017
New Revision: 300825

URL: http://llvm.org/viewvc/llvm-project?rev=300825&view=rev
Log:
PR19260: Teach doxygen to spell correctly the include paths.

Currently we have #include  in the doxygen page documenting Sema. The
patch changes it ot #include "clang/Sema/Sema.h" which is what we would spell if
we need to include it in a real codebase.

Patch by Yuka Takahashi (D32113)!

Modified:
cfe/trunk/docs/doxygen.cfg.in

Modified: cfe/trunk/docs/doxygen.cfg.in
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/doxygen.cfg.in?rev=300825&r1=300824&r2=300825&view=diff
==
--- cfe/trunk/docs/doxygen.cfg.in (original)
+++ cfe/trunk/docs/doxygen.cfg.in Thu Apr 20 03:57:41 2017
@@ -132,7 +132,7 @@ INLINE_INHERITED_MEMB  = NO
 # shortest path that makes the file name unique will be used
 # The default value is: YES.
 
-FULL_PATH_NAMES= NO
+FULL_PATH_NAMES= YES
 
 # The STRIP_FROM_PATH tag can be used to strip a user-defined part of the path.
 # Stripping is only done if one of the specified strings matches the left-hand
@@ -144,7 +144,7 @@ FULL_PATH_NAMES= NO
 # will be relative from the directory where doxygen is started.
 # This tag requires that the tag FULL_PATH_NAMES is set to YES.
 
-STRIP_FROM_PATH= ../..
+STRIP_FROM_PATH= @abs_srcdir@/..
 
 # The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of the
 # path mentioned in the documentation of a class, which tells the reader which
@@ -153,7 +153,7 @@ STRIP_FROM_PATH= ../..
 # specify the list of include paths that are normally passed to the compiler
 # using the -I flag.
 
-STRIP_FROM_INC_PATH=
+STRIP_FROM_INC_PATH= @abs_srcdir@/../include
 
 # If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter (but
 # less readable) file names. This can be useful is your file systems doesn't
@@ -513,7 +513,7 @@ SHOW_GROUPED_MEMB_INC  = NO
 # files with double quotes in the documentation rather than with sharp 
brackets.
 # The default value is: NO.
 
-FORCE_LOCAL_INCLUDES   = NO
+FORCE_LOCAL_INCLUDES   = YES
 
 # If the INLINE_INFO tag is set to YES then a tag [inline] is inserted in the
 # documentation for inline members.


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

[PATCH] D32113: Add path from clang to doxygen document include header

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev added a comment.

Landed in r300825. Maybe we should do something like that for LLVM 
documentation, too.


https://reviews.llvm.org/D32113



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

[PATCH] D29658: [OpenMP] Customize CUDA-based tool chain selection

[Jonas Hahnfeld via Phabricator via cfe-commits]

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

LGTM with one small note




Comment at: lib/Driver/Driver.cpp:564
+  auto &CudaTC =
+  ToolChains[TT.str() + "/" + HostTC->getTriple().normalize()];
+  if (!CudaTC)

The code above uses `HostTriple.str()`, maybe better align to this?


Repository:
  rL LLVM

https://reviews.llvm.org/D29658



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

[PATCH] D30771: [analyzer] Teach the MallocChecker about Glib API for two arguments

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

danielmarjamaki added inline comments.



Comment at: lib/StaticAnalyzer/Checkers/MallocChecker.cpp:337
+   const Expr *BlockBytes,
+   ProgramStateRef State);
   static ProgramStateRef CallocMem(CheckerContext &C, const CallExpr *CE,

Thanks for renaming the function I am happy now with that name. :-)

hmm.. if you have CheckerContext parameter already then ProgramStateRef 
parameter seems redundant. You should be able to use C.getState().

However looking at surrounding code it seems you can provide ProgramStateRef 
for consistency.

I don't have a strong opinion, but I would remove this State.



Repository:
  rL LLVM

https://reviews.llvm.org/D30771



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

Re: Permissions for llvm-mirror - Setting up Libc++ Appveyor builders

[Eric Fiselier via cfe-commits]

@Sylvestre Thanks!

After getting the permissions setup libc++ now has a new Windows builder!
https://ci.appveyor.com/project/EricWF/libcxx

/Eric

On Thu, Apr 20, 2017 at 2:30 AM, Sylvestre Ledru 
wrote:

> >
> > On Wed, Apr 19, 2017 at 5:50 PM, Eric Fiselier  e...@efcs.ca>> wrote:
> >
> > Hi Will,
> >
> > I would like to request collaborator permissions for the Libc++
> github mirror.
> Sure, I just sent you an invite on github.
>
> Cheers,
> S
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D30771: [analyzer] Teach the MallocChecker about Glib API for two arguments

[Leslie Zhai via Phabricator via cfe-commits]

xiangzhai added inline comments.



Comment at: lib/StaticAnalyzer/Checkers/MallocChecker.cpp:337
+   const Expr *BlockBytes,
+   ProgramStateRef State);
   static ProgramStateRef CallocMem(CheckerContext &C, const CallExpr *CE,

danielmarjamaki wrote:
> Thanks for renaming the function I am happy now with that name. :-)
> 
> hmm.. if you have CheckerContext parameter already then ProgramStateRef 
> parameter seems redundant. You should be able to use C.getState().
> 
> However looking at surrounding code it seems you can provide ProgramStateRef 
> for consistency.
> 
> I don't have a strong opinion, but I would remove this State.
> 
I will update it tomorrow! I have to gotta home to look after my kid :)


Repository:
  rL LLVM

https://reviews.llvm.org/D30771



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

r300826 - Add #pragma clang attribute support to the availability attribute

[Alex Lorenz via cfe-commits]

Author: arphaman
Date: Thu Apr 20 04:35:02 2017
New Revision: 300826

URL: http://llvm.org/viewvc/llvm-project?rev=300826&view=rev
Log:
Add #pragma clang attribute support to the availability attribute

rdar://31707804

Modified:
cfe/trunk/include/clang/Basic/Attr.td
cfe/trunk/lib/Sema/SemaDeclAttr.cpp
cfe/trunk/test/Misc/pragma-attribute-supported-attributes-list.test
cfe/trunk/test/Parser/pragma-attribute.cpp
cfe/trunk/test/Sema/attr-availability.c

Modified: cfe/trunk/include/clang/Basic/Attr.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=300826&r1=300825&r2=300826&view=diff
==
--- cfe/trunk/include/clang/Basic/Attr.td (original)
+++ cfe/trunk/include/clang/Basic/Attr.td Thu Apr 20 04:35:02 2017
@@ -655,7 +655,7 @@ def Availability : InheritableAttr {
 } }];
   let HasCustomParsing = 1;
   let DuplicatesAllowedWhileMerging = 1;
-//  let Subjects = SubjectList<[Named]>;
+  let Subjects = SubjectList<[Named]>;
   let Documentation = [AvailabilityDocs];
 }
 

Modified: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclAttr.cpp?rev=300826&r1=300825&r2=300826&view=diff
==
--- cfe/trunk/lib/Sema/SemaDeclAttr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp Thu Apr 20 04:35:02 2017
@@ -2398,10 +2398,8 @@ static void handleAvailabilityAttr(Sema
   << Platform->Ident;
 
   NamedDecl *ND = dyn_cast(D);
-  if (!ND) {
-S.Diag(Attr.getLoc(), diag::warn_attribute_ignored) << Attr.getName();
+  if (!ND) // We warned about this already, so just return.
 return;
-  }
 
   AvailabilityChange Introduced = Attr.getAvailabilityIntroduced();
   AvailabilityChange Deprecated = Attr.getAvailabilityDeprecated();

Modified: cfe/trunk/test/Misc/pragma-attribute-supported-attributes-list.test
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Misc/pragma-attribute-supported-attributes-list.test?rev=300826&r1=300825&r2=300826&view=diff
==
--- cfe/trunk/test/Misc/pragma-attribute-supported-attributes-list.test 
(original)
+++ cfe/trunk/test/Misc/pragma-attribute-supported-attributes-list.test Thu Apr 
20 04:35:02 2017
@@ -2,7 +2,7 @@
 
 // The number of supported attributes should never go down!
 
-// CHECK: #pragma clang attribute supports 58 attributes:
+// CHECK: #pragma clang attribute supports 59 attributes:
 // CHECK-NEXT: AMDGPUFlatWorkGroupSize (SubjectMatchRule_function)
 // CHECK-NEXT: AMDGPUNumSGPR (SubjectMatchRule_function)
 // CHECK-NEXT: AMDGPUNumVGPR (SubjectMatchRule_function)
@@ -13,6 +13,7 @@
 // CHECK-NEXT: AllocSize (SubjectMatchRule_function)
 // CHECK-NEXT: Annotate ()
 // CHECK-NEXT: AssumeAligned (SubjectMatchRule_objc_method, 
SubjectMatchRule_function)
+// CHECK-NEXT: Availability ((SubjectMatchRule_record, SubjectMatchRule_enum, 
SubjectMatchRule_enum_constant, SubjectMatchRule_field, 
SubjectMatchRule_function, SubjectMatchRule_namespace, 
SubjectMatchRule_objc_category, SubjectMatchRule_objc_interface, 
SubjectMatchRule_objc_method, SubjectMatchRule_objc_property, 
SubjectMatchRule_objc_protocol, SubjectMatchRule_record, 
SubjectMatchRule_type_alias, SubjectMatchRule_variable))
 // CHECK-NEXT: CXX11NoReturn (SubjectMatchRule_function)
 // CHECK-NEXT: CallableWhen (SubjectMatchRule_function_is_member)
 // CHECK-NEXT: CarriesDependency (SubjectMatchRule_variable_is_parameter, 
SubjectMatchRule_objc_method, SubjectMatchRule_function)

Modified: cfe/trunk/test/Parser/pragma-attribute.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Parser/pragma-attribute.cpp?rev=300826&r1=300825&r2=300826&view=diff
==
--- cfe/trunk/test/Parser/pragma-attribute.cpp (original)
+++ cfe/trunk/test/Parser/pragma-attribute.cpp Thu Apr 20 04:35:02 2017
@@ -122,9 +122,9 @@ void function();
 #pragma clang attribute push (__attribute__((annotate)) foo) // expected-error 
{{expected ','}}
 #pragma clang attribute push (__attribute__((annotate)), apply_to=function 
foo) // expected-error {{extra tokens after attribute in a '#pragma clang 
attribute push'}}
 
-#pragma clang attribute push (__attribute__((availability(macos, foo=1))), 
apply_to=function) // expected-error {{'foo' is not an availability stage; use 
'introduced', 'deprecated', or 'obsoleted'}}
-// expected-error@-1 {{attribute 'availability' is not supported by '#pragma 
clang attribute'}}
-#pragma clang attribute push (__attribute__((availability(macos, 1))), 
apply_to=function) // expected-error {{expected 'introduced', 'deprecated', or 
'obsoleted'}}
+#pragma clang attribute push (__attribute__((objc_bridge_related)), 
apply_to=function)
+// expected-error@-1 {{attribute 'objc_bridge_related' is not supported by 
'#pragma 

r300829 - Add Python 3 support to clang.cindex

[Jonathan Coe via cfe-commits]

Author: jbcoe
Date: Thu Apr 20 05:11:01 2017
New Revision: 300829

URL: http://llvm.org/viewvc/llvm-project?rev=300829&view=rev
Log:
Add Python 3 support to clang.cindex

Summary:
Introduce an interop string to convert from unicode to c-strings where needed.
Add missing conversions from _CXString to strings in function registrations.
Explicitly evaluate lists where Python 3's lazy iterators would not otherwise 
do so.

This is an improvement upon the reverted change proposed in 
https://reviews.llvm.org/D26082

Reviewers: compnerd, skalinichev, modocache, MathieuDuponchelle

Reviewed By: compnerd

Subscribers: cfe-commits

Tags: #clang-c

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

Modified:
cfe/trunk/bindings/python/clang/__init__.py
cfe/trunk/bindings/python/clang/cindex.py
cfe/trunk/bindings/python/tests/cindex/test_translation_unit.py

Modified: cfe/trunk/bindings/python/clang/__init__.py
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/bindings/python/clang/__init__.py?rev=300829&r1=300828&r2=300829&view=diff
==
--- cfe/trunk/bindings/python/clang/__init__.py (original)
+++ cfe/trunk/bindings/python/clang/__init__.py Thu Apr 20 05:11:01 2017
@@ -20,13 +20,5 @@ The available modules are:
 Bindings for the Clang indexing library.
 """
 
-
-# Python 3 uses unicode for strings. The bindings, in particular the 
interaction
-# with ctypes, need modifying to handle conversions between unicode and
-# c-strings.
-import sys 
-if sys.version_info[0] != 2: 
-raise Exception("Only Python 2 is supported.")
-
 __all__ = ['cindex']
 

Modified: cfe/trunk/bindings/python/clang/cindex.py
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/bindings/python/clang/cindex.py?rev=300829&r1=300828&r2=300829&view=diff
==
--- cfe/trunk/bindings/python/clang/cindex.py (original)
+++ cfe/trunk/bindings/python/clang/cindex.py Thu Apr 20 05:11:01 2017
@@ -67,6 +67,60 @@ import collections
 
 import clang.enumerations
 
+import sys
+if sys.version_info[0] == 3:
+# Python 3 strings are unicode, translate them to/from utf8 for C-interop.
+class c_interop_string(c_char_p):
+
+def __init__(self, p=None):
+if p is None:
+p = ""
+if isinstance(p, str):
+p = p.encode("utf8")
+super(c_char_p, self).__init__(p)
+
+def __str__(self):
+return self.value
+
+@property
+def value(self):
+if super(c_char_p, self).value is None:
+return None
+return super(c_char_p, self).value.decode("utf8")
+
+@classmethod
+def from_param(cls, param):
+if isinstance(param, str):
+return cls(param)
+if isinstance(param, bytes):
+return cls(param)
+raise TypeError("Cannot convert '{}' to 
'{}'".format(type(param).__name__, cls.__name__))
+
+@staticmethod
+def to_python_string(x, *args):
+return x.value
+
+def b(x):
+if isinstance(x, bytes):
+return x
+return x.encode('utf8')
+
+xrange = range
+
+elif sys.version_info[0] == 2:
+# Python 2 strings are utf8 byte strings, no translation is needed for
+# C-interop.
+c_interop_string = c_char_p
+
+def _to_python_string(x, *args):
+return x
+
+c_interop_string.to_python_string = staticmethod(_to_python_string)
+
+def b(x):
+return x
+
+
 # ctypes doesn't implicitly convert c_void_p to the appropriate wrapper
 # object. This is a problem, because it means that from_parameter will see an
 # integer and pass the wrong value on platforms where int != void*. Work around
@@ -157,6 +211,7 @@ class _CXString(Structure):
 assert isinstance(res, _CXString)
 return conf.lib.clang_getCString(res)
 
+
 class SourceLocation(Structure):
 """
 A SourceLocation represents a particular location within a source file.
@@ -596,7 +651,7 @@ class CursorKind(BaseEnumeration):
 @staticmethod
 def get_all_kinds():
 """Return all CursorKind enumeration instances."""
-return filter(None, CursorKind._kinds)
+return [x for x in CursorKind._kinds if not x is None]
 
 def is_declaration(self):
 """Test if this is a declaration kind."""
@@ -2128,7 +2183,7 @@ class Type(Structure):
 """
 Retrieve the offset of a field in the record.
 """
-return conf.lib.clang_Type_getOffsetOf(self, c_char_p(fieldname))
+return conf.lib.clang_Type_getOffsetOf(self, fieldname)
 
 def get_ref_qualifier(self):
 """
@@ -2239,7 +2294,7 @@ class CompletionChunk:
 def spelling(self):
 if self.__kindNumber in SpellingCache:
 return SpellingCache[self.__kindNumber]
-return conf.lib.clang_getCompletionCh

[PATCH] D31568: Add Python 3 support to clang.cindex

[Jonathan B Coe via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL300829: Add Python 3 support to clang.cindex (authored by 
jbcoe).

Changed prior to commit:
  https://reviews.llvm.org/D31568?vs=94120&id=95918#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D31568

Files:
  cfe/trunk/bindings/python/clang/__init__.py
  cfe/trunk/bindings/python/clang/cindex.py
  cfe/trunk/bindings/python/tests/cindex/test_translation_unit.py

Index: cfe/trunk/bindings/python/clang/__init__.py
===
--- cfe/trunk/bindings/python/clang/__init__.py
+++ cfe/trunk/bindings/python/clang/__init__.py
@@ -20,13 +20,5 @@
 Bindings for the Clang indexing library.
 """
 
-
-# Python 3 uses unicode for strings. The bindings, in particular the interaction
-# with ctypes, need modifying to handle conversions between unicode and
-# c-strings.
-import sys 
-if sys.version_info[0] != 2: 
-raise Exception("Only Python 2 is supported.")
-
 __all__ = ['cindex']
 
Index: cfe/trunk/bindings/python/clang/cindex.py
===
--- cfe/trunk/bindings/python/clang/cindex.py
+++ cfe/trunk/bindings/python/clang/cindex.py
@@ -67,6 +67,60 @@
 
 import clang.enumerations
 
+import sys
+if sys.version_info[0] == 3:
+# Python 3 strings are unicode, translate them to/from utf8 for C-interop.
+class c_interop_string(c_char_p):
+
+def __init__(self, p=None):
+if p is None:
+p = ""
+if isinstance(p, str):
+p = p.encode("utf8")
+super(c_char_p, self).__init__(p)
+
+def __str__(self):
+return self.value
+
+@property
+def value(self):
+if super(c_char_p, self).value is None:
+return None
+return super(c_char_p, self).value.decode("utf8")
+
+@classmethod
+def from_param(cls, param):
+if isinstance(param, str):
+return cls(param)
+if isinstance(param, bytes):
+return cls(param)
+raise TypeError("Cannot convert '{}' to '{}'".format(type(param).__name__, cls.__name__))
+
+@staticmethod
+def to_python_string(x, *args):
+return x.value
+
+def b(x):
+if isinstance(x, bytes):
+return x
+return x.encode('utf8')
+
+xrange = range
+
+elif sys.version_info[0] == 2:
+# Python 2 strings are utf8 byte strings, no translation is needed for
+# C-interop.
+c_interop_string = c_char_p
+
+def _to_python_string(x, *args):
+return x
+
+c_interop_string.to_python_string = staticmethod(_to_python_string)
+
+def b(x):
+return x
+
+
 # ctypes doesn't implicitly convert c_void_p to the appropriate wrapper
 # object. This is a problem, because it means that from_parameter will see an
 # integer and pass the wrong value on platforms where int != void*. Work around
@@ -157,6 +211,7 @@
 assert isinstance(res, _CXString)
 return conf.lib.clang_getCString(res)
 
+
 class SourceLocation(Structure):
 """
 A SourceLocation represents a particular location within a source file.
@@ -596,7 +651,7 @@
 @staticmethod
 def get_all_kinds():
 """Return all CursorKind enumeration instances."""
-return filter(None, CursorKind._kinds)
+return [x for x in CursorKind._kinds if not x is None]
 
 def is_declaration(self):
 """Test if this is a declaration kind."""
@@ -2128,7 +2183,7 @@
 """
 Retrieve the offset of a field in the record.
 """
-return conf.lib.clang_Type_getOffsetOf(self, c_char_p(fieldname))
+return conf.lib.clang_Type_getOffsetOf(self, fieldname)
 
 def get_ref_qualifier(self):
 """
@@ -2239,7 +2294,7 @@
 def spelling(self):
 if self.__kindNumber in SpellingCache:
 return SpellingCache[self.__kindNumber]
-return conf.lib.clang_getCompletionChunkText(self.cs, self.key).spelling
+return conf.lib.clang_getCompletionChunkText(self.cs, self.key)
 
 # We do not use @CachedProperty here, as the manual implementation is
 # apparently still significantly faster. Please profile carefully if you
@@ -2345,7 +2400,7 @@
 return " | ".join([str(a) for a in self]) \
+ " || Priority: " + str(self.priority) \
+ " || Availability: " + str(self.availability) \
-   + " || Brief comment: " + str(self.briefComment.spelling)
+   + " || Brief comment: " + str(self.briefComment)
 
 availabilityKinds = {
 0: CompletionChunk.Kind("Available"),
@@ -2542,17 +2597,17 @@
 
 args_array = None
 if len(args) > 0:
-args_array = (c_char_p * len(args))(* args)
+args_array = (c_char_p * len(args))(*[b(x) for x in args])
 
 unsaved_array = None

r300832 - [index] Record class template specializations using a new 'SpecializationOf'

[Alex Lorenz via cfe-commits]

Author: arphaman
Date: Thu Apr 20 05:43:22 2017
New Revision: 300832

URL: http://llvm.org/viewvc/llvm-project?rev=300832&view=rev
Log:
[index] Record class template specializations using a new 'SpecializationOf'
relationship

rdar://31603531

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

Modified:
cfe/trunk/include/clang/Index/IndexSymbol.h
cfe/trunk/lib/Index/IndexDecl.cpp
cfe/trunk/lib/Index/IndexSymbol.cpp
cfe/trunk/lib/Index/IndexTypeSourceInfo.cpp
cfe/trunk/lib/Index/IndexingContext.cpp
cfe/trunk/lib/Index/IndexingContext.h
cfe/trunk/test/Index/Core/index-source.cpp

Modified: cfe/trunk/include/clang/Index/IndexSymbol.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Index/IndexSymbol.h?rev=300832&r1=300831&r2=300832&view=diff
==
--- cfe/trunk/include/clang/Index/IndexSymbol.h (original)
+++ cfe/trunk/include/clang/Index/IndexSymbol.h Thu Apr 20 05:43:22 2017
@@ -106,8 +106,9 @@ enum class SymbolRole : uint32_t {
   RelationAccessorOf  = 1 << 15,
   RelationContainedBy = 1 << 16,
   RelationIBTypeOf= 1 << 17,
+  RelationSpecializationOf = 1 << 18,
 };
-static const unsigned SymbolRoleBitNum = 18;
+static const unsigned SymbolRoleBitNum = 19;
 typedef unsigned SymbolRoleSet;
 
 /// Represents a relation to another symbol for a symbol occurrence.

Modified: cfe/trunk/lib/Index/IndexDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Index/IndexDecl.cpp?rev=300832&r1=300831&r2=300832&view=diff
==
--- cfe/trunk/lib/Index/IndexDecl.cpp (original)
+++ cfe/trunk/lib/Index/IndexDecl.cpp Thu Apr 20 05:43:22 2017
@@ -495,8 +495,18 @@ public:
ClassTemplateSpecializationDecl *D) 
{
 // FIXME: Notify subsequent callbacks if info comes from implicit
 // instantiation.
-if (D->isThisDeclarationADefinition())
-  IndexCtx.indexTagDecl(D);
+if (D->isThisDeclarationADefinition()) {
+  llvm::PointerUnion
+  Template = D->getSpecializedTemplateOrPartial();
+  const Decl *SpecializationOf =
+  Template.is()
+  ? (Decl *)Template.get()
+  : Template.get();
+  IndexCtx.indexTagDecl(
+  D, 
SymbolRelation(SymbolRoleSet(SymbolRole::RelationSpecializationOf),
+SpecializationOf));
+}
 return true;
   }
 

Modified: cfe/trunk/lib/Index/IndexSymbol.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Index/IndexSymbol.cpp?rev=300832&r1=300831&r2=300832&view=diff
==
--- cfe/trunk/lib/Index/IndexSymbol.cpp (original)
+++ cfe/trunk/lib/Index/IndexSymbol.cpp Thu Apr 20 05:43:22 2017
@@ -346,6 +346,7 @@ bool index::applyForEachSymbolRoleInterr
   APPLY_FOR_ROLE(RelationAccessorOf);
   APPLY_FOR_ROLE(RelationContainedBy);
   APPLY_FOR_ROLE(RelationIBTypeOf);
+  APPLY_FOR_ROLE(RelationSpecializationOf);
 
 #undef APPLY_FOR_ROLE
 
@@ -386,6 +387,7 @@ void index::printSymbolRoles(SymbolRoleS
 case SymbolRole::RelationAccessorOf: OS << "RelAcc"; break;
 case SymbolRole::RelationContainedBy: OS << "RelCont"; break;
 case SymbolRole::RelationIBTypeOf: OS << "RelIBType"; break;
+case SymbolRole::RelationSpecializationOf: OS << "RelSpecialization"; 
break;
 }
   });
 }

Modified: cfe/trunk/lib/Index/IndexTypeSourceInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Index/IndexTypeSourceInfo.cpp?rev=300832&r1=300831&r2=300832&view=diff
==
--- cfe/trunk/lib/Index/IndexTypeSourceInfo.cpp (original)
+++ cfe/trunk/lib/Index/IndexTypeSourceInfo.cpp Thu Apr 20 05:43:22 2017
@@ -208,11 +208,12 @@ void IndexingContext::indexNestedNameSpe
   }
 }
 
-void IndexingContext::indexTagDecl(const TagDecl *D) {
+void IndexingContext::indexTagDecl(const TagDecl *D,
+   ArrayRef Relations) {
   if (!shouldIndexFunctionLocalSymbols() && isFunctionLocalSymbol(D))
 return;
 
-  if (handleDecl(D)) {
+  if (handleDecl(D, /*Roles=*/SymbolRoleSet(), Relations)) {
 if (D->isThisDeclarationADefinition()) {
   indexNestedNameSpecifierLoc(D->getQualifierLoc(), D);
   if (auto CXXRD = dyn_cast(D)) {

Modified: cfe/trunk/lib/Index/IndexingContext.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Index/IndexingContext.cpp?rev=300832&r1=300831&r2=300832&view=diff
==
--- cfe/trunk/lib/Index/IndexingContext.cpp (original)
+++ cfe/trunk/lib/Index/IndexingContext.cpp Thu Apr 20 05:43:22 2017
@@ -233,6 +233,7 @@ static bool shouldReportOccurrenceForSys
   case SymbolRole::RelationReceivedBy:
   case SymbolRole::RelationCalledBy:
   case SymbolRole::RelationContainedBy:
+   

[PATCH] D32010: [indexer] Record class template specializations using a new 'SpecializationOf' relationship

[Alex Lorenz via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL300832: [index] Record class template specializations using 
a new 'SpecializationOf' (authored by arphaman).

Changed prior to commit:
  https://reviews.llvm.org/D32010?vs=95112&id=95927#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D32010

Files:
  cfe/trunk/include/clang/Index/IndexSymbol.h
  cfe/trunk/lib/Index/IndexDecl.cpp
  cfe/trunk/lib/Index/IndexSymbol.cpp
  cfe/trunk/lib/Index/IndexTypeSourceInfo.cpp
  cfe/trunk/lib/Index/IndexingContext.cpp
  cfe/trunk/lib/Index/IndexingContext.h
  cfe/trunk/test/Index/Core/index-source.cpp

Index: cfe/trunk/include/clang/Index/IndexSymbol.h
===
--- cfe/trunk/include/clang/Index/IndexSymbol.h
+++ cfe/trunk/include/clang/Index/IndexSymbol.h
@@ -106,8 +106,9 @@
   RelationAccessorOf  = 1 << 15,
   RelationContainedBy = 1 << 16,
   RelationIBTypeOf= 1 << 17,
+  RelationSpecializationOf = 1 << 18,
 };
-static const unsigned SymbolRoleBitNum = 18;
+static const unsigned SymbolRoleBitNum = 19;
 typedef unsigned SymbolRoleSet;
 
 /// Represents a relation to another symbol for a symbol occurrence.
Index: cfe/trunk/test/Index/Core/index-source.cpp
===
--- cfe/trunk/test/Index/Core/index-source.cpp
+++ cfe/trunk/test/Index/Core/index-source.cpp
@@ -50,6 +50,12 @@
   // CHECK-NEXT: RelChild | TemplCls | c:@ST>1#T@TemplCls
 };
 
+template<>
+class TemplCls {
+// CHECK: [[@LINE-1]]:7 | class(Gen,TS)/C++ | TemplCls | c:@S@TemplCls>#d |  | Def,RelSpecialization | rel: 1
+// CHECK: RelSpecialization | TemplCls | c:@ST>1#T@TemplCls
+};
+
 TemplCls gtv(0);
 // CHECK: [[@LINE-1]]:1 | class(Gen)/C++ | TemplCls | c:@ST>1#T@TemplCls |  | Ref,RelCont | rel: 1
 
@@ -91,3 +97,17 @@
 // CHECK: [[@LINE+2]]:5 | variable/C | gvf | c:@gvf | _gvf | Def | rel: 0
 // CHECK: [[@LINE+1]]:11 | variable(Gen)/C++ | tmplVar | c:index-source.cpp@VT>1#T@tmplVar | __ZL7tmplVar | Ref,Read,RelCont | rel: 1
 int gvf = tmplVar;
+
+template
+class PartialSpecilizationClass { };
+// CHECK: [[@LINE-1]]:7 | class(Gen)/C++ | PartialSpecilizationClass | c:@ST>2#T#T@PartialSpecilizationClass |  | Def | rel: 0
+
+template
+class PartialSpecilizationClass { };
+// CHECK: [[@LINE-1]]:7 | class(Gen,TPS)/C++ | PartialSpecilizationClass | c:@SP>1#T@PartialSpecilizationClass>#I#*t0.0 |  | Def,RelSpecialization | rel: 1
+// CHECK-NEXT: RelSpecialization | PartialSpecilizationClass | c:@ST>2#T#T@PartialSpecilizationClass
+
+template<>
+class PartialSpecilizationClass { };
+// CHECK: [[@LINE-1]]:7 | class(Gen,TS)/C++ | PartialSpecilizationClass | c:@S@PartialSpecilizationClass>#I#I |  | Def,RelSpecialization | rel: 1
+// CHECK-NEXT: RelSpecialization | PartialSpecilizationClass | c:@ST>2#T#T@PartialSpecilizationClass
Index: cfe/trunk/lib/Index/IndexingContext.h
===
--- cfe/trunk/lib/Index/IndexingContext.h
+++ cfe/trunk/lib/Index/IndexingContext.h
@@ -80,7 +80,8 @@
 
   bool indexDecl(const Decl *D);
 
-  void indexTagDecl(const TagDecl *D);
+  void indexTagDecl(const TagDecl *D,
+ArrayRef Relations = None);
 
   void indexTypeSourceInfo(TypeSourceInfo *TInfo, const NamedDecl *Parent,
const DeclContext *DC = nullptr,
Index: cfe/trunk/lib/Index/IndexDecl.cpp
===
--- cfe/trunk/lib/Index/IndexDecl.cpp
+++ cfe/trunk/lib/Index/IndexDecl.cpp
@@ -495,8 +495,18 @@
ClassTemplateSpecializationDecl *D) {
 // FIXME: Notify subsequent callbacks if info comes from implicit
 // instantiation.
-if (D->isThisDeclarationADefinition())
-  IndexCtx.indexTagDecl(D);
+if (D->isThisDeclarationADefinition()) {
+  llvm::PointerUnion
+  Template = D->getSpecializedTemplateOrPartial();
+  const Decl *SpecializationOf =
+  Template.is()
+  ? (Decl *)Template.get()
+  : Template.get();
+  IndexCtx.indexTagDecl(
+  D, SymbolRelation(SymbolRoleSet(SymbolRole::RelationSpecializationOf),
+SpecializationOf));
+}
 return true;
   }
 
Index: cfe/trunk/lib/Index/IndexSymbol.cpp
===
--- cfe/trunk/lib/Index/IndexSymbol.cpp
+++ cfe/trunk/lib/Index/IndexSymbol.cpp
@@ -346,6 +346,7 @@
   APPLY_FOR_ROLE(RelationAccessorOf);
   APPLY_FOR_ROLE(RelationContainedBy);
   APPLY_FOR_ROLE(RelationIBTypeOf);
+  APPLY_FOR_ROLE(RelationSpecializationOf);
 
 #undef APPLY_FOR_ROLE
 
@@ -386,6 +387,7 @@
 case SymbolRole::RelationAccessorOf: OS << "RelAcc"; break;
 case SymbolRole::RelationContainedBy: OS << "RelCont"; break;
 case SymbolRole::RelationIBTypeOf: OS << "RelIBType"; break;
+case SymbolRole::RelationSpecializationOf: OS << "RelSpe

[PATCH] D31650: [Analyzer] Detect when function pointer is freed

[Anders Rönnholm via Phabricator via cfe-commits]

AndersRonnholm updated this revision to Diff 95929.
AndersRonnholm added a comment.

Updated after comments


Repository:
  rL LLVM

https://reviews.llvm.org/D31650

Files:
  lib/StaticAnalyzer/Checkers/MallocChecker.cpp
  test/Analysis/malloc.c


Index: test/Analysis/malloc.c
===
--- test/Analysis/malloc.c
+++ test/Analysis/malloc.c
@@ -1774,6 +1774,16 @@
return ok; // no warning
 }
 
+void (*fnptr)(int);
+void freeIndirectFunctionPtr() {
+  void *p = (void *)fnptr;
+  free(p); // expected-warning {{Argument to free() is a function pointer}}
+}
+
+void freeFunctionPtr() {
+  free((void *)fnptr); // expected-warning {{Argument to free() is a function 
pointer}}
+}
+
 // 
 // False negatives.
 
Index: lib/StaticAnalyzer/Checkers/MallocChecker.cpp
===
--- lib/StaticAnalyzer/Checkers/MallocChecker.cpp
+++ lib/StaticAnalyzer/Checkers/MallocChecker.cpp
@@ -392,6 +392,9 @@
   void ReportUseZeroAllocated(CheckerContext &C, SourceRange Range,
   SymbolRef Sym) const;
 
+  void ReportFunctionPointerFree(CheckerContext &C, SVal ArgVal,
+ SourceRange Range, const Expr *FreeExpr) 
const;
+
   /// Find the location of the allocation for Sym on the path leading to the
   /// exploded node N.
   LeakInfo getAllocationSite(const ExplodedNode *N, SymbolRef Sym,
@@ -1516,6 +1519,11 @@
 }
   }
 
+  if (SymBase->getType()->isFunctionPointerType()) {
+ReportFunctionPointerFree(C, ArgVal, ArgExpr->getSourceRange(), 
ParentExpr);
+return nullptr;
+  }
+
   ReleasedAllocated = (RsBase != nullptr) && (RsBase->isAllocated() ||
   RsBase->isAllocatedOfSizeZero());
 
@@ -1976,6 +1984,42 @@
   }
 }
 
+void MallocChecker::ReportFunctionPointerFree(CheckerContext &C, SVal ArgVal,
+  SourceRange Range,
+  const Expr *FreeExpr) const {
+
+  if (!ChecksEnabled[CK_MallocChecker])
+return;
+
+  Optional CheckKind = getCheckIfTracked(C, 
FreeExpr);
+  if (!CheckKind.hasValue())
+return;
+
+  if (ExplodedNode *N = C.generateErrorNode()) {
+if (!BT_BadFree[*CheckKind])
+  BT_BadFree[*CheckKind].reset(
+  new BugType(CheckNames[*CheckKind], "Bad free", "Memory Error"));
+
+SmallString<100> Buf;
+llvm::raw_svector_ostream Os(Buf);
+
+const MemRegion *MR = ArgVal.getAsRegion();
+while (const ElementRegion *ER = dyn_cast_or_null(MR))
+  MR = ER->getSuperRegion();
+
+Os << "Argument to ";
+if (!printAllocDeallocName(Os, C, FreeExpr))
+  Os << "deallocator";
+
+Os << " is a function pointer";
+
+auto R = llvm::make_unique(*BT_BadFree[*CheckKind], Os.str(), 
N);
+R->markInteresting(MR);
+R->addRange(Range);
+C.emitReport(std::move(R));
+  }
+}
+
 ProgramStateRef MallocChecker::ReallocMem(CheckerContext &C,
   const CallExpr *CE,
   bool FreesOnFail,


Index: test/Analysis/malloc.c
===
--- test/Analysis/malloc.c
+++ test/Analysis/malloc.c
@@ -1774,6 +1774,16 @@
return ok; // no warning
 }
 
+void (*fnptr)(int);
+void freeIndirectFunctionPtr() {
+  void *p = (void *)fnptr;
+  free(p); // expected-warning {{Argument to free() is a function pointer}}
+}
+
+void freeFunctionPtr() {
+  free((void *)fnptr); // expected-warning {{Argument to free() is a function pointer}}
+}
+
 // 
 // False negatives.
 
Index: lib/StaticAnalyzer/Checkers/MallocChecker.cpp
===
--- lib/StaticAnalyzer/Checkers/MallocChecker.cpp
+++ lib/StaticAnalyzer/Checkers/MallocChecker.cpp
@@ -392,6 +392,9 @@
   void ReportUseZeroAllocated(CheckerContext &C, SourceRange Range,
   SymbolRef Sym) const;
 
+  void ReportFunctionPointerFree(CheckerContext &C, SVal ArgVal,
+ SourceRange Range, const Expr *FreeExpr) const;
+
   /// Find the location of the allocation for Sym on the path leading to the
   /// exploded node N.
   LeakInfo getAllocationSite(const ExplodedNode *N, SymbolRef Sym,
@@ -1516,6 +1519,11 @@
 }
   }
 
+  if (SymBase->getType()->isFunctionPointerType()) {
+ReportFunctionPointerFree(C, ArgVal, ArgExpr->getSourceRange(), ParentExpr);
+return nullptr;
+  }
+
   ReleasedAllocated = (RsBase != nullptr) && (RsBase->isAllocated() ||
   RsBase->isAllocatedOfSizeZero());
 
@@ -1976,6 +1984,42 @@
   }
 }
 
+void MallocChecker::ReportFunctionPointerFree(CheckerContext &C, SVal ArgVal,
+ 

[PATCH] D31709: [NFC] Refactor DiagnosticRenderer to use FullSourceLoc

[Diana Picus via Phabricator via cfe-commits]

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

I don't see anything wrong with this, I think you can commit it in a couple of 
days if nobody comes up with a reason why the DiagnosticRenderer shouldn't use 
FullSourceLoc.


https://reviews.llvm.org/D31709



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

[PATCH] D32020: [indexer] The relationship between the declarations in template specializations that 'override' declarations in the base template should be recorded

[Alex Lorenz via Phabricator via cfe-commits]

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

Updated the relationship to be 'overrideOf | specializationOf' to differentiate 
it from regular 'overrideOf'.


Repository:
  rL LLVM

https://reviews.llvm.org/D32020

Files:
  lib/Index/IndexDecl.cpp
  lib/Index/IndexingContext.cpp
  lib/Index/IndexingContext.h
  test/Index/Core/index-source.cpp

Index: test/Index/Core/index-source.cpp
===
--- test/Index/Core/index-source.cpp
+++ test/Index/Core/index-source.cpp
@@ -111,3 +111,112 @@
 class PartialSpecilizationClass { };
 // CHECK: [[@LINE-1]]:7 | class(Gen,TS)/C++ | PartialSpecilizationClass | c:@S@PartialSpecilizationClass>#I#I |  | Def,RelSpecialization | rel: 1
 // CHECK-NEXT: RelSpecialization | PartialSpecilizationClass | c:@ST>2#T#T@PartialSpecilizationClass
+
+template
+class PseudoOverridesInSpecializations {
+  void function() { }
+  void function(int) { }
+
+  static void staticFunction() { }
+
+  int field;
+  static int variable;
+
+  typedef T TypeDef;
+  using TypeAlias = T;
+
+  enum anEnum { };
+
+  struct Struct { };
+  union Union { };
+
+  using TypealiasOrRecord = void;
+
+  template struct InnerTemplate { };
+  template struct InnerTemplate  { };
+};
+
+template<>
+class PseudoOverridesInSpecializations {
+  void function() { }
+// CHECK: [[@LINE-1]]:8 | instance-method/C++ | function | c:@S@PseudoOverridesInSpecializations>#d#I@F@function# | __ZN32PseudoOverridesInSpecializationsIdiE8functionEv | Def,RelChild,RelOver,RelSpecialization | rel: 2
+// CHECK-NEXT: RelChild
+// CHECK-NEXT: RelOver,RelSpecialization | function | c:@ST>2#T#T@PseudoOverridesInSpecializations@F@function#
+
+  void staticFunction() { }
+// CHECK: [[@LINE-1]]:8 | instance-method/C++ | staticFunction | c:@S@PseudoOverridesInSpecializations>#d#I@F@staticFunction# | __ZN32PseudoOverridesInSpecializationsIdiE14staticFunctionEv | Def,RelChild | rel: 1
+// CHECK-NOT: RelOver
+
+  int notOverridingField = 0;
+
+// CHECK-LABEL: checLabelBreak
+  int checLabelBreak = 0;
+
+  int field = 0;
+// CHECK: [[@LINE-1]]:7 | field/C++ | field | c:@S@PseudoOverridesInSpecializations>#d#I@FI@field |  | Def,RelChild,RelOver,RelSpecialization | rel: 2
+// CHECK-NEXT: RelChild
+// CHECK-NEXT: RelOver,RelSpecialization | field | c:@ST>2#T#T@PseudoOverridesInSpecializations@FI@field
+
+  static double variable;
+// CHECK: [[@LINE-1]]:17 | static-property/C++ | variable | c:@S@PseudoOverridesInSpecializations>#d#I@variable | __ZN32PseudoOverridesInSpecializationsIdiE8variableE | Decl,RelChild,RelOver,RelSpecialization | rel: 2
+// CHECK-NEXT: RelChild
+// CHECK-NEXT: RelOver,RelSpecialization | variable | c:@ST>2#T#T@PseudoOverridesInSpecializations@variable
+
+  typedef double TypeDef;
+// CHECK: [[@LINE-1]]:18 | type-alias/C | TypeDef | c:index-source.cpp@S@PseudoOverridesInSpecializations>#d#I@T@TypeDef |  | Def,RelChild,RelOver,RelSpecialization | rel: 2
+// CHECK-NEXT: RelChild
+// CHECK-NEXT: RelOver,RelSpecialization | TypeDef | c:index-source.cpp@ST>2#T#T@PseudoOverridesInSpecializations@T@TypeDef
+
+  using TypeAlias = int;
+// CHECK: [[@LINE-1]]:9 | type-alias/C++ | TypeAlias | c:@S@PseudoOverridesInSpecializations>#d#I@TypeAlias |  | Def,RelChild,RelOver,RelSpecialization | rel: 2
+// CHECK-NEXT: RelChild
+// CHECK-NEXT: RelOver,RelSpecialization | TypeAlias | c:@ST>2#T#T@PseudoOverridesInSpecializations@TypeAlias
+
+  enum anEnum { };
+// CHECK: [[@LINE-1]]:8 | enum/C | anEnum | c:@S@PseudoOverridesInSpecializations>#d#I@E@anEnum |  | Def,RelChild,RelOver,RelSpecialization | rel: 2
+// CHECK-NEXT: RelChild
+// CHECK-NEXT: RelOver,RelSpecialization | anEnum | c:@ST>2#T#T@PseudoOverridesInSpecializations@E@anEnum
+  class Struct { };
+// CHECK: [[@LINE-1]]:9 | class/C++ | Struct | c:@S@PseudoOverridesInSpecializations>#d#I@S@Struct |  | Def,RelChild,RelOver,RelSpecialization | rel: 2
+// CHECK-NEXT: RelChild
+// CHECK-NEXT: RelOver,RelSpecialization | Struct | c:@ST>2#T#T@PseudoOverridesInSpecializations@S@Struct
+  union Union { };
+// CHECK: [[@LINE-1]]:9 | union/C | Union | c:@S@PseudoOverridesInSpecializations>#d#I@U@Union |  | Def,RelChild,RelOver,RelSpecialization | rel: 2
+// CHECK-NEXT: RelChild
+// CHECK-NEXT: RelOver,RelSpecialization | Union | c:@ST>2#T#T@PseudoOverridesInSpecializations@U@Union
+
+  struct TypealiasOrRecord { };
+// CHECK: [[@LINE-1]]:10 | struct/C | TypealiasOrRecord | c:@S@PseudoOverridesInSpecializations>#d#I@S@TypealiasOrRecord |  | Def,RelChild,RelOver,RelSpecialization | rel: 2
+// CHECK-NEXT: RelChild
+// CHECK-NEXT: RelOver,RelSpecialization | TypealiasOrRecord | c:@ST>2#T#T@PseudoOverridesInSpecializations@TypealiasOrRecord
+
+  template struct InnerTemplate { };
+// CHECK: [[@LINE-1]]:31 | struct(Gen)/C++ | InnerTemplate | c:@S@PseudoOverridesInSpecializations>#d#I@ST>1#T@InnerTemplate |  | Def,RelChild,RelOver,RelSpecialization | rel: 2
+// CHECK-NEXT: RelChild
+// CHECK-NEXT: RelOver,RelSpecialization

[PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

[Hal Finkel via Phabricator via cfe-commits]

hfinkel added a comment.

In https://reviews.llvm.org/D32199#731472, @rsmith wrote:

> > As I've currently implemented it, both reads and writes set the type of 
> > previously-unknown storage, and after that it says fixed (unless you memcpy 
> > to it, memset it, or its lifetime ends (the type gets reset on 
> > lifetime.start/end and for malloc/allocas/etc.). There's a flag to enable 
> > the "writes always set the type" rule, but that's not the default. Is this 
> > too strict?
>
> That seems like it will have at least three flavors of false positive:
>
> 1. C's "effective type" rule allows writes to set the type pretty much 
> unconditionally, unless the storage is for a variable with a declared type
> 2. After a placement new in C++, you should be able to use the storage as a 
> new type
> 3. Storing directly to a member access on a union (ie, with the syntax `x.a = 
> b`) in C++ permits using the storage as the new type
>
>   If we want to follow the relevant language rules by default, that would 
> suggest that "writes always set the type" should be enabled by default in C 
> and disabled by default in C++. That may not be the right decision for other 
> reasons, though. In C++, writes through union members and new-expressions 
> should probably (re)set the type


Fair enough. For now we'll default to write-sets-the-type as the default. We 
can always add 'sticky' types later to correspond to types set by declaration.

> (do you have intrinsics the frontend can use to do so?).

I had thought that we could just use a lifetime.end/start pair to mark the 
placement new, etc. However, it might be better to use some dedicated intrinsic 
for this purpose?


https://reviews.llvm.org/D32199



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

[PATCH] D31972: Do not force the frame pointer by default for ARM EABI

[Christian Bruel via Phabricator via cfe-commits]

chrib updated this revision to Diff 95945.
chrib added a comment.



1. Updating https://reviews.llvm.org/D31972: Do not force the frame pointer by 
default for ARM EABI #

Add test case


https://reviews.llvm.org/D31972

Files:
  lib/Driver/ToolChains/Clang.cpp
  test/CodeGen/arm-fp-eabi.c


Index: test/CodeGen/arm-fp-eabi.c
===
--- /dev/null
+++ test/CodeGen/arm-fp-eabi.c
@@ -0,0 +1,13 @@
+// RUN: %clang %s -target arm-none-eabi -O2 -S -o nofp.s
+// RUN: grep -v '.setfp' nofp.s
+// RUN: %clang %s -target arm-none-eabi -fno-omit-frame-pointer -O2 -S -o fp.s
+// RUN: grep '.setfp' fp.s
+
+void
+foo(void);
+
+int main()
+{
+  foo();
+  return 0;
+}
Index: lib/Driver/ToolChains/Clang.cpp
===
--- lib/Driver/ToolChains/Clang.cpp
+++ lib/Driver/ToolChains/Clang.cpp
@@ -566,6 +566,17 @@
 }
   }
 
+  if (Triple.getEnvironment() == llvm::Triple::EABI) {
+switch (Triple.getArch()) {
+case llvm::Triple::arm:
+case llvm::Triple::thumb:
+  // ARM EABI doesn't require a frame pointer
+  return !areOptimizationsEnabled(Args);
+default:
+  return true;
+}
+  }
+
   return true;
 }
 


Index: test/CodeGen/arm-fp-eabi.c
===
--- /dev/null
+++ test/CodeGen/arm-fp-eabi.c
@@ -0,0 +1,13 @@
+// RUN: %clang %s -target arm-none-eabi -O2 -S -o nofp.s
+// RUN: grep -v '.setfp' nofp.s
+// RUN: %clang %s -target arm-none-eabi -fno-omit-frame-pointer -O2 -S -o fp.s
+// RUN: grep '.setfp' fp.s
+
+void
+foo(void);
+
+int main()
+{
+  foo();
+  return 0;
+}
Index: lib/Driver/ToolChains/Clang.cpp
===
--- lib/Driver/ToolChains/Clang.cpp
+++ lib/Driver/ToolChains/Clang.cpp
@@ -566,6 +566,17 @@
 }
   }
 
+  if (Triple.getEnvironment() == llvm::Triple::EABI) {
+switch (Triple.getArch()) {
+case llvm::Triple::arm:
+case llvm::Triple::thumb:
+  // ARM EABI doesn't require a frame pointer
+  return !areOptimizationsEnabled(Args);
+default:
+  return true;
+}
+  }
+
   return true;
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D32291: [analyzer] Implement handling array subscript into null pointer, improve null dereference checks for array subscripts

[Artem Dergachev via Phabricator via cfe-commits]

NoQ created this revision.

When encountering an array-to-pointer-decay and the array base is null (or any 
other concrete pointer value) (eg. it's a member array in a structure, and the 
structure pointer is null; of course it wouldn't happen to stack-based or 
global arrays), do not yield UnknownVal; instead, yield that concrete value.

While obvious, this change now triggers false positives because our suppression 
for inlined defensive checks was not prepared for dealing with array subscripts 
(the `idcTrackZeroValueThroughUnaryPointerOperatorsWithArrayField` test in 
`inlining/inline-defensive-checks.cpp` starts failing). So i additionally 
improve the suppression.

As discussed in https://reviews.llvm.org/D31982, which added the aforementioned 
test case, `bugreporter::getDerefExpr()` should have been used (we only used to 
match member expressions earlier, but now that we encountered arrays, we could 
use all the features it function can offer). Now that the code uses that 
function, and a few issues within that function were further fixed in order to 
support the new use case and avoid regressions.


https://reviews.llvm.org/D32291

Files:
  lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
  lib/StaticAnalyzer/Core/RegionStore.cpp
  test/Analysis/null-deref-offsets.c


Index: test/Analysis/null-deref-offsets.c
===
--- test/Analysis/null-deref-offsets.c
+++ test/Analysis/null-deref-offsets.c
@@ -7,7 +7,7 @@
   int z[2];
 };
 
-void testOffsets(struct S *s) {
+void testOffsets(struct S *s, int coin) {
   if (s != 0)
 return;
 
@@ -21,14 +21,17 @@
 
   // FIXME: These should ideally be true.
   clang_analyzer_eval(&(s->y) == 4); // expected-warning{{FALSE}}
-  clang_analyzer_eval(&(s->z[0]) == 8); // expected-warning{{UNKNOWN}}
-  clang_analyzer_eval(&(s->z[1]) == 12); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(&(s->z[0]) == 8); // expected-warning{{FALSE}}
+  clang_analyzer_eval(&(s->z[1]) == 12); // expected-warning{{FALSE}}
 
   // FIXME: These should ideally be false.
   clang_analyzer_eval(&(s->y) == 0); // expected-warning{{TRUE}}
-  clang_analyzer_eval(&(s->z[0]) == 0); // expected-warning{{UNKNOWN}}
-  clang_analyzer_eval(&(s->z[1]) == 0); // expected-warning{{UNKNOWN}}
-
-  // But this should still be a null dereference.
-  s->y = 5; // expected-warning{{Access to field 'y' results in a dereference 
of a null pointer (loaded from variable 's')}}
+  clang_analyzer_eval(&(s->z[0]) == 0); // expected-warning{{TRUE}}
+  clang_analyzer_eval(&(s->z[1]) == 0); // expected-warning{{TRUE}}
+
+  // But these should still be reported as null dereferences.
+  if (coin)
+s->y = 5; // expected-warning{{Access to field 'y' results in a 
dereference of a null pointer (loaded from variable 's')}}
+  else
+s->z[1] = 6; // expected-warning{{Array access (via field 'z') results in 
a null pointer dereference}}
 }
Index: lib/StaticAnalyzer/Core/RegionStore.cpp
===
--- lib/StaticAnalyzer/Core/RegionStore.cpp
+++ lib/StaticAnalyzer/Core/RegionStore.cpp
@@ -1338,6 +1338,9 @@
 ///  the array).  This is called by ExprEngine when evaluating casts
 ///  from arrays to pointers.
 SVal RegionStoreManager::ArrayToPointer(Loc Array, QualType T) {
+  if (Array.getAs())
+return Array;
+
   if (!Array.getAs())
 return UnknownVal();
 
Index: lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
===
--- lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
+++ lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
@@ -61,7 +61,9 @@
 return U->getSubExpr()->IgnoreParenCasts();
 }
 else if (const MemberExpr *ME = dyn_cast(E)) {
-  if (ME->isArrow() || isDeclRefExprToReference(ME->getBase())) {
+  if (ME->isImplicitAccess()) {
+return ME;
+  } else if (ME->isArrow() || isDeclRefExprToReference(ME->getBase())) {
 return ME->getBase()->IgnoreParenCasts();
   } else {
 // If we have a member expr with a dot, the base must have been
@@ -73,9 +75,9 @@
   return IvarRef->getBase()->IgnoreParenCasts();
 }
 else if (const ArraySubscriptExpr *AE = dyn_cast(E)) {
-  return AE->getBase();
+  return getDerefExpr(AE->getBase());
 }
-else if (isDeclRefExprToReference(E)) {
+else if (isa(E)) {
   return E;
 }
 break;
@@ -974,14 +976,11 @@
 // This code interacts heavily with this hack; otherwise the value
 // would not be null at all for most fields, so we'd be unable to track it.
 if (const auto *Op = dyn_cast(Ex))
-  if (Op->getOpcode() == UO_AddrOf && Op->getSubExpr()->isLValue()) {
-Ex = Op->getSubExpr()->IgnoreParenCasts();
-while (const auto *ME = dyn_cast(Ex)) {
-  Ex = ME->getBase()->IgnoreParenCasts();
-}
-  }
+  if (Op->getOpcode() == UO_AddrOf && Op->getSubExpr()->isLValue())
+  

[PATCH] D31982: [analyzer] Improve suppression for inlined defensive checks when operator& is involved.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added inline comments.



Comment at: lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:977
+  Ex = Op->getSubExpr()->IgnoreParenCasts();
+  while (true) {
+if (const auto *ME = dyn_cast(Ex)) {

zaks.anna wrote:
> Why do we need the "while (true)"? Can we just use "dyn_cast(Ex)" 
> as the loop condition?
> 
> Take a look at the getDerefExpr(const Stmt *S) and see if that would be a 
> better place to add this code. Maybe not..
> 
Accidentally clicked "Done" and forgot about the `getDerefExpr()` part.

I put it into a follow-up patch though: D32291, because it's quite a cascade of 
changes already.


https://reviews.llvm.org/D31982



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

[PATCH] D31982: [analyzer] Improve suppression for inlined defensive checks when operator& is involved.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added inline comments.



Comment at: lib/StaticAnalyzer/Core/Store.cpp:440
   //  well, although in reality we should return the offset added to that
-  //  value.
+  //  value. See also the similar FIXME in getLValueFieldOrIvar().
   if (Base.isUnknownOrUndef() || Base.getAs())

NoQ wrote:
> Note that this code doesn't really trigger; we return `UnknownVal()` 
> somewhere above, as shown on the newly added tests. I suspect we may be 
> missing valid null dereferences because of that; will have a look.
This is also addressed by  D32291.


https://reviews.llvm.org/D31982



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

r300841 - Delete unused IncompleteFormat variable, NFCi.

[Krasimir Georgiev via cfe-commits]

Author: krasimir
Date: Thu Apr 20 08:37:27 2017
New Revision: 300841

URL: http://llvm.org/viewvc/llvm-project?rev=300841&view=rev
Log:
Delete unused IncompleteFormat variable, NFCi.

Modified:
cfe/trunk/lib/Index/CommentToXML.cpp

Modified: cfe/trunk/lib/Index/CommentToXML.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Index/CommentToXML.cpp?rev=300841&r1=300840&r2=300841&view=diff
==
--- cfe/trunk/lib/Index/CommentToXML.cpp (original)
+++ cfe/trunk/lib/Index/CommentToXML.cpp Thu Apr 20 08:37:27 2017
@@ -592,12 +592,10 @@ void CommentASTToXMLConverter::formatTex
   unsigned Offset = 0;
   unsigned Length = Declaration.size();
 
-  bool IncompleteFormat = false;
   format::FormatStyle Style = format::getLLVMStyle();
   Style.FixNamespaceComments = false;
   tooling::Replacements Replaces =
-  reformat(Style, StringDecl, tooling::Range(Offset, Length), "xmldecl.xd",
-   &IncompleteFormat);
+  reformat(Style, StringDecl, tooling::Range(Offset, Length), 
"xmldecl.xd");
   auto FormattedStringDecl = applyAllReplacements(StringDecl, Replaces);
   if (static_cast(FormattedStringDecl)) {
 Declaration = *FormattedStringDecl;


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

[PATCH] D32294: [clang-tidy] run-clang-tidy.py: check if clang-apply-replacements succeeds

[Jakub Kuderski via Phabricator via cfe-commits]

kuhar created this revision.
kuhar added a project: clang-tools-extra.

When running run-clang-tidy.py with -fix it tries to apply found replacements 
at the end.
If there are errors running clang-apply-replacements, the script currently 
crashes or displays no error at all.

This patch checks for errors running clang-apply-replacements the same way 
clang-tidy binary is handled.

Another option would be probably checking for clang-apply-replacements (when 
-fix is passed) even before running clang-tidy.


https://reviews.llvm.org/D32294

Files:
  clang-tidy/tool/run-clang-tidy.py


Index: clang-tidy/tool/run-clang-tidy.py
===
--- clang-tidy/tool/run-clang-tidy.py
+++ clang-tidy/tool/run-clang-tidy.py
@@ -89,12 +89,16 @@
 
 def apply_fixes(args, tmpdir):
   """Calls clang-apply-fixes on a given directory. Deletes the dir when 
done."""
-  invocation = [args.clang_apply_replacements_binary]
-  if args.format:
-invocation.append('-format')
-  invocation.append(tmpdir)
-  subprocess.call(invocation)
-  shutil.rmtree(tmpdir)
+  try:
+invocation = [args.clang_apply_replacements_binary]
+if args.format:
+  invocation.append('-format')
+invocation.append(tmpdir)
+subprocess.call(invocation)
+shutil.rmtree(tmpdir)
+  except:
+print >>sys.stderr, "Unable to run clang-apply-replacements."
+sys.exit(1)
 
 
 def run_tidy(args, tmpdir, build_path, queue):


Index: clang-tidy/tool/run-clang-tidy.py
===
--- clang-tidy/tool/run-clang-tidy.py
+++ clang-tidy/tool/run-clang-tidy.py
@@ -89,12 +89,16 @@
 
 def apply_fixes(args, tmpdir):
   """Calls clang-apply-fixes on a given directory. Deletes the dir when done."""
-  invocation = [args.clang_apply_replacements_binary]
-  if args.format:
-invocation.append('-format')
-  invocation.append(tmpdir)
-  subprocess.call(invocation)
-  shutil.rmtree(tmpdir)
+  try:
+invocation = [args.clang_apply_replacements_binary]
+if args.format:
+  invocation.append('-format')
+invocation.append(tmpdir)
+subprocess.call(invocation)
+shutil.rmtree(tmpdir)
+  except:
+print >>sys.stderr, "Unable to run clang-apply-replacements."
+sys.exit(1)
 
 
 def run_tidy(args, tmpdir, build_path, queue):
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D31709: [NFC] Refactor DiagnosticRenderer to use FullSourceLoc

[Sanne Wouda via Phabricator via cfe-commits]

sanwou01 added a comment.

Hi Diana,

Thanks! Will do :)

Sanne


https://reviews.llvm.org/D31709



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

[PATCH] D31972: Do not force the frame pointer by default for ARM EABI

[Christian Bruel via Phabricator via cfe-commits]

chrib updated this revision to Diff 95958.
chrib added a comment.

- Fix thinko in test


https://reviews.llvm.org/D31972

Files:
  lib/Driver/ToolChains/Clang.cpp
  test/CodeGen/arm-fp-eabi.c


Index: test/CodeGen/arm-fp-eabi.c
===
--- /dev/null
+++ test/CodeGen/arm-fp-eabi.c
@@ -0,0 +1,13 @@
+// RUN: %clang %s -target arm-none-eabi -O2 -S -o nofp.s
+// RUN: not grep '.setfp' nofp.s
+// RUN: %clang %s -target arm-none-eabi -fno-omit-frame-pointer -O2 -S -o fp.s
+// RUN: grep '.setfp' fp.s
+
+void
+foo(void);
+
+int main()
+{
+  foo();
+  return 0;
+}
Index: lib/Driver/ToolChains/Clang.cpp
===
--- lib/Driver/ToolChains/Clang.cpp
+++ lib/Driver/ToolChains/Clang.cpp
@@ -566,6 +566,17 @@
 }
   }
 
+  if (Triple.getEnvironment() == llvm::Triple::EABI) {
+switch (Triple.getArch()) {
+case llvm::Triple::arm:
+case llvm::Triple::thumb:
+  // ARM EABI doesn't require a frame pointer
+  return !areOptimizationsEnabled(Args);
+default:
+  return true;
+}
+  }
+
   return true;
 }
 


Index: test/CodeGen/arm-fp-eabi.c
===
--- /dev/null
+++ test/CodeGen/arm-fp-eabi.c
@@ -0,0 +1,13 @@
+// RUN: %clang %s -target arm-none-eabi -O2 -S -o nofp.s
+// RUN: not grep '.setfp' nofp.s
+// RUN: %clang %s -target arm-none-eabi -fno-omit-frame-pointer -O2 -S -o fp.s
+// RUN: grep '.setfp' fp.s
+
+void
+foo(void);
+
+int main()
+{
+  foo();
+  return 0;
+}
Index: lib/Driver/ToolChains/Clang.cpp
===
--- lib/Driver/ToolChains/Clang.cpp
+++ lib/Driver/ToolChains/Clang.cpp
@@ -566,6 +566,17 @@
 }
   }
 
+  if (Triple.getEnvironment() == llvm::Triple::EABI) {
+switch (Triple.getArch()) {
+case llvm::Triple::arm:
+case llvm::Triple::thumb:
+  // ARM EABI doesn't require a frame pointer
+  return !areOptimizationsEnabled(Args);
+default:
+  return true;
+}
+  }
+
   return true;
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

[Hal Finkel via Phabricator via cfe-commits]

hfinkel added a comment.

In https://reviews.llvm.org/D32199#731472, @rsmith wrote:

> > As I've currently implemented it, both reads and writes set the type of 
> > previously-unknown storage, and after that it says fixed (unless you memcpy 
> > to it, memset it, or its lifetime ends (the type gets reset on 
> > lifetime.start/end and for malloc/allocas/etc.). There's a flag to enable 
> > the "writes always set the type" rule, but that's not the default. Is this 
> > too strict?
>
> That seems like it will have at least three flavors of false positive:
>
> 1. C's "effective type" rule allows writes to set the type pretty much 
> unconditionally, unless the storage is for a variable with a declared type


To come back to this point: We don't really implement these rules now, and it 
is not clear that we will. The problem here is that, if we take the 
specification literally, then we can't use our current TBAA at all. The problem 
is that if we have:

  write x, !tbaa "int"
  read x, !tbaa "int"
  write x, !tbaa "float"

TBAA will currently tell us that the "float" write aliases with neither the 
preceding read nor the preceding write. As a result, we might move the "float" 
write to before the read (which is wrong) or before the write (also wrong). It 
seems to me that following the effective-type rules strictly will require that 
we only emit TBAA for memory accesses we can prove are to declared variables 
(as these are the only ones whose types don't get changed just by writing to 
them). We could certainly do that (*), although it is going to make TBAA 
awfully limited. As @dberlin has asserted, GCC does not implement these rules 
either.

To be fair, there are inferences we might draw from TBAA on all access that are 
not incorrect. For example, if we have:

  write x, !tbaa "int"
  write y, !tbaa "float"
  read x, !tbaa "int"

and we can indeed conclude that the write to y and the read from x don't alias 
(because the write happens before the read). This is because the effective type 
of y must be float after the write and so we know that the read from x must be 
accessing a different object. We can also conclude that the writes don't alias, 
but only because of the later read. The sad part is that if we use this 
information to reorder the read before the write to y (which we might do to 
eliminate the read), we now lose our ability to use TBAA to tell us anything.

Also, a strict reading of C's access rules seems to rule out the premise 
underlying our struct-path TBAA entirely. So long as I'm accessing a value 
using a struct that has some member, including recursively, with that type, 
then it's fine. The matching of the relative offsets is a sufficient, but not 
necessary, condition for well-defined access. C++ has essentially the same 
language (and, thus, potentially the same problem).

While I'd like the sanitizer to follow the rules, that's really useful only to 
the extent that the compilers follow the rules. If the compilers are making 
stronger assumptions, then I think that the sanitizer should also. OTOH, maybe 
we should change our TBAA representation/implementation to actually follow the 
rules, and then have a sanitizer that does the same.

(*) The best way I can think of to do this is to tag globals and allocas with 
tbaa according to their declared type, something similar for function 
arguments, and then in TBAA, instead of comparing the TBAA metadata of both 
operands directly, we call getUnderlyingObjects on the pointers, get the 
corresponding most-generic TBAA from the objects themselves, and then compare 
that TBAA to the TBAA from the other access.

> 2. After a placement new in C++, you should be able to use the storage as a 
> new type
> 3. Storing directly to a member access on a union (ie, with the syntax `x.a = 
> b`) in C++ permits using the storage as the new type

Yes, although for the sake of discussion, this is only true if a is a 
"non-class, non-array type, or of a class type with a trivial default 
constructor that is not
deleted, or an array of such types." That seems potentially useful.

> If we want to follow the relevant language rules by default, that would 
> suggest that "writes always set the type" should be enabled by default in C 
> and disabled by default in C++. That may not be the right decision for other 
> reasons, though. In C++, writes through union members and new-expressions 
> should probably (re)set the type (do you have intrinsics the frontend can use 
> to do so?).

Also, in C, memcpy gets to copy the type for a destination that does not have 
declared types. It looks like the same is true for C++ for trivially-copyable 
types. Is the first read/write sets the unknown type (i.e. memory from 
malloc/calloc/memset, etc.) correct for C++ also? I recall discussing something 
along these lines in Kona.


https://reviews.llvm.org/D32199



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://

[PATCH] D32294: [clang-tidy] run-clang-tidy.py: check if clang-apply-replacements succeeds

[Alexander Kornienko via Phabricator via cfe-commits]

alexfh requested changes to this revision.
alexfh added inline comments.
This revision now requires changes to proceed.



Comment at: clang-tidy/tool/run-clang-tidy.py:99-101
+  except:
+print >>sys.stderr, "Unable to run clang-apply-replacements."
+sys.exit(1)

I'd place try/except in main around the call to apply_fixes() and also move 
`shutil.rmtree(tmpdir)` out of the `apply_fixes()` function.



Comment at: clang-tidy/tool/run-clang-tidy.py:100
+  except:
+print >>sys.stderr, "Unable to run clang-apply-replacements."
+sys.exit(1)

"Unable to run clang-apply-replacements" without any details seems to be far 
worse than just a default stack trace from an unhandled exception. At the very 
least add the message from the exception.


https://reviews.llvm.org/D32294



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

[PATCH] D24892: [clang-tidy] Add option "LiteralInitializers" to cppcoreguidelines-pro-type-member-init

[Alexander Kornienko via Phabricator via cfe-commits]

alexfh added a comment.

In https://reviews.llvm.org/D24892#723536, @malcolm.parsons wrote:

> The `modernize-use-default-member-init` check now has an option with the same 
> effect, but it is called `UseAssignment`.
>  We should use consistent option names.
>  Is there any way for multiple checks to share an option?


There's OptionsView::getLocalOrGlobal. See how StrictMode option is read in 
ArgumentCommentCheck, for example.


https://reviews.llvm.org/D24892



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

[PATCH] D32294: [clang-tidy] run-clang-tidy.py: check if clang-apply-replacements succeeds

[Kim Gräsman via Phabricator via cfe-commits]

kimgr added a comment.

Python 3 concern inline




Comment at: clang-tidy/tool/run-clang-tidy.py:100
+  except:
+print >>sys.stderr, "Unable to run clang-apply-replacements."
+sys.exit(1)

alexfh wrote:
> "Unable to run clang-apply-replacements" without any details seems to be far 
> worse than just a default stack trace from an unhandled exception. At the 
> very least add the message from the exception.
I don't know what the general Python3 ambitions of this script is, but it would 
be nice if the new code didn't use the Python2-only print style.

You can:

from __future__ import print_function

at the top of the file, and then use Python3-style print:

print("Unable to run clang-apply-replacements", file=sys.stderr)


https://reviews.llvm.org/D32294



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

[PATCH] D32248: CodeGen: Cast alloca to expected address space

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added inline comments.



Comment at: lib/CodeGen/CGDecl.cpp:1105-1119
+  // Alloca always returns a pointer in alloca address space, which may
+  // be different from the type defined by the language. For example,
+  // in C++ the auto variables are in the default address space. Therefore
+  // cast alloca to the expected address space when necessary.
+  auto Addr = address.getPointer();
+  auto AddrTy = cast(Addr->getType());
+  auto ExpectedAddrSpace = 
CGM.getTypes().getVariableType(D)->getAddressSpace();

yaxunl wrote:
> t-tye wrote:
> > Is any assert done to ensure that it is legal to address space cast from 
> > variable address space to expected address space? Presumably the language, 
> > by definition, will only be causing legal casts. For example from alloca 
> > address space to generic (which includes the alloca address space).
> > 
> > For OpenCL, can you explain how the local variable can have the constant 
> > address space and use an alloca for allocation? Wouldn't a constant address 
> > space mean it was static and so should not be using alloca? And if it is 
> > using an alloca, how can it then be accessed as if it was in constant 
> > address space?
> If the auto var has address space qualifier specified through 
> `__attribute__((address_space(n)))`, there is not much we can check in clang 
> since it is target dependent. We will just emit address space cast when 
> necessary and let the backend check the validity of the address space cast.
> 
> Otherwise, for OpenCL, we can assert the expected address space is default 
> (for OpenCL default address space in AST represents private address space in 
> source language) or constant. For other languages we can assert the expected 
> address space qualifier is default (no address space qualifier). It is not 
> convenient to further check whether the emitted LLVM address space cast 
> instruction is valid since it requires target specific information, therefore 
> such check is better deferred to the backend.
> 
> For OpenCL, currently automatic variable in constant address space is emitted 
> in private address space. For example, currently Clang does not diagnose the 
> following code
> 
> ```
> void f(global int* a) {
>   global int* constant p = a;
> }
> 
> ```
> Instead, it emits alloca for p, essentially treats it as `global int* const 
> p`. This seems to be a bug to me (or maybe we can call it a feature? since 
> there seems no better way to translate this to LLVM IR, or simply diagnose 
> this as an error). However, this is better addressed by another patch.

Hi Anastasia,

Any comments about the automatic variable in constant address space? Thanks.


https://reviews.llvm.org/D32248



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

[PATCH] D24892: [clang-tidy] Add option "LiteralInitializers" to cppcoreguidelines-pro-type-member-init

[Malcolm Parsons via Phabricator via cfe-commits]

malcolm.parsons added a comment.

In https://reviews.llvm.org/D24892#732217, @alexfh wrote:

> In https://reviews.llvm.org/D24892#723536, @malcolm.parsons wrote:
>
> > Is there any way for multiple checks to share an option?
>
>
> There's OptionsView::getLocalOrGlobal. See how StrictMode option is read in 
> ArgumentCommentCheck, for example.


ArgumentCommentCheck uses getLocalOrGlobal, but 
InefficientStringConcatenationCheck and SuspiciousEnumUsageCheck don't.
6 checks have an IncludeStyle option that isn't shared.
4 checks share a HeaderFileExtensions option, but with different defaults.


https://reviews.llvm.org/D24892



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

[PATCH] D30691: [analyzer] Support for naive cross translational unit analysis

[Devin Coughlin via Phabricator via cfe-commits]

dcoughlin added inline comments.



Comment at: include/clang/AST/Decl.h:53
 class VarTemplateDecl;
+class CompilerInstance;
 

Is this needed? It seems like a layering violation.



Comment at: include/clang/AST/Mangle.h:59
+  // the static analyzer.
+  bool ShouldForceMangleProto;
 

I'm pretty worried about using C++ mangling for C functions. It doesn't ever 
seem appropriate to do so and it sounds like it is papering over problems with 
the design.

Some questions:
- How do you handle when two translation units have different C functions with 
the same type signatures? Is there a collision? This can arise because of 
two-level namespacing or when building multiple targets with the same CTU 
directory.
- How do you handle when a C function has the same signature as a C++ function. 
Is there a collision when you mangle the C function?


https://reviews.llvm.org/D30691



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

[PATCH] D32301: Don't pass FPOpFusion::Strict to the backend

[Adam Nemet via Phabricator via cfe-commits]

anemet created this revision.

This restores the behavior prior to https://reviews.llvm.org/D31167 where the 
code-gen default was
FPC_On which mapped to FPOpFusion::Standard.  After merging the FE
state (on/off) and the code-gen state (on/fast/off), the default became off to
match the front-end.

In other words, the front-end controls when to fuse along the language
standards and the backend shouldn't override this by splitting fused
intrinsics as FPOpFusion::Strict would imply.


https://reviews.llvm.org/D32301

Files:
  lib/CodeGen/BackendUtil.cpp
  test/CodeGen/fp-contract-on-asm.c


Index: test/CodeGen/fp-contract-on-asm.c
===
--- /dev/null
+++ test/CodeGen/fp-contract-on-asm.c
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -O3 -triple=aarch64-apple-ios -S -o - %s | FileCheck %s
+// REQUIRES: aarch64-registered-target
+
+float fma_test1(float a, float b, float c) {
+#pragma STDC FP_CONTRACT ON
+// CHECK-LABEL: fma_test1:
+// CHECK: fmadd
+  float x = a * b + c;
+  return x;
+}
+
+float fma_test2(float a, float b, float c) {
+// CHECK-LABEL: fma_test2:
+// CHECK: fmul
+// CHECK: fadd
+  float x = a * b + c;
+  return x;
+}
Index: lib/CodeGen/BackendUtil.cpp
===
--- lib/CodeGen/BackendUtil.cpp
+++ lib/CodeGen/BackendUtil.cpp
@@ -372,7 +372,9 @@
   // Set FP fusion mode.
   switch (LangOpts.getDefaultFPContractMode()) {
   case LangOptions::FPC_Off:
-Options.AllowFPOpFusion = llvm::FPOpFusion::Strict;
+// Preserve any contraction performed by the front-end.  (Strict performs
+// splitting of the muladd instrinsic in the backend.)
+Options.AllowFPOpFusion = llvm::FPOpFusion::Standard;
 break;
   case LangOptions::FPC_On:
 Options.AllowFPOpFusion = llvm::FPOpFusion::Standard;


Index: test/CodeGen/fp-contract-on-asm.c
===
--- /dev/null
+++ test/CodeGen/fp-contract-on-asm.c
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -O3 -triple=aarch64-apple-ios -S -o - %s | FileCheck %s
+// REQUIRES: aarch64-registered-target
+
+float fma_test1(float a, float b, float c) {
+#pragma STDC FP_CONTRACT ON
+// CHECK-LABEL: fma_test1:
+// CHECK: fmadd
+  float x = a * b + c;
+  return x;
+}
+
+float fma_test2(float a, float b, float c) {
+// CHECK-LABEL: fma_test2:
+// CHECK: fmul
+// CHECK: fadd
+  float x = a * b + c;
+  return x;
+}
Index: lib/CodeGen/BackendUtil.cpp
===
--- lib/CodeGen/BackendUtil.cpp
+++ lib/CodeGen/BackendUtil.cpp
@@ -372,7 +372,9 @@
   // Set FP fusion mode.
   switch (LangOpts.getDefaultFPContractMode()) {
   case LangOptions::FPC_Off:
-Options.AllowFPOpFusion = llvm::FPOpFusion::Strict;
+// Preserve any contraction performed by the front-end.  (Strict performs
+// splitting of the muladd instrinsic in the backend.)
+Options.AllowFPOpFusion = llvm::FPOpFusion::Standard;
 break;
   case LangOptions::FPC_On:
 Options.AllowFPOpFusion = llvm::FPOpFusion::Standard;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D32301: Don't pass FPOpFusion::Strict to the backend

[Hal Finkel via Phabricator via cfe-commits]

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

LGTM


https://reviews.llvm.org/D32301



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

Re: [llvm-dev] Permissions for llvm-mirror - Setting up Libc++ Appveyor builders

[Mehdi Amini via cfe-commits]

> On Apr 20, 2017, at 12:39 AM, Eric Fiselier  wrote:
> 
> 
> 
> On Wed, Apr 19, 2017 at 11:19 PM, Mehdi Amini  > wrote:
> What would be the status of these buildbots? Is it for your private usage? 
> 
> I intend for them to be public Windows buildbots for libc++.


I’m not sure it’d be OK to send blame email to contributors based on this 
though.

— 
Mehdi


> 
> Otherwise having “project' bots” using a non-official mirror may sound like a 
> strange situation to me.
> 
> I agree it isn't ideal, but when/if LLVM moves to github it will be trivial 
> to re-configure for the official repositories.
> I considered a number of other ways to setup Appveyor but I concluded this 
> was the best/easiest way to do it.
> The other options I considered for configuring Appveyor are:
> 
> (1) Use the official LLVM github mirrors.
>  
> This has the issue of requiring the implementation of custom Git webhooks, 
> which would require
> modifying and maintaining changes to the existing LLVM Git infrastructure, 
> which in itself
> would require getting access to the LLVM servers to make the changes.
> 
> (2) Setup my own ever more unofficial github mirror 
> 
> This has all the same problems as using the existing github mirrors but it 
> requires
> me to configure and maintain my own mirror, which is non-trivial.
> 
> (3) Don't use Appveyor at all
> 
> This requires finding Windows hardware to host the bots, which is the main 
> reason
> I chose Appveyor to begin with. Even if hardware was available I would prefer 
> using
> Appveyor since it provides more dominion over the environment than I think
> donated hardware could.
> 
> /Eric
> 
> 
> — 
> Mehdi
> 
>> On Apr 19, 2017, at 5:04 PM, Eric Fiselier via llvm-dev 
>> mailto:llvm-...@lists.llvm.org>> wrote:
>> 
>> Adding cfe-dev list...
>> 
>> On Wed, Apr 19, 2017 at 5:50 PM, Eric Fiselier > > wrote:
>> Hi Will,
>> 
>> I would like to request collaborator permissions for the Libc++ github 
>> mirror.
>> 
>> I plan to use the access to setup Appveyor buildbots for libc++. In order to 
>> do this I need to be listed as a collaborator on Github. 
>> 
>> The alternative to Github access would be setting up the correct webhooks 
>> for llvm.org/git/libcxx.git , but this seems 
>> harder to both do and maintain.
>> 
>> /Eric
>> 
>> ___
>> LLVM Developers mailing list
>> llvm-...@lists.llvm.org 
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev 
>> 
> 
> 

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

r300858 - Don't pass FPOpFusion::Strict to the backend

[Adam Nemet via cfe-commits]

Author: anemet
Date: Thu Apr 20 12:09:35 2017
New Revision: 300858

URL: http://llvm.org/viewvc/llvm-project?rev=300858&view=rev
Log:
Don't pass FPOpFusion::Strict to the backend

This restores the behavior prior to D31167 where the code-gen default was
FPC_On which mapped to FPOpFusion::Standard.  After merging the FE
state (on/off) and the code-gen state (on/fast/off), the default became off to
match the front-end.

In other words, the front-end controls when to fuse along the language
standards and the backend shouldn't override this by splitting fused
intrinsics as FPOpFusion::Strict would imply.

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

Added:
cfe/trunk/test/CodeGen/fp-contract-on-asm.c
Modified:
cfe/trunk/lib/CodeGen/BackendUtil.cpp

Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/BackendUtil.cpp?rev=300858&r1=300857&r2=300858&view=diff
==
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original)
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Thu Apr 20 12:09:35 2017
@@ -369,7 +369,9 @@ static void initTargetOptions(llvm::Targ
   // Set FP fusion mode.
   switch (LangOpts.getDefaultFPContractMode()) {
   case LangOptions::FPC_Off:
-Options.AllowFPOpFusion = llvm::FPOpFusion::Strict;
+// Preserve any contraction performed by the front-end.  (Strict performs
+// splitting of the muladd instrinsic in the backend.)
+Options.AllowFPOpFusion = llvm::FPOpFusion::Standard;
 break;
   case LangOptions::FPC_On:
 Options.AllowFPOpFusion = llvm::FPOpFusion::Standard;

Added: cfe/trunk/test/CodeGen/fp-contract-on-asm.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/fp-contract-on-asm.c?rev=300858&view=auto
==
--- cfe/trunk/test/CodeGen/fp-contract-on-asm.c (added)
+++ cfe/trunk/test/CodeGen/fp-contract-on-asm.c Thu Apr 20 12:09:35 2017
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -O3 -triple=aarch64-apple-ios -S -o - %s | FileCheck %s
+// REQUIRES: aarch64-registered-target
+
+float fma_test1(float a, float b, float c) {
+#pragma STDC FP_CONTRACT ON
+// CHECK-LABEL: fma_test1:
+// CHECK: fmadd
+  float x = a * b + c;
+  return x;
+}
+
+float fma_test2(float a, float b, float c) {
+// CHECK-LABEL: fma_test2:
+// CHECK: fmul
+// CHECK: fadd
+  float x = a * b + c;
+  return x;
+}


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

[PATCH] D32301: Don't pass FPOpFusion::Strict to the backend

[Adam Nemet via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL300858: Don't pass FPOpFusion::Strict to the backend 
(authored by anemet).

Changed prior to commit:
  https://reviews.llvm.org/D32301?vs=95979&id=95982#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D32301

Files:
  cfe/trunk/lib/CodeGen/BackendUtil.cpp
  cfe/trunk/test/CodeGen/fp-contract-on-asm.c


Index: cfe/trunk/test/CodeGen/fp-contract-on-asm.c
===
--- cfe/trunk/test/CodeGen/fp-contract-on-asm.c
+++ cfe/trunk/test/CodeGen/fp-contract-on-asm.c
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -O3 -triple=aarch64-apple-ios -S -o - %s | FileCheck %s
+// REQUIRES: aarch64-registered-target
+
+float fma_test1(float a, float b, float c) {
+#pragma STDC FP_CONTRACT ON
+// CHECK-LABEL: fma_test1:
+// CHECK: fmadd
+  float x = a * b + c;
+  return x;
+}
+
+float fma_test2(float a, float b, float c) {
+// CHECK-LABEL: fma_test2:
+// CHECK: fmul
+// CHECK: fadd
+  float x = a * b + c;
+  return x;
+}
Index: cfe/trunk/lib/CodeGen/BackendUtil.cpp
===
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp
@@ -369,7 +369,9 @@
   // Set FP fusion mode.
   switch (LangOpts.getDefaultFPContractMode()) {
   case LangOptions::FPC_Off:
-Options.AllowFPOpFusion = llvm::FPOpFusion::Strict;
+// Preserve any contraction performed by the front-end.  (Strict performs
+// splitting of the muladd instrinsic in the backend.)
+Options.AllowFPOpFusion = llvm::FPOpFusion::Standard;
 break;
   case LangOptions::FPC_On:
 Options.AllowFPOpFusion = llvm::FPOpFusion::Standard;


Index: cfe/trunk/test/CodeGen/fp-contract-on-asm.c
===
--- cfe/trunk/test/CodeGen/fp-contract-on-asm.c
+++ cfe/trunk/test/CodeGen/fp-contract-on-asm.c
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -O3 -triple=aarch64-apple-ios -S -o - %s | FileCheck %s
+// REQUIRES: aarch64-registered-target
+
+float fma_test1(float a, float b, float c) {
+#pragma STDC FP_CONTRACT ON
+// CHECK-LABEL: fma_test1:
+// CHECK: fmadd
+  float x = a * b + c;
+  return x;
+}
+
+float fma_test2(float a, float b, float c) {
+// CHECK-LABEL: fma_test2:
+// CHECK: fmul
+// CHECK: fadd
+  float x = a * b + c;
+  return x;
+}
Index: cfe/trunk/lib/CodeGen/BackendUtil.cpp
===
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp
@@ -369,7 +369,9 @@
   // Set FP fusion mode.
   switch (LangOpts.getDefaultFPContractMode()) {
   case LangOptions::FPC_Off:
-Options.AllowFPOpFusion = llvm::FPOpFusion::Strict;
+// Preserve any contraction performed by the front-end.  (Strict performs
+// splitting of the muladd instrinsic in the backend.)
+Options.AllowFPOpFusion = llvm::FPOpFusion::Standard;
 break;
   case LangOptions::FPC_On:
 Options.AllowFPOpFusion = llvm::FPOpFusion::Standard;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D32084: AMDGPU/GFX9: Set +fast-fmaf for >=gfx900 unless -cl-denorms-are-zero is set

[Konstantin Zhuravlyov via Phabricator via cfe-commits]

kzhuravl added a comment.

Ping.


https://reviews.llvm.org/D32084



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

[PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

If you're going to try to enforce the declared type of memory, you'll also need 
something like the C effective type rule to handle char buffers in C++.  As far 
as I can tell, it's not actually legal under the spec to cast an array of chars 
to an arbitrary type and access it that way — you have to do something to 
establish that there's an object of that type there first.  If you memcpy'ed 
into that buffer from an object of the right type, that would be sufficient to 
create a new formal object of that type, but I don't see any way to sensibly 
apply that rule to e.g. the POSIX "read" function.  It seems to me that you at 
least need to have a rule saying that it's okay to access a formal object of 
type char/char[] using an arbitrarily-typed l-value.


https://reviews.llvm.org/D32199



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

[PATCH] D31972: Do not force the frame pointer by default for ARM EABI

[Akira Hatanaka via Phabricator via cfe-commits]

ahatanak added inline comments.



Comment at: test/CodeGen/arm-fp-eabi.c:1
+// RUN: %clang %s -target arm-none-eabi -O2 -S -o nofp.s
+// RUN: not grep '.setfp' nofp.s

Instead of generating a .s file and looking for ".setfp", you can pass -### and 
check the presence or absence of -mdisable-fp-elim (see other tests in 
test/Driver).


https://reviews.llvm.org/D31972



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

[PATCH] D32192: Enable leak sanitizer builds for darwin

[Francis Ricci via Phabricator via cfe-commits]

fjricci updated this revision to Diff 95986.
fjricci added a comment.

Add test cases


https://reviews.llvm.org/D32192

Files:
  lib/Driver/ToolChains/Darwin.cpp
  test/Driver/fsanitize.c
  test/Driver/sanitizer-ld.c


Index: test/Driver/sanitizer-ld.c
===
--- test/Driver/sanitizer-ld.c
+++ test/Driver/sanitizer-ld.c
@@ -409,6 +409,15 @@
 // CHECK-ASAN-DARWIN106-CXX: libclang_rt.asan_osx_dynamic.dylib
 // CHECK-ASAN-DARWIN106-CXX-NOT: -lc++abi
 
+// RUN: %clangxx -fsanitize=leak %s -### -o %t.o 2>&1 \
+// RUN: -mmacosx-version-min=10.6 \
+// RUN: -target x86_64-apple-darwin13.4.0 -fuse-ld=ld -stdlib=platform \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-LSAN-DARWIN106-CXX %s
+// CHECK-LSAN-DARWIN106-CXX: "{{.*}}ld{{(.exe)?}}"
+// CHECK-LSAN-DARWIN106-CXX: libclang_rt.lsan_osx_dynamic.dylib
+// CHECK-LSAN-DARWIN106-CXX-NOT: -lc++abi
+
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: -target x86_64-unknown-linux -fuse-ld=ld -fsanitize=safe-stack \
 // RUN: --sysroot=%S/Inputs/basic_linux_tree \
Index: test/Driver/fsanitize.c
===
--- test/Driver/fsanitize.c
+++ test/Driver/fsanitize.c
@@ -358,6 +358,27 @@
 // RUN: %clang -target i386-pc-openbsd -fsanitize=address %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-ASAN-OPENBSD
 // CHECK-ASAN-OPENBSD: unsupported option '-fsanitize=address' for target 
'i386-pc-openbsd'
 
+// RUN: %clang -target x86_64-apple-darwin -fsanitize=leak %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-LSAN-X86-64-DARWIN
+// CHECK-LSAN-X86-64-DARWIN-NOT: unsupported option
+
+// RUN: %clang -target x86_64-apple-iossimulator -fsanitize=leak %s -### 2>&1 
| FileCheck %s --check-prefix=CHECK-LSAN-X86-64-IOSSIMULATOR
+// CHECK-LSAN-X86-64-IOSSIMULATOR-NOT: unsupported option
+
+// RUN: %clang -target x86_64-apple-tvossimulator -fsanitize=leak %s -### 2>&1 
| FileCheck %s --check-prefix=CHECK-LSAN-X86-64-TVOSSIMULATOR
+// CHECK-LSAN-X86-64-TVOSSIMULATOR-NOT: unsupported option
+
+// RUN: %clang -target i386-apple-darwin -fsanitize=leak %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-LSAN-I386-DARWIN
+// CHECK-LSAN-I386-DARWIN-NOT: unsupported option
+
+// RUN: %clang -target arm-apple-ios -fsanitize=leak %s -### 2>&1 | FileCheck 
%s --check-prefix=CHECK-LSAN-ARM-IOS
+// CHECK-LSAN-ARM-IOS-NOT: unsupported option
+
+// RUN: %clang -target i386-apple-iossimulator -fsanitize=leak %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-LSAN-I386-IOSSIMULATOR
+// CHECK-LSAN-I386-IOSSIMULATOR-NOT: unsupported option
+
+// RUN: %clang -target i386-apple-tvossimulator -fsanitize=leak %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-LSAN-I386-TVOSSIMULATOR
+// CHECK-LSAN-I386-TVOSSIMULATOR-NOT: unsupported option
+
 // RUN: %clang -target i686-linux-gnu -fsanitize=efficiency-cache-frag %s -### 
2>&1 | FileCheck %s --check-prefix=CHECK-ESAN-X86
 // RUN: %clang -target i686-linux-gnu -fsanitize=efficiency-working-set %s 
-### 2>&1 | FileCheck %s --check-prefix=CHECK-ESAN-X86
 // CHECK-ESAN-X86: error: unsupported option '-fsanitize=efficiency-{{.*}}' 
for target 'i686--linux-gnu'
Index: lib/Driver/ToolChains/Darwin.cpp
===
--- lib/Driver/ToolChains/Darwin.cpp
+++ lib/Driver/ToolChains/Darwin.cpp
@@ -1035,6 +1035,8 @@
   const SanitizerArgs &Sanitize = getSanitizerArgs();
   if (Sanitize.needsAsanRt())
 AddLinkSanitizerLibArgs(Args, CmdArgs, "asan");
+  if (Sanitize.needsLsanRt())
+AddLinkSanitizerLibArgs(Args, CmdArgs, "lsan");
   if (Sanitize.needsUbsanRt())
 AddLinkSanitizerLibArgs(Args, CmdArgs, "ubsan");
   if (Sanitize.needsTsanRt())
@@ -1892,6 +1894,7 @@
   const bool IsX86_64 = getTriple().getArch() == llvm::Triple::x86_64;
   SanitizerMask Res = ToolChain::getSupportedSanitizers();
   Res |= SanitizerKind::Address;
+  Res |= SanitizerKind::Leak;
   if (isTargetMacOS()) {
 if (!isMacosxVersionLT(10, 9))
   Res |= SanitizerKind::Vptr;


Index: test/Driver/sanitizer-ld.c
===
--- test/Driver/sanitizer-ld.c
+++ test/Driver/sanitizer-ld.c
@@ -409,6 +409,15 @@
 // CHECK-ASAN-DARWIN106-CXX: libclang_rt.asan_osx_dynamic.dylib
 // CHECK-ASAN-DARWIN106-CXX-NOT: -lc++abi
 
+// RUN: %clangxx -fsanitize=leak %s -### -o %t.o 2>&1 \
+// RUN: -mmacosx-version-min=10.6 \
+// RUN: -target x86_64-apple-darwin13.4.0 -fuse-ld=ld -stdlib=platform \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-LSAN-DARWIN106-CXX %s
+// CHECK-LSAN-DARWIN106-CXX: "{{.*}}ld{{(.exe)?}}"
+// CHECK-LSAN-DARWIN106-CXX: libclang_rt.lsan_osx_dynamic.dylib
+// CHECK-LSAN-DARWIN106-CXX-NOT: -lc++abi
+
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: -target x86_64-unknown-linux -fuse-ld=ld -fsanitize=sa

[PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

[Hal Finkel via Phabricator via cfe-commits]

hfinkel added a comment.

In https://reviews.llvm.org/D32199#732382, @rjmccall wrote:

> If you're going to try to enforce the declared type of memory, you'll also 
> need something like the C effective type rule to handle char buffers in C++.  
> As far as I can tell, it's not actually legal under the spec to cast an array 
> of chars to an arbitrary type and access it that way — you have to do 
> something to establish that there's an object of that type there first. 
>  If you memcpy'ed into that buffer from an object of the right type, that 
> would be sufficient to create a new formal object of that type, but I don't 
> see any way to sensibly apply that rule to e.g. the POSIX "read" function.  
> It seems to me that you at least need to have a rule saying that it's okay to 
> access a formal object of type char/char[] using an arbitrarily-typed l-value.


I agree. That's exactly what the current implementation does (I get that for 
free from our TBAA setup). I get this for free from the TBAA scheme because the 
current checks are symmetric (just like the TBAA checks in the optimizer). I 
had wondered whether this symmetry was an over-approximation in some cases, but 
perhaps it is not.


https://reviews.llvm.org/D32199



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

r300873 - [Driver] Add a missing -no-canonical-prefixes to test.

[Benjamin Kramer via cfe-commits]

Author: d0k
Date: Thu Apr 20 14:06:24 2017
New Revision: 300873

URL: http://llvm.org/viewvc/llvm-project?rev=300873&view=rev
Log:
[Driver] Add a missing -no-canonical-prefixes to test.

Modified:
cfe/trunk/test/Driver/avr-mmcu.c

Modified: cfe/trunk/test/Driver/avr-mmcu.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/avr-mmcu.c?rev=300873&r1=300872&r2=300873&view=diff
==
--- cfe/trunk/test/Driver/avr-mmcu.c (original)
+++ cfe/trunk/test/Driver/avr-mmcu.c Thu Apr 20 14:06:24 2017
@@ -1,5 +1,5 @@
 // A test for the propagation of the -mmcu option to -cc1 and -cc1as
 
-// RUN: %clang -### -target avr -mmcu=atmega328p -save-temps %s 2>&1 | 
FileCheck %s
+// RUN: %clang -### -target avr -no-canonical-prefixes -mmcu=atmega328p 
-save-temps %s 2>&1 | FileCheck %s
 // CHECK: clang{{.*}} "-cc1" {{.*}} "-target-cpu" "atmega328p"
 // CHECK: clang{{.*}} "-cc1as" {{.*}} "-target-cpu" "atmega328p"


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

Re: [llvm-dev] Permissions for llvm-mirror - Setting up Libc++ Appveyor builders

[Eric Fiselier via cfe-commits]

On Thu, Apr 20, 2017 at 11:06 AM, Mehdi Amini  wrote:

>
> On Apr 20, 2017, at 12:39 AM, Eric Fiselier  wrote:
>
>
>
> On Wed, Apr 19, 2017 at 11:19 PM, Mehdi Amini 
> wrote:
>
>> What would be the status of these buildbots? Is it for your private
>> usage?
>>
>
> I intend for them to be public Windows buildbots for libc++.
>
>
>
> I’m not sure it’d be OK to send blame email to contributors based on this
> though.
>

I don't see why not (at least once the bot is stable). Can you elaborate?

/Eric


> —
> Mehdi
>
>
>
> Otherwise having “project' bots” using a non-official mirror may sound
>> like a strange situation to me.
>>
>
> I agree it isn't ideal, but when/if LLVM moves to github it will be
> trivial to re-configure for the official repositories.
> I considered a number of other ways to setup Appveyor but I concluded this
> was the best/easiest way to do it.
> The other options I considered for configuring Appveyor are:
>
> (1) Use the official LLVM github mirrors.
>
> This has the issue of requiring the implementation of custom Git webhooks,
> which would require
> modifying and maintaining changes to the existing LLVM Git infrastructure,
> which in itself
> would require getting access to the LLVM servers to make the changes.
>
> (2) Setup my own ever more unofficial github mirror
>
> This has all the same problems as using the existing github mirrors but it
> requires
> me to configure and maintain my own mirror, which is non-trivial.
>
> (3) Don't use Appveyor at all
>
> This requires finding Windows hardware to host the bots, which is the main
> reason
> I chose Appveyor to begin with. Even if hardware was available I would
> prefer using
> Appveyor since it provides more dominion over the environment than I think
> donated hardware could.
>
> /Eric
>
>
>> —
>> Mehdi
>>
>> On Apr 19, 2017, at 5:04 PM, Eric Fiselier via llvm-dev <
>> llvm-...@lists.llvm.org> wrote:
>>
>> Adding cfe-dev list...
>>
>> On Wed, Apr 19, 2017 at 5:50 PM, Eric Fiselier  wrote:
>>
>>> Hi Will,
>>>
>>> I would like to request collaborator permissions for the Libc++ github
>>> mirror.
>>>
>>> I plan to use the access to setup Appveyor buildbots for libc++. In
>>> order to do this I need to be listed as a collaborator on Github.
>>>
>>> The alternative to Github access would be setting up the correct
>>> webhooks for llvm.org/git/libcxx.git, but this seems harder to both do
>>> and maintain.
>>>
>>> /Eric
>>>
>>
>> ___
>> LLVM Developers mailing list
>> llvm-...@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D32294: [clang-tidy] run-clang-tidy.py: check if clang-apply-replacements succeeds

[Jakub Kuderski via Phabricator via cfe-commits]

kuhar updated this revision to Diff 96001.
kuhar added a comment.

Use python3 printing. Move exception handling out of apply_fixes.

Now, the code prints the following on failure:

  Applying fixes ...
  Error applying fixes. Is clang-apply-replacements binary correctly specified?
  
  Traceback (most recent call last):
File 
"/home/kuhar/projects/llvm/tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py",
 line 217, in main
  apply_fixes(args, tmpdir)
File 
"/home/kuhar/projects/llvm/tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py",
 line 98, in apply_fixes
  subprocess.call(invocation)
File "/usr/lib/python2.7/subprocess.py", line 523, in call
  return Popen(*popenargs, **kwargs).wait()
File "/usr/lib/python2.7/subprocess.py", line 711, in __init__
  errread, errwrite)
File "/usr/lib/python2.7/subprocess.py", line 1343, in _execute_child
  raise child_exception
  OSError: [Errno 2] No such file or directory

I hope that suggesting problem with clang-apply-replacements binary and 
printing stack trace is more useful.


https://reviews.llvm.org/D32294

Files:
  clang-tidy/tool/run-clang-tidy.py


Index: clang-tidy/tool/run-clang-tidy.py
===
--- clang-tidy/tool/run-clang-tidy.py
+++ clang-tidy/tool/run-clang-tidy.py
@@ -34,6 +34,7 @@
 http://clang.llvm.org/docs/HowToSetupToolingForLLVM.html
 """
 
+from __future__ import print_function
 import argparse
 import json
 import multiprocessing
@@ -45,14 +46,15 @@
 import sys
 import tempfile
 import threading
+import traceback
 
 
 def find_compilation_database(path):
   """Adjusts the directory until a compilation database is found."""
   result = './'
   while not os.path.isfile(os.path.join(result, path)):
 if os.path.realpath(result) == '/':
-  print 'Error: could not find compilation database.'
+  print('Error: could not find compilation database.')
   sys.exit(1)
 result += '../'
   return os.path.realpath(result)
@@ -94,7 +96,6 @@
 invocation.append('-format')
   invocation.append(tmpdir)
   subprocess.call(invocation)
-  shutil.rmtree(tmpdir)
 
 
 def run_tidy(args, tmpdir, build_path, queue):
@@ -164,9 +165,9 @@
 if args.checks:
   invocation.append('-checks=' + args.checks)
 invocation.append('-')
-print subprocess.check_output(invocation)
+print(subprocess.check_output(invocation))
   except:
-print >>sys.stderr, "Unable to run clang-tidy."
+print("Unable to run clang-tidy.", file=sys.stderr)
 sys.exit(1)
 
   # Load the database and extract all files.
@@ -204,14 +205,22 @@
   except KeyboardInterrupt:
 # This is a sad hack. Unfortunately subprocess goes
 # bonkers with ctrl-c and we start forking merrily.
-print '\nCtrl-C detected, goodbye.'
+print('\nCtrl-C detected, goodbye.')
 if args.fix:
   shutil.rmtree(tmpdir)
 os.kill(0, 9)
 
   if args.fix:
-print 'Applying fixes ...'
-apply_fixes(args, tmpdir)
+print('Applying fixes ...')
+
+try:
+  apply_fixes(args, tmpdir)
+except:
+  print('Error applying fixes. Is clang-apply-replacements binary '
+'correctly specified?\n', file=sys.stderr)
+  traceback.print_exc()
+
+shutil.rmtree(tmpdir)
 
 if __name__ == '__main__':
   main()


Index: clang-tidy/tool/run-clang-tidy.py
===
--- clang-tidy/tool/run-clang-tidy.py
+++ clang-tidy/tool/run-clang-tidy.py
@@ -34,6 +34,7 @@
 http://clang.llvm.org/docs/HowToSetupToolingForLLVM.html
 """
 
+from __future__ import print_function
 import argparse
 import json
 import multiprocessing
@@ -45,14 +46,15 @@
 import sys
 import tempfile
 import threading
+import traceback
 
 
 def find_compilation_database(path):
   """Adjusts the directory until a compilation database is found."""
   result = './'
   while not os.path.isfile(os.path.join(result, path)):
 if os.path.realpath(result) == '/':
-  print 'Error: could not find compilation database.'
+  print('Error: could not find compilation database.')
   sys.exit(1)
 result += '../'
   return os.path.realpath(result)
@@ -94,7 +96,6 @@
 invocation.append('-format')
   invocation.append(tmpdir)
   subprocess.call(invocation)
-  shutil.rmtree(tmpdir)
 
 
 def run_tidy(args, tmpdir, build_path, queue):
@@ -164,9 +165,9 @@
 if args.checks:
   invocation.append('-checks=' + args.checks)
 invocation.append('-')
-print subprocess.check_output(invocation)
+print(subprocess.check_output(invocation))
   except:
-print >>sys.stderr, "Unable to run clang-tidy."
+print("Unable to run clang-tidy.", file=sys.stderr)
 sys.exit(1)
 
   # Load the database and extract all files.
@@ -204,14 +205,22 @@
   except KeyboardInterrupt:
 # This is a sad hack. Unfortunately subprocess goes
 # bonkers with ctrl-c and we start forking merrily.
-print '\nCtrl-C detected, good

[PATCH] D32294: [clang-tidy] run-clang-tidy.py: check if clang-apply-replacements succeeds

[Jakub Kuderski via Phabricator via cfe-commits]

kuhar marked 2 inline comments as done.
kuhar added inline comments.



Comment at: clang-tidy/tool/run-clang-tidy.py:100
+  except:
+print >>sys.stderr, "Unable to run clang-apply-replacements."
+sys.exit(1)

kimgr wrote:
> alexfh wrote:
> > "Unable to run clang-apply-replacements" without any details seems to be 
> > far worse than just a default stack trace from an unhandled exception. At 
> > the very least add the message from the exception.
> I don't know what the general Python3 ambitions of this script is, but it 
> would be nice if the new code didn't use the Python2-only print style.
> 
> You can:
> 
> from __future__ import print_function
> 
> at the top of the file, and then use Python3-style print:
> 
> print("Unable to run clang-apply-replacements", file=sys.stderr)
Thanks for feedback. I changed the code to print suggestion about 
clang-apply-replacements and stack trace. Is there a better way to make it easy 
to debug?


https://reviews.llvm.org/D32294



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

[PATCH] D29904: [OpenMP] Prevent emission of exception handling code when using OpenMP to offload to NVIDIA devices.

[Alexey Bataev via Phabricator via cfe-commits]

ABataev accepted this revision.
ABataev added a comment.

LG


Repository:
  rL LLVM

https://reviews.llvm.org/D29904



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

[PATCH] D29658: [OpenMP] Customize CUDA-based tool chain selection

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added a comment.

Tests?




Comment at: lib/Driver/Driver.cpp:556
   else {
-const ToolChain &TC = getToolChain(C.getInputArgs(), TT);
-C.addOffloadDeviceToolChain(&TC, Action::OFK_OpenMP);
+const ToolChain *TC = nullptr;
+// CUDA toolchains have to be selected differently. They pair host

Seems to me you're not using this initial value, so it is better to leave this 
variable uninitialized


Repository:
  rL LLVM

https://reviews.llvm.org/D29658



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

[PATCH] D32294: [clang-tidy] run-clang-tidy.py: check if clang-apply-replacements succeeds

[Alexander Kornienko via Phabricator via cfe-commits]

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

SGTM provided this continues to work with python 2.


https://reviews.llvm.org/D32294



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

[PATCH] D29659: [OpenMP] Add flag for disabling the default generation of relocatable OpenMP target code for NVIDIA GPUs.

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added inline comments.



Comment at: lib/Driver/ToolChains/Cuda.cpp:297
+  !Args.hasFlag(options::OPT_fnoopenmp_relocatable_target,
+options::OPT_fopenmp_relocatable_target, false))
 CmdArgs.push_back("-c");

1. Add a comment with the name of the parameter for `false` argument
2. Why not to use this logic:
```
Args.hasFlag(options::OPT_fopenmp_relocatable_target,
options::OPT_fnoopenmp_relocatable_target, true)
```
?


Repository:
  rL LLVM

https://reviews.llvm.org/D29659



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

[PATCH] D31709: [NFC] Refactor DiagnosticRenderer to use FullSourceLoc

[Reid Kleckner via Phabricator via cfe-commits]

rnk added inline comments.



Comment at: include/clang/Basic/SourceLocation.h:336
 
+  bool hasManager() const { return SrcMgr != nullptr; }
   /// \pre This FullSourceLoc has an associated SourceManager.

SrcMgr is only non-null when the location is invalid, right? Can you do 
something like:
  bool hasManager() const {
bool R = SrcMgr != nullptr;
assert(R == isValid() && "FullSourceLoc has location but no manager");
return R;
  }



Comment at: lib/Basic/SourceLocation.cpp:25
 
+namespace clang {
 void PrettyStackTraceLoc::print(raw_ostream &OS) const {

This doesn't seem necessary, you aren't defining any free functions, right?



Comment at: lib/Frontend/DiagnosticRenderer.cpp:139
 void DiagnosticRenderer::emitStoredDiagnostic(StoredDiagnostic &Diag) {
-  emitDiagnostic(Diag.getLocation(), Diag.getLevel(), Diag.getMessage(),
- Diag.getRanges(), Diag.getFixIts(),
- Diag.getLocation().isValid() ? 
&Diag.getLocation().getManager()
-  : nullptr,
- &Diag);
+  emitDiagnostic(
+  Diag.getLocation().isValid()

I think `Diag.getLocation()` is already a FullSourceLoc, no need to check it.



Comment at: lib/Frontend/DiagnosticRenderer.cpp:512
   // Produce a stack of macro backtraces.
-  SmallVector LocationStack;
+  SmallVector LocationStack;
   unsigned IgnoredEnd = 0;

This seems inefficient, it wastes space on `SourceManager` pointers that will 
all be the same.


https://reviews.llvm.org/D31709



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

[libcxx] r300881 - Fix comment and remove incorrect linker flags in test configuration

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Thu Apr 20 15:22:19 2017
New Revision: 300881

URL: http://llvm.org/viewvc/llvm-project?rev=300881&view=rev
Log:
Fix comment and remove incorrect linker flags in test configuration

Modified:
libcxx/trunk/utils/libcxx/test/config.py

Modified: libcxx/trunk/utils/libcxx/test/config.py
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/utils/libcxx/test/config.py?rev=300881&r1=300880&r2=300881&view=diff
==
--- libcxx/trunk/utils/libcxx/test/config.py (original)
+++ libcxx/trunk/utils/libcxx/test/config.py Thu Apr 20 15:22:19 2017
@@ -414,7 +414,11 @@ class Configuration(object):
 if self.is_windows:
 self.config.available_features.add('windows')
 if self.cxx_stdlib_under_test == 'libc++':
-# LIBCXX-WINDOWS-FIXME is a
+# LIBCXX-WINDOWS-FIXME is the feature name used to XFAIL the
+# initial Windows failures until they can be properly diagnosed
+# and fixed. This allows easier detection of new test failures
+# and regressions. Note: New failures should not be suppressed
+# using this feature.
 self.config.available_features.add('LIBCXX-WINDOWS-FIXME')
 
 # Attempt to detect the glibc version by querying for __GLIBC__
@@ -482,8 +486,6 @@ class Configuration(object):
 self.cxx.flags += ['-m32']
 # Use verbose output for better errors
 self.cxx.flags += ['-v']
-if self.is_windows:
-self.cxx.link_flags += ['-Wl,-v']
 sysroot = self.get_lit_conf('sysroot')
 if sysroot:
 self.cxx.flags += ['--sysroot', sysroot]


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

[PATCH] D32265: Add __CLANG_ATOMIC__LOCK_FREE macros for use in MSVC compatibility mode.

[JF Bastien via Phabricator via cfe-commits]

jfb added a comment.

In https://reviews.llvm.org/D32265#731710, @EricWF wrote:

> In https://reviews.llvm.org/D32265#731709, @jfb wrote:
>
> > Is it a goal to support Microsoft's STL with this? If so, how does MSVC's 
> > STL implement `is_always_lock_free` at the moment? CL 19 2017 RTW doesn't 
> > seem to have anything ? Presumably they'll 
> > have to do *something*.
>
>
> The goal is to allow libc++ to implement`ATOMIC__LOCK_FREE` on Windows 
> using Clang. As you know libc++ currently uses the `__GCC_ATOMIC_FOO` macros, 
> but those aren't available on Windows.


OK so it's just a hygiene question of blanket-avoiding `__GCC_*` macros in 
clang-ms mode, but using `__CLANG_*` macros are OK? That sounds fine then. 
Would you all-out switch libc++ to use `__CLANG_*` then?

> Also AFAIK MSVC leaves the implementation of atomics up to the library, not 
> the frontend. So W/E MSVC's STL does it's likely not sane or desirable.

Wait what? How does that even work? This calls for a Twitter ping of Billy!


https://reviews.llvm.org/D32265



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

[PATCH] D32291: [analyzer] Implement handling array subscript into null pointer, improve null dereference checks for array subscripts

[Gábor Horváth via Phabricator via cfe-commits]

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

LGTM!


https://reviews.llvm.org/D32291



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

r300891 - Begin making git-clang-format python3 compatible.

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Thu Apr 20 16:05:58 2017
New Revision: 300891

URL: http://llvm.org/viewvc/llvm-project?rev=300891&view=rev
Log:
Begin making git-clang-format python3 compatible.

This patch fixes most of the python3 incompatabilities
within git-clang-format while keeping the script python2 compatible.
There is still one remaining incompatability that prevents using Python3
which is the `str` vs `byte` type change. I plan to put those fixes
up for review separately.

This patch contains fixes for the following incompatabilities:

1) Use the new style Python3 `print` function. This requires importing
   __future__.print_function.

2) Fix incompatability between the Python3 octal prefix and the
   octal prefix Git uses.

3) Replace use of dict.iteritems() with dict.viewitems() because iteritems()
   has been removed in Python3. viewitems() reviews python 2.7 but that is
   also what the script is documented as requiring.

Modified:
cfe/trunk/tools/clang-format/git-clang-format

Modified: cfe/trunk/tools/clang-format/git-clang-format
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-format/git-clang-format?rev=300891&r1=300890&r2=300891&view=diff
==
--- cfe/trunk/tools/clang-format/git-clang-format (original)
+++ cfe/trunk/tools/clang-format/git-clang-format Thu Apr 20 16:05:58 2017
@@ -23,6 +23,7 @@ git clang-format -h
 Requires Python 2.7
  
 """   
 
+from __future__ import print_function
 import argparse
 import collections
 import contextlib
@@ -138,15 +139,15 @@ def main():
   if opts.verbose >= 1:
 ignored_files.difference_update(changed_lines)
 if ignored_files:
-  print 'Ignoring changes in the following files (wrong extension):'
+  print('Ignoring changes in the following files (wrong extension):')
   for filename in ignored_files:
-print '   ', filename
+print('%s' % filename)
 if changed_lines:
-  print 'Running clang-format on the following files:'
+  print('Running clang-format on the following files:')
   for filename in changed_lines:
-print '   ', filename
+print('%s' % filename)
   if not changed_lines:
-print 'no modified files to format'
+print('no modified files to format')
 return
   # The computed diff outputs absolute paths, so we must cd before accessing
   # those files.
@@ -163,20 +164,20 @@ def main():
  binary=opts.binary,
  style=opts.style)
   if opts.verbose >= 1:
-print 'old tree:', old_tree
-print 'new tree:', new_tree
+print('old tree: %s' % old_tree)
+print('new tree: %s' % new_tree)
   if old_tree == new_tree:
 if opts.verbose >= 0:
-  print 'clang-format did not modify any files'
+  print('clang-format did not modify any files')
   elif opts.diff:
 print_diff(old_tree, new_tree)
   else:
 changed_files = apply_changes(old_tree, new_tree, force=opts.force,
   patch_mode=opts.patch)
 if (opts.verbose >= 0 and not opts.patch) or opts.verbose >= 1:
-  print 'changed files:'
+  print('changed files:')
   for filename in changed_files:
-print '   ', filename
+print('%s' % filename)
 
 
 def load_git_config(non_string_options=None):
@@ -320,7 +321,7 @@ def filter_by_extension(dictionary, allo
   `allowed_extensions` must be a collection of lowercase file extensions,
   excluding the period."""
   allowed_extensions = frozenset(allowed_extensions)
-  for filename in dictionary.keys():
+  for filename in list(dictionary.keys()):
 base_ext = filename.rsplit('.', 1)
 if len(base_ext) == 1 or base_ext[1].lower() not in allowed_extensions:
   del dictionary[filename]
@@ -345,7 +346,7 @@ def run_clang_format_and_save_to_tree(ch
 
   Returns the object ID (SHA-1) of the created tree."""
   def index_info_generator():
-for filename, line_ranges in changed_lines.iteritems():
+for filename, line_ranges in changed_lines.viewitems():
   if revision:
 git_metadata_cmd = ['git', 'ls-tree',
 '%s:%s' % (revision, os.path.dirname(filename)),
@@ -356,6 +357,9 @@ def run_clang_format_and_save_to_tree(ch
 mode = oct(int(stdout.split()[0], 8))
   else:
 mode = oct(os.stat(filename).st_mode)
+  # Adjust python3 octal format so that it matches what git expects
+  if mode.startswith('0o'):
+  mode = '0' + mode[2:]
   blob_id = clang_format_to_blob(filename, line_ranges,
  revision=revision,
  binary=binary,
@@ -488,10 +492,10 @@ def apply_changes(old_tree, new_tree, fo
   if not force:
 unstaged_files = run('git', 'diff-files', '--name-status', *changed_files)
 if unstaged_fil

[PATCH] D32265: Add __CLANG_ATOMIC__LOCK_FREE macros for use in MSVC compatibility mode.

[JF Bastien via Phabricator via cfe-commits]

jfb added a comment.

It looks like Billy is going to do something somewhat similar when he rewrites 
it: https://twitter.com/jfbastien/status/855168230918307840
For now it's kinda `#define IS_LOCK_FREE ¯\_(ツ)_/¯`


https://reviews.llvm.org/D32265



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

[PATCH] D32192: Enable leak sanitizer builds for darwin

[Francis Ricci via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL300894: Enable leak sanitizer builds for darwin (authored by 
fjricci).

Changed prior to commit:
  https://reviews.llvm.org/D32192?vs=95986&id=96019#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D32192

Files:
  cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
  cfe/trunk/test/Driver/fsanitize.c
  cfe/trunk/test/Driver/sanitizer-ld.c


Index: cfe/trunk/test/Driver/sanitizer-ld.c
===
--- cfe/trunk/test/Driver/sanitizer-ld.c
+++ cfe/trunk/test/Driver/sanitizer-ld.c
@@ -409,6 +409,15 @@
 // CHECK-ASAN-DARWIN106-CXX: libclang_rt.asan_osx_dynamic.dylib
 // CHECK-ASAN-DARWIN106-CXX-NOT: -lc++abi
 
+// RUN: %clangxx -fsanitize=leak %s -### -o %t.o 2>&1 \
+// RUN: -mmacosx-version-min=10.6 \
+// RUN: -target x86_64-apple-darwin13.4.0 -fuse-ld=ld -stdlib=platform \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-LSAN-DARWIN106-CXX %s
+// CHECK-LSAN-DARWIN106-CXX: "{{.*}}ld{{(.exe)?}}"
+// CHECK-LSAN-DARWIN106-CXX: libclang_rt.lsan_osx_dynamic.dylib
+// CHECK-LSAN-DARWIN106-CXX-NOT: -lc++abi
+
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: -target x86_64-unknown-linux -fuse-ld=ld -fsanitize=safe-stack \
 // RUN: --sysroot=%S/Inputs/basic_linux_tree \
Index: cfe/trunk/test/Driver/fsanitize.c
===
--- cfe/trunk/test/Driver/fsanitize.c
+++ cfe/trunk/test/Driver/fsanitize.c
@@ -358,6 +358,27 @@
 // RUN: %clang -target i386-pc-openbsd -fsanitize=address %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-ASAN-OPENBSD
 // CHECK-ASAN-OPENBSD: unsupported option '-fsanitize=address' for target 
'i386-pc-openbsd'
 
+// RUN: %clang -target x86_64-apple-darwin -fsanitize=leak %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-LSAN-X86-64-DARWIN
+// CHECK-LSAN-X86-64-DARWIN-NOT: unsupported option
+
+// RUN: %clang -target x86_64-apple-iossimulator -fsanitize=leak %s -### 2>&1 
| FileCheck %s --check-prefix=CHECK-LSAN-X86-64-IOSSIMULATOR
+// CHECK-LSAN-X86-64-IOSSIMULATOR-NOT: unsupported option
+
+// RUN: %clang -target x86_64-apple-tvossimulator -fsanitize=leak %s -### 2>&1 
| FileCheck %s --check-prefix=CHECK-LSAN-X86-64-TVOSSIMULATOR
+// CHECK-LSAN-X86-64-TVOSSIMULATOR-NOT: unsupported option
+
+// RUN: %clang -target i386-apple-darwin -fsanitize=leak %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-LSAN-I386-DARWIN
+// CHECK-LSAN-I386-DARWIN-NOT: unsupported option
+
+// RUN: %clang -target arm-apple-ios -fsanitize=leak %s -### 2>&1 | FileCheck 
%s --check-prefix=CHECK-LSAN-ARM-IOS
+// CHECK-LSAN-ARM-IOS-NOT: unsupported option
+
+// RUN: %clang -target i386-apple-iossimulator -fsanitize=leak %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-LSAN-I386-IOSSIMULATOR
+// CHECK-LSAN-I386-IOSSIMULATOR-NOT: unsupported option
+
+// RUN: %clang -target i386-apple-tvossimulator -fsanitize=leak %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-LSAN-I386-TVOSSIMULATOR
+// CHECK-LSAN-I386-TVOSSIMULATOR-NOT: unsupported option
+
 // RUN: %clang -target i686-linux-gnu -fsanitize=efficiency-cache-frag %s -### 
2>&1 | FileCheck %s --check-prefix=CHECK-ESAN-X86
 // RUN: %clang -target i686-linux-gnu -fsanitize=efficiency-working-set %s 
-### 2>&1 | FileCheck %s --check-prefix=CHECK-ESAN-X86
 // CHECK-ESAN-X86: error: unsupported option '-fsanitize=efficiency-{{.*}}' 
for target 'i686--linux-gnu'
Index: cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
+++ cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
@@ -1035,6 +1035,8 @@
   const SanitizerArgs &Sanitize = getSanitizerArgs();
   if (Sanitize.needsAsanRt())
 AddLinkSanitizerLibArgs(Args, CmdArgs, "asan");
+  if (Sanitize.needsLsanRt())
+AddLinkSanitizerLibArgs(Args, CmdArgs, "lsan");
   if (Sanitize.needsUbsanRt())
 AddLinkSanitizerLibArgs(Args, CmdArgs, "ubsan");
   if (Sanitize.needsTsanRt())
@@ -1892,6 +1894,7 @@
   const bool IsX86_64 = getTriple().getArch() == llvm::Triple::x86_64;
   SanitizerMask Res = ToolChain::getSupportedSanitizers();
   Res |= SanitizerKind::Address;
+  Res |= SanitizerKind::Leak;
   if (isTargetMacOS()) {
 if (!isMacosxVersionLT(10, 9))
   Res |= SanitizerKind::Vptr;


Index: cfe/trunk/test/Driver/sanitizer-ld.c
===
--- cfe/trunk/test/Driver/sanitizer-ld.c
+++ cfe/trunk/test/Driver/sanitizer-ld.c
@@ -409,6 +409,15 @@
 // CHECK-ASAN-DARWIN106-CXX: libclang_rt.asan_osx_dynamic.dylib
 // CHECK-ASAN-DARWIN106-CXX-NOT: -lc++abi
 
+// RUN: %clangxx -fsanitize=leak %s -### -o %t.o 2>&1 \
+// RUN: -mmacosx-version-min=10.6 \
+// RUN: -target x86_64-apple-darwin13.4.0 -fuse-ld=ld -stdlib=platform \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:   | FileCheck -

r300895 - Fix Python 2 vs 3 incompatability with dict.items() vs iteritems()

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Thu Apr 20 16:23:58 2017
New Revision: 300895

URL: http://llvm.org/viewvc/llvm-project?rev=300895&view=rev
Log:
Fix Python 2 vs 3 incompatability with dict.items() vs iteritems()

Modified:
cfe/trunk/tools/clang-format/git-clang-format

Modified: cfe/trunk/tools/clang-format/git-clang-format
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-format/git-clang-format?rev=300895&r1=300894&r2=300895&view=diff
==
--- cfe/trunk/tools/clang-format/git-clang-format (original)
+++ cfe/trunk/tools/clang-format/git-clang-format Thu Apr 20 16:23:58 2017
@@ -345,8 +345,13 @@ def run_clang_format_and_save_to_tree(ch
   """Run clang-format on each file and save the result to a git tree.
 
   Returns the object ID (SHA-1) of the created tree."""
+  def iteritems(container):
+  try:
+  return container.iteritems() # Python 2
+  except AttributeError:
+  return container.items() # Python 3
   def index_info_generator():
-for filename, line_ranges in changed_lines.viewitems():
+for filename, line_ranges in iteritems(changed_lines):
   if revision:
 git_metadata_cmd = ['git', 'ls-tree',
 '%s:%s' % (revision, os.path.dirname(filename)),


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

[PATCH] D32265: Add __CLANG_ATOMIC__LOCK_FREE macros for use in MSVC compatibility mode.

[Billy Robert O'Neal III via Phabricator via cfe-commits]

BillyONeal added a comment.

In https://reviews.llvm.org/D32265#732657, @jfb wrote:

> It looks like Billy is going to do something somewhat similar when he 
> rewrites it: https://twitter.com/jfbastien/status/855168230918307840
>  For now it's kinda `#define IS_LOCK_FREE ¯\_(ツ)_/¯`


Note that my rewrite of our  didn't touch the XXX_IS_LOCK_FREE macros. 
All of those for both implementations are hardcoded to 2 since any piece of 
hardware we ever plan to support has lock free ops for all those. I did add 
conditional DCAS support for amd64 though in v.Next.

Billy3


https://reviews.llvm.org/D32265



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

[PATCH] D32265: Add __CLANG_ATOMIC__LOCK_FREE macros for use in MSVC compatibility mode.

[Eric Fiselier via Phabricator via cfe-commits]

EricWF added a comment.

In https://reviews.llvm.org/D32265#732649, @jfb wrote:

> In https://reviews.llvm.org/D32265#731710, @EricWF wrote:
>
> > In https://reviews.llvm.org/D32265#731709, @jfb wrote:
> >
> > > Is it a goal to support Microsoft's STL with this? If so, how does MSVC's 
> > > STL implement `is_always_lock_free` at the moment? CL 19 2017 RTW doesn't 
> > > seem to have anything ? Presumably they'll 
> > > have to do *something*.
> >
> >
> > The goal is to allow libc++ to implement`ATOMIC__LOCK_FREE` on 
> > Windows using Clang. As you know libc++ currently uses the 
> > `__GCC_ATOMIC_FOO` macros, but those aren't available on Windows.
>
>
> OK so it's just a hygiene question of blanket-avoiding `__GCC_*` macros in 
> clang-ms mode, but using `__CLANG_*` macros are OK? That sounds fine then. 
> Would you all-out switch libc++ to use `__CLANG_*` then?


`__CLANG` macros are fine on libc++'s end; So as long as they're not uncouth 
for Clang it should be OK.

I would switch libc++ to do

  #ifdef __CLANG_ATOMIC_FOO
  # define ATOMIC_FOO __CLANG_ATOMIC_FOO
  # define ATOMIC_BAR __CLANG_ATOMIC_BAR
  #else
  # define ATOMIC_FOO __GCC_ATOMIC_FOO
  ...
  #endif



> 
> 
>> Also AFAIK MSVC leaves the implementation of atomics up to the library, not 
>> the frontend. So W/E MSVC's STL does it's likely not sane or desirable.
> 
> Wait what? How does that even work? This calls for a Twitter ping of Billy!




https://reviews.llvm.org/D32265



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

[PATCH] D32265: Add __CLANG_ATOMIC__LOCK_FREE macros for use in MSVC compatibility mode.

[Billy Robert O'Neal III via Phabricator via cfe-commits]

BillyONeal added a comment.

(sorry for double post)

And of course since you folks don't care about supporting pre-Vista you 
probably also don't care about supporting Opterons from 2005, in which case 
you'd want unconditional cmpxchg16b on amd64 :). In our next major version I 
added a configuration macro `_STD_ATOMIC_ALWAYS_USE_CMPXCHG16B` users can set 
to ask for that.


https://reviews.llvm.org/D32265



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

[PATCH] D30773: Make git-clang-format python 3 compatible

[Eric Fiselier via Phabricator via cfe-commits]

EricWF updated this revision to Diff 96025.
EricWF added a comment.

I've committed all but the `str` vs `byte` changes upstream.


https://reviews.llvm.org/D30773

Files:
  tools/clang-format/git-clang-format


Index: tools/clang-format/git-clang-format
===
--- tools/clang-format/git-clang-format
+++ tools/clang-format/git-clang-format
@@ -20,7 +20,7 @@
 For further details, run:  
  
 git clang-format -h
  

  
-Requires Python 2.7
  
+Requires Python 2.7 or Python 3
  
 """   
 
 from __future__ import print_function
@@ -258,7 +258,7 @@
   stdout, stderr = p.communicate()
   if p.returncode != 0:
 return None
-  return stdout.strip()
+  return convert_string(stdout.strip())
 
 
 def compute_diff_and_extract_lines(commits, files):
@@ -301,6 +301,7 @@
   list of line `Range`s."""
   matches = {}
   for line in patch_file:
+line = convert_string(line)
 match = re.search(r'^\+\+\+\ [^/]+/(.*)', line)
 if match:
   filename = match.group(1).rstrip('\r\n')
@@ -385,7 +386,7 @@
   with temporary_index_file():
 p = subprocess.Popen(cmd, stdin=subprocess.PIPE)
 for line in input_lines:
-  p.stdin.write('%s\0' % line)
+  p.stdin.write(to_bytes('%s\0' % line))
 p.stdin.close()
 if p.wait() != 0:
   die('`%s` failed' % ' '.join(cmd))
@@ -440,7 +441,7 @@
 die('`%s` failed' % ' '.join(clang_format_cmd))
   if git_show and git_show.wait() != 0:
 die('`%s` failed' % ' '.join(git_show_cmd))
-  return stdout.rstrip('\r\n')
+  return convert_string(stdout).rstrip('\r\n')
 
 
 @contextlib.contextmanager
@@ -527,6 +528,10 @@
   p = subprocess.Popen(args, stdout=subprocess.PIPE, stderr=subprocess.PIPE,
stdin=subprocess.PIPE)
   stdout, stderr = p.communicate(input=stdin)
+
+  stdout = convert_string(stdout)
+  stderr = convert_string(stderr)
+
   if p.returncode == 0:
 if stderr:
   if verbose:
@@ -547,5 +552,26 @@
   sys.exit(2)
 
 
+def to_bytes(str_input):
+# Encode to UTF-8 to get binary data.
+if isinstance(str_input, bytes):
+return str_input
+return str_input.encode('utf-8')
+
+
+def to_string(bytes_input):
+if isinstance(bytes_input, str):
+return bytes_input
+return bytes_input.encode('utf-8')
+
+
+def convert_string(bytes_input):
+try:
+return to_string(bytes_input.decode('utf-8'))
+except AttributeError: # 'str' object has no attribute 'decode'.
+return str(bytes_input)
+except UnicodeError:
+return str(bytes_input)
+
 if __name__ == '__main__':
   main()


Index: tools/clang-format/git-clang-format
===
--- tools/clang-format/git-clang-format
+++ tools/clang-format/git-clang-format
@@ -20,7 +20,7 @@
 For further details, run:
 git clang-format -h  
  
-Requires Python 2.7  
+Requires Python 2.7 or Python 3  
 """   
 
 from __future__ import print_function
@@ -258,7 +258,7 @@
   stdout, stderr = p.communicate()
   if p.returncode != 0:
 return None
-  return stdout.strip()
+  return convert_string(stdout.strip())
 
 
 def compute_diff_and_extract_lines(commits, files):
@@ -301,6 +301,7 @@
   list of line `Range`s."""
   matches = {}
   for line in patch_file:
+line = convert_string(line)
 match = re.search(r'^\+\+\+\ [^/]+/(.*)', line)
 if match:
   filename = match.group(1).rstrip('\r\n')
@@ -385,7 +386,7 @@
   with temporary_index_file():
 p = subprocess.Popen(cmd, stdin=subprocess.PIPE)
 for line in input_lines:
-  p.stdin.write('%s\0' % line)
+  p.stdin.write(to_bytes('%s\0' % line))
 p.stdin.close()
 if p.wait() != 0:
   die('`%s` failed' % ' '.join(cmd))
@@ -440,7 +441,7 @@
 die('`%s` failed' % ' '.join(clang_format_cmd))
   if git_show and git_show.wait() != 0:
 die('`%s` failed' % ' '.join(git_show_cmd))
-  return stdout.rstrip('\r\n')
+  return convert_string(stdout).rstrip('\r\n')
 
 
 @contextlib.contextmanager
@@ -527,6 +528,10 @@
   p = subprocess.Popen(args, stdout=subprocess.PIPE, stderr=subprocess.PIPE,
stdin=subprocess.PIPE)
   stdout, stderr = p.communicate(input=stdin)
+
+  stdout = convert_string(stdout)
+  stderr = convert_string(stderr)
+
   if p.returncode == 0:
 if stderr:
   if verbose:
@@ -547,5 +552,26 @

[PATCH] D32265: Add __CLANG_ATOMIC__LOCK_FREE macros for use in MSVC compatibility mode.

[Billy Robert O'Neal III via Phabricator via cfe-commits]

BillyONeal added a comment.

In https://reviews.llvm.org/D32265#731709, @jfb wrote:

> Is it a goal to support Microsoft's STL with this? If so, how does MSVC's STL 
> implement `is_always_lock_free` at the moment? CL 19 2017 RTW doesn't seem to 
> have anything ? Presumably they'll have to do 
> *something*.


Our STL implements  entirely as a library feature (on top of the 
_InterlockedXxx intrinsics and alignas).


https://reviews.llvm.org/D32265



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

[PATCH] D32313: [clang-tidy] Don't turn .push_back({1, 2}) into .emplace_back(1, 2) for pairs

[Jakub Kuderski via Phabricator via cfe-commits]

kuhar created this revision.
kuhar added a project: clang-tools-extra.

This patch prevents modernize-use-emplace from changing push_backs of brace 
initialized pairs (`.push_back({1, 2})`) to `.emplace_back(1, 2)`.
Pair's constructor doesn't have any interesting logic and basically performs 
aggregate initialization. There also doesn't seem to be much win
in terms of making code more concise, thus is makes little sense to turn such 
push_back calls into emplace_backs.

The change is inspired by the recent discussion on changing and enforcing 
coding guidelines:
[llvm-dev] [cfe-dev] Modernizing LLVM Coding Style Guide andenforcing 
Clang-tidy
http://lists.llvm.org/pipermail/llvm-dev/2016-December/108559.html


https://reviews.llvm.org/D32313

Files:
  clang-tidy/modernize/UseEmplaceCheck.cpp
  clang-tidy/modernize/UseEmplaceCheck.h
  test/clang-tidy/modernize-use-emplace.cpp


Index: test/clang-tidy/modernize-use-emplace.cpp
===
--- test/clang-tidy/modernize-use-emplace.cpp
+++ test/clang-tidy/modernize-use-emplace.cpp
@@ -186,6 +186,11 @@
   // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use emplace_back
   // CHECK-FIXES: v.emplace_back(1, 2);
 
+  v.push_back({1, 2});
+  v.push_back(std::pair{1, 2});
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use emplace_back
+  // CHECK-FIXES: v.emplace_back(1, 2);
+
   GetPair g;
   v.push_back(g.getPair());
   // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use emplace_back
Index: clang-tidy/modernize/UseEmplaceCheck.h
===
--- clang-tidy/modernize/UseEmplaceCheck.h
+++ clang-tidy/modernize/UseEmplaceCheck.h
@@ -35,6 +35,7 @@
 private:
   std::vector ContainersWithPushBack;
   std::vector SmartPointers;
+  std::vector PairTypes;
 };
 
 } // namespace modernize
Index: clang-tidy/modernize/UseEmplaceCheck.cpp
===
--- clang-tidy/modernize/UseEmplaceCheck.cpp
+++ clang-tidy/modernize/UseEmplaceCheck.cpp
@@ -19,13 +19,16 @@
 "::std::vector; ::std::list; ::std::deque";
 static const auto DefaultSmartPointers =
 "::std::shared_ptr; ::std::unique_ptr; ::std::auto_ptr; ::std::weak_ptr";
+static const auto DefaultPairTypes = "::std::pair";
 
 UseEmplaceCheck::UseEmplaceCheck(StringRef Name, ClangTidyContext *Context)
 : ClangTidyCheck(Name, Context),
   ContainersWithPushBack(utils::options::parseStringList(Options.get(
   "ContainersWithPushBack", DefaultContainersWithPushBack))),
   SmartPointers(utils::options::parseStringList(
-  Options.get("SmartPointers", DefaultSmartPointers))) {}
+  Options.get("SmartPointers", DefaultSmartPointers))),
+  PairTypes(utils::options::parseStringList(
+  Options.get("PairTypes", DefaultPairTypes))) {}
 
 void UseEmplaceCheck::registerMatchers(MatchFinder *Finder) {
   if (!getLangOpts().CPlusPlus11)
@@ -72,11 +75,19 @@
   auto hasInitList = has(ignoringImplicit(initListExpr()));
   // FIXME: Discard 0/NULL (as nullptr), static inline const data members,
   // overloaded functions and template names.
+
+  // Ignore push_back({first, second}) for pair types (eg. std::pair).
+  auto isPairBraceInit = expr(allOf(cxxConstructExpr(hasDeclaration(
+  cxxConstructorDecl(ofClass(hasAnyName(SmallVector(
+  PairTypes.begin(), PairTypes.end())),
+unless(cxxTemporaryObjectExpr())),
+  unless(hasParent(implicitCastExpr(;
+
   auto soughtConstructExpr =
   cxxConstructExpr(
   unless(anyOf(isCtorOfSmartPtr, hasInitList, bitFieldAsArgument,
initializerListAsArgument, newExprAsArgument,
-   constructingDerived, isPrivateCtor)))
+   constructingDerived, isPrivateCtor, isPairBraceInit)))
   .bind("ctor");
   auto hasConstructExpr = has(ignoringImplicit(soughtConstructExpr));
 


Index: test/clang-tidy/modernize-use-emplace.cpp
===
--- test/clang-tidy/modernize-use-emplace.cpp
+++ test/clang-tidy/modernize-use-emplace.cpp
@@ -186,6 +186,11 @@
   // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use emplace_back
   // CHECK-FIXES: v.emplace_back(1, 2);
 
+  v.push_back({1, 2});
+  v.push_back(std::pair{1, 2});
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use emplace_back
+  // CHECK-FIXES: v.emplace_back(1, 2);
+
   GetPair g;
   v.push_back(g.getPair());
   // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use emplace_back
Index: clang-tidy/modernize/UseEmplaceCheck.h
===
--- clang-tidy/modernize/UseEmplaceCheck.h
+++ clang-tidy/modernize/UseEmplaceCheck.h
@@ -35,6 +35,7 @@
 private:
   std::vector ContainersWithPushBack;
   std::vector SmartPointers;
+  std::vector PairTypes;
 };
 
 } // namespace modernize
Index: clang-tidy/moderniz

[PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

[Richard Smith via Phabricator via cfe-commits]

rsmith added a comment.

In https://reviews.llvm.org/D32199#732189, @hfinkel wrote:

> In https://reviews.llvm.org/D32199#731472, @rsmith wrote:
>
> > 1. C's "effective type" rule allows writes to set the type pretty much 
> > unconditionally, unless the storage is for a variable with a declared type
>
>
> To come back to this point: We don't really implement these rules now, and it 
> is not clear that we will. The problem here is that, if we take the 
> specification literally, then we can't use our current TBAA at all. The 
> problem is that if we have:
>
>   write x, !tbaa "int"
>   read x, !tbaa "int"
>   write x, !tbaa "float"
>   
>
> TBAA will currently tell us that the "float" write aliases with neither the 
> preceding read nor the preceding write.


Right, C's TBAA rules do not (in general) permit a store to be reordered before 
a memory operation of a different type, they only allow loads to be moved 
before stores. (Put another way, they do not tell you that pointers point to 
distinct memory locations, just that a stored value cannot be observed by a 
load of a different type.) You get the more general "distinct memory locations" 
result only for objects of a declared type.

C++ is similar, except that (because object lifetimes do not currently begin 
magically due to a store) you /can/ reorder stores past a memory operation of a 
different type if you know no object's lifetime began in between. (But 
currently we do not record all lifetime events in IR, so we can't do that 
today. Also, we may be about to lose the property that you can statically 
determine a small number of places that might start an object lifetime.)

> Also, a strict reading of C's access rules seems to rule out the premise 
> underlying our struct-path TBAA entirely. So long as I'm accessing a value 
> using a struct that has some member, including recursively, with that type, 
> then it's fine. The matching of the relative offsets is a sufficient, but not 
> necessary, condition for well-defined access. C++ has essentially the same 
> language (and, thus, potentially the same problem).

I agree this rule is garbage, but it's not as permissive as I think you're 
suggesting. The rule says that you can use an lvalue of struct type to access 
memory of struct field type. In C this happens during struct assignment, for 
instance. It does *not* permit using an lvalue of struct field type to access 
unrelated fields of the same struct. So C appears to allow this nonsense:

  char *p = malloc(8);
  *(int*)p = 0;
  *(int*)(p + 4) = 0;
  struct S {int n; float f;} s = *(struct S*)p; // use lvalue of type `struct 
S` to access object of effective type `int`, to initialize a `float`

but not this nonsense:

  float q = ((struct S*)p)->f; // ub, cannot use lvalue of type `float` to 
access object of effective type `int`

... which just means that we can't make much use of TBAA when emitting struct 
copies in C.

In C++, on the other hand, the rule is even more garbage, since there is no way 
to perform a memory access with a glvalue of class type. (The closest you get 
is that a defaulted union construction/assignment copies the object 
representation, but that's expressed in terms of copying a sequence of unsigned 
chars, and in any case those are member functions and so already require an 
object of the correct type to exist.) See wg21.link/cwg2051

> While I'd like the sanitizer to follow the rules, that's really useful only 
> to the extent that the compilers follow the rules. If the compilers are 
> making stronger assumptions, then I think that the sanitizer should also.

I agree.

>> If we want to follow the relevant language rules by default, that would 
>> suggest that "writes always set the type" should be enabled by default in C 
>> and disabled by default in C++. That may not be the right decision for other 
>> reasons, though. In C++, writes through union members and new-expressions 
>> should probably (re)set the type (do you have intrinsics the frontend can 
>> use to do so?).
> 
> Also, in C, memcpy gets to copy the type for a destination that does not have 
> declared types. It looks like the same is true for C++ for trivially-copyable 
> types. Is the first read/write sets the unknown type (i.e. memory from 
> malloc/calloc/memset, etc.) correct for C++ also?

As I recall, "store can create an object" is the broad direction that SG12 
agreed on for the cases where you have a pointer into a raw storage buffer 
(that is, a char array), and we want the low-level storage allocation functions 
to give us such a buffer.


https://reviews.llvm.org/D32199



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

[PATCH] D32294: [clang-tidy] run-clang-tidy.py: check if clang-apply-replacements succeeds

[Piotr Padlewski via Phabricator via cfe-commits]

Prazek accepted this revision.
Prazek added a comment.

LGTM, but please leave the FIXME comment about the running of apply replacement


https://reviews.llvm.org/D32294



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

[PATCH] D32265: Add __CLANG_ATOMIC__LOCK_FREE macros for use in MSVC compatibility mode.

[Richard Smith via Phabricator via cfe-commits]

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

I'm not thrilled about adding yet more predefined macros, but it really doesn't 
make sense for libc++ to depend on `__GCC_*` macros when targeting Windows, nor 
for these to be Windows-only, so let's do it.




Comment at: lib/Frontend/InitPreprocessor.cpp:910-912
+  addLockFreeMacros("__CLANG_ATOMIC");
+  if (!LangOpts.MSVCCompat)
+addLockFreeMacros("__GCC_ATOMIC");

I'd sink the `_` into the prefix too, but this looks fine either way.


https://reviews.llvm.org/D32265



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

r300908 - Parse: cleanup some bleeding whitespace

[Saleem Abdulrasool via cfe-commits]

Author: compnerd
Date: Thu Apr 20 17:23:07 2017
New Revision: 300908

URL: http://llvm.org/viewvc/llvm-project?rev=300908&view=rev
Log:
Parse: cleanup some bleeding whitespace

Clean up some bleeding whitespace that I noticed.  NFC

Modified:
cfe/trunk/lib/Parse/ParseExpr.cpp

Modified: cfe/trunk/lib/Parse/ParseExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseExpr.cpp?rev=300908&r1=300907&r2=300908&view=diff
==
--- cfe/trunk/lib/Parse/ParseExpr.cpp (original)
+++ cfe/trunk/lib/Parse/ParseExpr.cpp Thu Apr 20 17:23:07 2017
@@ -339,7 +339,7 @@ Parser::ParseRHSOfBinaryExpression(ExprR
 ColonLoc = Tok.getLocation();
   }
 }
-
+
 // Code completion for the right-hand side of an assignment expression
 // goes through a special hook that takes the left-hand side into account.
 if (Tok.is(tok::code_completion) && NextTokPrec == prec::Assignment) {
@@ -347,7 +347,7 @@ Parser::ParseRHSOfBinaryExpression(ExprR
   cutOffParsing();
   return ExprError();
 }
-
+
 // Parse another leaf here for the RHS of the operator.
 // ParseCastExpression works here because all RHS expressions in C have it
 // as a prefix, at least. However, in C++, an assignment-expression could
@@ -456,6 +456,7 @@ Parser::ParseRHSOfBinaryExpression(ExprR
   if (!getLangOpts().CPlusPlus)
 continue;
 }
+
 // Ensure potential typos aren't left undiagnosed.
 if (LHS.isInvalid()) {
   Actions.CorrectDelayedTyposInExpr(OrigLHS);


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

r300909 - Sema: protect against ObjC++ typo-correction failure

[Saleem Abdulrasool via cfe-commits]

Author: compnerd
Date: Thu Apr 20 17:23:10 2017
New Revision: 300909

URL: http://llvm.org/viewvc/llvm-project?rev=300909&view=rev
Log:
Sema: protect against ObjC++ typo-correction failure

ObjC++ has two different types of "pointer" types (ObjCClassPointerType
and PointerType).  Both can be indirected through.  However, the former
is not a member expression.  Ensure that we do not try to rebuild the
MRE in that case.

Added:
cfe/trunk/test/SemaObjCXX/pr32725.mm
Modified:
cfe/trunk/lib/Sema/TreeTransform.h

Modified: cfe/trunk/lib/Sema/TreeTransform.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/TreeTransform.h?rev=300909&r1=300908&r2=300909&view=diff
==
--- cfe/trunk/lib/Sema/TreeTransform.h (original)
+++ cfe/trunk/lib/Sema/TreeTransform.h Thu Apr 20 17:23:10 2017
@@ -2220,6 +2220,9 @@ public:
 Base = BaseResult.get();
 QualType BaseType = Base->getType();
 
+if (isArrow && !BaseType->isPointerType())
+  return ExprError();
+
 // FIXME: this involves duplicating earlier analysis in a lot of
 // cases; we should avoid this when possible.
 LookupResult R(getSema(), MemberNameInfo, Sema::LookupMemberName);

Added: cfe/trunk/test/SemaObjCXX/pr32725.mm
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaObjCXX/pr32725.mm?rev=300909&view=auto
==
--- cfe/trunk/test/SemaObjCXX/pr32725.mm (added)
+++ cfe/trunk/test/SemaObjCXX/pr32725.mm Thu Apr 20 17:23:10 2017
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -triple x86_64-apple-macosx -fsyntax-only -verify -x 
objective-c++ %s -o /dev/null
+// REQUIRES: asserts
+
+struct objc_class {
+  unsigned long long bits;
+};
+typedef struct objc_class *Class;
+static void f(Class c) { (void)(c->bits & RW_HAS_OVERFLOW_REFCOUNT); }
+// expected-error@-1{{use of undeclared identifier 'RW_HAS_OVERFLOW_REFCOUNT}}


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

Re: [llvm-dev] Permissions for llvm-mirror - Setting up Libc++ Appveyor builders

[Mehdi Amini via cfe-commits]

> On Apr 20, 2017, at 12:30 PM, Eric Fiselier  wrote:
> 
> 
> 
> On Thu, Apr 20, 2017 at 11:06 AM, Mehdi Amini  > wrote:
> 
>> On Apr 20, 2017, at 12:39 AM, Eric Fiselier > > wrote:
>> 
>> 
>> 
>> On Wed, Apr 19, 2017 at 11:19 PM, Mehdi Amini > > wrote:
>> What would be the status of these buildbots? Is it for your private usage? 
>> 
>> I intend for them to be public Windows buildbots for libc++.
> 
> 
> I’m not sure it’d be OK to send blame email to contributors based on this 
> though.
> 
> I don't see why not (at least once the bot is stable). Can you elaborate?

I don’t think there is a precedent for having a bot that does not checkout from 
SVN and email using the canonical SVN revision number.

So it does not seems like a given to me  (not that I’m against it) and would 
require a discussion on the mailing-list first IMO.

— 
Mehdi




>  
> /Eric
> 
> 
> — 
> Mehdi
> 
> 
>> 
>> Otherwise having “project' bots” using a non-official mirror may sound like 
>> a strange situation to me.
>> 
>> I agree it isn't ideal, but when/if LLVM moves to github it will be trivial 
>> to re-configure for the official repositories.
>> I considered a number of other ways to setup Appveyor but I concluded this 
>> was the best/easiest way to do it.
>> The other options I considered for configuring Appveyor are:
>> 
>> (1) Use the official LLVM github mirrors.
>>  
>> This has the issue of requiring the implementation of custom Git webhooks, 
>> which would require
>> modifying and maintaining changes to the existing LLVM Git infrastructure, 
>> which in itself
>> would require getting access to the LLVM servers to make the changes.
>> 
>> (2) Setup my own ever more unofficial github mirror 
>> 
>> This has all the same problems as using the existing github mirrors but it 
>> requires
>> me to configure and maintain my own mirror, which is non-trivial.
>> 
>> (3) Don't use Appveyor at all
>> 
>> This requires finding Windows hardware to host the bots, which is the main 
>> reason
>> I chose Appveyor to begin with. Even if hardware was available I would 
>> prefer using
>> Appveyor since it provides more dominion over the environment than I think
>> donated hardware could.
>> 
>> /Eric
>> 
>> 
>> — 
>> Mehdi
>> 
>>> On Apr 19, 2017, at 5:04 PM, Eric Fiselier via llvm-dev 
>>> mailto:llvm-...@lists.llvm.org>> wrote:
>>> 
>>> Adding cfe-dev list...
>>> 
>>> On Wed, Apr 19, 2017 at 5:50 PM, Eric Fiselier >> > wrote:
>>> Hi Will,
>>> 
>>> I would like to request collaborator permissions for the Libc++ github 
>>> mirror.
>>> 
>>> I plan to use the access to setup Appveyor buildbots for libc++. In order 
>>> to do this I need to be listed as a collaborator on Github. 
>>> 
>>> The alternative to Github access would be setting up the correct webhooks 
>>> for llvm.org/git/libcxx.git , but this 
>>> seems harder to both do and maintain.
>>> 
>>> /Eric
>>> 
>>> ___
>>> LLVM Developers mailing list
>>> llvm-...@lists.llvm.org 
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev 
>>> 
>> 
>> 
> 
> 

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

[PATCH] D32320: [libc++] Default to vcruntime when targeting MSVC

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai created this revision.
Herald added a subscriber: mgorny.

libc++abi is never the right option for LIBCXX_TARGETING_MSVC, since it
targets the Itanium ABI, whereas MSVC uses the Microsoft ABI. Make the
default ABI be vcruntime when targeting MSVC even if libc++abi is
present in the tree.


https://reviews.llvm.org/D32320

Files:
  CMakeLists.txt


Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -113,27 +113,29 @@
 
 # Setup the default options if LIBCXX_CXX_ABI is not specified.
 if (LIBCXX_CXX_ABI STREQUAL "default")
-  find_path(
-LIBCXX_LIBCXXABI_INCLUDES_INTERNAL
-cxxabi.h
-PATHS ${LLVM_MAIN_SRC_DIR}/projects/libcxxabi/include
-  ${LLVM_MAIN_SRC_DIR}/runtimes/libcxxabi/include
-NO_DEFAULT_PATH
-  )
-  if ((NOT LIBCXX_STANDALONE_BUILD OR HAVE_LIBCXXABI) AND
-  IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
-set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
-set(LIBCXX_CXX_ABI_INCLUDE_PATHS "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
-set(LIBCXX_CXX_ABI_INTREE 1)
+  if (LIBCXX_TARGETING_MSVC)
+# FIXME: Figure out how to configure the ABI library on Windows.
+set(LIBCXX_CXX_ABI_LIBNAME "vcruntime")
   else()
-if (LIBCXX_TARGETING_MSVC)
-  # FIXME: Figure out how to configure the ABI library on Windows.
-  set(LIBCXX_CXX_ABI_LIBNAME "vcruntime")
-elseif(APPLE)
+find_path(
+  LIBCXX_LIBCXXABI_INCLUDES_INTERNAL
+  cxxabi.h
+  PATHS ${LLVM_MAIN_SRC_DIR}/projects/libcxxabi/include
+${LLVM_MAIN_SRC_DIR}/runtimes/libcxxabi/include
+  NO_DEFAULT_PATH
+)
+if ((NOT LIBCXX_STANDALONE_BUILD OR HAVE_LIBCXXABI) AND
+IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
   set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
-  set(LIBCXX_CXX_ABI_SYSTEM 1)
+  set(LIBCXX_CXX_ABI_INCLUDE_PATHS "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
+  set(LIBCXX_CXX_ABI_INTREE 1)
 else()
-  set(LIBCXX_CXX_ABI_LIBNAME "default")
+  if (APPLE)
+set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
+set(LIBCXX_CXX_ABI_SYSTEM 1)
+  else()
+set(LIBCXX_CXX_ABI_LIBNAME "default")
+  endif()
 endif()
   endif()
 else()


Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -113,27 +113,29 @@
 
 # Setup the default options if LIBCXX_CXX_ABI is not specified.
 if (LIBCXX_CXX_ABI STREQUAL "default")
-  find_path(
-LIBCXX_LIBCXXABI_INCLUDES_INTERNAL
-cxxabi.h
-PATHS ${LLVM_MAIN_SRC_DIR}/projects/libcxxabi/include
-  ${LLVM_MAIN_SRC_DIR}/runtimes/libcxxabi/include
-NO_DEFAULT_PATH
-  )
-  if ((NOT LIBCXX_STANDALONE_BUILD OR HAVE_LIBCXXABI) AND
-  IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
-set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
-set(LIBCXX_CXX_ABI_INCLUDE_PATHS "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
-set(LIBCXX_CXX_ABI_INTREE 1)
+  if (LIBCXX_TARGETING_MSVC)
+# FIXME: Figure out how to configure the ABI library on Windows.
+set(LIBCXX_CXX_ABI_LIBNAME "vcruntime")
   else()
-if (LIBCXX_TARGETING_MSVC)
-  # FIXME: Figure out how to configure the ABI library on Windows.
-  set(LIBCXX_CXX_ABI_LIBNAME "vcruntime")
-elseif(APPLE)
+find_path(
+  LIBCXX_LIBCXXABI_INCLUDES_INTERNAL
+  cxxabi.h
+  PATHS ${LLVM_MAIN_SRC_DIR}/projects/libcxxabi/include
+${LLVM_MAIN_SRC_DIR}/runtimes/libcxxabi/include
+  NO_DEFAULT_PATH
+)
+if ((NOT LIBCXX_STANDALONE_BUILD OR HAVE_LIBCXXABI) AND
+IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
   set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
-  set(LIBCXX_CXX_ABI_SYSTEM 1)
+  set(LIBCXX_CXX_ABI_INCLUDE_PATHS "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
+  set(LIBCXX_CXX_ABI_INTREE 1)
 else()
-  set(LIBCXX_CXX_ABI_LIBNAME "default")
+  if (APPLE)
+set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
+set(LIBCXX_CXX_ABI_SYSTEM 1)
+  else()
+set(LIBCXX_CXX_ABI_LIBNAME "default")
+  endif()
 endif()
   endif()
 else()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r300914 - Add __CLANG_ATOMIC__LOCK_FREE macros for use in MSVC compatibility mode.

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Thu Apr 20 17:53:57 2017
New Revision: 300914

URL: http://llvm.org/viewvc/llvm-project?rev=300914&view=rev
Log:
Add __CLANG_ATOMIC__LOCK_FREE macros for use in MSVC compatibility mode.

Summary:
Libc++ currently implements the `ATOMIC__LOCK_FREE` macros using the 
`__GCC_ATOMIC__LOCK_FREE` macros. However these are not available when 
MSVC compatibility is enabled even though C11 `_Atomic` is.  This prevents 
libc++ from correctly implementing `ATOMIC__LOCK_FREE`.

This patch adds an alternative spelling `__CLANG_ATOMIC__LOCK_FREE` that 
is enabled with `-fms-compatibility`.

Reviewers: rsmith, aaron.ballman, majnemer, zturner, compnerd, jfb, rnk

Reviewed By: rsmith

Subscribers: BillyONeal, smeenai, jfb, cfe-commits, dschuff

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

Modified:
cfe/trunk/lib/Frontend/InitPreprocessor.cpp
cfe/trunk/test/Preprocessor/init.c
cfe/trunk/test/Sema/atomic-ops.c

Modified: cfe/trunk/lib/Frontend/InitPreprocessor.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/InitPreprocessor.cpp?rev=300914&r1=300913&r2=300914&view=diff
==
--- cfe/trunk/lib/Frontend/InitPreprocessor.cpp (original)
+++ cfe/trunk/lib/Frontend/InitPreprocessor.cpp Thu Apr 20 17:53:57 2017
@@ -882,14 +882,16 @@ static void InitializePredefinedMacros(c
 // The value written by __atomic_test_and_set.
 // FIXME: This is target-dependent.
 Builder.defineMacro("__GCC_ATOMIC_TEST_AND_SET_TRUEVAL", "1");
+  }
 
+  auto addLockFreeMacros = [&](const llvm::Twine &Prefix) {
 // Used by libc++ and libstdc++ to implement ATOMIC__LOCK_FREE.
 unsigned InlineWidthBits = TI.getMaxAtomicInlineWidth();
-#define DEFINE_LOCK_FREE_MACRO(TYPE, Type) \
-Builder.defineMacro("__GCC_ATOMIC_" #TYPE "_LOCK_FREE", \
-getLockFreeValue(TI.get##Type##Width(), \
- TI.get##Type##Align(), \
- InlineWidthBits));
+#define DEFINE_LOCK_FREE_MACRO(TYPE, Type) 
\
+  Builder.defineMacro(Prefix + #TYPE "_LOCK_FREE", 
\
+  getLockFreeValue(TI.get##Type##Width(),  
\
+   TI.get##Type##Align(),  
\
+   InlineWidthBits));
 DEFINE_LOCK_FREE_MACRO(BOOL, Bool);
 DEFINE_LOCK_FREE_MACRO(CHAR, Char);
 DEFINE_LOCK_FREE_MACRO(CHAR16_T, Char16);
@@ -899,12 +901,15 @@ static void InitializePredefinedMacros(c
 DEFINE_LOCK_FREE_MACRO(INT, Int);
 DEFINE_LOCK_FREE_MACRO(LONG, Long);
 DEFINE_LOCK_FREE_MACRO(LLONG, LongLong);
-Builder.defineMacro("__GCC_ATOMIC_POINTER_LOCK_FREE",
+Builder.defineMacro(Prefix + "POINTER_LOCK_FREE",
 getLockFreeValue(TI.getPointerWidth(0),
  TI.getPointerAlign(0),
  InlineWidthBits));
 #undef DEFINE_LOCK_FREE_MACRO
-  }
+  };
+  addLockFreeMacros("__CLANG_ATOMIC_");
+  if (!LangOpts.MSVCCompat)
+addLockFreeMacros("__GCC_ATOMIC_");
 
   if (LangOpts.NoInlineDefine)
 Builder.defineMacro("__NO_INLINE__");

Modified: cfe/trunk/test/Preprocessor/init.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Preprocessor/init.c?rev=300914&r1=300913&r2=300914&view=diff
==
--- cfe/trunk/test/Preprocessor/init.c (original)
+++ cfe/trunk/test/Preprocessor/init.c Thu Apr 20 17:53:57 2017
@@ -8846,6 +8846,16 @@
 // WEBASSEMBLY32-NEXT:#define __CHAR32_TYPE__ unsigned int
 // WEBASSEMBLY32-NEXT:#define __CHAR_BIT__ 8
 // WEBASSEMBLY32-NOT:#define __CHAR_UNSIGNED__
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_BOOL_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_CHAR16_T_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_CHAR32_T_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_CHAR_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_INT_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_LLONG_LOCK_FREE 1
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_LONG_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_POINTER_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_SHORT_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_WCHAR_T_LOCK_FREE 2
 // WEBASSEMBLY32-NEXT:#define __CONSTANT_CFSTRINGS__ 1
 // WEBASSEMBLY32-NEXT:#define __DBL_DECIMAL_DIG__ 17
 // WEBASSEMBLY32-NEXT:#define __DBL_DENORM_MIN__ 4.9406564584124654e-324
@@ -9162,6 +9172,16 @@
 // WEBASSEMBLY64-NEXT:#define __CHAR32_TYPE__ unsigned int
 // WEBASSEMBLY64-NEXT:#define __CHAR_BIT__ 8
 // WEBASSEMBLY64-NOT:#define __CHAR_UNSIGNED__
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_BOOL_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_CHAR16_T_LOCK_FREE 2
+// WEBASSEMBLY

[PATCH] D32265: Add __CLANG_ATOMIC__LOCK_FREE macros for use in MSVC compatibility mode.

[Eric Fiselier via Phabricator via cfe-commits]

EricWF updated this revision to Diff 96043.
EricWF added a comment.

- Address inline comments.


https://reviews.llvm.org/D32265

Files:
  lib/Frontend/InitPreprocessor.cpp
  test/Preprocessor/init.c
  test/Sema/atomic-ops.c

Index: test/Sema/atomic-ops.c
===
--- test/Sema/atomic-ops.c
+++ test/Sema/atomic-ops.c
@@ -7,19 +7,29 @@
 struct S { char c[3]; };
 
 _Static_assert(__GCC_ATOMIC_BOOL_LOCK_FREE == 2, "");
+_Static_assert(__GCC_ATOMIC_BOOL_LOCK_FREE == __CLANG_ATOMIC_BOOL_LOCK_FREE, "");
 _Static_assert(__GCC_ATOMIC_CHAR_LOCK_FREE == 2, "");
+_Static_assert(__GCC_ATOMIC_CHAR_LOCK_FREE == __CLANG_ATOMIC_CHAR_LOCK_FREE, "");
 _Static_assert(__GCC_ATOMIC_CHAR16_T_LOCK_FREE == 2, "");
+_Static_assert(__GCC_ATOMIC_CHAR16_T_LOCK_FREE == __CLANG_ATOMIC_CHAR16_T_LOCK_FREE, "");
 _Static_assert(__GCC_ATOMIC_CHAR32_T_LOCK_FREE == 2, "");
+_Static_assert(__GCC_ATOMIC_CHAR32_T_LOCK_FREE == __CLANG_ATOMIC_CHAR32_T_LOCK_FREE, "");
 _Static_assert(__GCC_ATOMIC_WCHAR_T_LOCK_FREE == 2, "");
+_Static_assert(__GCC_ATOMIC_WCHAR_T_LOCK_FREE == __CLANG_ATOMIC_WCHAR_T_LOCK_FREE, "");
 _Static_assert(__GCC_ATOMIC_SHORT_LOCK_FREE == 2, "");
+_Static_assert(__GCC_ATOMIC_SHORT_LOCK_FREE == __CLANG_ATOMIC_SHORT_LOCK_FREE, "");
 _Static_assert(__GCC_ATOMIC_INT_LOCK_FREE == 2, "");
+_Static_assert(__GCC_ATOMIC_INT_LOCK_FREE == __CLANG_ATOMIC_INT_LOCK_FREE, "");
 _Static_assert(__GCC_ATOMIC_LONG_LOCK_FREE == 2, "");
+_Static_assert(__GCC_ATOMIC_LONG_LOCK_FREE == __CLANG_ATOMIC_LONG_LOCK_FREE, "");
 #ifdef __i386__
 _Static_assert(__GCC_ATOMIC_LLONG_LOCK_FREE == 1, "");
 #else
 _Static_assert(__GCC_ATOMIC_LLONG_LOCK_FREE == 2, "");
 #endif
+_Static_assert(__GCC_ATOMIC_LLONG_LOCK_FREE == __CLANG_ATOMIC_LLONG_LOCK_FREE, "");
 _Static_assert(__GCC_ATOMIC_POINTER_LOCK_FREE == 2, "");
+_Static_assert(__GCC_ATOMIC_POINTER_LOCK_FREE == __CLANG_ATOMIC_POINTER_LOCK_FREE, "");
 
 _Static_assert(__c11_atomic_is_lock_free(1), "");
 _Static_assert(__c11_atomic_is_lock_free(2), "");
Index: test/Preprocessor/init.c
===
--- test/Preprocessor/init.c
+++ test/Preprocessor/init.c
@@ -8846,6 +8846,16 @@
 // WEBASSEMBLY32-NEXT:#define __CHAR32_TYPE__ unsigned int
 // WEBASSEMBLY32-NEXT:#define __CHAR_BIT__ 8
 // WEBASSEMBLY32-NOT:#define __CHAR_UNSIGNED__
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_BOOL_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_CHAR16_T_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_CHAR32_T_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_CHAR_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_INT_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_LLONG_LOCK_FREE 1
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_LONG_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_POINTER_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_SHORT_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_WCHAR_T_LOCK_FREE 2
 // WEBASSEMBLY32-NEXT:#define __CONSTANT_CFSTRINGS__ 1
 // WEBASSEMBLY32-NEXT:#define __DBL_DECIMAL_DIG__ 17
 // WEBASSEMBLY32-NEXT:#define __DBL_DENORM_MIN__ 4.9406564584124654e-324
@@ -9162,6 +9172,16 @@
 // WEBASSEMBLY64-NEXT:#define __CHAR32_TYPE__ unsigned int
 // WEBASSEMBLY64-NEXT:#define __CHAR_BIT__ 8
 // WEBASSEMBLY64-NOT:#define __CHAR_UNSIGNED__
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_BOOL_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_CHAR16_T_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_CHAR32_T_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_CHAR_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_INT_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_LLONG_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_LONG_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_POINTER_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_SHORT_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_WCHAR_T_LOCK_FREE 2
 // WEBASSEMBLY64-NEXT:#define __CONSTANT_CFSTRINGS__ 1
 // WEBASSEMBLY64-NEXT:#define __DBL_DECIMAL_DIG__ 17
 // WEBASSEMBLY64-NEXT:#define __DBL_DENORM_MIN__ 4.9406564584124654e-324
@@ -9637,3 +9657,36 @@
 // AVR:#define __WCHAR_MAX__ 32767
 // AVR:#define __WCHAR_TYPE__ int
 // AVR:#define __WINT_TYPE__ int
+
+
+// RUN: %clang_cc1 -E -dM -ffreestanding \
+// RUN:-triple i686-windows-msvc -fms-compatibility < /dev/null \
+// RUN:  | FileCheck -match-full-lines -check-prefix MSVC-X32 %s
+
+// RUN: %clang_cc1 -E -dM -ffreestanding \
+// RUN:-triple x86_64-windows-msvc -fms-compatibility < /dev/null \
+// RUN:  | FileCheck -match-full-lines -check-prefix MSVC-X64 %s
+
+// MSVC-X32:#define __CLANG_ATOMIC_BOOL_LOCK_FREE 2
+// MSVC-X32-NEXT:#define __CLANG_ATOMIC_CHAR16_T_LOCK_FREE 2
+// MSVC-X32-NEXT:#define __CLANG_ATOMIC_CHAR32_T_LOCK_FREE 2
+// MSVC-X32-NEXT:#define __CLANG_ATOMIC_CHAR_LOCK_FREE 2
+// MSVC-X32-NEXT:#define __CLANG_ATOMIC_INT_LOCK_FR

[PATCH] D32322: Use __CLANG_ATOMIC_TYPE_LOCK_FREE macros in `stdatomic.h`

[Eric Fiselier via Phabricator via cfe-commits]

EricWF created this revision.

This patch makes the header `stdatomic.h` work when `-fms-compatibility` is 
specified.


https://reviews.llvm.org/D32322

Files:
  lib/Headers/stdatomic.h
  test/Headers/stdatomic.c


Index: test/Headers/stdatomic.c
===
--- test/Headers/stdatomic.c
+++ test/Headers/stdatomic.c
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -std=c11 -E %s | FileCheck %s
+// RUN: %clang_cc1 -std=c11 -fms-compatibility -E %s | FileCheck %s
 #include 
 
 int bool_lock_free = ATOMIC_BOOL_LOCK_FREE;
Index: lib/Headers/stdatomic.h
===
--- lib/Headers/stdatomic.h
+++ lib/Headers/stdatomic.h
@@ -40,16 +40,16 @@
 
 /* 7.17.1 Introduction */
 
-#define ATOMIC_BOOL_LOCK_FREE   __GCC_ATOMIC_BOOL_LOCK_FREE
-#define ATOMIC_CHAR_LOCK_FREE   __GCC_ATOMIC_CHAR_LOCK_FREE
-#define ATOMIC_CHAR16_T_LOCK_FREE   __GCC_ATOMIC_CHAR16_T_LOCK_FREE
-#define ATOMIC_CHAR32_T_LOCK_FREE   __GCC_ATOMIC_CHAR32_T_LOCK_FREE
-#define ATOMIC_WCHAR_T_LOCK_FREE__GCC_ATOMIC_WCHAR_T_LOCK_FREE
-#define ATOMIC_SHORT_LOCK_FREE  __GCC_ATOMIC_SHORT_LOCK_FREE
-#define ATOMIC_INT_LOCK_FREE__GCC_ATOMIC_INT_LOCK_FREE
-#define ATOMIC_LONG_LOCK_FREE   __GCC_ATOMIC_LONG_LOCK_FREE
-#define ATOMIC_LLONG_LOCK_FREE  __GCC_ATOMIC_LLONG_LOCK_FREE
-#define ATOMIC_POINTER_LOCK_FREE__GCC_ATOMIC_POINTER_LOCK_FREE
+#define ATOMIC_BOOL_LOCK_FREE   __CLANG_ATOMIC_BOOL_LOCK_FREE
+#define ATOMIC_CHAR_LOCK_FREE   __CLANG_ATOMIC_CHAR_LOCK_FREE
+#define ATOMIC_CHAR16_T_LOCK_FREE   __CLANG_ATOMIC_CHAR16_T_LOCK_FREE
+#define ATOMIC_CHAR32_T_LOCK_FREE   __CLANG_ATOMIC_CHAR32_T_LOCK_FREE
+#define ATOMIC_WCHAR_T_LOCK_FREE__CLANG_ATOMIC_WCHAR_T_LOCK_FREE
+#define ATOMIC_SHORT_LOCK_FREE  __CLANG_ATOMIC_SHORT_LOCK_FREE
+#define ATOMIC_INT_LOCK_FREE__CLANG_ATOMIC_INT_LOCK_FREE
+#define ATOMIC_LONG_LOCK_FREE   __CLANG_ATOMIC_LONG_LOCK_FREE
+#define ATOMIC_LLONG_LOCK_FREE  __CLANG_ATOMIC_LLONG_LOCK_FREE
+#define ATOMIC_POINTER_LOCK_FREE__CLANG_ATOMIC_POINTER_LOCK_FREE
 
 /* 7.17.2 Initialization */
 


Index: test/Headers/stdatomic.c
===
--- test/Headers/stdatomic.c
+++ test/Headers/stdatomic.c
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -std=c11 -E %s | FileCheck %s
+// RUN: %clang_cc1 -std=c11 -fms-compatibility -E %s | FileCheck %s
 #include 
 
 int bool_lock_free = ATOMIC_BOOL_LOCK_FREE;
Index: lib/Headers/stdatomic.h
===
--- lib/Headers/stdatomic.h
+++ lib/Headers/stdatomic.h
@@ -40,16 +40,16 @@
 
 /* 7.17.1 Introduction */
 
-#define ATOMIC_BOOL_LOCK_FREE   __GCC_ATOMIC_BOOL_LOCK_FREE
-#define ATOMIC_CHAR_LOCK_FREE   __GCC_ATOMIC_CHAR_LOCK_FREE
-#define ATOMIC_CHAR16_T_LOCK_FREE   __GCC_ATOMIC_CHAR16_T_LOCK_FREE
-#define ATOMIC_CHAR32_T_LOCK_FREE   __GCC_ATOMIC_CHAR32_T_LOCK_FREE
-#define ATOMIC_WCHAR_T_LOCK_FREE__GCC_ATOMIC_WCHAR_T_LOCK_FREE
-#define ATOMIC_SHORT_LOCK_FREE  __GCC_ATOMIC_SHORT_LOCK_FREE
-#define ATOMIC_INT_LOCK_FREE__GCC_ATOMIC_INT_LOCK_FREE
-#define ATOMIC_LONG_LOCK_FREE   __GCC_ATOMIC_LONG_LOCK_FREE
-#define ATOMIC_LLONG_LOCK_FREE  __GCC_ATOMIC_LLONG_LOCK_FREE
-#define ATOMIC_POINTER_LOCK_FREE__GCC_ATOMIC_POINTER_LOCK_FREE
+#define ATOMIC_BOOL_LOCK_FREE   __CLANG_ATOMIC_BOOL_LOCK_FREE
+#define ATOMIC_CHAR_LOCK_FREE   __CLANG_ATOMIC_CHAR_LOCK_FREE
+#define ATOMIC_CHAR16_T_LOCK_FREE   __CLANG_ATOMIC_CHAR16_T_LOCK_FREE
+#define ATOMIC_CHAR32_T_LOCK_FREE   __CLANG_ATOMIC_CHAR32_T_LOCK_FREE
+#define ATOMIC_WCHAR_T_LOCK_FREE__CLANG_ATOMIC_WCHAR_T_LOCK_FREE
+#define ATOMIC_SHORT_LOCK_FREE  __CLANG_ATOMIC_SHORT_LOCK_FREE
+#define ATOMIC_INT_LOCK_FREE__CLANG_ATOMIC_INT_LOCK_FREE
+#define ATOMIC_LONG_LOCK_FREE   __CLANG_ATOMIC_LONG_LOCK_FREE
+#define ATOMIC_LLONG_LOCK_FREE  __CLANG_ATOMIC_LLONG_LOCK_FREE
+#define ATOMIC_POINTER_LOCK_FREE__CLANG_ATOMIC_POINTER_LOCK_FREE
 
 /* 7.17.2 Initialization */
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D32294: [clang-tidy] run-clang-tidy.py: check if clang-apply-replacements succeeds

[Jakub Kuderski via Phabricator via cfe-commits]

kuhar updated this revision to Diff 96045.
kuhar added a comment.

After thinking about Piotr's comment, I think that a better way to perform the 
check would be te invoking clang-apply-replacements with `--version` and seeing 
if it fails even before running clang-tidy.
This way it is possible to save a lot of time when run-clang-tidy.py is run on 
a big project and apply_fixes fails at the end.

Let me know what you think about this approach.


https://reviews.llvm.org/D32294

Files:
  clang-tidy/tool/run-clang-tidy.py

Index: clang-tidy/tool/run-clang-tidy.py
===
--- clang-tidy/tool/run-clang-tidy.py
+++ clang-tidy/tool/run-clang-tidy.py
@@ -34,6 +34,7 @@
 http://clang.llvm.org/docs/HowToSetupToolingForLLVM.html
 """
 
+from __future__ import print_function
 import argparse
 import json
 import multiprocessing
@@ -45,14 +46,15 @@
 import sys
 import tempfile
 import threading
+import traceback
 
 
 def find_compilation_database(path):
   """Adjusts the directory until a compilation database is found."""
   result = './'
   while not os.path.isfile(os.path.join(result, path)):
 if os.path.realpath(result) == '/':
-  print 'Error: could not find compilation database.'
+  print('Error: could not find compilation database.')
   sys.exit(1)
 result += '../'
   return os.path.realpath(result)
@@ -86,15 +88,24 @@
   start.append(f)
   return start
 
+def check_clang_apply_replacements_binary(args):
+  """Checks if invoking supplied clang-apply-replacements binary works."""
+  try:
+subprocess.check_call([args.clang_apply_replacements_binary, '--version'])
+  except:
+print('Unable to run clang-apply-replacements. Is clang-apply-replacements '
+  'binary correctly specified?', file=sys.stderr)
+traceback.print_exc()
+sys.exit(1)
+
 
 def apply_fixes(args, tmpdir):
   """Calls clang-apply-fixes on a given directory. Deletes the dir when done."""
   invocation = [args.clang_apply_replacements_binary]
   if args.format:
 invocation.append('-format')
   invocation.append(tmpdir)
   subprocess.call(invocation)
-  shutil.rmtree(tmpdir)
 
 
 def run_tidy(args, tmpdir, build_path, queue):
@@ -164,9 +175,9 @@
 if args.checks:
   invocation.append('-checks=' + args.checks)
 invocation.append('-')
-print subprocess.check_output(invocation)
+print(subprocess.check_output(invocation))
   except:
-print >>sys.stderr, "Unable to run clang-tidy."
+print("Unable to run clang-tidy.", file=sys.stderr)
 sys.exit(1)
 
   # Load the database and extract all files.
@@ -179,6 +190,7 @@
 
   tmpdir = None
   if args.fix:
+check_clang_apply_replacements_binary(args)
 tmpdir = tempfile.mkdtemp()
 
   # Build up a big regexy filter from all command line arguments.
@@ -204,14 +216,25 @@
   except KeyboardInterrupt:
 # This is a sad hack. Unfortunately subprocess goes
 # bonkers with ctrl-c and we start forking merrily.
-print '\nCtrl-C detected, goodbye.'
+print('\nCtrl-C detected, goodbye.')
 if args.fix:
   shutil.rmtree(tmpdir)
 os.kill(0, 9)
 
   if args.fix:
-print 'Applying fixes ...'
-apply_fixes(args, tmpdir)
+print('Applying fixes ...')
+successfully_applied = True
+
+try:
+  apply_fixes(args, tmpdir)
+except:
+  successfully_applied = False
+  print('Error applying fixes.\n', file=sys.stderr)
+  traceback.print_exc()
+
+shutil.rmtree(tmpdir)
+if not successfully_applied:
+  sys.exit(1)
 
 if __name__ == '__main__':
   main()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r300917 - [CMake] Enable ARM target in Fuchsia toolchain

[Petr Hosek via cfe-commits]

Author: phosek
Date: Thu Apr 20 18:06:53 2017
New Revision: 300917

URL: http://llvm.org/viewvc/llvm-project?rev=300917&view=rev
Log:
[CMake] Enable ARM target in Fuchsia toolchain

This is still used by some users of Fuchsia toolchain. Also include
llc and opt which is useful for development and testing.

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

Modified:
cfe/trunk/cmake/caches/Fuchsia-stage2.cmake

Modified: cfe/trunk/cmake/caches/Fuchsia-stage2.cmake
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/caches/Fuchsia-stage2.cmake?rev=300917&r1=300916&r2=300917&view=diff
==
--- cfe/trunk/cmake/caches/Fuchsia-stage2.cmake (original)
+++ cfe/trunk/cmake/caches/Fuchsia-stage2.cmake Thu Apr 20 18:06:53 2017
@@ -1,7 +1,7 @@
 # This file sets up a CMakeCache for the second stage of a Fuchsia toolchain
 # build.
 
-set(LLVM_TARGETS_TO_BUILD X86;AArch64 CACHE STRING "")
+set(LLVM_TARGETS_TO_BUILD X86;ARM;AArch64 CACHE STRING "")
 
 set(PACKAGE_VENDOR Fuchsia CACHE STRING "")
 
@@ -36,6 +36,7 @@ set(BUILTINS_aarch64-fuchsia-none_CMAKE_
 # Setup toolchain.
 set(LLVM_INSTALL_TOOLCHAIN_ONLY ON CACHE BOOL "")
 set(LLVM_TOOLCHAIN_TOOLS
+  llc
   llvm-ar
   llvm-cov
   llvm-cxxfilt
@@ -49,6 +50,7 @@ set(LLVM_TOOLCHAIN_TOOLS
   llvm-readobj
   llvm-size
   llvm-symbolizer
+  opt
   CACHE STRING "")
 
 set(LLVM_DISTRIBUTION_COMPONENTS


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

r300919 - Use __CLANG_ATOMIC_TYPE_LOCK_FREE macros in `stdatomic.h`

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Thu Apr 20 18:07:38 2017
New Revision: 300919

URL: http://llvm.org/viewvc/llvm-project?rev=300919&view=rev
Log:
Use __CLANG_ATOMIC_TYPE_LOCK_FREE macros in `stdatomic.h`

Summary: This patch makes the header `stdatomic.h` work when 
`-fms-compatibility` is specified.

Reviewers: rsmith

Reviewed By: rsmith

Subscribers: cfe-commits

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

Modified:
cfe/trunk/lib/Headers/stdatomic.h
cfe/trunk/test/Headers/stdatomic.c

Modified: cfe/trunk/lib/Headers/stdatomic.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/stdatomic.h?rev=300919&r1=300918&r2=300919&view=diff
==
--- cfe/trunk/lib/Headers/stdatomic.h (original)
+++ cfe/trunk/lib/Headers/stdatomic.h Thu Apr 20 18:07:38 2017
@@ -40,16 +40,16 @@ extern "C" {
 
 /* 7.17.1 Introduction */
 
-#define ATOMIC_BOOL_LOCK_FREE   __GCC_ATOMIC_BOOL_LOCK_FREE
-#define ATOMIC_CHAR_LOCK_FREE   __GCC_ATOMIC_CHAR_LOCK_FREE
-#define ATOMIC_CHAR16_T_LOCK_FREE   __GCC_ATOMIC_CHAR16_T_LOCK_FREE
-#define ATOMIC_CHAR32_T_LOCK_FREE   __GCC_ATOMIC_CHAR32_T_LOCK_FREE
-#define ATOMIC_WCHAR_T_LOCK_FREE__GCC_ATOMIC_WCHAR_T_LOCK_FREE
-#define ATOMIC_SHORT_LOCK_FREE  __GCC_ATOMIC_SHORT_LOCK_FREE
-#define ATOMIC_INT_LOCK_FREE__GCC_ATOMIC_INT_LOCK_FREE
-#define ATOMIC_LONG_LOCK_FREE   __GCC_ATOMIC_LONG_LOCK_FREE
-#define ATOMIC_LLONG_LOCK_FREE  __GCC_ATOMIC_LLONG_LOCK_FREE
-#define ATOMIC_POINTER_LOCK_FREE__GCC_ATOMIC_POINTER_LOCK_FREE
+#define ATOMIC_BOOL_LOCK_FREE   __CLANG_ATOMIC_BOOL_LOCK_FREE
+#define ATOMIC_CHAR_LOCK_FREE   __CLANG_ATOMIC_CHAR_LOCK_FREE
+#define ATOMIC_CHAR16_T_LOCK_FREE   __CLANG_ATOMIC_CHAR16_T_LOCK_FREE
+#define ATOMIC_CHAR32_T_LOCK_FREE   __CLANG_ATOMIC_CHAR32_T_LOCK_FREE
+#define ATOMIC_WCHAR_T_LOCK_FREE__CLANG_ATOMIC_WCHAR_T_LOCK_FREE
+#define ATOMIC_SHORT_LOCK_FREE  __CLANG_ATOMIC_SHORT_LOCK_FREE
+#define ATOMIC_INT_LOCK_FREE__CLANG_ATOMIC_INT_LOCK_FREE
+#define ATOMIC_LONG_LOCK_FREE   __CLANG_ATOMIC_LONG_LOCK_FREE
+#define ATOMIC_LLONG_LOCK_FREE  __CLANG_ATOMIC_LLONG_LOCK_FREE
+#define ATOMIC_POINTER_LOCK_FREE__CLANG_ATOMIC_POINTER_LOCK_FREE
 
 /* 7.17.2 Initialization */
 

Modified: cfe/trunk/test/Headers/stdatomic.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Headers/stdatomic.c?rev=300919&r1=300918&r2=300919&view=diff
==
--- cfe/trunk/test/Headers/stdatomic.c (original)
+++ cfe/trunk/test/Headers/stdatomic.c Thu Apr 20 18:07:38 2017
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -std=c11 -E %s | FileCheck %s
+// RUN: %clang_cc1 -std=c11 -fms-compatibility -E %s | FileCheck %s
 #include 
 
 int bool_lock_free = ATOMIC_BOOL_LOCK_FREE;


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

[PATCH] D32231: [CMake] Enable ARM target in Fuchsia toolchain

[Petr Hosek via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL300917: [CMake] Enable ARM target in Fuchsia toolchain 
(authored by phosek).

Changed prior to commit:
  https://reviews.llvm.org/D32231?vs=95766&id=96048#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D32231

Files:
  cfe/trunk/cmake/caches/Fuchsia-stage2.cmake


Index: cfe/trunk/cmake/caches/Fuchsia-stage2.cmake
===
--- cfe/trunk/cmake/caches/Fuchsia-stage2.cmake
+++ cfe/trunk/cmake/caches/Fuchsia-stage2.cmake
@@ -1,7 +1,7 @@
 # This file sets up a CMakeCache for the second stage of a Fuchsia toolchain
 # build.
 
-set(LLVM_TARGETS_TO_BUILD X86;AArch64 CACHE STRING "")
+set(LLVM_TARGETS_TO_BUILD X86;ARM;AArch64 CACHE STRING "")
 
 set(PACKAGE_VENDOR Fuchsia CACHE STRING "")
 
@@ -36,6 +36,7 @@
 # Setup toolchain.
 set(LLVM_INSTALL_TOOLCHAIN_ONLY ON CACHE BOOL "")
 set(LLVM_TOOLCHAIN_TOOLS
+  llc
   llvm-ar
   llvm-cov
   llvm-cxxfilt
@@ -49,6 +50,7 @@
   llvm-readobj
   llvm-size
   llvm-symbolizer
+  opt
   CACHE STRING "")
 
 set(LLVM_DISTRIBUTION_COMPONENTS


Index: cfe/trunk/cmake/caches/Fuchsia-stage2.cmake
===
--- cfe/trunk/cmake/caches/Fuchsia-stage2.cmake
+++ cfe/trunk/cmake/caches/Fuchsia-stage2.cmake
@@ -1,7 +1,7 @@
 # This file sets up a CMakeCache for the second stage of a Fuchsia toolchain
 # build.
 
-set(LLVM_TARGETS_TO_BUILD X86;AArch64 CACHE STRING "")
+set(LLVM_TARGETS_TO_BUILD X86;ARM;AArch64 CACHE STRING "")
 
 set(PACKAGE_VENDOR Fuchsia CACHE STRING "")
 
@@ -36,6 +36,7 @@
 # Setup toolchain.
 set(LLVM_INSTALL_TOOLCHAIN_ONLY ON CACHE BOOL "")
 set(LLVM_TOOLCHAIN_TOOLS
+  llc
   llvm-ar
   llvm-cov
   llvm-cxxfilt
@@ -49,6 +50,7 @@
   llvm-readobj
   llvm-size
   llvm-symbolizer
+  opt
   CACHE STRING "")
 
 set(LLVM_DISTRIBUTION_COMPONENTS
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D31856: Headers: Make the type of SIZE_MAX the same as size_t

[Richard Smith via Phabricator via cfe-commits]

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

This is sadly not a correct change. The relevant requirements (C11 7.20.3/2) on 
these macros are:

> Each instance of these macros shall be replaced by a constant expression 
> suitable for use in `#if` preprocessing directives, and this expression shall 
> have the same type as would an expression that is an object of the 
> corresponding type converted according to the integer promotions.

The "suitable for use in `#if`" requirement means that you cannot use a cast, 
and must instead use a suitable numeric suffix.

Can we instead use `__SIZE_MAX__`? (And likewise for `ptrdiff_t` etc.)




Comment at: clang/test/Preprocessor/stdint.c:1411
 // JOIN:PTRDIFF_MAX_ 2147483647
-// JOIN:SIZE_MAX_ 4294967295U
+// JOIN:SIZE_MAX_ ((unsigned a)4294967295U)
 // JOIN:INTMAX_MIN_ (-9223372036854775807LL -1)

Do we really define `__SIZE_TYPE__` to `unsigned a` for some target?


https://reviews.llvm.org/D31856



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

[PATCH] D32269: [Driver] Add iSOFTLinux to GNU ToolChains X86Triple

[Richard Smith via Phabricator via cfe-commits]

rsmith added a comment.

Please add some test coverage for these triples.


Repository:
  rL LLVM

https://reviews.llvm.org/D32269



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

[PATCH] D32320: [libc++] Default to vcruntime when targeting MSVC

[Eric Fiselier via Phabricator via cfe-commits]

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

LGTM.




Comment at: CMakeLists.txt:119
+set(LIBCXX_CXX_ABI_LIBNAME "vcruntime")
   else()
+find_path(

Nit: I would rather see this be
```
elseif ((NOT LIBCXX_STANDALONE_BUILD OR HAVE_LIBCXXABI) AND
IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
```

That way we can avoid a level of nesting. 


https://reviews.llvm.org/D32320



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

[PATCH] D32320: [libc++] Default to vcruntime when targeting MSVC

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added inline comments.



Comment at: CMakeLists.txt:119
+set(LIBCXX_CXX_ABI_LIBNAME "vcruntime")
   else()
+find_path(

EricWF wrote:
> Nit: I would rather see this be
> ```
> elseif ((NOT LIBCXX_STANDALONE_BUILD OR HAVE_LIBCXXABI) AND
> IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
> ```
> 
> That way we can avoid a level of nesting. 
Sounds good; will change before committing.


https://reviews.llvm.org/D32320



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

[libcxx] r300920 - Fix ATOMIC__LOCK_FREE macros on Windows.

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Thu Apr 20 18:22:46 2017
New Revision: 300920

URL: http://llvm.org/viewvc/llvm-project?rev=300920&view=rev
Log:
Fix ATOMIC__LOCK_FREE macros on Windows.

Previously the ATOMIC__LOCK_FREE macros were implemented
using __GCC_ATOMIC__LOCK_FREE but GCC specific macros
are defined when -fms-compatibility is specified.

To avoid this Libc++ now tries to use the newly added
__CLANG_ATOMIC__LOCK_FREE macros instead, and only falls
back to the GCC versions when the Clang ones aren't available.

Modified:
libcxx/trunk/include/atomic

Modified: libcxx/trunk/include/atomic
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/atomic?rev=300920&r1=300919&r2=300920&view=diff
==
--- libcxx/trunk/include/atomic (original)
+++ libcxx/trunk/include/atomic Thu Apr 20 18:22:46 2017
@@ -861,16 +861,29 @@ kill_dependency(_Tp __y) _NOEXCEPT
 return __y;
 }
 
-#define ATOMIC_BOOL_LOCK_FREE  __GCC_ATOMIC_BOOL_LOCK_FREE
-#define ATOMIC_CHAR_LOCK_FREE  __GCC_ATOMIC_CHAR_LOCK_FREE
-#define ATOMIC_CHAR16_T_LOCK_FREE  __GCC_ATOMIC_CHAR16_T_LOCK_FREE
-#define ATOMIC_CHAR32_T_LOCK_FREE  __GCC_ATOMIC_CHAR32_T_LOCK_FREE
-#define ATOMIC_WCHAR_T_LOCK_FREE   __GCC_ATOMIC_WCHAR_T_LOCK_FREE
-#define ATOMIC_SHORT_LOCK_FREE __GCC_ATOMIC_SHORT_LOCK_FREE
-#define ATOMIC_INT_LOCK_FREE   __GCC_ATOMIC_INT_LOCK_FREE
-#define ATOMIC_LONG_LOCK_FREE  __GCC_ATOMIC_LONG_LOCK_FREE
-#define ATOMIC_LLONG_LOCK_FREE __GCC_ATOMIC_LLONG_LOCK_FREE
-#define ATOMIC_POINTER_LOCK_FREE   __GCC_ATOMIC_POINTER_LOCK_FREE
+#if defined(__CLANG_ATOMIC_BOOL_LOCK_FREE)
+# define ATOMIC_BOOL_LOCK_FREE  __CLANG_ATOMIC_BOOL_LOCK_FREE
+# define ATOMIC_CHAR_LOCK_FREE  __CLANG_ATOMIC_CHAR_LOCK_FREE
+# define ATOMIC_CHAR16_T_LOCK_FREE  __CLANG_ATOMIC_CHAR16_T_LOCK_FREE
+# define ATOMIC_CHAR32_T_LOCK_FREE  __CLANG_ATOMIC_CHAR32_T_LOCK_FREE
+# define ATOMIC_WCHAR_T_LOCK_FREE   __CLANG_ATOMIC_WCHAR_T_LOCK_FREE
+# define ATOMIC_SHORT_LOCK_FREE __CLANG_ATOMIC_SHORT_LOCK_FREE
+# define ATOMIC_INT_LOCK_FREE   __CLANG_ATOMIC_INT_LOCK_FREE
+# define ATOMIC_LONG_LOCK_FREE  __CLANG_ATOMIC_LONG_LOCK_FREE
+# define ATOMIC_LLONG_LOCK_FREE __CLANG_ATOMIC_LLONG_LOCK_FREE
+# define ATOMIC_POINTER_LOCK_FREE   __CLANG_ATOMIC_POINTER_LOCK_FREE
+#else
+# define ATOMIC_BOOL_LOCK_FREE  __GCC_ATOMIC_BOOL_LOCK_FREE
+# define ATOMIC_CHAR_LOCK_FREE  __GCC_ATOMIC_CHAR_LOCK_FREE
+# define ATOMIC_CHAR16_T_LOCK_FREE  __GCC_ATOMIC_CHAR16_T_LOCK_FREE
+# define ATOMIC_CHAR32_T_LOCK_FREE  __GCC_ATOMIC_CHAR32_T_LOCK_FREE
+# define ATOMIC_WCHAR_T_LOCK_FREE   __GCC_ATOMIC_WCHAR_T_LOCK_FREE
+# define ATOMIC_SHORT_LOCK_FREE __GCC_ATOMIC_SHORT_LOCK_FREE
+# define ATOMIC_INT_LOCK_FREE   __GCC_ATOMIC_INT_LOCK_FREE
+# define ATOMIC_LONG_LOCK_FREE  __GCC_ATOMIC_LONG_LOCK_FREE
+# define ATOMIC_LLONG_LOCK_FREE __GCC_ATOMIC_LLONG_LOCK_FREE
+# define ATOMIC_POINTER_LOCK_FREE   __GCC_ATOMIC_POINTER_LOCK_FREE
+#endif
 
 // general atomic
 


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

[PATCH] D31856: Headers: Make the type of SIZE_MAX the same as size_t

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

dexonsmith added a comment.

Thanks for the review.  `__SIZE_MAX__` makes sense to me; and better even if 
not for the `#if` requirement.  I'll do that for both `SIZE_MAX` and 
`PTRDIFF_MAX` when I get a chance.




Comment at: clang/test/Preprocessor/stdint.c:1411
 // JOIN:PTRDIFF_MAX_ 2147483647
-// JOIN:SIZE_MAX_ 4294967295U
+// JOIN:SIZE_MAX_ ((unsigned a)4294967295U)
 // JOIN:INTMAX_MIN_ (-9223372036854775807LL -1)

rsmith wrote:
> Do we really define `__SIZE_TYPE__` to `unsigned a` for some target?
This testcase has a `#define int a` to confirm that we get `intmax_t` from our 
token pasting instead of `amax_t`.  `unsigned a` looks bogus, but I figure such 
a user is getting what they asked for.


https://reviews.llvm.org/D31856



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

[PATCH] D32320: [libc++] Default to vcruntime when targeting MSVC

[Shoaib Meenai via Phabricator via cfe-commits]

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

Reduce nesting (address comments)


https://reviews.llvm.org/D32320

Files:
  CMakeLists.txt


Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -120,21 +120,19 @@
   ${LLVM_MAIN_SRC_DIR}/runtimes/libcxxabi/include
 NO_DEFAULT_PATH
   )
-  if ((NOT LIBCXX_STANDALONE_BUILD OR HAVE_LIBCXXABI) AND
-  IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
+  if (LIBCXX_TARGETING_MSVC)
+# FIXME: Figure out how to configure the ABI library on Windows.
+set(LIBCXX_CXX_ABI_LIBNAME "vcruntime")
+  elseif ((NOT LIBCXX_STANDALONE_BUILD OR HAVE_LIBCXXABI) AND
+  IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
 set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
 set(LIBCXX_CXX_ABI_INCLUDE_PATHS "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
 set(LIBCXX_CXX_ABI_INTREE 1)
+  elseif (APPLE)
+set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
+set(LIBCXX_CXX_ABI_SYSTEM 1)
   else()
-if (LIBCXX_TARGETING_MSVC)
-  # FIXME: Figure out how to configure the ABI library on Windows.
-  set(LIBCXX_CXX_ABI_LIBNAME "vcruntime")
-elseif(APPLE)
-  set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
-  set(LIBCXX_CXX_ABI_SYSTEM 1)
-else()
-  set(LIBCXX_CXX_ABI_LIBNAME "default")
-endif()
+set(LIBCXX_CXX_ABI_LIBNAME "default")
   endif()
 else()
   set(LIBCXX_CXX_ABI_LIBNAME "${LIBCXX_CXX_ABI}")


Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -120,21 +120,19 @@
   ${LLVM_MAIN_SRC_DIR}/runtimes/libcxxabi/include
 NO_DEFAULT_PATH
   )
-  if ((NOT LIBCXX_STANDALONE_BUILD OR HAVE_LIBCXXABI) AND
-  IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
+  if (LIBCXX_TARGETING_MSVC)
+# FIXME: Figure out how to configure the ABI library on Windows.
+set(LIBCXX_CXX_ABI_LIBNAME "vcruntime")
+  elseif ((NOT LIBCXX_STANDALONE_BUILD OR HAVE_LIBCXXABI) AND
+  IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
 set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
 set(LIBCXX_CXX_ABI_INCLUDE_PATHS "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
 set(LIBCXX_CXX_ABI_INTREE 1)
+  elseif (APPLE)
+set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
+set(LIBCXX_CXX_ABI_SYSTEM 1)
   else()
-if (LIBCXX_TARGETING_MSVC)
-  # FIXME: Figure out how to configure the ABI library on Windows.
-  set(LIBCXX_CXX_ABI_LIBNAME "vcruntime")
-elseif(APPLE)
-  set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
-  set(LIBCXX_CXX_ABI_SYSTEM 1)
-else()
-  set(LIBCXX_CXX_ABI_LIBNAME "default")
-endif()
+set(LIBCXX_CXX_ABI_LIBNAME "default")
   endif()
 else()
   set(LIBCXX_CXX_ABI_LIBNAME "${LIBCXX_CXX_ABI}")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D32320: [libc++] Default to vcruntime when targeting MSVC

[Shoaib Meenai via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL300921: [libc++] Default to vcruntime when targeting MSVC 
(authored by smeenai).

Changed prior to commit:
  https://reviews.llvm.org/D32320?vs=96055&id=96056#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D32320

Files:
  libcxx/trunk/CMakeLists.txt


Index: libcxx/trunk/CMakeLists.txt
===
--- libcxx/trunk/CMakeLists.txt
+++ libcxx/trunk/CMakeLists.txt
@@ -120,21 +120,19 @@
   ${LLVM_MAIN_SRC_DIR}/runtimes/libcxxabi/include
 NO_DEFAULT_PATH
   )
-  if ((NOT LIBCXX_STANDALONE_BUILD OR HAVE_LIBCXXABI) AND
-  IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
+  if (LIBCXX_TARGETING_MSVC)
+# FIXME: Figure out how to configure the ABI library on Windows.
+set(LIBCXX_CXX_ABI_LIBNAME "vcruntime")
+  elseif ((NOT LIBCXX_STANDALONE_BUILD OR HAVE_LIBCXXABI) AND
+  IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
 set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
 set(LIBCXX_CXX_ABI_INCLUDE_PATHS "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
 set(LIBCXX_CXX_ABI_INTREE 1)
+  elseif (APPLE)
+set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
+set(LIBCXX_CXX_ABI_SYSTEM 1)
   else()
-if (LIBCXX_TARGETING_MSVC)
-  # FIXME: Figure out how to configure the ABI library on Windows.
-  set(LIBCXX_CXX_ABI_LIBNAME "vcruntime")
-elseif(APPLE)
-  set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
-  set(LIBCXX_CXX_ABI_SYSTEM 1)
-else()
-  set(LIBCXX_CXX_ABI_LIBNAME "default")
-endif()
+set(LIBCXX_CXX_ABI_LIBNAME "default")
   endif()
 else()
   set(LIBCXX_CXX_ABI_LIBNAME "${LIBCXX_CXX_ABI}")


Index: libcxx/trunk/CMakeLists.txt
===
--- libcxx/trunk/CMakeLists.txt
+++ libcxx/trunk/CMakeLists.txt
@@ -120,21 +120,19 @@
   ${LLVM_MAIN_SRC_DIR}/runtimes/libcxxabi/include
 NO_DEFAULT_PATH
   )
-  if ((NOT LIBCXX_STANDALONE_BUILD OR HAVE_LIBCXXABI) AND
-  IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
+  if (LIBCXX_TARGETING_MSVC)
+# FIXME: Figure out how to configure the ABI library on Windows.
+set(LIBCXX_CXX_ABI_LIBNAME "vcruntime")
+  elseif ((NOT LIBCXX_STANDALONE_BUILD OR HAVE_LIBCXXABI) AND
+  IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
 set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
 set(LIBCXX_CXX_ABI_INCLUDE_PATHS "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
 set(LIBCXX_CXX_ABI_INTREE 1)
+  elseif (APPLE)
+set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
+set(LIBCXX_CXX_ABI_SYSTEM 1)
   else()
-if (LIBCXX_TARGETING_MSVC)
-  # FIXME: Figure out how to configure the ABI library on Windows.
-  set(LIBCXX_CXX_ABI_LIBNAME "vcruntime")
-elseif(APPLE)
-  set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
-  set(LIBCXX_CXX_ABI_SYSTEM 1)
-else()
-  set(LIBCXX_CXX_ABI_LIBNAME "default")
-endif()
+set(LIBCXX_CXX_ABI_LIBNAME "default")
   endif()
 else()
   set(LIBCXX_CXX_ABI_LIBNAME "${LIBCXX_CXX_ABI}")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxx] r300921 - [libc++] Default to vcruntime when targeting MSVC

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Thu Apr 20 18:33:49 2017
New Revision: 300921

URL: http://llvm.org/viewvc/llvm-project?rev=300921&view=rev
Log:
[libc++] Default to vcruntime when targeting MSVC

Summary:
libc++abi is never the right option for LIBCXX_TARGETING_MSVC, since it
targets the Itanium ABI, whereas MSVC uses the Microsoft ABI. Make the
default ABI be vcruntime when targeting MSVC even if libc++abi is
present in the tree.

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

Modified:
libcxx/trunk/CMakeLists.txt

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=300921&r1=300920&r2=300921&view=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Thu Apr 20 18:33:49 2017
@@ -120,21 +120,19 @@ if (LIBCXX_CXX_ABI STREQUAL "default")
   ${LLVM_MAIN_SRC_DIR}/runtimes/libcxxabi/include
 NO_DEFAULT_PATH
   )
-  if ((NOT LIBCXX_STANDALONE_BUILD OR HAVE_LIBCXXABI) AND
-  IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
+  if (LIBCXX_TARGETING_MSVC)
+# FIXME: Figure out how to configure the ABI library on Windows.
+set(LIBCXX_CXX_ABI_LIBNAME "vcruntime")
+  elseif ((NOT LIBCXX_STANDALONE_BUILD OR HAVE_LIBCXXABI) AND
+  IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
 set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
 set(LIBCXX_CXX_ABI_INCLUDE_PATHS "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
 set(LIBCXX_CXX_ABI_INTREE 1)
+  elseif (APPLE)
+set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
+set(LIBCXX_CXX_ABI_SYSTEM 1)
   else()
-if (LIBCXX_TARGETING_MSVC)
-  # FIXME: Figure out how to configure the ABI library on Windows.
-  set(LIBCXX_CXX_ABI_LIBNAME "vcruntime")
-elseif(APPLE)
-  set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
-  set(LIBCXX_CXX_ABI_SYSTEM 1)
-else()
-  set(LIBCXX_CXX_ABI_LIBNAME "default")
-endif()
+set(LIBCXX_CXX_ABI_LIBNAME "default")
   endif()
 else()
   set(LIBCXX_CXX_ABI_LIBNAME "${LIBCXX_CXX_ABI}")


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

[libcxxabi] r300925 - Fix PR25874 - cxa_thread_atexit_test.pass.cpp has an incorrect XFAIL.

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Thu Apr 20 18:40:35 2017
New Revision: 300925

URL: http://llvm.org/viewvc/llvm-project?rev=300925&view=rev
Log:
Fix PR25874 - cxa_thread_atexit_test.pass.cpp has an incorrect XFAIL.

Modified:
libcxxabi/trunk/test/CMakeLists.txt
libcxxabi/trunk/test/cxa_thread_atexit_test.pass.cpp
libcxxabi/trunk/test/libcxxabi/test/config.py
libcxxabi/trunk/test/lit.site.cfg.in

Modified: libcxxabi/trunk/test/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/test/CMakeLists.txt?rev=300925&r1=300924&r2=300925&view=diff
==
--- libcxxabi/trunk/test/CMakeLists.txt (original)
+++ libcxxabi/trunk/test/CMakeLists.txt Thu Apr 20 18:40:35 2017
@@ -18,7 +18,6 @@ pythonize_bool(LIBCXXABI_ENABLE_THREADS)
 pythonize_bool(LIBCXXABI_ENABLE_EXCEPTIONS)
 pythonize_bool(LIBCXXABI_USE_LLVM_UNWINDER)
 pythonize_bool(LIBCXXABI_BUILD_EXTERNAL_THREAD_LIBRARY)
-pythonize_bool(LIBCXXABI_HAS_CXA_THREAD_ATEXIT_IMPL)
 set(LIBCXXABI_TARGET_INFO "libcxx.test.target_info.LocalTI" CACHE STRING
 "TargetInfo to use when setting up test environment.")
 set(LIBCXXABI_EXECUTOR "None" CACHE STRING

Modified: libcxxabi/trunk/test/cxa_thread_atexit_test.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/test/cxa_thread_atexit_test.pass.cpp?rev=300925&r1=300924&r2=300925&view=diff
==
--- libcxxabi/trunk/test/cxa_thread_atexit_test.pass.cpp (original)
+++ libcxxabi/trunk/test/cxa_thread_atexit_test.pass.cpp Thu Apr 20 18:40:35 
2017
@@ -10,11 +10,6 @@
 // UNSUPPORTED: libcxxabi-no-threads
 // REQUIRES: linux
 
-// this test will only work if CMake detects a real __cxa_thread_atexit_impl
-// at configure time. This function, however, was added only in glibc 2.18,
-// and there are still plenty of systems only using 2.17 (Ex RHEL 7).
-// XFAIL: libcxxabi-no-cxa-thread-atexit-impl
-
 #include 
 #include 
 

Modified: libcxxabi/trunk/test/libcxxabi/test/config.py
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/test/libcxxabi/test/config.py?rev=300925&r1=300924&r2=300925&view=diff
==
--- libcxxabi/trunk/test/libcxxabi/test/config.py (original)
+++ libcxxabi/trunk/test/libcxxabi/test/config.py Thu Apr 20 18:40:35 2017
@@ -45,9 +45,6 @@ class Configuration(LibcxxConfiguration)
 # test_exception_storage_nodynmem.pass.cpp fails under this specific 
configuration
 if self.get_lit_bool('cxx_ext_threads', False) and 
self.get_lit_bool('libcxxabi_shared', False):
 
self.config.available_features.add('libcxxabi-shared-externally-threaded')
-if not self.get_lit_bool('has_cxa_thread_atexit_impl', True):
-self.config.available_features.add(
-'libcxxabi-no-cxa-thread-atexit-impl')
 if not self.get_lit_bool('llvm_unwinder', False):
 self.config.available_features.add('libcxxabi-has-system-unwinder')
 

Modified: libcxxabi/trunk/test/lit.site.cfg.in
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/test/lit.site.cfg.in?rev=300925&r1=300924&r2=300925&view=diff
==
--- libcxxabi/trunk/test/lit.site.cfg.in (original)
+++ libcxxabi/trunk/test/lit.site.cfg.in Thu Apr 20 18:40:35 2017
@@ -21,7 +21,6 @@ config.host_triple  = "@LLVM
 config.target_triple= "@TARGET_TRIPLE@"
 config.use_target   = len("@LIBCXXABI_TARGET_TRIPLE@") > 0
 config.cxx_ext_threads  = "@LIBCXXABI_BUILD_EXTERNAL_THREAD_LIBRARY@"
-config.has_cxa_thread_atexit_impl = "@LIBCXXABI_HAS_CXA_THREAD_ATEXIT_IMPL@"
 
 # Let the main config do the real work.
 lit_config.load_config(config, "@LIBCXXABI_SOURCE_DIR@/test/lit.cfg")


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

[PATCH] D32328: [analyzer] Fix assert in ExprEngine::processSwitch

[Alexander Shaposhnikov via Phabricator via cfe-commits]

alexshap created this revision.
alexshap created this object with visibility "All Users".

This diff replaces getTypeSize(CondE->getType())) with 
getIntWidth(CondE->getType())).
These calls are not equivalent for bool 
https://clang.llvm.org/doxygen/ASTContext_8cpp_source.html#l08444 
and the analyzer crashes. 
Add a test case.


Repository:
  rL LLVM

https://reviews.llvm.org/D32328

Files:
  lib/StaticAnalyzer/Core/ExprEngine.cpp
  test/Analysis/enum.cpp


Index: test/Analysis/enum.cpp
===
--- test/Analysis/enum.cpp
+++ test/Analysis/enum.cpp
@@ -24,3 +24,16 @@
 clang_analyzer_eval(j == 0); // expected-warning{{FALSE}}
   }
 }
+
+enum class EnumBool : bool {
+  F = false,
+  T = true
+};
+
+bool testNoCrashOnSwitchEnumBool(EnumBool E) {
+  switch (E) {
+  case EnumBool::F:
+return false;
+  }
+  return true;
+}
Index: lib/StaticAnalyzer/Core/ExprEngine.cpp
===
--- lib/StaticAnalyzer/Core/ExprEngine.cpp
+++ lib/StaticAnalyzer/Core/ExprEngine.cpp
@@ -1904,7 +1904,7 @@
 
 // Evaluate the LHS of the case value.
 llvm::APSInt V1 = Case->getLHS()->EvaluateKnownConstInt(getContext());
-assert(V1.getBitWidth() == getContext().getTypeSize(CondE->getType()));
+assert(V1.getBitWidth() == getContext().getIntWidth(CondE->getType()));
 
 // Get the RHS of the case, if it exists.
 llvm::APSInt V2;


Index: test/Analysis/enum.cpp
===
--- test/Analysis/enum.cpp
+++ test/Analysis/enum.cpp
@@ -24,3 +24,16 @@
 clang_analyzer_eval(j == 0); // expected-warning{{FALSE}}
   }
 }
+
+enum class EnumBool : bool {
+  F = false,
+  T = true
+};
+
+bool testNoCrashOnSwitchEnumBool(EnumBool E) {
+  switch (E) {
+  case EnumBool::F:
+return false;
+  }
+  return true;
+}
Index: lib/StaticAnalyzer/Core/ExprEngine.cpp
===
--- lib/StaticAnalyzer/Core/ExprEngine.cpp
+++ lib/StaticAnalyzer/Core/ExprEngine.cpp
@@ -1904,7 +1904,7 @@
 
 // Evaluate the LHS of the case value.
 llvm::APSInt V1 = Case->getLHS()->EvaluateKnownConstInt(getContext());
-assert(V1.getBitWidth() == getContext().getTypeSize(CondE->getType()));
+assert(V1.getBitWidth() == getContext().getIntWidth(CondE->getType()));
 
 // Get the RHS of the case, if it exists.
 llvm::APSInt V2;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D32329: [libc++abi] Disable libc++ extern templates project-wide

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai created this revision.
Herald added a subscriber: mgorny.

libc++abi can't depend on libc++, so disable extern templates in libc++
headers project-wide. This was previously done in cxa_demangle.cpp, but
I consider it more appropriate to do at the cmake level (since none of
libc++abi's source files can use libc++ extern templates).

I also think the _LIBCPP_NO_EXCEPTIONS in cxa_demangle.cpp is
suspicious, but I'm doing one thing at a time.


https://reviews.llvm.org/D32329

Files:
  CMakeLists.txt
  src/cxa_demangle.cpp


Index: src/cxa_demangle.cpp
===
--- src/cxa_demangle.cpp
+++ src/cxa_demangle.cpp
@@ -7,7 +7,6 @@
 //
 
//===--===//
 
-#define _LIBCPP_EXTERN_TEMPLATE(...)
 #define _LIBCPP_NO_EXCEPTIONS
 
 #include "__cxxabi_config.h"
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -453,6 +453,9 @@
   add_definitions(-D_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL)
 endif()
 
+# Prevent libc++abi from having library dependencies on libc++
+add_definitions(-D_LIBCPP_DISABLE_EXTERN_TEMPLATE)
+
 if (MSVC)
   add_definitions(-D_CRT_SECURE_NO_WARNINGS)
 endif()


Index: src/cxa_demangle.cpp
===
--- src/cxa_demangle.cpp
+++ src/cxa_demangle.cpp
@@ -7,7 +7,6 @@
 //
 //===--===//
 
-#define _LIBCPP_EXTERN_TEMPLATE(...)
 #define _LIBCPP_NO_EXCEPTIONS
 
 #include "__cxxabi_config.h"
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -453,6 +453,9 @@
   add_definitions(-D_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL)
 endif()
 
+# Prevent libc++abi from having library dependencies on libc++
+add_definitions(-D_LIBCPP_DISABLE_EXTERN_TEMPLATE)
+
 if (MSVC)
   add_definitions(-D_CRT_SECURE_NO_WARNINGS)
 endif()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r300650 - [modules] Properly look up the owning module for an instantiation of a merged template.

[Richard Smith via cfe-commits]

On 18 April 2017 at 22:41, Chandler Carruth  wrote:

> Reverted in r300658.
>

For posterity, the above has an off-by-one error, the revert was r300659.


> On Tue, Apr 18, 2017 at 8:30 PM Chandler Carruth 
> wrote:
>
>> Consider code like the following:
>>
>> ```
>> #include 
>>
>> template 
>> class MyAllocator : public std::allocator {
>>  public:
>>   typedef std::allocator Alloc;
>>   typedef typename Alloc::pointer pointer;
>>   typedef typename Alloc::size_type size_type;
>>
>>   MyAllocator() {}
>>
>>   template 
>>   MyAllocator(const MyAllocator& x) : Alloc(x) {}
>>
>>   pointer allocate(size_type n,
>>std::allocator::const_pointer /*hint*/ =
>> nullptr) {
>> void* p = malloc(n * sizeof(T));
>> return static_cast(p);
>>   }
>>
>>   void deallocate(pointer p, size_type) { free(p); }
>>
>>   template 
>>   struct rebind {
>> typedef MyAllocator other;
>>   };
>>
>>  private:
>>   template 
>>   friend class MyAllocator;
>> };
>>
>> std::shared_ptr x = std::allocate_shared(MyAllocator(),
>> 0);
>> ```
>>
>> This will fail to compile against libstdc++ 4.9's alloc_traits.h, when
>> that header comes from a module, with an error message along the lines of:
>> .../bits/alloc_traits.h:197:2: error: too few template arguments for
>> class template '__alloctr_rebind'
>> using rebind_alloc = typename __alloctr_rebind<_Alloc,
>> _Tp>::__type;
>>
>> I think this is enough for you to debug, but let me know if not. I'm
>> going to revert this temporarily to unbreak our modules builds using this
>> version of libstdc++.
>>
>> On Tue, Apr 18, 2017 at 8:14 PM Chandler Carruth 
>> wrote:
>>
>>> This appears to break a pretty straightforward use of things like
>>> libstdc++'s __alloctr_rebind (undefined template with a default argument,
>>> specializations, etc):
>>> https://github.com/gcc-mirror/gcc/blob/gcc-4_9-branch/
>>> libstdc++-v3/include/bits/alloc_traits.h#L58-L73
>>>
>>> At least, I'm getting errors from this. I'm working on a test case, but
>>> as usual, the test case may be... large.
>>>
>>> On Tue, Apr 18, 2017 at 6:49 PM Richard Smith via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 Author: rsmith
 Date: Tue Apr 18 20:36:43 2017
 New Revision: 300650

 URL: http://llvm.org/viewvc/llvm-project?rev=300650&view=rev
 Log:
 [modules] Properly look up the owning module for an instantiation of a
 merged template.

 When looking for the template instantiation pattern of a templated
 entity,
 consistently select the definition of the pattern if there is one. This
 means
 we'll pick the same owning module when we start instantiating a
 template that
 we'll later pick when determining which modules are visible during that
 instantiation.

 Modified:
 cfe/trunk/lib/AST/Decl.cpp
 cfe/trunk/lib/AST/DeclCXX.cpp
 cfe/trunk/lib/Sema/SemaLookup.cpp
 cfe/trunk/test/Modules/Inputs/template-default-args/a.h
 cfe/trunk/test/Modules/template-default-args.cpp

 Modified: cfe/trunk/lib/AST/Decl.cpp
 URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/
 Decl.cpp?rev=300650&r1=300649&r2=300650&view=diff
 
 ==
 --- cfe/trunk/lib/AST/Decl.cpp (original)
 +++ cfe/trunk/lib/AST/Decl.cpp Tue Apr 18 20:36:43 2017
 @@ -2251,6 +2251,13 @@ bool VarDecl::checkInitIsICE() const {
return Eval->IsICE;
  }

 +template
 +static DeclT *getDefinitionOrSelf(DeclT *D) {
 +  if (auto *Def = D->getDefinition())
 +return Def;
 +  return D;
 +}
 +
  VarDecl *VarDecl::getTemplateInstantiationPattern() const {
// If it's a variable template specialization, find the template or
 partial
// specialization from which it was instantiated.
 @@ -2262,7 +2269,7 @@ VarDecl *VarDecl::getTemplateInstantiati
break;
  VTD = NewVTD;
}
 -  return VTD->getTemplatedDecl()->getDefinition();
 +  return getDefinitionOrSelf(VTD->getTemplatedDecl());
  }
  if (auto *VTPSD =
  From.dyn_cast()) {
 @@ -2271,7 +2278,7 @@ VarDecl *VarDecl::getTemplateInstantiati
break;
  VTPSD = NewVTPSD;
}
 -  return VTPSD->getDefinition();
 +  return getDefinitionOrSelf(VTPSD);
  }
}

 @@ -2280,23 +2287,18 @@ VarDecl *VarDecl::getTemplateInstantiati
VarDecl *VD = getInstantiatedFromStaticDataMember();
while (auto *NewVD = VD->getInstantiatedFromStaticDataMember())
  VD = NewVD;
 -  return VD->getDefinition();
 +  return getDefinitionOrSelf(VD);
  }
}

if (VarTemplateDecl *VarTemplate = getDescribedVarTemplate()) {
 -
  while (VarTemplate->getInstantiatedFromMemberTemplate()) {

Buildbot numbers for the week of 04/02/2017 - 04/08/2017

[Galina Kistanova via cfe-commits]

Hello everyone,

Below are some buildbot numbers for the week of 04/02/2017 - 04/08/2017.

Please see the same data in attached csv files:

The longest time each builder was red during the last week;
"Status change ratio" by active builder (percent of builds that changed the
builder status from greed to red or from red to green);
Count of commits by project;
Number of completed builds, failed builds and average build time for
successful builds per active builder;
Average waiting time for a revision to get build result per active builder
(response time).

Thanks

Galina


The longest time each builder was red during the last week:

buildername |  was_red
+--
 clang-x64-ninja-win7   | 131:11:54
 lldb-amd64-ninja-freebsd11 | 74:30:52
 lldb-x86_64-ubuntu-14.04-android   | 42:01:22
 sanitizer-windows  | 40:01:49
 clang-lld-x86_64-2stage| 30:53:01
 clang-with-lto-ubuntu  | 29:17:54
 sanitizer-x86_64-linux-autoconf| 25:11:10
 clang-s390x-linux  | 24:04:42
 clang-ppc64le-linux-lnt| 24:03:16
 clang-ppc64le-linux-multistage | 22:52:11
 lldb-x86_64-ubuntu-14.04-cmake | 21:35:51
 clang-ppc64be-linux-lnt| 16:00:25
 perf-x86_64-penryn-O3-polly-before-vectorizer-detect-only  | 15:14:08
 perf-x86_64-penryn-O3  | 12:06:38
 clang-cmake-armv7-a15-selfhost | 11:04:31
 clang-cmake-mipsel | 10:49:21
 perf-x86_64-penryn-O3-polly| 10:36:54
 clang-x86-windows-msvc2015 | 09:25:23
 llvm-clang-x86_64-expensive-checks-win | 09:18:55
 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast   | 09:01:11
 libcxx-libcxxabi-libunwind-aarch64-linux   | 08:43:12
 perf-x86_64-penryn-O3-polly-before-vectorizer-unprofitable | 08:20:05
 sanitizer-x86_64-linux-fast| 08:06:20
 sanitizer-ppc64be-linux| 08:02:19
 perf-x86_64-penryn-O3-polly-before-vectorizer  | 08:01:14
 clang-cmake-aarch64-full   | 07:06:55
 clang-cmake-armv7-a15-selfhost-neon| 06:53:09
 clang-cmake-mips   | 06:47:06
 sanitizer-x86_64-linux | 06:39:15
 perf-x86_64-penryn-O3-polly-parallel-fast  | 06:31:00
 sanitizer-x86_64-linux-bootstrap   | 06:24:43
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03 | 06:05:44
 perf-x86_64-penryn-O3-polly-unprofitable   | 05:51:43
 llvm-mips-linux| 05:50:22
 clang-cmake-thumbv7-a15-full-sh| 05:41:46
 clang-ppc64be-linux-multistage | 05:33:48
 clang-cmake-aarch64-lld| 05:31:08
 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast | 05:18:18
 perf-x86_64-penryn-O3-polly-fast   | 05:13:25
 polly-amd64-linux  | 05:05:36
 clang-native-arm-lnt   | 05:01:41
 clang-cmake-armv7-a15  | 04:56:45
 clang-cmake-aarch64-42vma  | 04:49:19
 libomp-gcc-x86_64-linux-debian | 04:24:54
 polly-arm-linux| 04:13:38
 libcxx-libcxxabi-x86_64-linux-ubuntu-ubsan | 03:38:26
 libcxx-libcxxabi-x86_64-linux-ubuntu-tsan  | 03:37:44
 libcxx-libcxxabi-x86_64-linux-ubuntu-msan  | 03:34:34
 libcxx-libcxxabi-libunwind-x86_64-linux-ubuntu | 03:30:54
 libcxx-libcxxabi-libunwind-aarch64-linux-noexceptions  | 03:03:33
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx1z | 03:02:27
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14 | 03:00:22
 clang-cmake-armv7-a15-full | 02:49:28
 lldb-windows7-android  | 02:45:27
 clang-cmake-thumbv7-a15| 02:45:26
 clang-x86_64-linux-selfhost-modules-2  | 02:41:11
 clang-ppc64le-linux| 02:35:20
 clang-cuda-build   | 02:31:10
 clang-cmake-aarch64-39vma  | 02:27:15
 clang-cmake-aarch64-quick 

Buildbot numbers for the week of 04/09/2017 - 04/15/2017

[Galina Kistanova via cfe-commits]

Hello everyone,

Below are some buildbot numbers for the last week of 04/09/2017 -
04/15/2017.

Please see the same data in attached csv files:

The longest time each builder was red during the last week;
"Status change ratio" by active builder (percent of builds that changed the
builder status from greed to red or from red to green);
Count of commits by project;
Number of completed builds, failed builds and average build time for
successful builds per active builder;
Average waiting time for a revision to get build result per active builder
(response time).

Thanks

Galina


The longest time each builder was red during the last week:

buildername | was_red
+-
 clang-x86_64-linux-selfhost-modules| 76:17:27
 libcxx-libcxxabi-x86_64-linux-ubuntu-asan  | 52:20:18
 clang-lld-x86_64-2stage| 50:37:55
 clang-x86_64-linux-selfhost-modules-2  | 47:24:53
 sanitizer-ppc64le-linux| 42:59:32
 clang-cmake-thumbv7-a15-full-sh| 39:55:31
 clang-ppc64be-linux-multistage | 28:48:14
 clang-x64-ninja-win7   | 27:23:55
 clang-x86-windows-msvc2015 | 27:13:14
 clang-cmake-armv7-a15-selfhost-neon| 26:33:39
 clang-cmake-armv7-a15-selfhost | 24:38:47
 sanitizer-x86_64-linux-bootstrap   | 23:18:49
 clang-cmake-aarch64-lld| 23:12:21
 clang-ppc64le-linux-multistage | 23:10:30
 clang-with-lto-ubuntu  | 23:07:50
 clang-cmake-aarch64-full   | 22:25:25
 llvm-clang-x86_64-expensive-checks-win | 18:08:11
 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast   | 18:07:41
 lldb-x86_64-ubuntu-14.04-android   | 16:30:53
 lldb-x86_64-darwin-13.4| 10:25:03
 lldb-x86_64-ubuntu-14.04-cmake | 10:01:41
 lldb-windows7-android  | 10:00:29
 clang-cmake-aarch64-39vma  | 08:42:25
 clang-cmake-aarch64-42vma  | 08:41:55
 clang-cmake-armv7-a15-full | 08:34:15
 sanitizer-x86_64-linux-autoconf| 07:43:05
 sanitizer-ppc64be-linux| 07:41:12
 perf-x86_64-penryn-O3  | 06:57:03
 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast | 06:21:15
 perf-x86_64-penryn-O3-polly| 06:19:15
 clang-cmake-thumbv7-a15| 06:11:09
 clang-cmake-armv7-a15  | 06:11:02
 clang-hexagon-elf  | 06:05:43
 polly-arm-linux| 05:59:33
 llvm-hexagon-elf   | 05:59:32
 clang-cmake-aarch64-quick  | 05:59:09
 lld-x86_64-darwin13| 05:55:08
 perf-x86_64-penryn-O3-polly-fast   | 05:20:31
 clang-cmake-mips   | 05:10:18
 clang-cmake-mipsel | 04:53:45
 polly-amd64-linux  | 04:38:23
 clang-ppc64be-linux-lnt| 04:31:54
 lldb-x86_64-ubuntu-14.04-buildserver   | 03:35:44
 clang-ppc64le-linux| 03:30:42
 lldb-amd64-ninja-netbsd7   | 03:26:29
 llvm-sphinx-docs   | 03:21:14
 llvm-mips-linux| 03:21:02
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03 | 02:48:01
 clang-ppc64le-linux-lnt| 02:47:56
 clang-ppc64be-linux| 02:41:03
 libcxx-libcxxabi-libunwind-arm-linux-noexceptions  | 02:38:34
 sanitizer-x86_64-linux-fast| 02:37:50
 lldb-x86-windows-msvc2015  | 02:28:17
 perf-x86_64-penryn-O3-polly-parallel-fast  | 02:21:54
 perf-x86_64-penryn-O3-polly-unprofitable   | 02:15:47
 lldb-amd64-ninja-freebsd11 | 02:05:38
 libcxx-libcxxabi-libunwind-aarch64-linux-noexceptions  | 02:00:19
 perf-x86_64-penryn-O3-polly-before-vectorizer-unprofitable | 01:53:15
 sanitizer-windows  | 01:44:58
 clang-s390x-linux   

r300894 - Enable leak sanitizer builds for darwin

[Francis Ricci via cfe-commits]

Author: fjricci
Date: Thu Apr 20 16:11:51 2017
New Revision: 300894

URL: http://llvm.org/viewvc/llvm-project?rev=300894&view=rev
Log:
Enable leak sanitizer builds for darwin

Summary:
Support for leak sanitizer on darwin has been added to
compiler-rt, this patch adds compiler support.

Reviewers: dexonsmith, compnerd

Subscribers: alekseyshl, kubamracek, cfe-commits

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

Modified:
cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
cfe/trunk/test/Driver/fsanitize.c
cfe/trunk/test/Driver/sanitizer-ld.c

Modified: cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Darwin.cpp?rev=300894&r1=300893&r2=300894&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Darwin.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Darwin.cpp Thu Apr 20 16:11:51 2017
@@ -1035,6 +1035,8 @@ void DarwinClang::AddLinkRuntimeLibArgs(
   const SanitizerArgs &Sanitize = getSanitizerArgs();
   if (Sanitize.needsAsanRt())
 AddLinkSanitizerLibArgs(Args, CmdArgs, "asan");
+  if (Sanitize.needsLsanRt())
+AddLinkSanitizerLibArgs(Args, CmdArgs, "lsan");
   if (Sanitize.needsUbsanRt())
 AddLinkSanitizerLibArgs(Args, CmdArgs, "ubsan");
   if (Sanitize.needsTsanRt())
@@ -1892,6 +1894,7 @@ SanitizerMask Darwin::getSupportedSaniti
   const bool IsX86_64 = getTriple().getArch() == llvm::Triple::x86_64;
   SanitizerMask Res = ToolChain::getSupportedSanitizers();
   Res |= SanitizerKind::Address;
+  Res |= SanitizerKind::Leak;
   if (isTargetMacOS()) {
 if (!isMacosxVersionLT(10, 9))
   Res |= SanitizerKind::Vptr;

Modified: cfe/trunk/test/Driver/fsanitize.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/fsanitize.c?rev=300894&r1=300893&r2=300894&view=diff
==
--- cfe/trunk/test/Driver/fsanitize.c (original)
+++ cfe/trunk/test/Driver/fsanitize.c Thu Apr 20 16:11:51 2017
@@ -358,6 +358,27 @@
 // RUN: %clang -target i386-pc-openbsd -fsanitize=address %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-ASAN-OPENBSD
 // CHECK-ASAN-OPENBSD: unsupported option '-fsanitize=address' for target 
'i386-pc-openbsd'
 
+// RUN: %clang -target x86_64-apple-darwin -fsanitize=leak %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-LSAN-X86-64-DARWIN
+// CHECK-LSAN-X86-64-DARWIN-NOT: unsupported option
+
+// RUN: %clang -target x86_64-apple-iossimulator -fsanitize=leak %s -### 2>&1 
| FileCheck %s --check-prefix=CHECK-LSAN-X86-64-IOSSIMULATOR
+// CHECK-LSAN-X86-64-IOSSIMULATOR-NOT: unsupported option
+
+// RUN: %clang -target x86_64-apple-tvossimulator -fsanitize=leak %s -### 2>&1 
| FileCheck %s --check-prefix=CHECK-LSAN-X86-64-TVOSSIMULATOR
+// CHECK-LSAN-X86-64-TVOSSIMULATOR-NOT: unsupported option
+
+// RUN: %clang -target i386-apple-darwin -fsanitize=leak %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-LSAN-I386-DARWIN
+// CHECK-LSAN-I386-DARWIN-NOT: unsupported option
+
+// RUN: %clang -target arm-apple-ios -fsanitize=leak %s -### 2>&1 | FileCheck 
%s --check-prefix=CHECK-LSAN-ARM-IOS
+// CHECK-LSAN-ARM-IOS-NOT: unsupported option
+
+// RUN: %clang -target i386-apple-iossimulator -fsanitize=leak %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-LSAN-I386-IOSSIMULATOR
+// CHECK-LSAN-I386-IOSSIMULATOR-NOT: unsupported option
+
+// RUN: %clang -target i386-apple-tvossimulator -fsanitize=leak %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-LSAN-I386-TVOSSIMULATOR
+// CHECK-LSAN-I386-TVOSSIMULATOR-NOT: unsupported option
+
 // RUN: %clang -target i686-linux-gnu -fsanitize=efficiency-cache-frag %s -### 
2>&1 | FileCheck %s --check-prefix=CHECK-ESAN-X86
 // RUN: %clang -target i686-linux-gnu -fsanitize=efficiency-working-set %s 
-### 2>&1 | FileCheck %s --check-prefix=CHECK-ESAN-X86
 // CHECK-ESAN-X86: error: unsupported option '-fsanitize=efficiency-{{.*}}' 
for target 'i686--linux-gnu'

Modified: cfe/trunk/test/Driver/sanitizer-ld.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/sanitizer-ld.c?rev=300894&r1=300893&r2=300894&view=diff
==
--- cfe/trunk/test/Driver/sanitizer-ld.c (original)
+++ cfe/trunk/test/Driver/sanitizer-ld.c Thu Apr 20 16:11:51 2017
@@ -409,6 +409,15 @@
 // CHECK-ASAN-DARWIN106-CXX: libclang_rt.asan_osx_dynamic.dylib
 // CHECK-ASAN-DARWIN106-CXX-NOT: -lc++abi
 
+// RUN: %clangxx -fsanitize=leak %s -### -o %t.o 2>&1 \
+// RUN: -mmacosx-version-min=10.6 \
+// RUN: -target x86_64-apple-darwin13.4.0 -fuse-ld=ld -stdlib=platform \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-LSAN-DARWIN106-CXX %s
+// CHECK-LSAN-DARWIN106-CXX: "{{.*}}ld{{(.exe)?}}"
+// CHECK-LSAN-DARWIN106-CXX: libclang_rt.lsan_osx_dynamic.dylib
+// CHECK-LSAN-DARWIN106-CXX-NOT: -lc++abi
+
 // RUN: %clang -no-canonical-prefixes %s -

[PATCH] D31561: cmath: Skip Libc for integral types in isinf, etc.

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

dexonsmith added a comment.

Marshall, are you fine with figuring this out in-tree?  Or should I revert to 
using `std::is_floating_point` for now?


https://reviews.llvm.org/D31561



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

[PATCH] D32294: [clang-tidy] run-clang-tidy.py: check if clang-apply-replacements succeeds

[Piotr Padlewski via Phabricator via cfe-commits]

Prazek added a comment.

In https://reviews.llvm.org/D32294#732861, @kuhar wrote:

> After thinking about Piotr's comment, I think that a better way to perform 
> the check would be te invoking clang-apply-replacements with `--version` and 
> seeing if it fails even before running clang-tidy.
>  This way it is possible to save a lot of time when run-clang-tidy.py is run 
> on a big project and apply_fixes fails at the end.
>
> Let me know what you think about this approach.


Sounds good to me!


https://reviews.llvm.org/D32294



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