[PATCH] D47672: [Headers] Add _Interlocked*_HLEAcquire/_HLERelease

2018-06-01 Thread Ethan via Phabricator via cfe-commits
ethanhs created this revision.
Herald added a subscriber: cfe-commits.

Adds MSVC intrinsics for atomic exchange and compare & exchange.


Repository:
  rC Clang

https://reviews.llvm.org/D47672

Files:
  lib/Headers/immintrin.h
  lib/Headers/intrin.h


Index: lib/Headers/intrin.h
===
--- lib/Headers/intrin.h
+++ lib/Headers/intrin.h
@@ -174,12 +174,6 @@
 long _InterlockedAddLargeStatistic(__int64 volatile *_Addend, long _Value);
 unsigned char _interlockedbittestandreset(long volatile *, long);
 unsigned char _interlockedbittestandset(long volatile *, long);
-long _InterlockedCompareExchange_HLEAcquire(long volatile *, long, long);
-long _InterlockedCompareExchange_HLERelease(long volatile *, long, long);
-__int64 _InterlockedcompareExchange64_HLEAcquire(__int64 volatile *, __int64,
- __int64);
-__int64 _InterlockedCompareExchange64_HLERelease(__int64 volatile *, __int64,
- __int64);
 void *_InterlockedCompareExchangePointer_HLEAcquire(void *volatile *, void *,
 void *);
 void *_InterlockedCompareExchangePointer_HLERelease(void *volatile *, void *,
@@ -287,10 +281,6 @@
 __int64 *_ComparandResult);
 short _InterlockedCompareExchange16_np(short volatile *_Destination,
short _Exchange, short _Comparand);
-__int64 _InterlockedCompareExchange64_HLEAcquire(__int64 volatile *, __int64,
- __int64);
-__int64 _InterlockedCompareExchange64_HLERelease(__int64 volatile *, __int64,
- __int64);
 __int64 _InterlockedCompareExchange64_np(__int64 volatile *_Destination,
  __int64 _Exchange, __int64 
_Comparand);
 void *_InterlockedCompareExchangePointer_np(void *volatile *_Destination,
Index: lib/Headers/immintrin.h
===
--- lib/Headers/immintrin.h
+++ lib/Headers/immintrin.h
@@ -380,4 +380,63 @@
 #include 
 #endif
 
+/**\
+|* Interlocked Exchange HLE
+\**/
+#if defined(__i386__) || defined(__x86_64__)
+static __inline__ long __DEFAULT_FN_ATTRS
+_InterlockedExchange_HLEAcquire(long volatile *_Target, long _Value) {
+  __atomic_exchange(_Target, &_Value, &_Value, __ATOMIC_ACQUIRE);
+  return _Value;
+}
+static __inline__ long __DEFAULT_FN_ATTRS
+_InterlockedExchange_HLERelease(long volatile *_Target, long _Value) {
+  __atomic_exchange(_Target, &_Value, &_Value, __ATOMIC_RELEASE);
+  return _Value;
+}
+static __inline__ __int64 __DEFAULT_FN_ATTRS
+_InterlockedExchange64_HLEAcquire(__int64 volatile *_Target, __int64 _Value) {
+  __atomic_exchange(_Target, &_Value, &_Value, __ATOMIC_ACQUIRE);
+  return _Value;
+}
+static __inline__ __int64 __DEFAULT_FN_ATTRS
+_InterlockedExchange64_HLERelease(__int64 volatile *_Target, __int64 _Value) {
+  __atomic_exchange(_Target, &_Value, &_Value, __ATOMIC_RELEASE);
+  return _Value;
+}
+#endif
+/**\
+|* Interlocked Compare Exchange HLE
+\**/
+#if defined(__i386__) || defined(__x86_64__)
+static __inline__ long __DEFAULT_FN_ATTRS
+_InterlockedCompareExchange_HLEAcquire(long volatile *_Destination,
+  long _Exchange, long _Comparand) {
+  __atomic_compare_exchange(_Destination, &_Comparand, &_Exchange, 0,
+__ATOMIC_SEQ_CST, __ATOMIC_ACQUIRE);
+  return _Comparand;
+}
+static __inline__ long __DEFAULT_FN_ATTRS
+_InterlockedCompareExchange_HLERelease(long volatile *_Destination,
+  long _Exchange, long _Comparand) {
+  __atomic_compare_exchange(_Destination, &_Comparand, &_Exchange, 0,
+__ATOMIC_SEQ_CST, __ATOMIC_RELEASE);
+  return _Comparand;
+}
+static __inline__ __int64 __DEFAULT_FN_ATTRS
+_InterlockedCompareExchange64_HLEAcquire(__int64 volatile *_Destination,
+  __int64 _Exchange, __int64 _Comparand) {
+  __atomic_compare_exchange(_Destination, &_Comparand, &_Exchange, 0,
+__ATOMIC_SEQ_CST, __ATOMIC_ACQUIRE);
+  return _Comparand;
+}
+static __inline__ __int64 __DEFAULT_FN_ATTRS
+_InterlockedCompareExchange64_HLERelease(__int64 volatile *_Destination,
+  __int64 _Exchange, __int64 _Comparand) {
+  __atomic_compare_exchange(_Destination, &_Comparand, &_Exchange, 0,
+__ATOMIC_SEQ_CST, __ATOMIC_RELEASE);
+  return _Comparand;
+}
+#endif
+
 #endif /* __IMMINTRIN_H */


Index: 

r333815 - Revert "This diff includes changes for supporting the following types."

2018-06-01 Thread Leonard Chan via cfe-commits
Author: leonardchan
Date: Fri Jun  1 20:27:13 2018
New Revision: 333815

URL: http://llvm.org/viewvc/llvm-project?rev=333815=rev
Log:
Revert "This diff includes changes for supporting the following types."

This reverts commit r333814, which fails for a test checking the bit
width on ubuntu.

Removed:
cfe/trunk/test/Frontend/fixed_point.c
cfe/trunk/test/Frontend/fixed_point_bit_widths.c
cfe/trunk/test/Frontend/fixed_point_errors.c
cfe/trunk/test/Frontend/fixed_point_errors.cpp
cfe/trunk/test/Frontend/fixed_point_not_enabled.c
Modified:
cfe/trunk/include/clang-c/Index.h
cfe/trunk/include/clang/AST/ASTContext.h
cfe/trunk/include/clang/AST/BuiltinTypes.def
cfe/trunk/include/clang/Basic/DiagnosticCommonKinds.td
cfe/trunk/include/clang/Basic/LangOptions.def
cfe/trunk/include/clang/Basic/Specifiers.h
cfe/trunk/include/clang/Basic/TargetInfo.h
cfe/trunk/include/clang/Basic/TokenKinds.def
cfe/trunk/include/clang/Driver/Options.td
cfe/trunk/include/clang/Sema/DeclSpec.h
cfe/trunk/include/clang/Serialization/ASTBitCodes.h
cfe/trunk/lib/AST/ASTContext.cpp
cfe/trunk/lib/AST/ExprConstant.cpp
cfe/trunk/lib/AST/ItaniumMangle.cpp
cfe/trunk/lib/AST/MicrosoftMangle.cpp
cfe/trunk/lib/AST/NSAPI.cpp
cfe/trunk/lib/AST/Type.cpp
cfe/trunk/lib/AST/TypeLoc.cpp
cfe/trunk/lib/Analysis/PrintfFormatString.cpp
cfe/trunk/lib/Basic/TargetInfo.cpp
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/lib/CodeGen/CodeGenTypes.cpp
cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
cfe/trunk/lib/Driver/ToolChains/Clang.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/lib/Index/USRGeneration.cpp
cfe/trunk/lib/Parse/ParseDecl.cpp
cfe/trunk/lib/Sema/DeclSpec.cpp
cfe/trunk/lib/Sema/SemaTemplateVariadic.cpp
cfe/trunk/lib/Sema/SemaType.cpp
cfe/trunk/lib/Serialization/ASTCommon.cpp
cfe/trunk/lib/Serialization/ASTReader.cpp
cfe/trunk/tools/libclang/CXType.cpp

Modified: cfe/trunk/include/clang-c/Index.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang-c/Index.h?rev=333815=333814=333815=diff
==
--- cfe/trunk/include/clang-c/Index.h (original)
+++ cfe/trunk/include/clang-c/Index.h Fri Jun  1 20:27:13 2018
@@ -3182,14 +3182,8 @@ enum CXTypeKind {
   CXType_Float128 = 30,
   CXType_Half = 31,
   CXType_Float16 = 32,
-  CXType_ShortAccum = 33,
-  CXType_Accum = 34,
-  CXType_LongAccum = 35,
-  CXType_UShortAccum = 36,
-  CXType_UAccum = 37,
-  CXType_ULongAccum = 38,
   CXType_FirstBuiltin = CXType_Void,
-  CXType_LastBuiltin = CXType_ULongAccum,
+  CXType_LastBuiltin  = CXType_Float16,
 
   CXType_Complex = 100,
   CXType_Pointer = 101,

Modified: cfe/trunk/include/clang/AST/ASTContext.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTContext.h?rev=333815=333814=333815=diff
==
--- cfe/trunk/include/clang/AST/ASTContext.h (original)
+++ cfe/trunk/include/clang/AST/ASTContext.h Fri Jun  1 20:27:13 2018
@@ -1007,9 +1007,6 @@ public:
   CanQualType UnsignedCharTy, UnsignedShortTy, UnsignedIntTy, UnsignedLongTy;
   CanQualType UnsignedLongLongTy, UnsignedInt128Ty;
   CanQualType FloatTy, DoubleTy, LongDoubleTy, Float128Ty;
-  CanQualType ShortAccumTy, AccumTy,
-  LongAccumTy;  // ISO/IEC JTC1 SC22 WG14 N1169 Extension
-  CanQualType UnsignedShortAccumTy, UnsignedAccumTy, UnsignedLongAccumTy;
   CanQualType HalfTy; // [OpenCL 6.1.1.1], ARM NEON
   CanQualType Float16Ty; // C11 extension ISO/IEC TS 18661-3
   CanQualType FloatComplexTy, DoubleComplexTy, LongDoubleComplexTy;

Modified: cfe/trunk/include/clang/AST/BuiltinTypes.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/BuiltinTypes.def?rev=333815=333814=333815=diff
==
--- cfe/trunk/include/clang/AST/BuiltinTypes.def (original)
+++ cfe/trunk/include/clang/AST/BuiltinTypes.def Fri Jun  1 20:27:13 2018
@@ -122,26 +122,6 @@ SIGNED_TYPE(LongLong, LongLongTy)
 // '__int128_t'
 SIGNED_TYPE(Int128, Int128Ty)
 
-//===- Fixed point types 
--===//
-
-// 'short _Accum'
-SIGNED_TYPE(ShortAccum, ShortAccumTy)
-
-// '_Accum'
-SIGNED_TYPE(Accum, AccumTy)
-
-// 'long _Accum'
-SIGNED_TYPE(LongAccum, LongAccumTy)
-
-// 'unsigned short _Accum'
-UNSIGNED_TYPE(UShortAccum, UnsignedShortAccumTy)
-
-// 'unsigned _Accum'
-UNSIGNED_TYPE(UAccum, UnsignedAccumTy)
-
-// 'unsigned long _Accum'
-UNSIGNED_TYPE(ULongAccum, UnsignedLongAccumTy)
-
 //===- Floating point types 
---===//
 
 // 'half' in OpenCL, '__fp16' in ARM NEON.

Modified: cfe/trunk/include/clang/Basic/DiagnosticCommonKinds.td
URL: 

[PATCH] D46084: [Fixed Point Arithmetic] Addition of the Fixed Point _Accum type

2018-06-01 Thread Leonard Chan via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL333814: This diff includes changes for supporting the 
following types. (authored by leonardchan, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D46084?vs=149305=149602#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D46084

Files:
  cfe/trunk/include/clang-c/Index.h
  cfe/trunk/include/clang/AST/ASTContext.h
  cfe/trunk/include/clang/AST/BuiltinTypes.def
  cfe/trunk/include/clang/Basic/DiagnosticCommonKinds.td
  cfe/trunk/include/clang/Basic/LangOptions.def
  cfe/trunk/include/clang/Basic/Specifiers.h
  cfe/trunk/include/clang/Basic/TargetInfo.h
  cfe/trunk/include/clang/Basic/TokenKinds.def
  cfe/trunk/include/clang/Driver/Options.td
  cfe/trunk/include/clang/Sema/DeclSpec.h
  cfe/trunk/include/clang/Serialization/ASTBitCodes.h
  cfe/trunk/lib/AST/ASTContext.cpp
  cfe/trunk/lib/AST/ExprConstant.cpp
  cfe/trunk/lib/AST/ItaniumMangle.cpp
  cfe/trunk/lib/AST/MicrosoftMangle.cpp
  cfe/trunk/lib/AST/NSAPI.cpp
  cfe/trunk/lib/AST/Type.cpp
  cfe/trunk/lib/AST/TypeLoc.cpp
  cfe/trunk/lib/Analysis/PrintfFormatString.cpp
  cfe/trunk/lib/Basic/TargetInfo.cpp
  cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
  cfe/trunk/lib/CodeGen/CodeGenTypes.cpp
  cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
  cfe/trunk/lib/Driver/ToolChains/Clang.cpp
  cfe/trunk/lib/Frontend/CompilerInvocation.cpp
  cfe/trunk/lib/Index/USRGeneration.cpp
  cfe/trunk/lib/Parse/ParseDecl.cpp
  cfe/trunk/lib/Sema/DeclSpec.cpp
  cfe/trunk/lib/Sema/SemaTemplateVariadic.cpp
  cfe/trunk/lib/Sema/SemaType.cpp
  cfe/trunk/lib/Serialization/ASTCommon.cpp
  cfe/trunk/lib/Serialization/ASTReader.cpp
  cfe/trunk/test/Frontend/fixed_point.c
  cfe/trunk/test/Frontend/fixed_point_bit_widths.c
  cfe/trunk/test/Frontend/fixed_point_errors.c
  cfe/trunk/test/Frontend/fixed_point_errors.cpp
  cfe/trunk/test/Frontend/fixed_point_not_enabled.c
  cfe/trunk/tools/libclang/CXType.cpp

Index: cfe/trunk/tools/libclang/CXType.cpp
===
--- cfe/trunk/tools/libclang/CXType.cpp
+++ cfe/trunk/tools/libclang/CXType.cpp
@@ -53,6 +53,12 @@
 BTCASE(Float);
 BTCASE(Double);
 BTCASE(LongDouble);
+BTCASE(ShortAccum);
+BTCASE(Accum);
+BTCASE(LongAccum);
+BTCASE(UShortAccum);
+BTCASE(UAccum);
+BTCASE(ULongAccum);
 BTCASE(Float16);
 BTCASE(Float128);
 BTCASE(NullPtr);
@@ -546,6 +552,12 @@
 TKIND(Float);
 TKIND(Double);
 TKIND(LongDouble);
+TKIND(ShortAccum);
+TKIND(Accum);
+TKIND(LongAccum);
+TKIND(UShortAccum);
+TKIND(UAccum);
+TKIND(ULongAccum);
 TKIND(Float16);
 TKIND(Float128);
 TKIND(NullPtr);
Index: cfe/trunk/include/clang-c/Index.h
===
--- cfe/trunk/include/clang-c/Index.h
+++ cfe/trunk/include/clang-c/Index.h
@@ -3182,8 +3182,14 @@
   CXType_Float128 = 30,
   CXType_Half = 31,
   CXType_Float16 = 32,
+  CXType_ShortAccum = 33,
+  CXType_Accum = 34,
+  CXType_LongAccum = 35,
+  CXType_UShortAccum = 36,
+  CXType_UAccum = 37,
+  CXType_ULongAccum = 38,
   CXType_FirstBuiltin = CXType_Void,
-  CXType_LastBuiltin  = CXType_Float16,
+  CXType_LastBuiltin = CXType_ULongAccum,
 
   CXType_Complex = 100,
   CXType_Pointer = 101,
Index: cfe/trunk/include/clang/Driver/Options.td
===
--- cfe/trunk/include/clang/Driver/Options.td
+++ cfe/trunk/include/clang/Driver/Options.td
@@ -887,6 +887,11 @@
   Group, Flags<[CC1Option]>,
   HelpText<"Disable support for int128_t type">;
 
+def ffixed_point : Flag<["-"], "ffixed-point">, Group,
+   Flags<[CC1Option]>, HelpText<"Enable fixed point types">;
+def fno_fixed_point : Flag<["-"], "fno-fixed-point">, Group,
+  HelpText<"Disable fixed point types">;
+
 // Begin sanitizer flags. These should all be core options exposed in all driver
 // modes.
 let Flags = [CC1Option, CoreOption] in {
Index: cfe/trunk/include/clang/AST/ASTContext.h
===
--- cfe/trunk/include/clang/AST/ASTContext.h
+++ cfe/trunk/include/clang/AST/ASTContext.h
@@ -1007,6 +1007,9 @@
   CanQualType UnsignedCharTy, UnsignedShortTy, UnsignedIntTy, UnsignedLongTy;
   CanQualType UnsignedLongLongTy, UnsignedInt128Ty;
   CanQualType FloatTy, DoubleTy, LongDoubleTy, Float128Ty;
+  CanQualType ShortAccumTy, AccumTy,
+  LongAccumTy;  // ISO/IEC JTC1 SC22 WG14 N1169 Extension
+  CanQualType UnsignedShortAccumTy, UnsignedAccumTy, UnsignedLongAccumTy;
   CanQualType HalfTy; // [OpenCL 6.1.1.1], ARM NEON
   CanQualType Float16Ty; // C11 extension ISO/IEC TS 18661-3
   CanQualType FloatComplexTy, DoubleComplexTy, LongDoubleComplexTy;
Index: cfe/trunk/include/clang/AST/BuiltinTypes.def
===
--- 

r333814 - This diff includes changes for supporting the following types.

2018-06-01 Thread Leonard Chan via cfe-commits
Author: leonardchan
Date: Fri Jun  1 19:58:51 2018
New Revision: 333814

URL: http://llvm.org/viewvc/llvm-project?rev=333814=rev
Log:
This diff includes changes for supporting the following types.

```

// Primary fixed point types
signed short _Accum s_short_accum;
signed _Accum s_accum;
signed long _Accum s_long_accum;
unsigned short _Accum u_short_accum;
unsigned _Accum u_accum;
unsigned long _Accum u_long_accum;

// Aliased fixed point types
short _Accum short_accum;
_Accum accum;
long _Accum long_accum;

```

This diff only allows for declaration of the fixed point types. Assignment and 
other operations done on fixed point types according to 
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf will be added in 
future patches. The saturated versions of these types and the equivalent 
`_Fract` types will also be added in future patches.

The tests included are for asserting that we can declare these types.

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

Added:
cfe/trunk/test/Frontend/fixed_point.c
cfe/trunk/test/Frontend/fixed_point_bit_widths.c
cfe/trunk/test/Frontend/fixed_point_errors.c
cfe/trunk/test/Frontend/fixed_point_errors.cpp
cfe/trunk/test/Frontend/fixed_point_not_enabled.c
Modified:
cfe/trunk/include/clang-c/Index.h
cfe/trunk/include/clang/AST/ASTContext.h
cfe/trunk/include/clang/AST/BuiltinTypes.def
cfe/trunk/include/clang/Basic/DiagnosticCommonKinds.td
cfe/trunk/include/clang/Basic/LangOptions.def
cfe/trunk/include/clang/Basic/Specifiers.h
cfe/trunk/include/clang/Basic/TargetInfo.h
cfe/trunk/include/clang/Basic/TokenKinds.def
cfe/trunk/include/clang/Driver/Options.td
cfe/trunk/include/clang/Sema/DeclSpec.h
cfe/trunk/include/clang/Serialization/ASTBitCodes.h
cfe/trunk/lib/AST/ASTContext.cpp
cfe/trunk/lib/AST/ExprConstant.cpp
cfe/trunk/lib/AST/ItaniumMangle.cpp
cfe/trunk/lib/AST/MicrosoftMangle.cpp
cfe/trunk/lib/AST/NSAPI.cpp
cfe/trunk/lib/AST/Type.cpp
cfe/trunk/lib/AST/TypeLoc.cpp
cfe/trunk/lib/Analysis/PrintfFormatString.cpp
cfe/trunk/lib/Basic/TargetInfo.cpp
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/lib/CodeGen/CodeGenTypes.cpp
cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
cfe/trunk/lib/Driver/ToolChains/Clang.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/lib/Index/USRGeneration.cpp
cfe/trunk/lib/Parse/ParseDecl.cpp
cfe/trunk/lib/Sema/DeclSpec.cpp
cfe/trunk/lib/Sema/SemaTemplateVariadic.cpp
cfe/trunk/lib/Sema/SemaType.cpp
cfe/trunk/lib/Serialization/ASTCommon.cpp
cfe/trunk/lib/Serialization/ASTReader.cpp
cfe/trunk/tools/libclang/CXType.cpp

Modified: cfe/trunk/include/clang-c/Index.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang-c/Index.h?rev=333814=333813=333814=diff
==
--- cfe/trunk/include/clang-c/Index.h (original)
+++ cfe/trunk/include/clang-c/Index.h Fri Jun  1 19:58:51 2018
@@ -3182,8 +3182,14 @@ enum CXTypeKind {
   CXType_Float128 = 30,
   CXType_Half = 31,
   CXType_Float16 = 32,
+  CXType_ShortAccum = 33,
+  CXType_Accum = 34,
+  CXType_LongAccum = 35,
+  CXType_UShortAccum = 36,
+  CXType_UAccum = 37,
+  CXType_ULongAccum = 38,
   CXType_FirstBuiltin = CXType_Void,
-  CXType_LastBuiltin  = CXType_Float16,
+  CXType_LastBuiltin = CXType_ULongAccum,
 
   CXType_Complex = 100,
   CXType_Pointer = 101,

Modified: cfe/trunk/include/clang/AST/ASTContext.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTContext.h?rev=333814=333813=333814=diff
==
--- cfe/trunk/include/clang/AST/ASTContext.h (original)
+++ cfe/trunk/include/clang/AST/ASTContext.h Fri Jun  1 19:58:51 2018
@@ -1007,6 +1007,9 @@ public:
   CanQualType UnsignedCharTy, UnsignedShortTy, UnsignedIntTy, UnsignedLongTy;
   CanQualType UnsignedLongLongTy, UnsignedInt128Ty;
   CanQualType FloatTy, DoubleTy, LongDoubleTy, Float128Ty;
+  CanQualType ShortAccumTy, AccumTy,
+  LongAccumTy;  // ISO/IEC JTC1 SC22 WG14 N1169 Extension
+  CanQualType UnsignedShortAccumTy, UnsignedAccumTy, UnsignedLongAccumTy;
   CanQualType HalfTy; // [OpenCL 6.1.1.1], ARM NEON
   CanQualType Float16Ty; // C11 extension ISO/IEC TS 18661-3
   CanQualType FloatComplexTy, DoubleComplexTy, LongDoubleComplexTy;

Modified: cfe/trunk/include/clang/AST/BuiltinTypes.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/BuiltinTypes.def?rev=333814=333813=333814=diff
==
--- cfe/trunk/include/clang/AST/BuiltinTypes.def (original)
+++ cfe/trunk/include/clang/AST/BuiltinTypes.def Fri Jun  1 19:58:51 2018
@@ -122,6 +122,26 @@ SIGNED_TYPE(LongLong, LongLongTy)
 // '__int128_t'
 SIGNED_TYPE(Int128, Int128Ty)
 
+//===- Fixed point types 
--===//
+
+// 

[PATCH] D47671: [analyzer] Implement copy elision.

2018-06-01 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ created this revision.
NoQ added reviewers: dcoughlin, xazax.hun, a.sidorin, george.karpenkov, szepet, 
rnkovacs.
Herald added subscribers: cfe-commits, baloghadamsoftware.

This patch builds on top of https://reviews.llvm.org/D47616 to elide pre-C++17 
elidable constructors during analysis. They are present in the AST and in the 
CFG but they'll be skipped during analysis, as planned in 
http://lists.llvm.org/pipermail/cfe-dev/2018-March/057318.html

It also elides destructors that correspond to elided constructors, and for that 
i had to add another program state trait, because the universal state trait i 
added previously had no room for this flag.

The main idea is straightforward. Construction context for the elidable 
constructor can already be retrieved from construction context of the inner 
"temporary" constructor. Therefore upon constructing the "temporary", we can 
use the target region of the elided constructor (which isn't necessarily a 
temporary region). Then we flag the elidable constructor's `CXXConstructExpr` 
in the program state and track what target region was already computed for it. 
Upon encountering the elidable construct-expression during analysis, we don't 
perform construction, but only assign the value to the expression.

Temporary materialization becomes funny because temporary can now be 
materialized into a non-temporary region. But the algorithm has not changed 
much.

Massive changes in the tests indicate that copy elision is in fact working as 
intended. I also extended tests to track whether there were conservatively 
evaluated calls (those `glob` tests in `cxx17-mandatory-elision.cpp`). They 
indicate the problem with C++17 CFG that still contains destructors for 
C++17-mandatory-ly elided constructors. I could easily mark them as "elided", 
but it'd be better to never add them to the CFG in the first place.

I'm not sure we need an `-analyzer-config` flag for disabling this feature, 
though i wouldn't mind adding one.


Repository:
  rC Clang

https://reviews.llvm.org/D47671

Files:
  include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
  lib/StaticAnalyzer/Core/ExprEngine.cpp
  lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
  test/Analysis/cxx17-mandatory-elision.cpp
  test/Analysis/gtest.cpp
  test/Analysis/inlining/temp-dtors-path-notes.cpp
  test/Analysis/lifetime-extension.cpp
  test/Analysis/temporaries.cpp

Index: test/Analysis/temporaries.cpp
===
--- test/Analysis/temporaries.cpp
+++ test/Analysis/temporaries.cpp
@@ -612,107 +612,44 @@
   clang_analyzer_eval(c3.getY() == 2); // expected-warning{{TRUE}}
 
   C c4 = returnTemporaryWithConstruction();
-  clang_analyzer_eval(c4.getX() == 1);
-  clang_analyzer_eval(c4.getY() == 2);
-#ifdef TEMPORARY_DTORS
-  // expected-warning@-3{{TRUE}}
-  // expected-warning@-3{{TRUE}}
-#else
-  // expected-warning@-6{{UNKNOWN}}
-  // expected-warning@-6{{UNKNOWN}}
-#endif
+  clang_analyzer_eval(c4.getX() == 1); // expected-warning{{TRUE}}
+  clang_analyzer_eval(c4.getY() == 2); // expected-warning{{TRUE}}
 
   C c5 = returnTemporaryWithAnotherFunctionWithConstruction();
-  clang_analyzer_eval(c5.getX() == 1);
-  clang_analyzer_eval(c5.getY() == 2);
-#ifdef TEMPORARY_DTORS
-  // expected-warning@-3{{TRUE}}
-  // expected-warning@-3{{TRUE}}
-#else
-  // expected-warning@-6{{UNKNOWN}}
-  // expected-warning@-6{{UNKNOWN}}
-#endif
+  clang_analyzer_eval(c5.getX() == 1); // expected-warning{{TRUE}}
+  clang_analyzer_eval(c5.getY() == 2); // expected-warning{{TRUE}}
 
   C c6 = returnTemporaryWithCopyConstructionWithConstruction();
-  clang_analyzer_eval(c5.getX() == 1);
-  clang_analyzer_eval(c5.getY() == 2);
-#ifdef TEMPORARY_DTORS
-  // expected-warning@-3{{TRUE}}
-  // expected-warning@-3{{TRUE}}
-#else
-  // expected-warning@-6{{UNKNOWN}}
-  // expected-warning@-6{{UNKNOWN}}
-#endif
+  clang_analyzer_eval(c5.getX() == 1); // expected-warning{{TRUE}}
+  clang_analyzer_eval(c5.getY() == 2); // expected-warning{{TRUE}}
 
 #if __cplusplus >= 201103L
 
   C c7 = returnTemporaryWithBraces();
-  clang_analyzer_eval(c7.getX() == 1);
-  clang_analyzer_eval(c7.getY() == 2);
-#ifdef TEMPORARY_DTORS
-  // expected-warning@-3{{TRUE}}
-  // expected-warning@-3{{TRUE}}
-#else
-  // expected-warning@-6{{UNKNOWN}}
-  // expected-warning@-6{{UNKNOWN}}
-#endif
+  clang_analyzer_eval(c7.getX() == 1); // expected-warning{{TRUE}}
+  clang_analyzer_eval(c7.getY() == 2); // expected-warning{{TRUE}}
 
   C c8 = returnTemporaryWithAnotherFunctionWithBraces();
-  clang_analyzer_eval(c8.getX() == 1);
-  clang_analyzer_eval(c8.getY() == 2);
-#ifdef TEMPORARY_DTORS
-  // expected-warning@-3{{TRUE}}
-  // expected-warning@-3{{TRUE}}
-#else
-  // expected-warning@-6{{UNKNOWN}}
-  // expected-warning@-6{{UNKNOWN}}
-#endif
+  clang_analyzer_eval(c8.getX() == 1); // expected-warning{{TRUE}}
+  clang_analyzer_eval(c8.getY() == 2); // expected-warning{{TRUE}}
 
   C c9 = 

[PATCH] D45015: [Preprocessor] Allow libc++ to detect when aligned allocation is unavailable.

2018-06-01 Thread Eric Fiselier via Phabricator via cfe-commits
EricWF updated this revision to Diff 149596.
EricWF edited the summary of this revision.
EricWF added a comment.

Update the patch with the form suggested in the previous conversation. See the 
updated summary for a description of the behavior.

The Darwin driver no longer passes `-faligned-alloc-unavailable` when 
`-nostdinc++` is specified, but I'm not sure this is the behavior
we want.  Having `-nostdinc++` have side-effects which affect the 
well-formedness of new/delete expressions seems non-obvious and potentially 
problematic.


https://reviews.llvm.org/D45015

Files:
  include/clang/Basic/DiagnosticGroups.td
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/Driver/ToolChains/Darwin.cpp
  lib/Frontend/InitPreprocessor.cpp
  lib/Sema/SemaExprCXX.cpp
  test/Driver/unavailable_aligned_allocation.cpp
  test/Lexer/aligned-allocation.cpp

Index: test/Lexer/aligned-allocation.cpp
===
--- /dev/null
+++ test/Lexer/aligned-allocation.cpp
@@ -0,0 +1,23 @@
+// RUN: %clang_cc1 -triple x86_64-apple-macosx10.12.0 -fexceptions -std=c++17 -verify %s \
+// RUN:   -DEXPECT_DEFINED
+//
+// RUN: %clang_cc1 -triple x86_64-apple-macosx10.12.0 -fexceptions -std=c++17 -verify %s \
+// RUN:   -faligned-alloc-unavailable
+//
+// RUN: %clang_cc1 -triple x86_64-apple-macosx10.12.0 -fexceptions -std=c++17 -verify %s \
+// RUN:   -faligned-allocation -faligned-alloc-unavailable
+
+// Test that __cpp_aligned_new is not defined when CC1 is passed
+// -faligned-alloc-unavailable by the Darwin driver, even when aligned
+// allocation is actually enabled.
+
+// expected-no-diagnostics
+#ifdef EXPECT_DEFINED
+# ifndef __cpp_aligned_new
+#   error "__cpp_aligned_new" should be defined
+# endif
+#else
+# ifdef __cpp_aligned_new
+#   error "__cpp_aligned_new" should not be defined
+# endif
+#endif
Index: test/Driver/unavailable_aligned_allocation.cpp
===
--- test/Driver/unavailable_aligned_allocation.cpp
+++ test/Driver/unavailable_aligned_allocation.cpp
@@ -51,4 +51,16 @@
 // RUN: -c -### %s 2>&1 \
 // RUN:   | FileCheck %s -check-prefix=AVAILABLE
 //
+// Check that passing -faligned-allocation, -fno-aligned-allocation, or
+// -nostdinc++ stops the driver from passing -faligned-alloc-unavailable to cc1.
+//
+// RUN: %clang -target x86_64-apple-macosx10.12 -faligned-allocation -c -### %s 2>&1 \
+// RUN:   | FileCheck %s -check-prefix=AVAILABLE
+//
+// RUN: %clang -target x86_64-apple-macosx10.12 -fno-aligned-allocation -c -### %s 2>&1 \
+// RUN:   | FileCheck %s -check-prefix=AVAILABLE
+//
+// RUN: %clang -target x86_64-apple-macosx10.12 -nostdinc++ -c -### %s 2>&1 \
+// RUN:   | FileCheck %s -check-prefix=AVAILABLE
+
 // AVAILABLE-NOT: "-faligned-alloc-unavailable"
Index: lib/Sema/SemaExprCXX.cpp
===
--- lib/Sema/SemaExprCXX.cpp
+++ lib/Sema/SemaExprCXX.cpp
@@ -1697,7 +1697,7 @@
 StringRef OSName = AvailabilityAttr::getPlatformNameSourceSpelling(
 S.getASTContext().getTargetInfo().getPlatformName());
 
-S.Diag(Loc, diag::warn_aligned_allocation_unavailable)
+S.Diag(Loc, diag::err_aligned_allocation_unavailable)
 << IsDelete << FD.getType().getAsString() << OSName
 << alignedAllocMinVersion(T.getOS()).getAsString();
 S.Diag(Loc, diag::note_silence_unligned_allocation_unavailable);
Index: lib/Frontend/InitPreprocessor.cpp
===
--- lib/Frontend/InitPreprocessor.cpp
+++ lib/Frontend/InitPreprocessor.cpp
@@ -551,7 +551,7 @@
 Builder.defineMacro("__cpp_nontype_template_args", "201411");
 Builder.defineMacro("__cpp_fold_expressions", "201603");
   }
-  if (LangOpts.AlignedAllocation)
+  if (LangOpts.AlignedAllocation && !LangOpts.AlignedAllocationUnavailable)
 Builder.defineMacro("__cpp_aligned_new", "201606");
 
   // TS features.
Index: lib/Driver/ToolChains/Darwin.cpp
===
--- lib/Driver/ToolChains/Darwin.cpp
+++ lib/Driver/ToolChains/Darwin.cpp
@@ -2018,7 +2018,13 @@
 void Darwin::addClangTargetOptions(const llvm::opt::ArgList ,
llvm::opt::ArgStringList ,
Action::OffloadKind DeviceOffloadKind) const {
-  if (isAlignedAllocationUnavailable())
+  // Pass "-faligned-alloc-unavailable" only when the user hasn't manually
+  // enabled or disabled aligned allocations and hasn't specified a custom
+  // standard library installation.
+  if (!DriverArgs.hasArgNoClaim(options::OPT_faligned_allocation,
+options::OPT_fno_aligned_allocation,
+options::OPT_nostdincxx) &&
+  isAlignedAllocationUnavailable())
 CC1Args.push_back("-faligned-alloc-unavailable");
 }
 
Index: include/clang/Basic/DiagnosticSemaKinds.td

[PATCH] D47564: [Parse] Use CapturedStmt for @finally on MSVC

2018-06-01 Thread Shoaib Meenai via Phabricator via cfe-commits
smeenai added a comment.

In https://reviews.llvm.org/D47564#1118424, @rjmccall wrote:

> In https://reviews.llvm.org/D47564#1118423, @smeenai wrote:
>
> > In https://reviews.llvm.org/D47564#1118381, @rjmccall wrote:
> >
> > > That's an interesting idea.  I don't see any particular reason not to do 
> > > it this way if you're willing to accept that it's never going to support 
> > > the full control-flow possibilities of @finally.  You will need to add 
> > > JumpDiagnostics logic to prevent branches out of the block, and I don't 
> > > know how this will interact with attempts to throw an exception out.
> >
> >
> > There's already some logic in CapturedStmt to prevent branches out of the 
> > block:
> >
> > - Attempting to return will produce "cannot return from Objective-C 
> > @finally statement"
> > - Attempting to goto out of the block will result in "use of undeclared 
> > label", which is a bad diagnostic (and should be improved), but it does 
> > error
>
>
> Alright, that makes sense.
>
> > It should be possible to add support for returns, at least; the idea we'd 
> > discussed with @rnk was setting a flag in the captured function to indicate 
> > a return having been executed, and then reading that flag outside the 
> > captured function and acting on it appropriately. gotos would be more 
> > complicated, but I think we could make them work if we really wanted to.
> > 
> > Throwing an exception out should just work, I think; the outlined function 
> > will just participate normally in exception handling. Did you have a 
> > specific case you were thinking of?
>
> No, it was just a general question.  Have you gotten this to a point where 
> it's testable?


Yup, it's been working fine in my local testing. There's one more patch that I 
need to put up, which actually handles doing proper codegen for 
@try/@catch/@finally; I'm working on cleaning that up right now. The other 
piece of the puzzle is https://reviews.llvm.org/D47233, which emits the proper 
typeinfo required for this.


Repository:
  rC Clang

https://reviews.llvm.org/D47564



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


r333810 - [cmake] Support LLD for CLANG_ORDER_FILE

2018-06-01 Thread Shoaib Meenai via cfe-commits
Author: smeenai
Date: Fri Jun  1 18:22:39 2018
New Revision: 333810

URL: http://llvm.org/viewvc/llvm-project?rev=333810=rev
Log:
[cmake] Support LLD for CLANG_ORDER_FILE

LLD also supports order files using the `--symbol-ordering-file` option.
As the name would suggest, the order file format is slightly different
from gold; gold's order files specify section names, whereas LLD's
specify symbol names. Assuming you have an order file in the correct
format though, we should support using it with LLD.

Switch the check to actually use LLVM's linker detection rather than
just checking for the presence of the gold executable, since we might
have a gold executable present but be using LLD (or bfd for that matter)
as our linker.

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

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

Modified: cfe/trunk/tools/driver/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/driver/CMakeLists.txt?rev=333810=333809=333810=diff
==
--- cfe/trunk/tools/driver/CMakeLists.txt (original)
+++ cfe/trunk/tools/driver/CMakeLists.txt Fri Jun  1 18:22:39 2018
@@ -98,13 +98,16 @@ if (APPLE)
   set(TOOL_INFO_BUILD_VERSION)
 endif()
 
-if(CLANG_ORDER_FILE AND (LD64_EXECUTABLE OR GOLD_EXECUTABLE))
+if(CLANG_ORDER_FILE AND
+   (LD64_EXECUTABLE OR LLVM_LINKER_IS_GOLD OR LLVM_LINKER_IS_LLD))
   include(CheckLinkerFlag)
 
   if (LD64_EXECUTABLE)
 set(LINKER_ORDER_FILE_OPTION "-Wl,-order_file,${CLANG_ORDER_FILE}")
-  elseif (GOLD_EXECUTABLE)
+  elseif (LLVM_LINKER_IS_GOLD)
 set(LINKER_ORDER_FILE_OPTION 
"-Wl,--section-ordering-file,${CLANG_ORDER_FILE}")
+  elseif (LLVM_LINKER_IS_LLD)
+set(LINKER_ORDER_FILE_OPTION 
"-Wl,--symbol-ordering-file,${CLANG_ORDER_FILE}")
   endif()
 
   # This is a test to ensure the actual order file works with the linker.


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


[PATCH] D47669: [cmake] Support LLD for CLANG_ORDER_FILE

2018-06-01 Thread Shoaib Meenai via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL333810: [cmake] Support LLD for CLANG_ORDER_FILE (authored 
by smeenai, committed by ).
Herald added a subscriber: llvm-commits.

Repository:
  rL LLVM

https://reviews.llvm.org/D47669

Files:
  cfe/trunk/tools/driver/CMakeLists.txt


Index: cfe/trunk/tools/driver/CMakeLists.txt
===
--- cfe/trunk/tools/driver/CMakeLists.txt
+++ cfe/trunk/tools/driver/CMakeLists.txt
@@ -98,13 +98,16 @@
   set(TOOL_INFO_BUILD_VERSION)
 endif()
 
-if(CLANG_ORDER_FILE AND (LD64_EXECUTABLE OR GOLD_EXECUTABLE))
+if(CLANG_ORDER_FILE AND
+   (LD64_EXECUTABLE OR LLVM_LINKER_IS_GOLD OR LLVM_LINKER_IS_LLD))
   include(CheckLinkerFlag)
 
   if (LD64_EXECUTABLE)
 set(LINKER_ORDER_FILE_OPTION "-Wl,-order_file,${CLANG_ORDER_FILE}")
-  elseif (GOLD_EXECUTABLE)
+  elseif (LLVM_LINKER_IS_GOLD)
 set(LINKER_ORDER_FILE_OPTION 
"-Wl,--section-ordering-file,${CLANG_ORDER_FILE}")
+  elseif (LLVM_LINKER_IS_LLD)
+set(LINKER_ORDER_FILE_OPTION 
"-Wl,--symbol-ordering-file,${CLANG_ORDER_FILE}")
   endif()
 
   # This is a test to ensure the actual order file works with the linker.


Index: cfe/trunk/tools/driver/CMakeLists.txt
===
--- cfe/trunk/tools/driver/CMakeLists.txt
+++ cfe/trunk/tools/driver/CMakeLists.txt
@@ -98,13 +98,16 @@
   set(TOOL_INFO_BUILD_VERSION)
 endif()
 
-if(CLANG_ORDER_FILE AND (LD64_EXECUTABLE OR GOLD_EXECUTABLE))
+if(CLANG_ORDER_FILE AND
+   (LD64_EXECUTABLE OR LLVM_LINKER_IS_GOLD OR LLVM_LINKER_IS_LLD))
   include(CheckLinkerFlag)
 
   if (LD64_EXECUTABLE)
 set(LINKER_ORDER_FILE_OPTION "-Wl,-order_file,${CLANG_ORDER_FILE}")
-  elseif (GOLD_EXECUTABLE)
+  elseif (LLVM_LINKER_IS_GOLD)
 set(LINKER_ORDER_FILE_OPTION "-Wl,--section-ordering-file,${CLANG_ORDER_FILE}")
+  elseif (LLVM_LINKER_IS_LLD)
+set(LINKER_ORDER_FILE_OPTION "-Wl,--symbol-ordering-file,${CLANG_ORDER_FILE}")
   endif()
 
   # This is a test to ensure the actual order file works with the linker.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D47669: [cmake] Support LLD for CLANG_ORDER_FILE

2018-06-01 Thread Petr Hosek via Phabricator via cfe-commits
phosek accepted this revision.
phosek added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rC Clang

https://reviews.llvm.org/D47669



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


[PATCH] D47669: [cmake] Support LLD for CLANG_ORDER_FILE

2018-06-01 Thread Shoaib Meenai via Phabricator via cfe-commits
smeenai created this revision.
smeenai added reviewers: beanz, compnerd, phosek.
Herald added a subscriber: mgorny.
smeenai added a subscriber: alexshap.

LLD also supports order files using the `--symbol-ordering-file` option.
As the name would suggest, the order file format is slightly different
from gold; gold's order files specify section names, whereas LLD's
specify symbol names. Assuming you have an order file in the correct
format though, we should support using it with LLD.

Switch the check to actually use LLVM's linker detection rather than
just checking for the presence of the gold executable, since we might
have a gold executable present but be using LLD (or bfd for that matter)
as our linker.


Repository:
  rC Clang

https://reviews.llvm.org/D47669

Files:
  tools/driver/CMakeLists.txt


Index: tools/driver/CMakeLists.txt
===
--- tools/driver/CMakeLists.txt
+++ tools/driver/CMakeLists.txt
@@ -98,13 +98,16 @@
   set(TOOL_INFO_BUILD_VERSION)
 endif()
 
-if(CLANG_ORDER_FILE AND (LD64_EXECUTABLE OR GOLD_EXECUTABLE))
+if(CLANG_ORDER_FILE AND
+   (LD64_EXECUTABLE OR LLVM_LINKER_IS_GOLD OR LLVM_LINKER_IS_LLD))
   include(CheckLinkerFlag)
 
   if (LD64_EXECUTABLE)
 set(LINKER_ORDER_FILE_OPTION "-Wl,-order_file,${CLANG_ORDER_FILE}")
-  elseif (GOLD_EXECUTABLE)
+  elseif (LLVM_LINKER_IS_GOLD)
 set(LINKER_ORDER_FILE_OPTION 
"-Wl,--section-ordering-file,${CLANG_ORDER_FILE}")
+  elseif (LLVM_LINKER_IS_LLD)
+set(LINKER_ORDER_FILE_OPTION 
"-Wl,--symbol-ordering-file,${CLANG_ORDER_FILE}")
   endif()
 
   # This is a test to ensure the actual order file works with the linker.


Index: tools/driver/CMakeLists.txt
===
--- tools/driver/CMakeLists.txt
+++ tools/driver/CMakeLists.txt
@@ -98,13 +98,16 @@
   set(TOOL_INFO_BUILD_VERSION)
 endif()
 
-if(CLANG_ORDER_FILE AND (LD64_EXECUTABLE OR GOLD_EXECUTABLE))
+if(CLANG_ORDER_FILE AND
+   (LD64_EXECUTABLE OR LLVM_LINKER_IS_GOLD OR LLVM_LINKER_IS_LLD))
   include(CheckLinkerFlag)
 
   if (LD64_EXECUTABLE)
 set(LINKER_ORDER_FILE_OPTION "-Wl,-order_file,${CLANG_ORDER_FILE}")
-  elseif (GOLD_EXECUTABLE)
+  elseif (LLVM_LINKER_IS_GOLD)
 set(LINKER_ORDER_FILE_OPTION "-Wl,--section-ordering-file,${CLANG_ORDER_FILE}")
+  elseif (LLVM_LINKER_IS_LLD)
+set(LINKER_ORDER_FILE_OPTION "-Wl,--symbol-ordering-file,${CLANG_ORDER_FILE}")
   endif()
 
   # This is a test to ensure the actual order file works with the linker.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r333808 - [cmake] Use LLVM's check_linker_flag

2018-06-01 Thread Shoaib Meenai via cfe-commits
Author: smeenai
Date: Fri Jun  1 17:49:54 2018
New Revision: 333808

URL: http://llvm.org/viewvc/llvm-project?rev=333808=rev
Log:
[cmake] Use LLVM's check_linker_flag

LLVM already defines this function, so make use of it instead of rolling
our own.

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

Modified: cfe/trunk/tools/driver/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/driver/CMakeLists.txt?rev=333808=333807=333808=diff
==
--- cfe/trunk/tools/driver/CMakeLists.txt (original)
+++ cfe/trunk/tools/driver/CMakeLists.txt Fri Jun  1 17:49:54 2018
@@ -99,14 +99,7 @@ if (APPLE)
 endif()
 
 if(CLANG_ORDER_FILE AND (LD64_EXECUTABLE OR GOLD_EXECUTABLE))
-  include(CMakePushCheckState)
-
-  function(check_linker_flag flag out_var)
-cmake_push_check_state()
-set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} ${flag}")
-check_cxx_compiler_flag("" ${out_var})
-cmake_pop_check_state()
-  endfunction()
+  include(CheckLinkerFlag)
 
   if (LD64_EXECUTABLE)
 set(LINKER_ORDER_FILE_OPTION "-Wl,-order_file,${CLANG_ORDER_FILE}")


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


[PATCH] D47668: [Driver][Fuchsia] Pass LTO flags to linker

2018-06-01 Thread Petr Hosek via Phabricator via cfe-commits
phosek created this revision.
phosek added reviewers: mcgrathr, juliehockett.
Herald added subscribers: cfe-commits, inglorion.

Even though we use lld by default for Fuchsia, we use Gold plugin
arguments like all other drivers as lld supports Gold plugin options.


Repository:
  rC Clang

https://reviews.llvm.org/D47668

Files:
  clang/lib/Driver/ToolChains/Fuchsia.cpp
  clang/test/Driver/fuchsia.c


Index: clang/test/Driver/fuchsia.c
===
--- clang/test/Driver/fuchsia.c
+++ clang/test/Driver/fuchsia.c
@@ -114,3 +114,16 @@
 // RUN: | FileCheck %s -check-prefix=CHECK-SCUDO-SHARED
 // CHECK-SCUDO-SHARED: "-fsanitize=safe-stack,scudo"
 // CHECK-SCUDO-SHARED: "{{.*[/\\]}}libclang_rt.scudo-x86_64.so"
+
+// RUN: %clang %s -### --target=aarch64-fuchsia \
+// RUN: -O3 -flto -mcpu=cortex-a53 2>&1 \
+// RUN: | FileCheck %s -check-prefix=CHECK-LTO
+// CHECK-LTO: "-plugin-opt=mcpu=cortex-a53"
+// CHECK-LTO: "-plugin-opt=O3"
+
+// RUN: %clang %s -### --target=x86_64-fuchsia \
+// RUN: -flto=thin -flto-jobs=8 2>&1 \
+// RUN: | FileCheck %s -check-prefix=CHECK-THINLTO
+// CHECK-THINLTO: "-plugin-opt=mcpu=x86-64"
+// CHECK-THINLTO: "-plugin-opt=thinlto"
+// CHECK-THINLTO: "-plugin-opt=jobs=8"
Index: clang/lib/Driver/ToolChains/Fuchsia.cpp
===
--- clang/lib/Driver/ToolChains/Fuchsia.cpp
+++ clang/lib/Driver/ToolChains/Fuchsia.cpp
@@ -100,6 +100,12 @@
 
   ToolChain.AddFilePathLibArgs(Args, CmdArgs);
 
+  if (D.isUsingLTO()) {
+assert(!Inputs.empty() && "Must have at least one input.");
+AddGoldPlugin(ToolChain, Args, CmdArgs, Output, Inputs[0],
+  D.getLTOMode() == LTOK_Thin);
+  }
+
   addSanitizerRuntimes(ToolChain, Args, CmdArgs);
 
   AddLinkerInputs(ToolChain, Inputs, Args, CmdArgs, JA);


Index: clang/test/Driver/fuchsia.c
===
--- clang/test/Driver/fuchsia.c
+++ clang/test/Driver/fuchsia.c
@@ -114,3 +114,16 @@
 // RUN: | FileCheck %s -check-prefix=CHECK-SCUDO-SHARED
 // CHECK-SCUDO-SHARED: "-fsanitize=safe-stack,scudo"
 // CHECK-SCUDO-SHARED: "{{.*[/\\]}}libclang_rt.scudo-x86_64.so"
+
+// RUN: %clang %s -### --target=aarch64-fuchsia \
+// RUN: -O3 -flto -mcpu=cortex-a53 2>&1 \
+// RUN: | FileCheck %s -check-prefix=CHECK-LTO
+// CHECK-LTO: "-plugin-opt=mcpu=cortex-a53"
+// CHECK-LTO: "-plugin-opt=O3"
+
+// RUN: %clang %s -### --target=x86_64-fuchsia \
+// RUN: -flto=thin -flto-jobs=8 2>&1 \
+// RUN: | FileCheck %s -check-prefix=CHECK-THINLTO
+// CHECK-THINLTO: "-plugin-opt=mcpu=x86-64"
+// CHECK-THINLTO: "-plugin-opt=thinlto"
+// CHECK-THINLTO: "-plugin-opt=jobs=8"
Index: clang/lib/Driver/ToolChains/Fuchsia.cpp
===
--- clang/lib/Driver/ToolChains/Fuchsia.cpp
+++ clang/lib/Driver/ToolChains/Fuchsia.cpp
@@ -100,6 +100,12 @@
 
   ToolChain.AddFilePathLibArgs(Args, CmdArgs);
 
+  if (D.isUsingLTO()) {
+assert(!Inputs.empty() && "Must have at least one input.");
+AddGoldPlugin(ToolChain, Args, CmdArgs, Output, Inputs[0],
+  D.getLTOMode() == LTOK_Thin);
+  }
+
   addSanitizerRuntimes(ToolChain, Args, CmdArgs);
 
   AddLinkerInputs(ToolChain, Inputs, Args, CmdArgs, JA);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D47667: [CFG] [analyzer] Remove unnecessary CXXBindTemporaryExpr from lifetime-extended temporary construction contexts.

2018-06-01 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ created this revision.
NoQ added reviewers: dcoughlin, xazax.hun, a.sidorin, george.karpenkov, szepet, 
rnkovacs.
Herald added subscribers: cfe-commits, baloghadamsoftware.

`CXXBindTemporaryExpr ` is used for attaching the destructor of the temporary 
object to it.

If the object is lifetime-extended (which is indicated by the surrounding 
`MaterializeTemporaryExpr`'s storage duration property), then it doesn't 
require a temporary object destructor; it'll instead be destroyed automatically.

Remove `CXXBindTemporaryExpr` completely from the `ConstructionContext` in this 
case, instead of making clients take care of it.


Repository:
  rC Clang

https://reviews.llvm.org/D47667

Files:
  lib/Analysis/ConstructionContext.cpp
  lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
  test/Analysis/auto-obj-dtors-cfg-output.cpp
  test/Analysis/cfg-rich-constructors.cpp
  test/Analysis/temp-obj-dtors-cfg-output.cpp

Index: test/Analysis/temp-obj-dtors-cfg-output.cpp
===
--- test/Analysis/temp-obj-dtors-cfg-output.cpp
+++ test/Analysis/temp-obj-dtors-cfg-output.cpp
@@ -857,7 +857,7 @@
 // CHECK: 3: [B11.2] (ImplicitCastExpr, NoOp, const class A)
 // CHECK: 4: [B11.3]
 // WARNINGS: 5: [B11.4] (CXXConstructExpr, class A)
-// ANALYZER: 5: [B11.4] (CXXConstructExpr, [B11.6], [B10.3], class A)
+// ANALYZER: 5: [B11.4] (CXXConstructExpr, [B10.3], class A)
 // CHECK: 6: [B11.5] (BindTemporary)
 // CHECK: Preds (1): B13
 // CHECK: Succs (1): B10
@@ -878,7 +878,7 @@
 // CHECK:12: [B12.11] (ImplicitCastExpr, NoOp, const class A)
 // CHECK:13: [B12.12]
 // WARNINGS:14: [B12.13] (CXXConstructExpr, class A)
-// ANALYZER:14: [B12.13] (CXXConstructExpr, [B12.15], [B10.3], class A)
+// ANALYZER:14: [B12.13] (CXXConstructExpr, [B10.3], class A)
 // CHECK:15: [B12.14] (BindTemporary)
 // CHECK: Preds (1): B13
 // CHECK: Succs (1): B10
@@ -1104,7 +1104,7 @@
 // CHECK: Succs (1): B1
 // CHECK:   [B1]
 // WARNINGS: 1: A() (CXXConstructExpr, class A)
-// ANALYZER: 1: A() (CXXConstructExpr, [B1.2], [B1.4], class A)
+// ANALYZER: 1: A() (CXXConstructExpr, [B1.4], class A)
 // CHECK: 2: [B1.1] (BindTemporary)
 // CHECK: 3: [B1.2] (ImplicitCastExpr, NoOp, const class A)
 // CHECK: 4: [B1.3]
@@ -1150,7 +1150,7 @@
 // CHECK: 1: A::make
 // CHECK: 2: [B1.1] (ImplicitCastExpr, FunctionToPointerDecay, class A (*)(void))
 // WARNINGS: 3: [B1.2]()
-// ANALYZER: 3: [B1.2]() (CXXRecordTypedCall, [B1.4], [B1.6])
+// ANALYZER: 3: [B1.2]() (CXXRecordTypedCall, [B1.6])
 // CHECK: 4: [B1.3] (BindTemporary)
 // CHECK: 5: [B1.4] (ImplicitCastExpr, NoOp, const class A)
 // CHECK: 6: [B1.5]
Index: test/Analysis/cfg-rich-constructors.cpp
===
--- test/Analysis/cfg-rich-constructors.cpp
+++ test/Analysis/cfg-rich-constructors.cpp
@@ -572,7 +572,7 @@
 
 // CHECK: void referenceVariableWithConstructor()
 // CHECK:  1: 0
-// CHECK-NEXT: 2: [B1.1] (CXXConstructExpr, [B1.3], [B1.4], const class temporary_object_expr_with_dtors::D)
+// CHECK-NEXT: 2: [B1.1] (CXXConstructExpr, [B1.4], const class temporary_object_expr_with_dtors::D)
 // CHECK-NEXT: 3: [B1.2] (BindTemporary)
 // CHECK-NEXT: 4: [B1.3]
 // CHECK-NEXT: 5: const temporary_object_expr_with_dtors::D (0);
@@ -582,7 +582,7 @@
 }
 
 // CHECK: void referenceVariableWithInitializer()
-// CHECK:  1: temporary_object_expr_with_dtors::D() (CXXConstructExpr, [B1.2], [B1.4], class temporary_object_expr_with_dtors::D)
+// CHECK:  1: temporary_object_expr_with_dtors::D() (CXXConstructExpr, [B1.4], class temporary_object_expr_with_dtors::D)
 // CHECK-NEXT: 2: [B1.1] (BindTemporary)
 // CHECK-NEXT: 3: [B1.2] (ImplicitCastExpr, NoOp, const class temporary_object_expr_with_dtors::D)
 // CHECK-NEXT: 4: [B1.3]
@@ -612,16 +612,16 @@
 // CXX11-NEXT: 4: [B5.3] (BindTemporary)
 // CXX11-NEXT: 5: [B5.4] (ImplicitCastExpr, NoOp, const class temporary_object_expr_with_dtors::D)
 // CXX11-NEXT: 6: [B5.5]
-// CXX11-NEXT: 7: [B5.6] (CXXConstructExpr, [B5.8], [B4.3], class temporary_object_expr_with_dtors::D)
+// CXX11-NEXT: 7: [B5.6] (CXXConstructExpr, [B4.3], class temporary_object_expr_with_dtors::D)
 // CXX11-NEXT: 8: [B5.7] (BindTemporary)
 // CXX11:[B6]
 // CXX11-NEXT: 1: 0
 // CXX11-NEXT: 2: [B6.1] (CXXConstructExpr, [B6.3], [B6.6], [B6.7], class temporary_object_expr_with_dtors::D)
 // CXX11-NEXT: 3: [B6.2] (BindTemporary)
 // CXX11-NEXT: 4: temporary_object_expr_with_dtors::D([B6.3]) (CXXFunctionalCastExpr, ConstructorConversion, class temporary_object_expr_with_dtors::D)
 // CXX11-NEXT: 5: [B6.4] (ImplicitCastExpr, NoOp, const class temporary_object_expr_with_dtors::D)
 // CXX11-NEXT: 6: [B6.5]
-// CXX11-NEXT: 7: [B6.6] (CXXConstructExpr, [B6.8], [B4.3], class 

[PATCH] D47666: Refactored clang-fuzzer and added new (copy) files

2018-06-01 Thread Vitaly Buka via Phabricator via cfe-commits
vitalybuka added a comment.

In https://reviews.llvm.org/D47666#1119821, @vitalybuka wrote:

> Good practice is to avoid merging changes into a single one.
>  Here one patch should be "refactoring" and the second for 
> "loop-proto-fuzzer."


We are doing this for several reasons:

1. smaller patches, faster review
2. easier to investigate regressions caused by smaller patches


Repository:
  rC Clang

https://reviews.llvm.org/D47666



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


[PATCH] D47666: Refactored clang-fuzzer and added new (copy) files

2018-06-01 Thread Vitaly Buka via Phabricator via cfe-commits
vitalybuka added a comment.

Good practice is to avoid merging changes into a single one.
Here one patch should be "refactoring" and the second for "loop-proto-fuzzer."




Comment at: tools/clang-fuzzer/ExampleClangProtoFuzzer.cpp:29
+/*
 static std::vector CLArgs;
 

Please delete commented code.



Comment at: tools/clang-fuzzer/FuzzerInitialize.h:11
+
+static std::vector CLArgs;
+extern "C" int LLVMFuzzerInitialize(int *argc, char ***argv);

static here means that each module which includes this header is going to have 
own instance of the variable.
I guess you need only one instance in FuzzerInitialize.cpp which can be 
achieved with 
```
extern std::vector CLArgs;

```

However I'd recommend getter:

```
const std::vector& GetCLArgs();
```
with implementation and 
```
static std::vector CLArgs;
```
in FuzzerInitialize.cpp



Comment at: tools/clang-fuzzer/FuzzerInitialize.h:12
+static std::vector CLArgs;
+extern "C" int LLVMFuzzerInitialize(int *argc, char ***argv);
+

you need only CLArgs here.
code which includes this header is not going to call LLVMFuzzerInitialize



Comment at: tools/clang-fuzzer/experimental/ExampleClangLoopProtoFuzzer.cpp:30
 
+/*
 static std::vector CLArgs;

Please remove deleted code


Repository:
  rC Clang

https://reviews.llvm.org/D47666



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


[PATCH] D47658: [analyzer] Re-enable lifetime extension for temporaries with destructors and bring back static temporaries.

2018-06-01 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ updated this revision to Diff 149586.
NoQ added a comment.

Remove the outdated FIXME comment.


https://reviews.llvm.org/D47658

Files:
  lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
  test/Analysis/lifetime-extension.cpp
  test/Analysis/temporaries-callback-order.cpp

Index: test/Analysis/temporaries-callback-order.cpp
===
--- test/Analysis/temporaries-callback-order.cpp
+++ test/Analysis/temporaries-callback-order.cpp
@@ -8,11 +8,7 @@
 };
 
 void testTemporaries() {
-  // This triggers RegionChanges twice:
-  // - Once for zero-initialization of the structure.
-  // - Once for creating a temporary region and copying the structure there.
-  // FIXME: This code shouldn't really produce the extra temporary, however
-  // that's how we behave for now.
+  // This triggers RegionChanges once for zero-initialization of the structure.
   Sub().m();
 }
 
@@ -29,7 +25,6 @@
 
 // testTemporaries():
 // CHECK-NEXT: RegionChanges
-// CHECK-NEXT: RegionChanges
 
 // Make sure there's no further output.
 // CHECK-NOT: Bind
Index: test/Analysis/lifetime-extension.cpp
===
--- test/Analysis/lifetime-extension.cpp
+++ test/Analysis/lifetime-extension.cpp
@@ -234,25 +234,24 @@
 } // end namespace maintain_original_object_address_on_move
 
 namespace maintain_address_of_copies {
-class C;
 
-struct AddressVector {
-  C *buf[10];
+template  struct AddressVector {
+  const T *buf[10];
   int len;
 
   AddressVector() : len(0) {}
 
-  void push(C *c) {
-buf[len] = c;
+  void push(const T *t) {
+buf[len] = t;
 ++len;
   }
 };
 
 class C {
-  AddressVector 
+  AddressVector 
 
 public:
-  C(AddressVector ) : v(v) { v.push(this); }
+  C(AddressVector ) : v(v) { v.push(this); }
   ~C() { v.push(this); }
 
 #ifdef MOVES
@@ -268,11 +267,11 @@
 #endif
   } // no-warning
 
-  static C make(AddressVector ) { return C(v); }
+  static C make(AddressVector ) { return C(v); }
 };
 
 void f1() {
-  AddressVector v;
+  AddressVector v;
   {
 C c = C(v);
   }
@@ -296,7 +295,7 @@
 }
 
 void f2() {
-  AddressVector v;
+  AddressVector v;
   {
 const C  = C::make(v);
   }
@@ -320,7 +319,7 @@
 }
 
 void f3() {
-  AddressVector v;
+  AddressVector v;
   {
 C & = C::make(v);
   }
@@ -343,12 +342,12 @@
 #endif
 }
 
-C doubleMake(AddressVector ) {
+C doubleMake(AddressVector ) {
   return C::make(v);
 }
 
 void f4() {
-  AddressVector v;
+  AddressVector v;
   {
 C c = doubleMake(v);
   }
@@ -382,4 +381,18 @@
   // expected-warning@-12{{UNKNOWN}}
 #endif
 }
+
+class NoDtor {
+  AddressVector 
+
+public:
+  NoDtor(AddressVector ) : v(v) { v.push(this); }
+};
+
+void f5() {
+  AddressVector v;
+  const NoDtor  = NoDtor(v);
+  clang_analyzer_eval(v.buf[0] == ); // expected-warning{{TRUE}}
+}
+
 } // end namespace maintain_address_of_copies
Index: lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
===
--- lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
+++ lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
@@ -216,12 +216,6 @@
   const CXXBindTemporaryExpr *BTE = TCC->getCXXBindTemporaryExpr();
   const MaterializeTemporaryExpr *MTE = TCC->getMaterializedTemporaryExpr();
 
-  if (!BTE) {
-// FIXME: Lifetime extension for temporaries without destructors
-// is not implemented yet.
-MTE = nullptr;
-  }
-
   if (MTE) {
 if (const ValueDecl *VD = MTE->getExtendingDecl()) {
   assert(MTE->getStorageDuration() != SD_FullExpression);
@@ -236,16 +230,22 @@
 }
   }
 
-  if (MTE && MTE->getStorageDuration() != SD_FullExpression) {
-// If the temporary is lifetime-extended, don't save the BTE,
-// because we don't need a temporary destructor, but an automatic
-// destructor.
-BTE = nullptr;
+  SVal V = UnknownVal();
+  if (MTE) {
+if (MTE->getStorageDuration() != SD_FullExpression) {
+  // If the temporary is lifetime-extended, don't save the BTE,
+  // because we don't need a temporary destructor, but an automatic
+  // destructor.
+  BTE = nullptr;
+
+  if (MTE->getStorageDuration() == SD_Static ||
+  MTE->getStorageDuration() == SD_Thread)
+V = loc::MemRegionVal(MRMgr.getCXXStaticTempObjectRegion(E));
+}
   }
 
-  // FIXME: Support temporaries lifetime-extended via static references.
-  // They'd need a getCXXStaticTempObjectRegion().
-  SVal V = loc::MemRegionVal(MRMgr.getCXXTempObjectRegion(E, LCtx));
+  if (V.isUnknown())
+V = loc::MemRegionVal(MRMgr.getCXXTempObjectRegion(E, LCtx));
 
   if (BTE)
 State = addObjectUnderConstruction(State, BTE, LCtx, V);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D47666: Refactored clang-fuzzer and added new (copy) files

2018-06-01 Thread Emmett Neyman via Phabricator via cfe-commits
emmettneyman updated this revision to Diff 149585.
emmettneyman added a comment.

- Took out a debug print statement


Repository:
  rC Clang

https://reviews.llvm.org/D47666

Files:
  tools/clang-fuzzer/CMakeLists.txt
  tools/clang-fuzzer/ExampleClangProtoFuzzer.cpp
  tools/clang-fuzzer/FuzzerInitialize.cpp
  tools/clang-fuzzer/FuzzerInitialize.h
  tools/clang-fuzzer/experimental/ExampleClangLoopProtoFuzzer.cpp
  tools/clang-fuzzer/experimental/cxx_loop_proto.proto
  tools/clang-fuzzer/proto-to-cxx/experimental/loop_proto_to_cxx.cpp
  tools/clang-fuzzer/proto-to-cxx/experimental/loop_proto_to_cxx.h
  tools/clang-fuzzer/proto-to-cxx/experimental/loop_proto_to_cxx_main.cpp

Index: tools/clang-fuzzer/proto-to-cxx/experimental/loop_proto_to_cxx_main.cpp
===
--- /dev/null
+++ tools/clang-fuzzer/proto-to-cxx/experimental/loop_proto_to_cxx_main.cpp
@@ -0,0 +1,34 @@
+//==-- proto_to_cxx_main.cpp - Driver for protobuf-C++ conversion --==//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+//
+// Implements a simple driver to print a C++ program from a protobuf.
+//
+//===--===//
+
+// This is a copy and will be updated later to introduce changes
+
+#include 
+#include 
+#include 
+#include 
+
+#include "loop_proto_to_cxx.h"
+
+int main(int argc, char **argv) {
+  for (int i = 1; i < argc; i++) {
+std::fstream in(argv[i]);
+std::string str((std::istreambuf_iterator(in)),
+std::istreambuf_iterator());
+std::cout << "// " << argv[i] << std::endl;
+std::cout << clang_fuzzer::ProtoToCxx(
+reinterpret_cast(str.data()), str.size());
+// std::cout << clang_fuzzer::ProtoStringToCxx(str);
+  }
+}
+
Index: tools/clang-fuzzer/proto-to-cxx/experimental/loop_proto_to_cxx.h
===
--- /dev/null
+++ tools/clang-fuzzer/proto-to-cxx/experimental/loop_proto_to_cxx.h
@@ -0,0 +1,24 @@
+//==-- proto_to_cxx.h - Protobuf-C++ conversion ==//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+//
+// Defines functions for converting between protobufs and C++.
+//
+//===--===//
+
+// This is a copy and will be updated later to introduce changes
+
+#include 
+#include 
+#include 
+
+namespace clang_fuzzer {
+class Function;
+std::string FunctionToString(const Function );
+std::string ProtoToCxx(const uint8_t *data, size_t size);
+}
Index: tools/clang-fuzzer/proto-to-cxx/experimental/loop_proto_to_cxx.cpp
===
--- /dev/null
+++ tools/clang-fuzzer/proto-to-cxx/experimental/loop_proto_to_cxx.cpp
@@ -0,0 +1,115 @@
+//==-- proto_to_cxx.cpp - Protobuf-C++ conversion --==//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+//
+// Implements functions for converting between protobufs and C++.
+//
+//===--===//
+
+// This is a copy and will be updated later to introduce changes
+
+#include "loop_proto_to_cxx.h"
+#include "cxx_loop_proto.pb.h"
+
+// The following is needed to convert protos in human-readable form
+#include 
+
+
+#include 
+#include 
+
+namespace clang_fuzzer {
+
+// Forward decls.
+std::ostream <<(std::ostream , const BinaryOp );
+std::ostream <<(std::ostream , const StatementSeq );
+
+// Proto to C++.
+std::ostream <<(std::ostream , const Const ) {
+  return os << "(" << x.val() << ")";
+}
+std::ostream <<(std::ostream , const VarRef ) {
+  return os << "a[" << (static_cast(x.varnum()) % 100) << "]";
+}
+std::ostream <<(std::ostream , const Lvalue ) {
+  return os << x.varref();
+}
+std::ostream <<(std::ostream , const Rvalue ) {
+if (x.has_varref()) return os << x.varref();
+if (x.has_cons())   return os << x.cons();
+if (x.has_binop())  return os << x.binop();
+return os << "1";
+}
+std::ostream <<(std::ostream , const BinaryOp ) {
+  os << "(" << x.left();
+  switch (x.op()) {
+case BinaryOp::PLUS: os << "+"; break;
+case BinaryOp::MINUS: os << "-"; break;
+case BinaryOp::MUL: os << "*"; break;
+case BinaryOp::DIV: os << "/"; break;
+case BinaryOp::MOD: os << "%"; 

[PATCH] D47666: Refactored clang-fuzzer and added new (copy) files

2018-06-01 Thread Emmett Neyman via Phabricator via cfe-commits
emmettneyman created this revision.
emmettneyman added reviewers: vitalybuka, kcc, morehouse.
Herald added subscribers: cfe-commits, mgorny.

Refactored LLVMFuzzerInitialize function into its own file.
Copied and renamed some files in preparation for new loop-proto-fuzzer.


Repository:
  rC Clang

https://reviews.llvm.org/D47666

Files:
  tools/clang-fuzzer/CMakeLists.txt
  tools/clang-fuzzer/ExampleClangProtoFuzzer.cpp
  tools/clang-fuzzer/FuzzerInitialize.cpp
  tools/clang-fuzzer/FuzzerInitialize.h
  tools/clang-fuzzer/experimental/ExampleClangLoopProtoFuzzer.cpp
  tools/clang-fuzzer/experimental/cxx_loop_proto.proto
  tools/clang-fuzzer/proto-to-cxx/experimental/loop_proto_to_cxx.cpp
  tools/clang-fuzzer/proto-to-cxx/experimental/loop_proto_to_cxx.h
  tools/clang-fuzzer/proto-to-cxx/experimental/loop_proto_to_cxx_main.cpp

Index: tools/clang-fuzzer/proto-to-cxx/experimental/loop_proto_to_cxx_main.cpp
===
--- /dev/null
+++ tools/clang-fuzzer/proto-to-cxx/experimental/loop_proto_to_cxx_main.cpp
@@ -0,0 +1,34 @@
+//==-- proto_to_cxx_main.cpp - Driver for protobuf-C++ conversion --==//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+//
+// Implements a simple driver to print a C++ program from a protobuf.
+//
+//===--===//
+
+// This is a copy and will be updated later to introduce changes
+
+#include 
+#include 
+#include 
+#include 
+
+#include "loop_proto_to_cxx.h"
+
+int main(int argc, char **argv) {
+  for (int i = 1; i < argc; i++) {
+std::fstream in(argv[i]);
+std::string str((std::istreambuf_iterator(in)),
+std::istreambuf_iterator());
+std::cout << "// " << argv[i] << std::endl;
+std::cout << clang_fuzzer::ProtoToCxx(
+reinterpret_cast(str.data()), str.size());
+// std::cout << clang_fuzzer::ProtoStringToCxx(str);
+  }
+}
+
Index: tools/clang-fuzzer/proto-to-cxx/experimental/loop_proto_to_cxx.h
===
--- /dev/null
+++ tools/clang-fuzzer/proto-to-cxx/experimental/loop_proto_to_cxx.h
@@ -0,0 +1,24 @@
+//==-- proto_to_cxx.h - Protobuf-C++ conversion ==//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+//
+// Defines functions for converting between protobufs and C++.
+//
+//===--===//
+
+// This is a copy and will be updated later to introduce changes
+
+#include 
+#include 
+#include 
+
+namespace clang_fuzzer {
+class Function;
+std::string FunctionToString(const Function );
+std::string ProtoToCxx(const uint8_t *data, size_t size);
+}
Index: tools/clang-fuzzer/proto-to-cxx/experimental/loop_proto_to_cxx.cpp
===
--- /dev/null
+++ tools/clang-fuzzer/proto-to-cxx/experimental/loop_proto_to_cxx.cpp
@@ -0,0 +1,115 @@
+//==-- proto_to_cxx.cpp - Protobuf-C++ conversion --==//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+//
+// Implements functions for converting between protobufs and C++.
+//
+//===--===//
+
+// This is a copy and will be updated later to introduce changes
+
+#include "loop_proto_to_cxx.h"
+#include "cxx_loop_proto.pb.h"
+
+// The following is needed to convert protos in human-readable form
+#include 
+
+
+#include 
+#include 
+
+namespace clang_fuzzer {
+
+// Forward decls.
+std::ostream <<(std::ostream , const BinaryOp );
+std::ostream <<(std::ostream , const StatementSeq );
+
+// Proto to C++.
+std::ostream <<(std::ostream , const Const ) {
+  return os << "(" << x.val() << ")";
+}
+std::ostream <<(std::ostream , const VarRef ) {
+  return os << "a[" << (static_cast(x.varnum()) % 100) << "]";
+}
+std::ostream <<(std::ostream , const Lvalue ) {
+  return os << x.varref();
+}
+std::ostream <<(std::ostream , const Rvalue ) {
+if (x.has_varref()) return os << x.varref();
+if (x.has_cons())   return os << x.cons();
+if (x.has_binop())  return os << x.binop();
+return os << "1";
+}
+std::ostream <<(std::ostream , const BinaryOp ) {
+  os << "(" << x.left();
+  switch (x.op()) {
+case BinaryOp::PLUS: os << "+"; break;
+case 

[PATCH] D45015: [Preprocessor] Allow libc++ to detect when aligned allocation is unavailable.

2018-06-01 Thread Eric Fiselier via Phabricator via cfe-commits
EricWF added a comment.

In https://reviews.llvm.org/D45015#1119286, @ahatanak wrote:

> In https://reviews.llvm.org/D45015#1105388, @rsmith wrote:
>
> > In https://reviews.llvm.org/D45015#1105372, @vsapsai wrote:
> >
> > > What when compiler has `__builtin_operator_new`, 
> > > `__builtin_operator_delete`? If I build libc++ tests with recent Clang 
> > > which has these builtins and run tests with libc++.dylib from old Darwin, 
> > > there are no linkage errors. Should we define `__cpp_aligned_allocation` 
> > > in this case?
> >
> >
> > I don't see why that should make any difference -- those builtins call the 
> > same functions that the new and delete operator call. Perhaps libc++ isn't 
> > calling the forms of those builtins that take an alignment argument yet?
>
>
> It looks like clang currently doesn't issue a warning when a call to 
> __builtin_operator_new or __builtin_operator_delete calls an aligned 
> allocation function that is not support by the OS version. I suppose we 
> should fix this?
>
>   // no warning issued when triple is "thumbv7-apple-ios5.0.0" even though 
> aligned allocation is unavailable.
>   void *p = __builtin_operator_new(100, std::align_val_t(32));


If we switch to no longer defining `__cpp_aligned_new` when it's unavailable 
that means libc++ shouldn't generate calls to an aligned allocation or 
deallocation function. Do we need the compiler to protect libc++ from itself 
here?


Repository:
  rC Clang

https://reviews.llvm.org/D45015



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


Re: r333802 - Add Features.def to module map

2018-06-01 Thread Aaron Ballman via cfe-commits
On Fri, Jun 1, 2018 at 6:52 PM, Eric Fiselier via cfe-commits
 wrote:
> Author: ericwf
> Date: Fri Jun  1 15:51:59 2018
> New Revision: 333802
>
> URL: http://llvm.org/viewvc/llvm-project?rev=333802=rev
> Log:
> Add Features.def to module map

Thank you! I didn't know I had missed that.

~Aaron

>
> Modified:
> cfe/trunk/include/clang/module.modulemap
>
> Modified: cfe/trunk/include/clang/module.modulemap
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/module.modulemap?rev=333802=333801=333802=diff
> ==
> --- cfe/trunk/include/clang/module.modulemap (original)
> +++ cfe/trunk/include/clang/module.modulemap Fri Jun  1 15:51:59 2018
> @@ -42,6 +42,7 @@ module Clang_Basic {
>textual header "Basic/BuiltinsX86_64.def"
>textual header "Basic/BuiltinsXCore.def"
>textual header "Basic/DiagnosticOptions.def"
> +  textual header "Basic/Features.def"
>textual header "Basic/LangOptions.def"
>textual header "Basic/OpenCLExtensions.def"
>textual header "Basic/OpenCLImageTypes.def"
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D45015: [Preprocessor] Allow libc++ to detect when aligned allocation is unavailable.

2018-06-01 Thread Eric Fiselier via Phabricator via cfe-commits
EricWF added a comment.

The new path forward sounds good to me. I'll work on implementing it.


Repository:
  rC Clang

https://reviews.llvm.org/D45015



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


[PATCH] D47393: [clang-format] Disable AlwaysBreakBeforeMultilineStrings in Google style for Objective-C 

2018-06-01 Thread Stephane Moore via Phabricator via cfe-commits
stephanemoore added a comment.

Polling the Google Objective-C community to see if anyone objects to this 
change. So far no concerns have been raised.


Repository:
  rC Clang

https://reviews.llvm.org/D47393



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


[PATCH] D45015: [Preprocessor] Allow libc++ to detect when aligned allocation is unavailable.

2018-06-01 Thread Akira Hatanaka via Phabricator via cfe-commits
ahatanak added a comment.

I think clang should error out or warn when aligned operator or builtin 
operator new/delete functions are used when they are not available (r306722 
should have handled them).

I'm also not sure not defining `__cpp_aligned_new` is sufficient. My 
understanding is that if `__cpp_aligned_new` is not defined, libc++ will define 
`_LIBCPP_HAS_NO_ALIGNED_ALLOCATION`, which will cause the aligned new/delete 
functions declared in  to be removed. That is fine if the new/delete 
function that is used in a program is one of the function implicitly declared 
by the compiler (e.g., 'void operator delete  ( void*, std::align_val_t)'), but 
if it isn't one of those functions (e.g., 'void operator delete (void *, 
std::align_val_t, const std::nothrow_t&)'), clang will produce diagnostics that 
are not very informative to the user (error: no matching function for call to 
'operator delete') instead of the one added in r306722 (aligned allocation 
function of type is only available on ...).

For example:

  #include 

  void foo1(void *p, std::align_val_t a, std::nothrow_t t) {
operator delete(p, a, t);
  }


Repository:
  rC Clang

https://reviews.llvm.org/D45015



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


r333802 - Add Features.def to module map

2018-06-01 Thread Eric Fiselier via cfe-commits
Author: ericwf
Date: Fri Jun  1 15:51:59 2018
New Revision: 333802

URL: http://llvm.org/viewvc/llvm-project?rev=333802=rev
Log:
Add Features.def to module map

Modified:
cfe/trunk/include/clang/module.modulemap

Modified: cfe/trunk/include/clang/module.modulemap
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/module.modulemap?rev=333802=333801=333802=diff
==
--- cfe/trunk/include/clang/module.modulemap (original)
+++ cfe/trunk/include/clang/module.modulemap Fri Jun  1 15:51:59 2018
@@ -42,6 +42,7 @@ module Clang_Basic {
   textual header "Basic/BuiltinsX86_64.def"
   textual header "Basic/BuiltinsXCore.def"
   textual header "Basic/DiagnosticOptions.def"
+  textual header "Basic/Features.def"
   textual header "Basic/LangOptions.def"
   textual header "Basic/OpenCLExtensions.def"
   textual header "Basic/OpenCLImageTypes.def"


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


[PATCH] D47607: [libcxx] Almost fix some UB in and

2018-06-01 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added a comment.

In https://reviews.llvm.org/D47607#1118464, @EricWF wrote:

> One other concern I have is if there will be any performance impact to using 
> `launder` all the time, but better safe than sorry.


In the short-to-medium term, I think we can tackle this by adding an attribute:

  // ...
  struct pair {
T first;
[[clang::not_actually_const]] U second;
  };

... to directly express that the `second` field of a non-const `pair` is never 
a const subobject, even if `U` is a `const`-qualified type. I think we'll need 
this once we head down the path of `constexpr` containers, otherwise 
`node_handle`s are not going to work in constant expression evaluation.

Then we can remove the `launder` calls for implementations that support the 
attribute.


https://reviews.llvm.org/D47607



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


[PATCH] D47665: Refactored clang-fuzzer in preparation for adding new loop-proto-fuzzer

2018-06-01 Thread Vitaly Buka via Phabricator via cfe-commits
vitalybuka added inline comments.



Comment at: tools/clang-fuzzer/CMakeLists.txt:17
   ExampleClangProtoFuzzer.cpp
+  FuzzerInitialize.cpp
   )

this file is missing



Comment at: tools/clang-fuzzer/ExampleClangProtoFuzzer.cpp:29
 
+/*
 static std::vector CLArgs;

don't keep dead code



Comment at: tools/clang-fuzzer/proto-to-cxx/proto_to_cxx_main.cpp:26
 std::cout << "// " << argv[i] << std::endl;
-std::cout << clang_fuzzer::ProtoToCxx(
-reinterpret_cast(str.data()), str.size());
+//std::cout << clang_fuzzer::ProtoToCxx(
+//reinterpret_cast(str.data()), str.size());

Probably some debug changes?


Repository:
  rC Clang

https://reviews.llvm.org/D47665



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


[PATCH] D47665: Refactored clang-fuzzer in preparation for adding new loop-proto-fuzzer

2018-06-01 Thread Emmett Neyman via Phabricator via cfe-commits
emmettneyman created this revision.
emmettneyman added reviewers: vitalybuka, kcc, morehouse.
Herald added subscribers: cfe-commits, mgorny.

Refactored LLVMFuzzerInitialize function into its own file.

  Copied and renamed files in preparation for new loop-proto-fuzzer.


Repository:
  rC Clang

https://reviews.llvm.org/D47665

Files:
  tools/clang-fuzzer/CMakeLists.txt
  tools/clang-fuzzer/ExampleClangProtoFuzzer.cpp
  tools/clang-fuzzer/proto-to-cxx/proto_to_cxx.cpp
  tools/clang-fuzzer/proto-to-cxx/proto_to_cxx.h
  tools/clang-fuzzer/proto-to-cxx/proto_to_cxx_main.cpp

Index: tools/clang-fuzzer/proto-to-cxx/proto_to_cxx_main.cpp
===
--- tools/clang-fuzzer/proto-to-cxx/proto_to_cxx_main.cpp
+++ tools/clang-fuzzer/proto-to-cxx/proto_to_cxx_main.cpp
@@ -23,8 +23,9 @@
 std::string str((std::istreambuf_iterator(in)),
 std::istreambuf_iterator());
 std::cout << "// " << argv[i] << std::endl;
-std::cout << clang_fuzzer::ProtoToCxx(
-reinterpret_cast(str.data()), str.size());
+//std::cout << clang_fuzzer::ProtoToCxx(
+//reinterpret_cast(str.data()), str.size());
+std::cout << clang_fuzzer::ProtoStringToCxx(str);
   }
 }
 
Index: tools/clang-fuzzer/proto-to-cxx/proto_to_cxx.h
===
--- tools/clang-fuzzer/proto-to-cxx/proto_to_cxx.h
+++ tools/clang-fuzzer/proto-to-cxx/proto_to_cxx.h
@@ -19,4 +19,5 @@
 class Function;
 std::string FunctionToString(const Function );
 std::string ProtoToCxx(const uint8_t *data, size_t size);
+std::string ProtoStringToCxx(const std::string& data);
 }
Index: tools/clang-fuzzer/proto-to-cxx/proto_to_cxx.cpp
===
--- tools/clang-fuzzer/proto-to-cxx/proto_to_cxx.cpp
+++ tools/clang-fuzzer/proto-to-cxx/proto_to_cxx.cpp
@@ -14,6 +14,10 @@
 #include "proto_to_cxx.h"
 #include "cxx_proto.pb.h"
 
+// The following is needed to convert protos in human-readable form
+#include 
+
+
 #include 
 #include 
 
@@ -95,7 +99,13 @@
 std::string ProtoToCxx(const uint8_t *data, size_t size) {
   Function message;
   if (!message.ParsePartialFromArray(data, size))
-return "#error invalid proto\n";
+return "#error invalid proto, may not be binary encoded\n";
+  return FunctionToString(message);
+}
+std::string ProtoStringToCxx(const std::string& data) {
+  Function message;
+  if (!google::protobuf::TextFormat::ParseFromString(data, ))
+return "#error invalid proto, may not be string encoded\n";
   return FunctionToString(message);
 }
 
Index: tools/clang-fuzzer/ExampleClangProtoFuzzer.cpp
===
--- tools/clang-fuzzer/ExampleClangProtoFuzzer.cpp
+++ tools/clang-fuzzer/ExampleClangProtoFuzzer.cpp
@@ -18,12 +18,15 @@
 #include "handle-cxx/handle_cxx.h"
 #include "proto-to-cxx/proto_to_cxx.h"
 
+#include "FuzzerInitialize.h"
+
 #include "src/libfuzzer/libfuzzer_macro.h"
 
 #include 
 
 using namespace clang_fuzzer;
 
+/*
 static std::vector CLArgs;
 
 extern "C" int LLVMFuzzerInitialize(int *argc, char ***argv) {
@@ -37,8 +40,9 @@
   }
   return 0;
 }
+*/
 
-DEFINE_BINARY_PROTO_FUZZER(const Function& input) {
+DEFINE_PROTO_FUZZER(const Function& input) {
   auto S = FunctionToString(input);
   HandleCXX(S, CLArgs);
 }
Index: tools/clang-fuzzer/CMakeLists.txt
===
--- tools/clang-fuzzer/CMakeLists.txt
+++ tools/clang-fuzzer/CMakeLists.txt
@@ -14,6 +14,7 @@
   ClangFuzzer.cpp
   DummyClangFuzzer.cpp
   ExampleClangProtoFuzzer.cpp
+  FuzzerInitialize.cpp
   )
 
 if(CLANG_ENABLE_PROTO_FUZZER)
@@ -44,6 +45,7 @@
   add_clang_executable(clang-proto-fuzzer
 ${DUMMY_MAIN}
 ExampleClangProtoFuzzer.cpp
+FuzzerInitialize.cpp
 )
 
   target_link_libraries(clang-proto-fuzzer
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D47616: [CFG] [analyzer] Explain copy elision through construction contexts.

2018-06-01 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added inline comments.



Comment at: lib/Analysis/CFG.cpp:1320
+auto *MTE = cast(Child);
+findConstructionContexts(ConstructionContextLayer::create(
+ cfg->getBumpVectorContext(), MTE, Layer),

NoQ wrote:
> george.karpenkov wrote:
> > There are three repeated calls to `findConstructionContexts`, with only the 
> > second argument changing. Perhaps a helper lambda closure would help?
> I'll look into this later for the whole function.
Aha, we are changing the whole function anyway, ok then.


https://reviews.llvm.org/D47616



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


[PATCH] D47616: [CFG] [analyzer] Explain copy elision through construction contexts.

2018-06-01 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ updated this revision to Diff 149571.
NoQ added a comment.

Actually let's use lambdas as well.


https://reviews.llvm.org/D47616

Files:
  include/clang/Analysis/ConstructionContext.h
  lib/Analysis/CFG.cpp
  lib/Analysis/ConstructionContext.cpp
  lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
  test/Analysis/cfg-rich-constructors.cpp
  test/Analysis/temp-obj-dtors-cfg-output.cpp

Index: test/Analysis/temp-obj-dtors-cfg-output.cpp
===
--- test/Analysis/temp-obj-dtors-cfg-output.cpp
+++ test/Analysis/temp-obj-dtors-cfg-output.cpp
@@ -235,7 +235,7 @@
 // CHECK: Succs (1): B1
 // CHECK:   [B1]
 // WARNINGS: 1: A() (CXXConstructExpr, class A)
-// ANALYZER: 1: A() (CXXConstructExpr, [B1.2], [B1.4], class A)
+// ANALYZER: 1: A() (CXXConstructExpr, [B1.2], [B1.4], [B1.5], class A)
 // CHECK: 2: [B1.1] (BindTemporary)
 // CHECK: 3: [B1.2] (ImplicitCastExpr, NoOp, const class A)
 // CHECK: 4: [B1.3]
@@ -295,7 +295,7 @@
 // CHECK: Succs (1): B1
 // CHECK:   [B1]
 // WARNINGS: 1: A() (CXXConstructExpr, class A)
-// ANALYZER: 1: A() (CXXConstructExpr, [B1.2], [B1.4], class A)
+// ANALYZER: 1: A() (CXXConstructExpr, [B1.2], [B1.4], [B1.5], class A)
 // CHECK: 2: [B1.1] (BindTemporary)
 // CHECK: 3: [B1.2] (ImplicitCastExpr, NoOp, const class A)
 // CHECK: 4: [B1.3]
@@ -550,12 +550,12 @@
 // CHECK: Succs (2): B6 B5
 // CHECK:   [B8]
 // WARNINGS: 1: A() (CXXConstructExpr, class A)
-// ANALYZER: 1: A() (CXXConstructExpr, [B8.2], [B8.4], class A)
+// ANALYZER: 1: A() (CXXConstructExpr, [B8.2], [B8.4], [B8.5], class A)
 // CHECK: 2: [B8.1] (BindTemporary)
 // CHECK: 3: [B8.2] (ImplicitCastExpr, NoOp, const class A)
 // CHECK: 4: [B8.3]
 // WARNINGS: 5: [B8.4] (CXXConstructExpr, class A)
-// ANALYZER: 5: [B8.4] (CXXConstructExpr, [B8.6], [B7.3], class A)
+// ANALYZER: 5: [B8.4] (CXXConstructExpr, [B8.6], [B7.3], [B7.4], class A)
 // CHECK: 6: [B8.5] (BindTemporary)
 // CHECK: Preds (1): B10
 // CHECK: Succs (1): B7
@@ -570,13 +570,13 @@
 // CHECK: 7: [B9.6] (ImplicitCastExpr, NoOp, const class A)
 // CHECK: 8: [B9.7]
 // WARNINGS: 9: [B9.8] (CXXConstructExpr, class A)
-// ANALYZER: 9: [B9.8] (CXXConstructExpr, [B9.10], [B9.13], class A)
+// ANALYZER: 9: [B9.8] (CXXConstructExpr, [B9.10], [B9.13], [B9.14], class A)
 // CHECK:10: [B9.9] (BindTemporary)
 // CHECK:11: A([B9.10]) (CXXFunctionalCastExpr, ConstructorConversion, class A)
 // CHECK:12: [B9.11] (ImplicitCastExpr, NoOp, const class A)
 // CHECK:13: [B9.12]
 // WARNINGS:14: [B9.13] (CXXConstructExpr, class A)
-// ANALYZER:14: [B9.13] (CXXConstructExpr, [B9.15], [B7.3], class A)
+// ANALYZER:14: [B9.13] (CXXConstructExpr, [B9.15], [B7.3], [B7.4], class A)
 // CHECK:15: [B9.14] (BindTemporary)
 // CHECK: Preds (1): B10
 // CHECK: Succs (1): B7
@@ -680,7 +680,7 @@
 // CHECK: Succs (1): B0
 // CHECK:   [B4]
 // WARNINGS: 1: C() (CXXConstructExpr, struct C)
-// ANALYZER: 1: C() (CXXConstructExpr, [B4.2], [B4.4], struct C)
+// ANALYZER: 1: C() (CXXConstructExpr, [B4.2], [B4.4], [B4.5], struct C)
 // CHECK: 2: [B4.1] (BindTemporary)
 // CHECK: 3: [B4.2] (ImplicitCastExpr, NoOp, const struct C)
 // CHECK: 4: [B4.3]
@@ -733,7 +733,7 @@
 // CHECK: Succs (1): B0
 // CHECK:   [B3]
 // CXX98-WARNINGS: 1: D() (CXXConstructExpr, struct D)
-// CXX98-ANALYZER: 1: D() (CXXConstructExpr, [B3.3], struct D)
+// CXX98-ANALYZER: 1: D() (CXXConstructExpr, [B3.3], [B3.4], struct D)
 // CXX98: 2: [B3.1] (ImplicitCastExpr, NoOp, const struct D)
 // CXX98: 3: [B3.2]
 // CXX98-WARNINGS: 4: [B3.3] (CXXConstructExpr, struct D)
@@ -745,7 +745,7 @@
 // CXX98: 9: [B3.8] (ImplicitCastExpr, UserDefinedConversion, _Bool)
 // CXX98: T: if [B3.9]
 // CXX11-WARNINGS: 1: D() (CXXConstructExpr, struct D)
-// CXX11-ANALYZER: 1: D() (CXXConstructExpr, [B3.2], struct D)
+// CXX11-ANALYZER: 1: D() (CXXConstructExpr, [B3.2], [B3.3], struct D)
 // CXX11: 2: [B3.1]
 // CXX11-WARNINGS: 3: [B3.2] (CXXConstructExpr, struct D)
 // CXX11-ANALYZER: 3: [B3.2] (CXXConstructExpr, [B3.4], struct D)
@@ -789,7 +789,7 @@
 // CHECK: Succs (2): B3 B2
 // CHECK:   [B5]
 // WARNINGS: 1: A() (CXXConstructExpr, class A)
-// ANALYZER: 1: A() (CXXConstructExpr, [B5.2], [B5.4], class A)
+// ANALYZER: 1: A() (CXXConstructExpr, [B5.2], [B5.4], [B5.5], class A)
 // CHECK: 2: [B5.1] (BindTemporary)
 // CHECK: 3: [B5.2] (ImplicitCastExpr, NoOp, const class A)
 // CHECK: 4: [B5.3]
@@ -809,7 +809,7 @@
 // CHECK: 7: [B6.6] (ImplicitCastExpr, NoOp, const class A)
 // CHECK: 8: [B6.7]
 // WARNINGS: 9: [B6.8] (CXXConstructExpr, class A)
-// ANALYZER: 9: [B6.8] (CXXConstructExpr, [B6.10], [B6.13], class A)
+// ANALYZER: 9: [B6.8] (CXXConstructExpr, [B6.10], [B6.13], [B6.14], class A)
 // 

[PATCH] D47616: [CFG] [analyzer] Explain copy elision through construction contexts.

2018-06-01 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ updated this revision to Diff 149568.
NoQ marked 2 inline comments as done.
NoQ added a comment.

Actually let's do a separate context kind. The difference in semantics they 
represent is so drastically different that i think it's worth it.


https://reviews.llvm.org/D47616

Files:
  include/clang/Analysis/ConstructionContext.h
  lib/Analysis/CFG.cpp
  lib/Analysis/ConstructionContext.cpp
  lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
  test/Analysis/cfg-rich-constructors.cpp
  test/Analysis/temp-obj-dtors-cfg-output.cpp

Index: test/Analysis/temp-obj-dtors-cfg-output.cpp
===
--- test/Analysis/temp-obj-dtors-cfg-output.cpp
+++ test/Analysis/temp-obj-dtors-cfg-output.cpp
@@ -235,7 +235,7 @@
 // CHECK: Succs (1): B1
 // CHECK:   [B1]
 // WARNINGS: 1: A() (CXXConstructExpr, class A)
-// ANALYZER: 1: A() (CXXConstructExpr, [B1.2], [B1.4], class A)
+// ANALYZER: 1: A() (CXXConstructExpr, [B1.2], [B1.4], [B1.5], class A)
 // CHECK: 2: [B1.1] (BindTemporary)
 // CHECK: 3: [B1.2] (ImplicitCastExpr, NoOp, const class A)
 // CHECK: 4: [B1.3]
@@ -295,7 +295,7 @@
 // CHECK: Succs (1): B1
 // CHECK:   [B1]
 // WARNINGS: 1: A() (CXXConstructExpr, class A)
-// ANALYZER: 1: A() (CXXConstructExpr, [B1.2], [B1.4], class A)
+// ANALYZER: 1: A() (CXXConstructExpr, [B1.2], [B1.4], [B1.5], class A)
 // CHECK: 2: [B1.1] (BindTemporary)
 // CHECK: 3: [B1.2] (ImplicitCastExpr, NoOp, const class A)
 // CHECK: 4: [B1.3]
@@ -550,12 +550,12 @@
 // CHECK: Succs (2): B6 B5
 // CHECK:   [B8]
 // WARNINGS: 1: A() (CXXConstructExpr, class A)
-// ANALYZER: 1: A() (CXXConstructExpr, [B8.2], [B8.4], class A)
+// ANALYZER: 1: A() (CXXConstructExpr, [B8.2], [B8.4], [B8.5], class A)
 // CHECK: 2: [B8.1] (BindTemporary)
 // CHECK: 3: [B8.2] (ImplicitCastExpr, NoOp, const class A)
 // CHECK: 4: [B8.3]
 // WARNINGS: 5: [B8.4] (CXXConstructExpr, class A)
-// ANALYZER: 5: [B8.4] (CXXConstructExpr, [B8.6], [B7.3], class A)
+// ANALYZER: 5: [B8.4] (CXXConstructExpr, [B8.6], [B7.3], [B7.4], class A)
 // CHECK: 6: [B8.5] (BindTemporary)
 // CHECK: Preds (1): B10
 // CHECK: Succs (1): B7
@@ -570,13 +570,13 @@
 // CHECK: 7: [B9.6] (ImplicitCastExpr, NoOp, const class A)
 // CHECK: 8: [B9.7]
 // WARNINGS: 9: [B9.8] (CXXConstructExpr, class A)
-// ANALYZER: 9: [B9.8] (CXXConstructExpr, [B9.10], [B9.13], class A)
+// ANALYZER: 9: [B9.8] (CXXConstructExpr, [B9.10], [B9.13], [B9.14], class A)
 // CHECK:10: [B9.9] (BindTemporary)
 // CHECK:11: A([B9.10]) (CXXFunctionalCastExpr, ConstructorConversion, class A)
 // CHECK:12: [B9.11] (ImplicitCastExpr, NoOp, const class A)
 // CHECK:13: [B9.12]
 // WARNINGS:14: [B9.13] (CXXConstructExpr, class A)
-// ANALYZER:14: [B9.13] (CXXConstructExpr, [B9.15], [B7.3], class A)
+// ANALYZER:14: [B9.13] (CXXConstructExpr, [B9.15], [B7.3], [B7.4], class A)
 // CHECK:15: [B9.14] (BindTemporary)
 // CHECK: Preds (1): B10
 // CHECK: Succs (1): B7
@@ -680,7 +680,7 @@
 // CHECK: Succs (1): B0
 // CHECK:   [B4]
 // WARNINGS: 1: C() (CXXConstructExpr, struct C)
-// ANALYZER: 1: C() (CXXConstructExpr, [B4.2], [B4.4], struct C)
+// ANALYZER: 1: C() (CXXConstructExpr, [B4.2], [B4.4], [B4.5], struct C)
 // CHECK: 2: [B4.1] (BindTemporary)
 // CHECK: 3: [B4.2] (ImplicitCastExpr, NoOp, const struct C)
 // CHECK: 4: [B4.3]
@@ -733,7 +733,7 @@
 // CHECK: Succs (1): B0
 // CHECK:   [B3]
 // CXX98-WARNINGS: 1: D() (CXXConstructExpr, struct D)
-// CXX98-ANALYZER: 1: D() (CXXConstructExpr, [B3.3], struct D)
+// CXX98-ANALYZER: 1: D() (CXXConstructExpr, [B3.3], [B3.4], struct D)
 // CXX98: 2: [B3.1] (ImplicitCastExpr, NoOp, const struct D)
 // CXX98: 3: [B3.2]
 // CXX98-WARNINGS: 4: [B3.3] (CXXConstructExpr, struct D)
@@ -745,7 +745,7 @@
 // CXX98: 9: [B3.8] (ImplicitCastExpr, UserDefinedConversion, _Bool)
 // CXX98: T: if [B3.9]
 // CXX11-WARNINGS: 1: D() (CXXConstructExpr, struct D)
-// CXX11-ANALYZER: 1: D() (CXXConstructExpr, [B3.2], struct D)
+// CXX11-ANALYZER: 1: D() (CXXConstructExpr, [B3.2], [B3.3], struct D)
 // CXX11: 2: [B3.1]
 // CXX11-WARNINGS: 3: [B3.2] (CXXConstructExpr, struct D)
 // CXX11-ANALYZER: 3: [B3.2] (CXXConstructExpr, [B3.4], struct D)
@@ -789,7 +789,7 @@
 // CHECK: Succs (2): B3 B2
 // CHECK:   [B5]
 // WARNINGS: 1: A() (CXXConstructExpr, class A)
-// ANALYZER: 1: A() (CXXConstructExpr, [B5.2], [B5.4], class A)
+// ANALYZER: 1: A() (CXXConstructExpr, [B5.2], [B5.4], [B5.5], class A)
 // CHECK: 2: [B5.1] (BindTemporary)
 // CHECK: 3: [B5.2] (ImplicitCastExpr, NoOp, const class A)
 // CHECK: 4: [B5.3]
@@ -809,7 +809,7 @@
 // CHECK: 7: [B6.6] (ImplicitCastExpr, NoOp, const class A)
 // CHECK: 8: [B6.7]
 // WARNINGS: 9: [B6.8] (CXXConstructExpr, class A)
-// ANALYZER:

[PATCH] D47616: [CFG] [analyzer] Explain copy elision through construction contexts.

2018-06-01 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added inline comments.



Comment at: lib/Analysis/CFG.cpp:1320
+auto *MTE = cast(Child);
+findConstructionContexts(ConstructionContextLayer::create(
+ cfg->getBumpVectorContext(), MTE, Layer),

george.karpenkov wrote:
> There are three repeated calls to `findConstructionContexts`, with only the 
> second argument changing. Perhaps a helper lambda closure would help?
I'll look into this later for the whole function.



Comment at: lib/Analysis/CFG.cpp:4959
+  const Stmt *S1 = nullptr, *S2 = nullptr, *S3 = nullptr;
+  const ConstructionContext *CC1 = nullptr;
   switch (CC->getKind()) {

george.karpenkov wrote:
> begs for a comment differentiating CC from CC1
This variable was in fact unused.


https://reviews.llvm.org/D47616



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


[PATCH] D47658: [analyzer] Re-enable lifetime extension for temporaries with destructors and bring back static temporaries.

2018-06-01 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ updated this revision to Diff 149567.
NoQ added a comment.

Fix comments in the callback test. The test itself is pretty pointless now, 
because the behavior that it was supposed to test was a workaround for lack of 
lifetime extension support.


https://reviews.llvm.org/D47658

Files:
  lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
  test/Analysis/lifetime-extension.cpp
  test/Analysis/temporaries-callback-order.cpp

Index: test/Analysis/temporaries-callback-order.cpp
===
--- test/Analysis/temporaries-callback-order.cpp
+++ test/Analysis/temporaries-callback-order.cpp
@@ -8,11 +8,7 @@
 };
 
 void testTemporaries() {
-  // This triggers RegionChanges twice:
-  // - Once for zero-initialization of the structure.
-  // - Once for creating a temporary region and copying the structure there.
-  // FIXME: This code shouldn't really produce the extra temporary, however
-  // that's how we behave for now.
+  // This triggers RegionChanges once for zero-initialization of the structure.
   Sub().m();
 }
 
@@ -29,7 +25,6 @@
 
 // testTemporaries():
 // CHECK-NEXT: RegionChanges
-// CHECK-NEXT: RegionChanges
 
 // Make sure there's no further output.
 // CHECK-NOT: Bind
Index: test/Analysis/lifetime-extension.cpp
===
--- test/Analysis/lifetime-extension.cpp
+++ test/Analysis/lifetime-extension.cpp
@@ -234,25 +234,24 @@
 } // end namespace maintain_original_object_address_on_move
 
 namespace maintain_address_of_copies {
-class C;
 
-struct AddressVector {
-  C *buf[10];
+template  struct AddressVector {
+  const T *buf[10];
   int len;
 
   AddressVector() : len(0) {}
 
-  void push(C *c) {
-buf[len] = c;
+  void push(const T *t) {
+buf[len] = t;
 ++len;
   }
 };
 
 class C {
-  AddressVector 
+  AddressVector 
 
 public:
-  C(AddressVector ) : v(v) { v.push(this); }
+  C(AddressVector ) : v(v) { v.push(this); }
   ~C() { v.push(this); }
 
 #ifdef MOVES
@@ -268,11 +267,11 @@
 #endif
   } // no-warning
 
-  static C make(AddressVector ) { return C(v); }
+  static C make(AddressVector ) { return C(v); }
 };
 
 void f1() {
-  AddressVector v;
+  AddressVector v;
   {
 C c = C(v);
   }
@@ -296,7 +295,7 @@
 }
 
 void f2() {
-  AddressVector v;
+  AddressVector v;
   {
 const C  = C::make(v);
   }
@@ -320,7 +319,7 @@
 }
 
 void f3() {
-  AddressVector v;
+  AddressVector v;
   {
 C & = C::make(v);
   }
@@ -343,12 +342,12 @@
 #endif
 }
 
-C doubleMake(AddressVector ) {
+C doubleMake(AddressVector ) {
   return C::make(v);
 }
 
 void f4() {
-  AddressVector v;
+  AddressVector v;
   {
 C c = doubleMake(v);
   }
@@ -382,4 +381,18 @@
   // expected-warning@-12{{UNKNOWN}}
 #endif
 }
+
+class NoDtor {
+  AddressVector 
+
+public:
+  NoDtor(AddressVector ) : v(v) { v.push(this); }
+};
+
+void f5() {
+  AddressVector v;
+  const NoDtor  = NoDtor(v);
+  clang_analyzer_eval(v.buf[0] == ); // expected-warning{{TRUE}}
+}
+
 } // end namespace maintain_address_of_copies
Index: lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
===
--- lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
+++ lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
@@ -214,12 +214,6 @@
   const CXXBindTemporaryExpr *BTE = TCC->getCXXBindTemporaryExpr();
   const MaterializeTemporaryExpr *MTE = TCC->getMaterializedTemporaryExpr();
 
-  if (!BTE) {
-// FIXME: Lifetime extension for temporaries without destructors
-// is not implemented yet.
-MTE = nullptr;
-  }
-
   if (MTE) {
 if (const ValueDecl *VD = MTE->getExtendingDecl()) {
   assert(MTE->getStorageDuration() != SD_FullExpression);
@@ -234,16 +228,25 @@
 }
   }
 
-  if (MTE && MTE->getStorageDuration() != SD_FullExpression) {
-// If the temporary is lifetime-extended, don't save the BTE,
-// because we don't need a temporary destructor, but an automatic
-// destructor.
-BTE = nullptr;
+  SVal V = UnknownVal();
+  if (MTE) {
+if (MTE->getStorageDuration() != SD_FullExpression) {
+  // If the temporary is lifetime-extended, don't save the BTE,
+  // because we don't need a temporary destructor, but an automatic
+  // destructor.
+  BTE = nullptr;
+
+  if (MTE->getStorageDuration() == SD_Static ||
+  MTE->getStorageDuration() == SD_Thread)
+V = loc::MemRegionVal(MRMgr.getCXXStaticTempObjectRegion(E));
+}
   }
 
+  if (V.isUnknown())
+V = loc::MemRegionVal(MRMgr.getCXXTempObjectRegion(E, LCtx));
+
   // FIXME: Support temporaries lifetime-extended via static references.
   // They'd need a getCXXStaticTempObjectRegion().
-  SVal V = loc::MemRegionVal(MRMgr.getCXXTempObjectRegion(E, LCtx));
 
   if (BTE)
 State = addObjectUnderConstruction(State, BTE, LCtx, V);

[PATCH] D47616: [CFG] [analyzer] Explain copy elision through construction contexts.

2018-06-01 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added a comment.

Whoops wrong patch.


https://reviews.llvm.org/D47616



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


[PATCH] D47616: [CFG] [analyzer] Explain copy elision through construction contexts.

2018-06-01 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ updated this revision to Diff 149566.
NoQ added a comment.

Fix comments in the callback test. The test itself is pretty pointless now, 
because the behavior that it was supposed to test was a workaround for lack of 
lifetime extension support.


https://reviews.llvm.org/D47616

Files:
  lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
  test/Analysis/lifetime-extension.cpp
  test/Analysis/temporaries-callback-order.cpp

Index: test/Analysis/temporaries-callback-order.cpp
===
--- test/Analysis/temporaries-callback-order.cpp
+++ test/Analysis/temporaries-callback-order.cpp
@@ -8,11 +8,7 @@
 };
 
 void testTemporaries() {
-  // This triggers RegionChanges twice:
-  // - Once for zero-initialization of the structure.
-  // - Once for creating a temporary region and copying the structure there.
-  // FIXME: This code shouldn't really produce the extra temporary, however
-  // that's how we behave for now.
+  // This triggers RegionChanges once for zero-initialization of the structure.
   Sub().m();
 }
 
@@ -29,7 +25,6 @@
 
 // testTemporaries():
 // CHECK-NEXT: RegionChanges
-// CHECK-NEXT: RegionChanges
 
 // Make sure there's no further output.
 // CHECK-NOT: Bind
Index: test/Analysis/lifetime-extension.cpp
===
--- test/Analysis/lifetime-extension.cpp
+++ test/Analysis/lifetime-extension.cpp
@@ -234,25 +234,24 @@
 } // end namespace maintain_original_object_address_on_move
 
 namespace maintain_address_of_copies {
-class C;
 
-struct AddressVector {
-  C *buf[10];
+template  struct AddressVector {
+  const T *buf[10];
   int len;
 
   AddressVector() : len(0) {}
 
-  void push(C *c) {
-buf[len] = c;
+  void push(const T *t) {
+buf[len] = t;
 ++len;
   }
 };
 
 class C {
-  AddressVector 
+  AddressVector 
 
 public:
-  C(AddressVector ) : v(v) { v.push(this); }
+  C(AddressVector ) : v(v) { v.push(this); }
   ~C() { v.push(this); }
 
 #ifdef MOVES
@@ -268,11 +267,11 @@
 #endif
   } // no-warning
 
-  static C make(AddressVector ) { return C(v); }
+  static C make(AddressVector ) { return C(v); }
 };
 
 void f1() {
-  AddressVector v;
+  AddressVector v;
   {
 C c = C(v);
   }
@@ -296,7 +295,7 @@
 }
 
 void f2() {
-  AddressVector v;
+  AddressVector v;
   {
 const C  = C::make(v);
   }
@@ -320,7 +319,7 @@
 }
 
 void f3() {
-  AddressVector v;
+  AddressVector v;
   {
 C & = C::make(v);
   }
@@ -343,12 +342,12 @@
 #endif
 }
 
-C doubleMake(AddressVector ) {
+C doubleMake(AddressVector ) {
   return C::make(v);
 }
 
 void f4() {
-  AddressVector v;
+  AddressVector v;
   {
 C c = doubleMake(v);
   }
@@ -382,4 +381,18 @@
   // expected-warning@-12{{UNKNOWN}}
 #endif
 }
+
+class NoDtor {
+  AddressVector 
+
+public:
+  NoDtor(AddressVector ) : v(v) { v.push(this); }
+};
+
+void f5() {
+  AddressVector v;
+  const NoDtor  = NoDtor(v);
+  clang_analyzer_eval(v.buf[0] == ); // expected-warning{{TRUE}}
+}
+
 } // end namespace maintain_address_of_copies
Index: lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
===
--- lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
+++ lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
@@ -214,12 +214,6 @@
   const CXXBindTemporaryExpr *BTE = TCC->getCXXBindTemporaryExpr();
   const MaterializeTemporaryExpr *MTE = TCC->getMaterializedTemporaryExpr();
 
-  if (!BTE) {
-// FIXME: Lifetime extension for temporaries without destructors
-// is not implemented yet.
-MTE = nullptr;
-  }
-
   if (MTE) {
 if (const ValueDecl *VD = MTE->getExtendingDecl()) {
   assert(MTE->getStorageDuration() != SD_FullExpression);
@@ -234,16 +228,25 @@
 }
   }
 
-  if (MTE && MTE->getStorageDuration() != SD_FullExpression) {
-// If the temporary is lifetime-extended, don't save the BTE,
-// because we don't need a temporary destructor, but an automatic
-// destructor.
-BTE = nullptr;
+  SVal V = UnknownVal();
+  if (MTE) {
+if (MTE->getStorageDuration() != SD_FullExpression) {
+  // If the temporary is lifetime-extended, don't save the BTE,
+  // because we don't need a temporary destructor, but an automatic
+  // destructor.
+  BTE = nullptr;
+
+  if (MTE->getStorageDuration() == SD_Static ||
+  MTE->getStorageDuration() == SD_Thread)
+V = loc::MemRegionVal(MRMgr.getCXXStaticTempObjectRegion(E));
+}
   }
 
+  if (V.isUnknown())
+V = loc::MemRegionVal(MRMgr.getCXXTempObjectRegion(E, LCtx));
+
   // FIXME: Support temporaries lifetime-extended via static references.
   // They'd need a getCXXStaticTempObjectRegion().
-  SVal V = loc::MemRegionVal(MRMgr.getCXXTempObjectRegion(E, LCtx));
 
   if (BTE)
 State = addObjectUnderConstruction(State, BTE, LCtx, V);

[PATCH] D47135: [analyzer] A checker for dangling internal buffer pointers in C++

2018-06-01 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 accepted this revision.
xbolva00 added a comment.

Looks fine, awesome feature!


https://reviews.llvm.org/D47135



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


[PATCH] D46042: Cap vector alignment at 16 for all Darwin platforms

2018-06-01 Thread John McCall via Phabricator via cfe-commits
rjmccall closed this revision.
rjmccall added a comment.

Landed as r333791.


Repository:
  rC Clang

https://reviews.llvm.org/D46042



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


[PATCH] D34796: upporting -f(no)-reorder-functions flag, clang side change

2018-06-01 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 added a comment.

Ping


https://reviews.llvm.org/D34796



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


[PATCH] D47658: [analyzer] Re-enable lifetime extension for temporaries with destructors and bring back static temporaries.

2018-06-01 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ created this revision.
NoQ added reviewers: dcoughlin, xazax.hun, a.sidorin, george.karpenkov, szepet, 
rnkovacs.
Herald added subscribers: cfe-commits, baloghadamsoftware.

I don't remember why lifetime extension for temporaries without destructors was 
disabled. It's clearly less important and is a different syntax to support, so 
i guess i simply didn't want to pretend that it works before i tested it, but 
it generally seems to be pretty much the same.

Added a simple test to test this.

One thing i noticed when i re-enabled such lifetime extension was that we had 
tests for "static temporaries" (i.e. temporaries lifetime-extended by static or 
global variables) which started to fail, so i had to fix them as well, which 
wasn't hard.


Repository:
  rC Clang

https://reviews.llvm.org/D47658

Files:
  lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
  test/Analysis/lifetime-extension.cpp
  test/Analysis/temporaries-callback-order.cpp

Index: test/Analysis/temporaries-callback-order.cpp
===
--- test/Analysis/temporaries-callback-order.cpp
+++ test/Analysis/temporaries-callback-order.cpp
@@ -11,8 +11,6 @@
   // This triggers RegionChanges twice:
   // - Once for zero-initialization of the structure.
   // - Once for creating a temporary region and copying the structure there.
-  // FIXME: This code shouldn't really produce the extra temporary, however
-  // that's how we behave for now.
   Sub().m();
 }
 
@@ -29,7 +27,6 @@
 
 // testTemporaries():
 // CHECK-NEXT: RegionChanges
-// CHECK-NEXT: RegionChanges
 
 // Make sure there's no further output.
 // CHECK-NOT: Bind
Index: test/Analysis/lifetime-extension.cpp
===
--- test/Analysis/lifetime-extension.cpp
+++ test/Analysis/lifetime-extension.cpp
@@ -234,25 +234,24 @@
 } // end namespace maintain_original_object_address_on_move
 
 namespace maintain_address_of_copies {
-class C;
 
-struct AddressVector {
-  C *buf[10];
+template  struct AddressVector {
+  const T *buf[10];
   int len;
 
   AddressVector() : len(0) {}
 
-  void push(C *c) {
-buf[len] = c;
+  void push(const T *t) {
+buf[len] = t;
 ++len;
   }
 };
 
 class C {
-  AddressVector 
+  AddressVector 
 
 public:
-  C(AddressVector ) : v(v) { v.push(this); }
+  C(AddressVector ) : v(v) { v.push(this); }
   ~C() { v.push(this); }
 
 #ifdef MOVES
@@ -268,11 +267,11 @@
 #endif
   } // no-warning
 
-  static C make(AddressVector ) { return C(v); }
+  static C make(AddressVector ) { return C(v); }
 };
 
 void f1() {
-  AddressVector v;
+  AddressVector v;
   {
 C c = C(v);
   }
@@ -296,7 +295,7 @@
 }
 
 void f2() {
-  AddressVector v;
+  AddressVector v;
   {
 const C  = C::make(v);
   }
@@ -320,7 +319,7 @@
 }
 
 void f3() {
-  AddressVector v;
+  AddressVector v;
   {
 C & = C::make(v);
   }
@@ -343,12 +342,12 @@
 #endif
 }
 
-C doubleMake(AddressVector ) {
+C doubleMake(AddressVector ) {
   return C::make(v);
 }
 
 void f4() {
-  AddressVector v;
+  AddressVector v;
   {
 C c = doubleMake(v);
   }
@@ -382,4 +381,18 @@
   // expected-warning@-12{{UNKNOWN}}
 #endif
 }
+
+class NoDtor {
+  AddressVector 
+
+public:
+  NoDtor(AddressVector ) : v(v) { v.push(this); }
+};
+
+void f5() {
+  AddressVector v;
+  const NoDtor  = NoDtor(v);
+  clang_analyzer_eval(v.buf[0] == ); // expected-warning{{TRUE}}
+}
+
 } // end namespace maintain_address_of_copies
Index: lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
===
--- lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
+++ lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
@@ -214,12 +214,6 @@
   const CXXBindTemporaryExpr *BTE = TCC->getCXXBindTemporaryExpr();
   const MaterializeTemporaryExpr *MTE = TCC->getMaterializedTemporaryExpr();
 
-  if (!BTE) {
-// FIXME: Lifetime extension for temporaries without destructors
-// is not implemented yet.
-MTE = nullptr;
-  }
-
   if (MTE) {
 if (const ValueDecl *VD = MTE->getExtendingDecl()) {
   assert(MTE->getStorageDuration() != SD_FullExpression);
@@ -234,16 +228,25 @@
 }
   }
 
-  if (MTE && MTE->getStorageDuration() != SD_FullExpression) {
-// If the temporary is lifetime-extended, don't save the BTE,
-// because we don't need a temporary destructor, but an automatic
-// destructor.
-BTE = nullptr;
+  SVal V = UnknownVal();
+  if (MTE) {
+if (MTE->getStorageDuration() != SD_FullExpression) {
+  // If the temporary is lifetime-extended, don't save the BTE,
+  // because we don't need a temporary destructor, but an automatic
+  // destructor.
+  BTE = nullptr;
+
+  if (MTE->getStorageDuration() == SD_Static ||
+  MTE->getStorageDuration() == SD_Thread)
+V = loc::MemRegionVal(MRMgr.getCXXStaticTempObjectRegion(E));
+}
   }
 
+  

r333791 - Cap "voluntary" vector alignment at 16 for all Darwin platforms.

2018-06-01 Thread John McCall via cfe-commits
Author: rjmccall
Date: Fri Jun  1 14:34:26 2018
New Revision: 333791

URL: http://llvm.org/viewvc/llvm-project?rev=333791=rev
Log:
Cap "voluntary" vector alignment at 16 for all Darwin platforms.

This fixes two major problems:
- We were not capping vector alignment as desired on 32-bit ARM.
- We were using different alignments based on the AVX settings on
  Intel, so we did not have a consistent ABI.

This is an ABI break, but we think we can get away with it because
vectors tend to be used mostly in inline code (which is why not having
a consistent ABI has not proven disastrous on Intel).

Intel's AVX types are specified as having 32-byte / 64-byte alignment,
so align them explicitly instead of relying on the base ABI rule.
Note that this sort of attribute is stripped from template arguments
in template substitution, so there's a possibility that code templated
over vectors will produce inadequately-aligned objects.  The right
long-term solution for this is for alignment attributes to be
interpreted as true qualifiers and thus preserved in the canonical type.

Modified:
cfe/trunk/lib/Basic/Targets/OSTargets.h
cfe/trunk/lib/Basic/Targets/X86.h
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/lib/Headers/avx512fintrin.h
cfe/trunk/lib/Headers/avxintrin.h
cfe/trunk/test/CodeGen/arm-swiftcall.c
cfe/trunk/test/CodeGen/vector-alignment.c
cfe/trunk/test/CodeGenCXX/align-avx-complete-objects.cpp

Modified: cfe/trunk/lib/Basic/Targets/OSTargets.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/OSTargets.h?rev=333791=333790=333791=diff
==
--- cfe/trunk/lib/Basic/Targets/OSTargets.h (original)
+++ cfe/trunk/lib/Basic/Targets/OSTargets.h Fri Jun  1 14:34:26 2018
@@ -113,6 +113,9 @@ public:
 }
 
 this->MCountName = "\01mcount";
+
+// Cap vector alignment at 16 bytes for all Darwin platforms.
+this->MaxVectorAlign = 128;
   }
 
   std::string isValidSectionSpecifier(StringRef SR) const override {

Modified: cfe/trunk/lib/Basic/Targets/X86.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/X86.h?rev=333791=333790=333791=diff
==
--- cfe/trunk/lib/Basic/Targets/X86.h (original)
+++ cfe/trunk/lib/Basic/Targets/X86.h Fri Jun  1 14:34:26 2018
@@ -421,7 +421,6 @@ public:
 LongDoubleWidth = 128;
 LongDoubleAlign = 128;
 SuitableAlign = 128;
-MaxVectorAlign = 256;
 // The watchOS simulator uses the builtin bool type for Objective-C.
 llvm::Triple T = llvm::Triple(Triple);
 if (T.isWatchOS())
@@ -437,9 +436,6 @@ public:
 if (!DarwinTargetInfo::handleTargetFeatures(Features,
   Diags))
   return false;
-// We now know the features we have: we can decide how to align vectors.
-MaxVectorAlign =
-hasFeature("avx512f") ? 512 : hasFeature("avx") ? 256 : 128;
 return true;
   }
 };
@@ -802,9 +798,6 @@ public:
 if (!DarwinTargetInfo::handleTargetFeatures(Features,
   Diags))
   return false;
-// We now know the features we have: we can decide how to align vectors.
-MaxVectorAlign =
-hasFeature("avx512f") ? 512 : hasFeature("avx") ? 256 : 128;
 return true;
   }
 };

Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=333791=333790=333791=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Fri Jun  1 14:34:26 2018
@@ -8918,18 +8918,20 @@ Value *CodeGenFunction::EmitX86BuiltinEx
   case X86::BI__builtin_ia32_movdqa64store128_mask:
   case X86::BI__builtin_ia32_storeaps128_mask:
   case X86::BI__builtin_ia32_storeapd128_mask:
+return EmitX86MaskedStore(*this, Ops, 16);
+
   case X86::BI__builtin_ia32_movdqa32store256_mask:
   case X86::BI__builtin_ia32_movdqa64store256_mask:
   case X86::BI__builtin_ia32_storeaps256_mask:
   case X86::BI__builtin_ia32_storeapd256_mask:
+return EmitX86MaskedStore(*this, Ops, 32);
+
   case X86::BI__builtin_ia32_movdqa32store512_mask:
   case X86::BI__builtin_ia32_movdqa64store512_mask:
   case X86::BI__builtin_ia32_storeaps512_mask:
-  case X86::BI__builtin_ia32_storeapd512_mask: {
-unsigned Align =
-  getContext().getTypeAlignInChars(E->getArg(1)->getType()).getQuantity();
-return EmitX86MaskedStore(*this, Ops, Align);
-  }
+  case X86::BI__builtin_ia32_storeapd512_mask:
+return EmitX86MaskedStore(*this, Ops, 64);
+
   case X86::BI__builtin_ia32_loadups128_mask:
   case X86::BI__builtin_ia32_loadups256_mask:
   case X86::BI__builtin_ia32_loadups512_mask:
@@ -8950,26 +8952,25 @@ Value *CodeGenFunction::EmitX86BuiltinEx
   case 

[PATCH] D46013: [ARM] Conform to AAPCS when passing overaligned composites as arguments

2018-06-01 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

In https://reviews.llvm.org/D46013#1119513, @efriedma wrote:

> > I'm not sure it's appropriate to impose this as an overhead on all targets.
>
> You mean the overhead of increasing the size of TypeInfo?  That's fair.


Yeah.  It seems like something that could be pretty easily computed 
retroactively in the places that need it.  It might be okay to have a 
ASTContext-level cache for it; that cache would just stay empty in practice for 
most compiler invocations.


https://reviews.llvm.org/D46013



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


[PATCH] D46013: [ARM] Conform to AAPCS when passing overaligned composites as arguments

2018-06-01 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added a comment.

> I'm not sure it's appropriate to impose this as an overhead on all targets.

You mean the overhead of increasing the size of TypeInfo?  That's fair.


https://reviews.llvm.org/D46013



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


[PATCH] D46013: [ARM] Conform to AAPCS when passing overaligned composites as arguments

2018-06-01 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

I'm not sure it's appropriate to impose this as an overhead on all targets.


https://reviews.llvm.org/D46013



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


[PATCH] D35110: [Analyzer] Constraint Manager Negates Difference

2018-06-01 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added a comment.

In https://reviews.llvm.org/D35110#1117401, @baloghadamsoftware wrote:

> Sorry, Artem, but it does not work this way. Even if the symbolic expressions 
> are constrained to `[-MAX/4..MAX/4]`, after rearrangement the difference 
> still uses the whole range, thus `m>n` becomes `m-n>0`, where in the false 
> branch the range for `m-n` is `[MIN..0]`. Then if we check `n>=m` the range 
> set is reversed to `[MIN..MIN]U[0..MAX]` which results `UNKNOWN` for `n-m`. 
> It does not solve any of our problems and there is no remedy on the checker's 
> side.


Which expressions are constrained? Why does the difference use the whole range? 
Is it something that could have been fixed by the "enforce that separately" 
part in my old comment:

> iterator-related symbols are all planned to be within range [-2²⁹, -2²⁹], 
> right? So if we subtract one such symbol from another, it's going to be in 
> range [-2³⁰, 2³⁰]. Can we currently infer that? Or maybe we should make the 
> iterator checker to enforce that separately?

?


https://reviews.llvm.org/D35110



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


[PATCH] D46013: [ARM] Conform to AAPCS when passing overaligned composites as arguments

2018-06-01 Thread Momchil Velikov via Phabricator via cfe-commits
chill marked 2 inline comments as done.
chill added a comment.

In https://reviews.llvm.org/D46013#1118014, @efriedma wrote:

> I'm not sure Apple will want to mess with their ABI like this... adding some 
> reviewers.


Fair enough, I'd rather not touch it :)


https://reviews.llvm.org/D46013



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


[PATCH] D47617: [Analyzer] Fix Z3ConstraintManager crash (PR37646)

2018-06-01 Thread Dominic Chen via Phabricator via cfe-commits
ddcc added a comment.

In https://reviews.llvm.org/D47617#1119257, @george.karpenkov wrote:

> LGTM with a nit on a test name.


Same.

In https://reviews.llvm.org/D47617#1119268, @NoQ wrote:

> Also does this test need to be z3-specific? We would also not like to crash 
> here without z3.


I had the same though originally about the `REQUIRES` line. Since this code 
path is very specific to Z3ConstraintManager, it didn't seem useful to run the 
test on normal buildbots. But I have no preference either way.


Repository:
  rC Clang

https://reviews.llvm.org/D47617



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


[PATCH] D47627: [ASTContext] Make getAddrSpaceQualType replace address spaces.

2018-06-01 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

Is there a specific reason to change the implementation instead of changing the 
documentation?


Repository:
  rC Clang

https://reviews.llvm.org/D47627



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


[PATCH] D46013: [ARM] Conform to AAPCS when passing overaligned composites as arguments

2018-06-01 Thread Momchil Velikov via Phabricator via cfe-commits
chill updated this revision to Diff 149536.
chill added a comment.

Update:

- fix only APCS, don't touch other ABIs
- misc other


https://reviews.llvm.org/D46013

Files:
  include/clang/AST/ASTContext.h
  include/clang/AST/RecordLayout.h
  lib/AST/ASTContext.cpp
  lib/AST/RecordLayout.cpp
  lib/AST/RecordLayoutBuilder.cpp
  lib/CodeGen/TargetInfo.cpp
  test/CodeGen/aapcs-align.cc
  test/CodeGen/aapcs64-align.cc
  test/CodeGen/arm-arguments.c

Index: test/CodeGen/arm-arguments.c
===
--- test/CodeGen/arm-arguments.c
+++ test/CodeGen/arm-arguments.c
@@ -211,10 +211,13 @@
 // APCS-GNU: call void @llvm.memcpy.p0i8.p0i8.i32(i8* align {{[0-9]+}} %[[b]], i8* align {{[0-9]+}} %[[c]]
 // APCS-GNU: %[[d:.*]] = bitcast %struct.s35* %[[a]] to <4 x float>*
 // APCS-GNU: load <4 x float>, <4 x float>* %[[d]], align 16
-// AAPCS-LABEL: define arm_aapcscc <4 x float> @f35(i32 %i, %struct.s35* byval align 8, %struct.s35* byval align 8)
-// AAPCS: %[[a:.*]] = alloca %struct.s35, align 16
-// AAPCS: %[[b:.*]] = bitcast %struct.s35* %[[a]] to i8*
-// AAPCS: %[[c:.*]] = bitcast %struct.s35* %0 to i8*
-// AAPCS: call void @llvm.memcpy.p0i8.p0i8.i32(i8* align 16 %[[b]], i8* align 8 %[[c]]
-// AAPCS: %[[d:.*]] = bitcast %struct.s35* %[[a]] to <4 x float>*
-// AAPCS: load <4 x float>, <4 x float>* %[[d]], align 16
+
+// AAPCS-LABEL: define arm_aapcscc <4 x float> @f35(i32 %i, %struct.s35* byval align 4 %s1, %struct.s35* byval align 4 %s2)
+// AAPCS: %[[a_addr:.*]] = alloca <4 x float>, align 16
+// AAPCS: %[[b_addr:.*]] = alloca <4 x float>, align 16
+// AAPCS: %[[p1:.*]] = bitcast %struct.s35* %s1 to <4 x float>*
+// AAPCS: %[[a:.*]] = load <4 x float>, <4 x float>* %[[p1]], align 4
+// AAPCS: %[[p2:.*]] = bitcast %struct.s35* %s2 to <4 x float>*
+// AAPCS: %[[b:.*]] = load <4 x float>, <4 x float>* %[[p2]], align 4
+// AAPCS: store <4 x float> %[[a]], <4 x float>* %[[a_addr]], align 16
+// AAPCS: store <4 x float> %[[b]], <4 x float>* %[[b_addr]], align 16
Index: test/CodeGen/aapcs64-align.cc
===
--- /dev/null
+++ test/CodeGen/aapcs64-align.cc
@@ -0,0 +1,103 @@
+// REQUIRES: arm-registered-target
+// RUN: %clang_cc1 -triple aarch64-none-none-eabi \
+// RUN:   -O2 \
+// RUN:   -emit-llvm -o - %s | FileCheck %s
+
+extern "C" {
+
+// Base case, nothing interesting.
+struct S {
+  long x, y;
+};
+
+void f0(long, S);
+void f0m(long, long, long, long, long, S);
+void g0() {
+  S s = {6, 7};
+  f0(1, s);
+  f0m(1, 2, 3, 4, 5, s);
+}
+// CHECK: define void @g0
+// CHECK: call void @f0(i64 1, [2 x i64] [i64 6, i64 7]
+// CHECK: call void @f0m{{.*}}[2 x i64] [i64 6, i64 7]
+// CHECK: declare void @f0(i64, [2 x i64])
+// CHECK: declare void @f0m(i64, i64, i64, i64, i64, [2 x i64])
+
+// Aligned struct, passed according to its natural alignment.
+struct __attribute__((aligned(16))) S16 {
+  long x, y;
+} s16;
+
+void f1(long, S16);
+void f1m(long, long, long, long, long, S16);
+void g1() {
+  S16 s = {6, 7};
+  f1(1, s);
+  f1m(1, 2, 3, 4, 5, s);
+}
+// CHECK: define void @g1
+// CHECK: call void @f1{{.*}}[2 x i64] [i64 6, i64 7]
+// CHECK: call void @f1m{{.*}}[2 x i64] [i64 6, i64 7]
+// CHECK: declare void @f1(i64, [2 x i64])
+// CHECK: declare void @f1m(i64, i64, i64, i64, i64, [2 x i64])
+
+// Increased natural alignment.
+struct SF16 {
+  long x __attribute__((aligned(16)));
+  long y;
+};
+
+void f3(long, SF16);
+void f3m(long, long, long, long, long, SF16);
+void g3() {
+  SF16 s = {6, 7};
+  f3(1, s);
+  f3m(1, 2, 3, 4, 5, s);
+}
+// CHECK: define void @g3
+// CHECK: call void @f3(i64 1, i128 129127208515966861318)
+// CHECK: call void @f3m(i64 1, i64 2, i64 3, i64 4, i64 5, i128 129127208515966861318)
+// CHECK: declare void @f3(i64, i128)
+// CHECK: declare void @f3m(i64, i64, i64, i64, i64, i128)
+
+
+// Packed structure.
+struct  __attribute__((packed)) P {
+  int x;
+  long u;
+};
+
+void f4(int, P);
+void f4m(int, int, int, int, int, P);
+void g4() {
+  P s = {6, 7};
+  f4(1, s);
+  f4m(1, 2, 3, 4, 5, s);
+}
+// CHECK: define void @g4()
+// CHECK: call void @f4(i32 1, [2 x i64] [i64 30064771078, i64 0])
+// CHECK: void @f4m(i32 1, i32 2, i32 3, i32 4, i32 5, [2 x i64] [i64 30064771078, i64 0])
+// CHECK: declare void @f4(i32, [2 x i64])
+// CHECK: declare void @f4m(i32, i32, i32, i32, i32, [2 x i64])
+
+
+// Packed structure, overaligned, same as above.
+struct  __attribute__((packed, aligned(16))) P16 {
+  int x;
+  long y;
+};
+
+void f5(int, P16);
+void f5m(int, int, int, int, int, P16);
+  void g5() {
+P16 s = {6, 7};
+f5(1, s);
+f5m(1, 2, 3, 4, 5, s);
+}
+// CHECK: define void @g5()
+// CHECK: call void @f5(i32 1, [2 x i64] [i64 30064771078, i64 0])
+// CHECK: void @f5m(i32 1, i32 2, i32 3, i32 4, i32 5, [2 x i64] [i64 30064771078, i64 0])
+// CHECK: declare void @f5(i32, [2 x i64])
+// CHECK: declare void @f5m(i32, i32, i32, i32, i32, [2 x i64])
+
+}
Index: 

[PATCH] D47394: [OpenMP][Clang][NVPTX] Replace bundling with partial linking for the OpenMP NVPTX device offloading toolchain

2018-06-01 Thread Gheorghe-Teodor Bercea via Phabricator via cfe-commits
gtbercea added a comment.

In https://reviews.llvm.org/D47394#1119056, @Hahnfeld wrote:

> Hmm, maybe the scope is much larger: I just tried linking an executable that 
> references a `declare target` function in a shared library. My assumption was 
> that this already works, given that `libomptarget`'s registration functions 
> can be called multiple times. Am I doing something wrong?


I believe this is a limitation coming from the Cuda toolchain. Not even nvcc 
supports this case: 
https://stackoverflow.com/questions/35897002/cuda-nvcc-building-chain-of-libraries


Repository:
  rC Clang

https://reviews.llvm.org/D47394



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


[PATCH] D46911: [Fixed Point Arithmetic] Addition of the remaining fixed point types and their saturated equivalents

2018-06-01 Thread Leonard Chan via Phabricator via cfe-commits
leonardchan updated this revision to Diff 149533.
leonardchan marked an inline comment as done.

Repository:
  rC Clang

https://reviews.llvm.org/D46911

Files:
  include/clang/AST/ASTContext.h
  include/clang/AST/BuiltinTypes.def
  include/clang/AST/Type.h
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/Specifiers.h
  include/clang/Basic/TargetInfo.h
  include/clang/Basic/TokenKinds.def
  include/clang/Sema/DeclSpec.h
  include/clang/Serialization/ASTBitCodes.h
  lib/AST/ASTContext.cpp
  lib/AST/ExprConstant.cpp
  lib/AST/ItaniumMangle.cpp
  lib/AST/MicrosoftMangle.cpp
  lib/AST/NSAPI.cpp
  lib/AST/Type.cpp
  lib/AST/TypeLoc.cpp
  lib/Analysis/PrintfFormatString.cpp
  lib/Basic/TargetInfo.cpp
  lib/CodeGen/CGDebugInfo.cpp
  lib/CodeGen/CodeGenTypes.cpp
  lib/CodeGen/ItaniumCXXABI.cpp
  lib/Index/USRGeneration.cpp
  lib/Parse/ParseDecl.cpp
  lib/Sema/DeclSpec.cpp
  lib/Sema/SemaTemplateVariadic.cpp
  lib/Sema/SemaType.cpp
  lib/Serialization/ASTCommon.cpp
  lib/Serialization/ASTReader.cpp
  test/Frontend/fixed_point.c
  test/Frontend/fixed_point_bit_widths.c
  test/Frontend/fixed_point_errors.c
  test/Frontend/fixed_point_errors.cpp

Index: test/Frontend/fixed_point_errors.cpp
===
--- test/Frontend/fixed_point_errors.cpp
+++ test/Frontend/fixed_point_errors.cpp
@@ -1,5 +1,9 @@
+// RUN: %clang_cc1 -x c++ %s -verify
 // RUN: %clang_cc1 -x c++ -ffixed-point %s -verify
 
 // Name namgling is not provided for fixed point types in c++
 
 _Accum accum;   // expected-error{{unknown type name '_Accum'}}
+_Fract fract;   // expected-error{{unknown type name '_Fract'}}
+_Sat _Accum sat_accum;  // expected-error{{unknown type name '_Sat'}}
+// expected-error@-1{{expected ';' after top level declarator}}
Index: test/Frontend/fixed_point_errors.c
===
--- test/Frontend/fixed_point_errors.c
+++ test/Frontend/fixed_point_errors.c
@@ -5,6 +5,14 @@
 
 long long _Accum longlong_accum;  // expected-error{{'long long _Accum' is invalid}}
 unsigned long long _Accum u_longlong_accum;   // expected-error{{'long long _Accum' is invalid}}
+long long _Fract longlong_fract;  // expected-error{{'long long _Fract' is invalid}}
+unsigned long long _Fract u_longlong_fract;   // expected-error{{'long long _Fract' is invalid}}
+
+_Sat long long _Accum sat_longlong_accum; // expected-error{{'long long _Accum' is invalid}}
+_Sat unsigned long long _Accum sat_u_longlong_accum;  // expected-error{{'long long _Accum' is invalid}}
+_Sat long long _Fract sat_longlong_fract; // expected-error{{'long long _Fract' is invalid}}
+_Sat unsigned long long _Fract sat_u_longlong_fract;  // expected-error{{'long long _Fract' is invalid}}
+
 
 /* Although _Complex types work with floating point numbers, the extension
  * provides no info for complex fixed point types. */
@@ -19,9 +27,67 @@
 _Complex _Accum cmplx_s_accum;  // expected-error{{'_Complex _Accum' is invalid}}
 _Complex long _Accum cmplx_s_long_accum;// expected-error{{'_Complex _Accum' is invalid}}
 
+_Complex signed short _Fract cmplx_s_short_fract;   // expected-error{{'_Complex _Fract' is invalid}}
+_Complex signed _Fract cmplx_s_fract;   // expected-error{{'_Complex _Fract' is invalid}}
+_Complex signed long _Fract cmplx_s_long_fract; // expected-error{{'_Complex _Fract' is invalid}}
+_Complex unsigned short _Fract cmplx_u_short_fract; // expected-error{{'_Complex _Fract' is invalid}}
+_Complex unsigned _Fract cmplx_u_fract; // expected-error{{'_Complex _Fract' is invalid}}
+_Complex unsigned long _Fract cmplx_u_long_fract;   // expected-error{{'_Complex _Fract' is invalid}}
+_Complex short _Fract cmplx_s_short_fract;  // expected-error{{'_Complex _Fract' is invalid}}
+_Complex _Fract cmplx_s_fract;  // expected-error{{'_Complex _Fract' is invalid}}
+_Complex long _Fract cmplx_s_long_fract;// expected-error{{'_Complex _Fract' is invalid}}
+
+_Complex _Sat signed short _Accum cmplx_sat_s_short_accum;   // expected-error{{'_Complex _Accum' is invalid}}
+_Complex _Sat signed _Accum cmplx_sat_s_accum;   // expected-error{{'_Complex _Accum' is invalid}}
+_Complex _Sat signed long _Accum cmplx_sat_s_long_accum; // expected-error{{'_Complex _Accum' is invalid}}
+_Complex _Sat unsigned short _Accum cmplx_sat_u_short_accum; // expected-error{{'_Complex _Accum' is invalid}}
+_Complex _Sat unsigned _Accum cmplx_sat_u_accum; // expected-error{{'_Complex _Accum' is invalid}}
+_Complex _Sat unsigned long _Accum cmplx_sat_u_long_accum;   // expected-error{{'_Complex _Accum' is invalid}}
+_Complex _Sat short _Accum cmplx_sat_s_short_accum;  // expected-error{{'_Complex _Accum' is 

[PATCH] D44954: [clangd] Add "member" symbols to the index

2018-06-01 Thread Marc-Andre Laperle via Phabricator via cfe-commits
malaperle updated this revision to Diff 149532.
malaperle marked 4 inline comments as done.
malaperle added a comment.

Address comments.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D44954

Files:
  clangd/CodeComplete.cpp
  clangd/CodeComplete.h
  clangd/index/Index.h
  clangd/index/MemIndex.cpp
  clangd/index/SymbolCollector.cpp
  clangd/index/SymbolCollector.h
  clangd/index/SymbolYAML.cpp
  unittests/clangd/CodeCompleteTests.cpp
  unittests/clangd/FileIndexTests.cpp
  unittests/clangd/FindSymbolsTests.cpp
  unittests/clangd/SymbolCollectorTests.cpp

Index: unittests/clangd/SymbolCollectorTests.cpp
===
--- unittests/clangd/SymbolCollectorTests.cpp
+++ unittests/clangd/SymbolCollectorTests.cpp
@@ -67,6 +67,9 @@
   Pos.end.character);
 }
 MATCHER_P(Refs, R, "") { return int(arg.References) == R; }
+MATCHER_P(ForCodeCompletion, IsIndexedForCodeCompletion, "") {
+  return arg.IsIndexedForCodeCompletion == IsIndexedForCodeCompletion;
+}
 
 namespace clang {
 namespace clangd {
@@ -132,9 +135,13 @@
 CollectorOpts, PragmaHandler.get());
 
 std::vector Args = {
-"symbol_collector", "-fsyntax-only", "-xc++", "-std=c++11",
-"-include", TestHeaderName,  TestFileName};
+"symbol_collector", "-fsyntax-only", "-xc++",
+"-std=c++11",   "-include",  TestHeaderName};
 Args.insert(Args.end(), ExtraArgs.begin(), ExtraArgs.end());
+// This allows to override the "-xc++" with something else, i.e.
+// -xobjective-c++.
+Args.push_back(TestFileName);
+
 tooling::ToolInvocation Invocation(
 Args,
 Factory->create(), Files.get(),
@@ -163,8 +170,20 @@
 TEST_F(SymbolCollectorTest, CollectSymbols) {
   const std::string Header = R"(
 class Foo {
+  Foo() {}
+  Foo(int a) {}
   void f();
+  friend void f1();
+  friend class Friend;
+  Foo& operator=(const Foo&);
+  ~Foo();
+  class Nested {
+  void f();
+  };
+};
+class Friend {
 };
+
 void f1();
 inline void f2() {}
 static const int KInt = 2;
@@ -200,23 +219,78 @@
   runSymbolCollector(Header, /*Main=*/"");
   EXPECT_THAT(Symbols,
   UnorderedElementsAreArray(
-  {QName("Foo"), QName("f1"), QName("f2"), QName("KInt"),
-   QName("kStr"), QName("foo"), QName("foo::bar"),
-   QName("foo::int32"), QName("foo::int32_t"), QName("foo::v1"),
-   QName("foo::bar::v2"), QName("foo::baz")}));
+  {AllOf(QName("Foo"), ForCodeCompletion(true)),
+   AllOf(QName("Foo::Foo"), ForCodeCompletion(false)),
+   AllOf(QName("Foo::Foo"), ForCodeCompletion(false)),
+   AllOf(QName("Foo::f"), ForCodeCompletion(false)),
+   AllOf(QName("Foo::~Foo"), ForCodeCompletion(false)),
+   AllOf(QName("Foo::operator="), ForCodeCompletion(false)),
+   AllOf(QName("Foo::Nested"), ForCodeCompletion(false)),
+   AllOf(QName("Foo::Nested::f"), ForCodeCompletion(false)),
+
+   AllOf(QName("Friend"), ForCodeCompletion(true)),
+   AllOf(QName("f1"), ForCodeCompletion(true)),
+   AllOf(QName("f2"), ForCodeCompletion(true)),
+   AllOf(QName("KInt"), ForCodeCompletion(true)),
+   AllOf(QName("kStr"), ForCodeCompletion(true)),
+   AllOf(QName("foo"), ForCodeCompletion(true)),
+   AllOf(QName("foo::bar"), ForCodeCompletion(true)),
+   AllOf(QName("foo::int32"), ForCodeCompletion(true)),
+   AllOf(QName("foo::int32_t"), ForCodeCompletion(true)),
+   AllOf(QName("foo::v1"), ForCodeCompletion(true)),
+   AllOf(QName("foo::bar::v2"), ForCodeCompletion(true)),
+   AllOf(QName("foo::baz"), ForCodeCompletion(true))}));
 }
 
 TEST_F(SymbolCollectorTest, Template) {
   Annotations Header(R"(
 // Template is indexed, specialization and instantiation is not.
-template  struct [[Tmpl]] {T x = 0;};
+template  struct [[Tmpl]] {T $xdecl[[x]] = 0;};
 template <> struct Tmpl {};
 extern template struct Tmpl;
 template struct Tmpl;
   )");
   runSymbolCollector(Header.code(), /*Main=*/"");
-  EXPECT_THAT(Symbols, UnorderedElementsAreArray({AllOf(
-   QName("Tmpl"), DeclRange(Header.range()))}));
+  EXPECT_THAT(Symbols,
+  UnorderedElementsAreArray(
+  {AllOf(QName("Tmpl"), DeclRange(Header.range())),
+   AllOf(QName("Tmpl::x"), DeclRange(Header.range("xdecl")))}));
+}
+
+TEST_F(SymbolCollectorTest, ObjCSymbols) {
+  const std::string Header = R"(
+@interface Person
+- (void)someMethodName:(void*)name1 lastName:(void*)lName;
+@end
+
+@implementation Person
+- 

[PATCH] D44954: [clangd] Add "member" symbols to the index

2018-06-01 Thread Marc-Andre Laperle via Phabricator via cfe-commits
malaperle added inline comments.



Comment at: unittests/clangd/CodeCompleteTests.cpp:741
 
+TEST(CompletionTest, Enums) {
+  EXPECT_THAT(completions(R"cpp(

ioeric wrote:
> malaperle wrote:
> > ioeric wrote:
> > > It's not clear to me what the following tests (`Enums`, 
> > > `AnonymousNamespace`, `InMainFile`) are testing. Do they test code 
> > > completion or  symbol collector? If these test symbol collection, they 
> > > should be moved int SymbolCollectorTest.cpp
> > They are testing that code completion works as intended regardless of how 
> > symbol collector is implemented. It's similar to our previous discussion in 
> > D44882 about "black box testing". I can remove them but it seems odd to me 
> > to not have code completion level tests for all cases because we assume 
> > that it will behave a certain way at the symbol collection and querying 
> > levels.
> FWIW, I am not against those tests at all; increasing coverage is always a 
> nice thing to do IMO. I just thought it would make more sense to add them in 
> a separate patch if they are not related to changes in this patch; I found 
> unrelated tests a bit confusing otherwise.
> I found unrelated tests a bit confusing otherwise.

Fair point!


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D44954



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


[PATCH] D47623: [clangd] Avoid indexing decls associated with friend decls.

2018-06-01 Thread Eric Liu via Phabricator via cfe-commits
ioeric added a comment.

In https://reviews.llvm.org/D47623#1118951, @ilya-biryukov wrote:

> In https://reviews.llvm.org/D47623#1118810, @sammccall wrote:
>
> > - friend decls that are not definitions should be ignored for indexing 
> > purposes
>
>
> This is not generally true IIUC. A friend declaration can be a reference, a 
> declaration or a definition.
>
>   int foo(int);
>   int bar(int, int);
>   class ExistingFwdCls;
>  
>   class X {
> friend class ExistingFwdCls; // a reference and a declaration.
> friend class NewClass; // a new declaration.
> friend int foo(int); // a reference and a declaration.
> friend int baz(int, int, int); // a new declaration.
>   };
>  
>   class Y {
> friend class ::ExistingFwdCls; // qualified => just a reference.
> friend int ::bar(int a, int b); // qualified => just a reference.
> friend int foo(int) { // a reference  and a definition
>   return 100;
> }
>   };
>
>
> Note that friend functions with bodies are probably ok as canonical 
> declaration, as they are often the only declaration, e.g.
>
>   class Foo {
> friend bool operator < (Foo const& lhs, Foo const) {
>  return false;
> }
>   };
>


Sorry for the late response Ilya. I was trying to test these cases. So, with 
the current change, if a real "canonical" declaration comes before the friend 
decl, then the reference will still be recorded (I've added a test case for 
this). Would this address your concern?




Comment at: clangd/index/SymbolCollector.cpp:303
+  // canonical declaration in the index.
+  if (D->getFriendObjectKind() != Decl::FriendObjectKind::FOK_None)
+D = ASTNode.OrigD;

sammccall wrote:
> Ah, now I understand - we're picking another to use as canonical. But the 
> exception for definitions should apply here too. And there's nothing special 
> about *OrigD* that makes it a good pick for canonical.
> 
> For determinism, can we instead iterate over the redecls of D and pick the 
> first one that's not a friend or is a definition?
> 
> (I'd pull that check out into a function `shouldSkipDecl` and rename the 
> existing one `shouldSkipSymbol`, but up to you)
> But the exception for definitions should apply here too
I'm not sure why this is needed. Do you have an example?

> And there's nothing special about *OrigD* that makes it a good pick for 
> canonical.
I think `OrigD` is "special" because we have checked that it's not an 
uninteresting friend decl.

> For determinism, can we instead iterate over the redecls of D and pick the 
> first one that's not a friend or is a definition?
This seems to be the most ideal option, although, in practice, it's a bit hard 
to check if each `redecl` is a definition, as we don't have `Roles` for them. 
To make it more deterministic, I added a map from clang's canonical decl to 
clangd's "canonical" decl so that we could be sure that all redecls would have 
the same `D`. WDYT?

>(I'd pull that check out into a function shouldSkipDecl and rename the 
>existing one shouldSkipSymbol, but up to you)
I gave this a try, but it couldn't find a very good abstraction. Happy to chat 
more next week.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D47623



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


[PATCH] D45517: [analyzer] False positive refutation with Z3

2018-06-01 Thread Mikhail Ramalho via Phabricator via cfe-commits
mikhail.ramalho updated this revision to Diff 149524.
mikhail.ramalho added a comment.

- Simplified the API even further by constructing a Z3ConstraintManager object 
directly.
- Update isModelFeasible to return a isModelFeasible
- Update code with the fix for 1-bit long integer


https://reviews.llvm.org/D45517

Files:
  include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
  include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitors.h
  include/clang/StaticAnalyzer/Core/PathSensitive/ConstraintManager.h
  include/clang/StaticAnalyzer/Core/PathSensitive/Z3ConstraintManager.h
  lib/StaticAnalyzer/Core/AnalyzerOptions.cpp
  lib/StaticAnalyzer/Core/BugReporter.cpp
  lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
  lib/StaticAnalyzer/Core/Z3ConstraintManager.cpp
  test/Analysis/z3-crosscheck.c

Index: test/Analysis/z3-crosscheck.c
===
--- /dev/null
+++ test/Analysis/z3-crosscheck.c
@@ -0,0 +1,57 @@
+// RUN: %clang_cc1 -analyze -analyzer-checker=core,unix.Malloc,debug.ExprInspection -DNO_CROSSCHECK -verify %s
+// RUN: %clang_cc1 -analyze -analyzer-checker=core,unix.Malloc,debug.ExprInspection -analyzer-config crosscheck-with-z3=true -verify %s
+// REQUIRES: z3
+
+#ifndef NO_CROSSCHECK
+// expected-no-diagnostics
+#endif
+
+int foo(int x) 
+{
+  int *z = 0;
+  if ((x & 1) && ((x & 1) ^ 1))
+#ifdef NO_CROSSCHECK
+  return *z; // expected-warning {{Dereference of null pointer (loaded from variable 'z')}}
+#else
+  return *z; // no-warning
+#endif
+  return 0;
+}
+
+void g(int d);
+
+void f(int *a, int *b) {
+  int c = 5;
+  if ((a - b) == 0)
+c = 0;
+  if (a != b)
+#ifdef NO_CROSSCHECK
+g(3 / c); // expected-warning {{Division by zero}}
+#else
+g(3 / c); // no-warning
+#endif
+}
+
+_Bool nondet_bool();
+
+void h(int d) {
+  int x, y, k, z = 1;
+#ifdef NO_CROSSCHECK
+  while (z < k) { // expected-warning {{The right operand of '<' is a garbage value}}
+#else
+  // FIXME: Should warn about 'k' being a garbage value
+  while (z < k) { // no-warning
+#endif
+z = 2 * z;
+  }
+}
+
+void i() {
+  _Bool c = nondet_bool();
+  if (c) {
+h(1);
+  } else {
+h(2);
+  }
+}
+
Index: lib/StaticAnalyzer/Core/Z3ConstraintManager.cpp
===
--- lib/StaticAnalyzer/Core/Z3ConstraintManager.cpp
+++ lib/StaticAnalyzer/Core/Z3ConstraintManager.cpp
@@ -8,7 +8,7 @@
 //===--===//
 
 #include "clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h"
-#include "clang/StaticAnalyzer/Core/PathSensitive/SimpleConstraintManager.h"
+#include "clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/Z3ConstraintManager.h"
 
 using namespace clang;
@@ -1013,6 +1013,50 @@
   return State->set(CZ);
 }
 
+void Z3ConstraintManager::addRangeConstraints(ConstraintRangeTy CR) {
+  for (const auto  : CR) {
+SymbolRef Sym = I.first;
+
+Z3Expr Constraints = Z3Expr::fromBoolean(false);
+
+for (const auto  : I.second) {
+  const llvm::APSInt  = Range.From();
+  const llvm::APSInt  = Range.To();
+
+  QualType FromTy;
+  llvm::APSInt NewFromInt;
+  std::tie(NewFromInt, FromTy) = fixAPSInt(From);
+  Z3Expr FromExp = Z3Expr::fromAPSInt(NewFromInt);
+
+  QualType SymTy;
+  Z3Expr Exp = getZ3Expr(Sym, );
+  bool IsSignedTy = SymTy->isSignedIntegerOrEnumerationType();
+
+  QualType ToTy;
+  llvm::APSInt NewToInt;
+  std::tie(NewToInt, ToTy) = fixAPSInt(To);
+  Z3Expr ToExp = Z3Expr::fromAPSInt(NewToInt);
+  assert(FromTy == ToTy && "Range values have different types!");
+
+  Z3Expr LHS =
+  getZ3BinExpr(Exp, SymTy, BO_GE, FromExp, FromTy, /*RetTy=*/nullptr);
+  Z3Expr RHS =
+  getZ3BinExpr(Exp, SymTy, BO_LE, ToExp, FromTy, /*RetTy=*/nullptr);
+  Z3Expr SymRange = Z3Expr::fromBinOp(LHS, BO_LAnd, RHS, IsSignedTy);
+  Constraints =
+  Z3Expr::fromBinOp(Constraints, BO_LOr, SymRange, IsSignedTy);
+}
+Solver.addConstraint(Constraints);
+  }
+}
+
+clang::ento::ConditionTruthVal Z3ConstraintManager::isModelFeasible() {
+  if(Solver.check() == Z3_L_FALSE)
+return false;
+
+  return ConditionTruthVal();
+}
+
 //===--===//
 // Internal implementation.
 //===--===//
Index: lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
===
--- lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
+++ lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
@@ -41,6 +41,7 @@
 #include "clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/ProgramState_Fwd.h"
+#include 

[PATCH] D47623: [clangd] Avoid indexing decls associated with friend decls.

2018-06-01 Thread Eric Liu via Phabricator via cfe-commits
ioeric updated this revision to Diff 149528.
ioeric added a comment.

- Remove debug message.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D47623

Files:
  clangd/index/SymbolCollector.cpp
  clangd/index/SymbolCollector.h
  unittests/clangd/SymbolCollectorTests.cpp


Index: unittests/clangd/SymbolCollectorTests.cpp
===
--- unittests/clangd/SymbolCollectorTests.cpp
+++ unittests/clangd/SymbolCollectorTests.cpp
@@ -812,6 +812,48 @@
QName("nx::Kind"), QName("nx::Kind_Fine")));
 }
 
+TEST_F(SymbolCollectorTest, DoNotIndexSymbolsInFriendDecl) {
+  Annotations Header(R"(
+namespace nx {
+  class $z[[Z]] {};
+  class X {
+friend class Y;
+friend class Z;
+friend void foo();
+friend void $bar[[bar]]() {}
+  };
+  class $y[[Y]] {};
+  void $foo[[foo]]();
+}
+  )");
+  runSymbolCollector(Header.code(), /*Main=*/"");
+
+  EXPECT_THAT(Symbols,
+  UnorderedElementsAre(
+  QName("nx"), QName("nx::X"),
+  AllOf(QName("nx::Y"), DeclRange(Header.range("y"))),
+  AllOf(QName("nx::Z"), DeclRange(Header.range("z"))),
+  AllOf(QName("nx::foo"), DeclRange(Header.range("foo"))),
+  AllOf(QName("nx::bar"), DeclRange(Header.range("bar");
+}
+
+TEST_F(SymbolCollectorTest, ReferencesInFriendDecl) {
+  const std::string Header = R"(
+class X;
+class Y;
+  )";
+  const std::string Main = R"(
+class C {
+  friend ::X;
+  friend class Y;
+};
+  )";
+  CollectorOpts.CountReferences = true;
+  runSymbolCollector(Header, Main);
+  EXPECT_THAT(Symbols, UnorderedElementsAre(AllOf(QName("X"), Refs(1)),
+AllOf(QName("Y"), Refs(1;
+}
+
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clangd/index/SymbolCollector.h
===
--- clangd/index/SymbolCollector.h
+++ clangd/index/SymbolCollector.h
@@ -80,6 +80,12 @@
   Options Opts;
   // Decls referenced from the current TU, flushed on finish().
   llvm::DenseSet ReferencedDecls;
+  // Maps canonical declaration provided by clang to canonical declaration for
+  // an index symbol, if clangd prefers a different declaration than that
+  // provided by clang. For example, friend declaration might be considered
+  // canonical by clang but should not be considered canonical in the index
+  // unless it's a definition.
+  llvm::DenseMap CanonicalDecls;
 };
 
 } // namespace clangd
Index: clangd/index/SymbolCollector.cpp
===
--- clangd/index/SymbolCollector.cpp
+++ clangd/index/SymbolCollector.cpp
@@ -290,6 +290,23 @@
 index::IndexDataConsumer::ASTNodeInfo ASTNode) {
   assert(ASTCtx && PP.get() && "ASTContext and Preprocessor must be set.");
   assert(CompletionAllocator && CompletionTUInfo);
+  assert(ASTNode.OrigD);
+  // If OrigD is an declaration associated with a friend declaration and it's
+  // not a definition, skip it. Note that OrigD is the occurrence that the
+  // collector is currently visiting.
+  if ((ASTNode.OrigD->getFriendObjectKind() !=
+   Decl::FriendObjectKind::FOK_None) &&
+  !(Roles & static_cast(index::SymbolRole::Definition)))
+return true;
+  // A declaration created for a friend declaration should not be used as the
+  // canonical declaration in the index. If D is a defintion and is not OrigD,
+  // D would have been picked as the canonical declaration, if it has been
+  // visited, or OrigD, which could only be a non-friend declaration as 
multiple
+  // definitons are not possible, will be preferred.
+  if (D->getFriendObjectKind() != Decl::FriendObjectKind::FOK_None)
+// Either use a OrigD or a previous recorded canonical declaration as the
+// canonical declaration.
+D = CanonicalDecls.try_emplace(D, ASTNode.OrigD).first->second;
   const NamedDecl *ND = llvm::dyn_cast(D);
   if (!ND)
 return true;


Index: unittests/clangd/SymbolCollectorTests.cpp
===
--- unittests/clangd/SymbolCollectorTests.cpp
+++ unittests/clangd/SymbolCollectorTests.cpp
@@ -812,6 +812,48 @@
QName("nx::Kind"), QName("nx::Kind_Fine")));
 }
 
+TEST_F(SymbolCollectorTest, DoNotIndexSymbolsInFriendDecl) {
+  Annotations Header(R"(
+namespace nx {
+  class $z[[Z]] {};
+  class X {
+friend class Y;
+friend class Z;
+friend void foo();
+friend void $bar[[bar]]() {}
+  };
+  class $y[[Y]] {};
+  void $foo[[foo]]();
+}
+  )");
+  runSymbolCollector(Header.code(), /*Main=*/"");
+
+  EXPECT_THAT(Symbols,
+  UnorderedElementsAre(
+  QName("nx"), QName("nx::X"),
+  AllOf(QName("nx::Y"), 

[PATCH] D46084: [Fixed Point Arithmetic] Addition of the Fixed Point _Accum type

2018-06-01 Thread Leonard Chan via Phabricator via cfe-commits
leonardchan added a comment.

Hi all, I'll be attempting to commit this patch around 6pm PT today unless 
anyone has any more comments on this specific patch. Any other suggestions 
regarding potential design changes can be discussed in future patches since 
this is only the first of many.


Repository:
  rC Clang

https://reviews.llvm.org/D46084



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


[PATCH] D47623: [clangd] Avoid indexing decls associated with friend decls.

2018-06-01 Thread Eric Liu via Phabricator via cfe-commits
ioeric updated this revision to Diff 149526.
ioeric added a comment.

- Make canonical decls determinstic.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D47623

Files:
  clangd/index/SymbolCollector.cpp
  clangd/index/SymbolCollector.h
  unittests/clangd/SymbolCollectorTests.cpp


Index: unittests/clangd/SymbolCollectorTests.cpp
===
--- unittests/clangd/SymbolCollectorTests.cpp
+++ unittests/clangd/SymbolCollectorTests.cpp
@@ -812,6 +812,50 @@
QName("nx::Kind"), QName("nx::Kind_Fine")));
 }
 
+TEST_F(SymbolCollectorTest, DoNotIndexSymbolsInFriendDecl) {
+  Annotations Header(R"(
+namespace nx {
+  class $z[[Z]] {};
+  class X {
+friend class Y;
+friend class Z;
+friend void foo();
+friend void $bar[[bar]]() {}
+  };
+  class $y[[Y]] {};
+  void $foo[[foo]]();
+}
+  )");
+  runSymbolCollector(Header.code(), /*Main=*/"");
+
+  EXPECT_THAT(Symbols,
+  UnorderedElementsAre(
+  QName("nx"), QName("nx::X"),
+  AllOf(QName("nx::Y"), DeclRange(Header.range("y"))),
+  AllOf(QName("nx::Z"), DeclRange(Header.range("z"))),
+  AllOf(QName("nx::foo"), DeclRange(Header.range("foo"))),
+  AllOf(QName("nx::bar"), DeclRange(Header.range("bar");
+}
+
+TEST_F(SymbolCollectorTest, ReferencesInFriendDecl) {
+  const std::string Header = R"(
+class X;
+class Y;
+  )";
+  const std::string Main = R"(
+class C {
+  friend ::X;
+  friend class Y;
+};
+  )";
+  CollectorOpts.CountReferences = true;
+  runSymbolCollector(Header, Main);
+  for (const auto  : Symbols)
+llvm::errs() << Sym.Name << ":   " << Sym.References << "\n";
+  EXPECT_THAT(Symbols, UnorderedElementsAre(AllOf(QName("X"), Refs(1)),
+AllOf(QName("Y"), Refs(1;
+}
+
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clangd/index/SymbolCollector.h
===
--- clangd/index/SymbolCollector.h
+++ clangd/index/SymbolCollector.h
@@ -80,6 +80,12 @@
   Options Opts;
   // Decls referenced from the current TU, flushed on finish().
   llvm::DenseSet ReferencedDecls;
+  // Maps canonical declaration provided by clang to canonical declaration for
+  // an index symbol, if clangd prefers a different declaration than that
+  // provided by clang. For example, friend declaration might be considered
+  // canonical by clang but should not be considered canonical in the index
+  // unless it's a definition.
+  llvm::DenseMap CanonicalDecls;
 };
 
 } // namespace clangd
Index: clangd/index/SymbolCollector.cpp
===
--- clangd/index/SymbolCollector.cpp
+++ clangd/index/SymbolCollector.cpp
@@ -290,6 +290,23 @@
 index::IndexDataConsumer::ASTNodeInfo ASTNode) {
   assert(ASTCtx && PP.get() && "ASTContext and Preprocessor must be set.");
   assert(CompletionAllocator && CompletionTUInfo);
+  assert(ASTNode.OrigD);
+  // If OrigD is an declaration associated with a friend declaration and it's
+  // not a definition, skip it. Note that OrigD is the occurrence that the
+  // collector is currently visiting.
+  if ((ASTNode.OrigD->getFriendObjectKind() !=
+   Decl::FriendObjectKind::FOK_None) &&
+  !(Roles & static_cast(index::SymbolRole::Definition)))
+return true;
+  // A declaration created for a friend declaration should not be used as the
+  // canonical declaration in the index. If D is a defintion and is not OrigD,
+  // D would have been picked as the canonical declaration, if it has been
+  // visited, or OrigD, which could only be a non-friend declaration as 
multiple
+  // definitons are not possible, will be preferred.
+  if (D->getFriendObjectKind() != Decl::FriendObjectKind::FOK_None)
+// Either use a OrigD or a previous recorded canonical declaration as the
+// canonical declaration.
+D = CanonicalDecls.try_emplace(D, ASTNode.OrigD).first->second;
   const NamedDecl *ND = llvm::dyn_cast(D);
   if (!ND)
 return true;


Index: unittests/clangd/SymbolCollectorTests.cpp
===
--- unittests/clangd/SymbolCollectorTests.cpp
+++ unittests/clangd/SymbolCollectorTests.cpp
@@ -812,6 +812,50 @@
QName("nx::Kind"), QName("nx::Kind_Fine")));
 }
 
+TEST_F(SymbolCollectorTest, DoNotIndexSymbolsInFriendDecl) {
+  Annotations Header(R"(
+namespace nx {
+  class $z[[Z]] {};
+  class X {
+friend class Y;
+friend class Z;
+friend void foo();
+friend void $bar[[bar]]() {}
+  };
+  class $y[[Y]] {};
+  void $foo[[foo]]();
+}
+  )");
+  runSymbolCollector(Header.code(), /*Main=*/"");
+
+  EXPECT_THAT(Symbols,
+  

r333778 - [X86] Rewrite avx512vbmi unmasked and maskz macro intrinsics to be wrappers around their __builtin function with appropriate arguments rather than just passing arguments to the masked intrin

2018-06-01 Thread Craig Topper via cfe-commits
Author: ctopper
Date: Fri Jun  1 11:26:35 2018
New Revision: 333778

URL: http://llvm.org/viewvc/llvm-project?rev=333778=rev
Log:
[X86] Rewrite avx512vbmi unmasked and maskz macro intrinsics to be wrappers 
around their __builtin function with appropriate arguments rather than just 
passing arguments to the masked intrinsic.

This is more consistent with all of our other avx512 macro intrinsics.

It also fixes a bad cast where an argument was casted to mmask8 when it should 
have been a mmask16.

Modified:
cfe/trunk/lib/Headers/avx512vbmi2intrin.h
cfe/trunk/lib/Headers/avx512vlvbmi2intrin.h

Modified: cfe/trunk/lib/Headers/avx512vbmi2intrin.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/avx512vbmi2intrin.h?rev=333778=333777=333778=diff
==
--- cfe/trunk/lib/Headers/avx512vbmi2intrin.h (original)
+++ cfe/trunk/lib/Headers/avx512vbmi2intrin.h Fri Jun  1 11:26:35 2018
@@ -150,10 +150,18 @@ _mm512_maskz_expandloadu_epi8(__mmask64
   (__mmask8)(U))
 
 #define _mm512_maskz_shldi_epi64(U, A, B, I) \
-  _mm512_mask_shldi_epi64(_mm512_setzero_si512(), (U), (A), (B), (I))
+  (__m512i)__builtin_ia32_vpshldq512_mask((__v8di)(__m512i)(A), \
+  (__v8di)(__m512i)(B), \
+  (int)(I), \
+  (__v8di)_mm512_setzero_si512(), \
+  (__mmask8)(U))
 
 #define _mm512_shldi_epi64(A, B, I) \
-  _mm512_mask_shldi_epi64(_mm512_undefined(), (__mmask8)(-1), (A), (B), (I))
+  (__m512i)__builtin_ia32_vpshldq512_mask((__v8di)(__m512i)(A), \
+  (__v8di)(__m512i)(B), \
+  (int)(I), \
+  (__v8di)_mm512_undefined_epi32(), \
+  (__mmask8)-1)
 
 #define _mm512_mask_shldi_epi32(S, U, A, B, I) \
   (__m512i)__builtin_ia32_vpshldd512_mask((__v16si)(__m512i)(A), \
@@ -163,10 +171,18 @@ _mm512_maskz_expandloadu_epi8(__mmask64
   (__mmask16)(U))
 
 #define _mm512_maskz_shldi_epi32(U, A, B, I) \
-  _mm512_mask_shldi_epi32(_mm512_setzero_si512(), (U), (A), (B), (I))
+  (__m512i)__builtin_ia32_vpshldd512_mask((__v16si)(__m512i)(A), \
+  (__v16si)(__m512i)(B), \
+  (int)(I), \
+  (__v16si)_mm512_setzero_si512(), \
+  (__mmask16)(U))
 
 #define _mm512_shldi_epi32(A, B, I) \
-  _mm512_mask_shldi_epi32(_mm512_undefined(), (__mmask16)(-1), (A), (B), (I))
+  (__m512i)__builtin_ia32_vpshldd512_mask((__v16si)(__m512i)(A), \
+  (__v16si)(__m512i)(B), \
+  (int)(I), \
+  (__v16si)_mm512_undefined_epi32(), \
+  (__mmask16)-1)
 
 #define _mm512_mask_shldi_epi16(S, U, A, B, I) \
   (__m512i)__builtin_ia32_vpshldw512_mask((__v32hi)(__m512i)(A), \
@@ -176,10 +192,18 @@ _mm512_maskz_expandloadu_epi8(__mmask64
   (__mmask32)(U))
 
 #define _mm512_maskz_shldi_epi16(U, A, B, I) \
-  _mm512_mask_shldi_epi16(_mm512_setzero_si512(), (U), (A), (B), (I))
+  (__m512i)__builtin_ia32_vpshldw512_mask((__v32hi)(__m512i)(A), \
+  (__v32hi)(__m512i)(B), \
+  (int)(I), \
+  (__v32hi)_mm512_setzero_si512(), \
+  (__mmask32)(U))
 
 #define _mm512_shldi_epi16(A, B, I) \
-  _mm512_mask_shldi_epi16(_mm512_undefined(), (__mmask32)(-1), (A), (B), (I))
+  (__m512i)__builtin_ia32_vpshldw512_mask((__v32hi)(__m512i)(A), \
+  (__v32hi)(__m512i)(B), \
+  (int)(I), \
+  (__v32hi)_mm512_undefined_epi32(), \
+  (__mmask32)-1)
 
 #define _mm512_mask_shrdi_epi64(S, U, A, B, I) \
   (__m512i)__builtin_ia32_vpshrdq512_mask((__v8di)(__m512i)(A), \
@@ -189,10 +213,18 @@ _mm512_maskz_expandloadu_epi8(__mmask64
   (__mmask8)(U))
 
 #define _mm512_maskz_shrdi_epi64(U, A, B, I) \
-  _mm512_mask_shrdi_epi64(_mm512_setzero_si512(), (U), (A), (B), (I))
+  (__m512i)__builtin_ia32_vpshrdq512_mask((__v8di)(__m512i)(A), \
+  (__v8di)(__m512i)(B), \
+  (int)(I), \
+  (__v8di)_mm512_setzero_si512(), \
+  (__mmask8)(U))
 
 #define _mm512_shrdi_epi64(A, B, I) \
-  

[PATCH] D47613: Mark __c11_atomic_load as const

2018-06-01 Thread JF Bastien via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL333776: Mark __c11_atomic_load as const (authored by jfb, 
committed by ).
Herald added a subscriber: llvm-commits.

Repository:
  rL LLVM

https://reviews.llvm.org/D47613

Files:
  libcxx/trunk/include/atomic


Index: libcxx/trunk/include/atomic
===
--- libcxx/trunk/include/atomic
+++ libcxx/trunk/include/atomic
@@ -698,16 +698,16 @@
 }
 
 template 
-static inline _Tp __c11_atomic_load(volatile _Atomic(_Tp)* __a,
+static inline _Tp __c11_atomic_load(const volatile _Atomic(_Tp)* __a,
 memory_order __order) {
   _Tp __ret;
   __atomic_load(&__a->__a_value, &__ret,
 __gcc_atomic::__to_gcc_order(__order));
   return __ret;
 }
 
 template 
-static inline _Tp __c11_atomic_load(_Atomic(_Tp)* __a, memory_order __order) {
+static inline _Tp __c11_atomic_load(const _Atomic(_Tp)* __a, memory_order 
__order) {
   _Tp __ret;
   __atomic_load(&__a->__a_value, &__ret,
 __gcc_atomic::__to_gcc_order(__order));


Index: libcxx/trunk/include/atomic
===
--- libcxx/trunk/include/atomic
+++ libcxx/trunk/include/atomic
@@ -698,16 +698,16 @@
 }
 
 template 
-static inline _Tp __c11_atomic_load(volatile _Atomic(_Tp)* __a,
+static inline _Tp __c11_atomic_load(const volatile _Atomic(_Tp)* __a,
 memory_order __order) {
   _Tp __ret;
   __atomic_load(&__a->__a_value, &__ret,
 __gcc_atomic::__to_gcc_order(__order));
   return __ret;
 }
 
 template 
-static inline _Tp __c11_atomic_load(_Atomic(_Tp)* __a, memory_order __order) {
+static inline _Tp __c11_atomic_load(const _Atomic(_Tp)* __a, memory_order __order) {
   _Tp __ret;
   __atomic_load(&__a->__a_value, &__ret,
 __gcc_atomic::__to_gcc_order(__order));
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[libcxx] r333776 - Mark __c11_atomic_load as const

2018-06-01 Thread JF Bastien via cfe-commits
Author: jfb
Date: Fri Jun  1 11:02:53 2018
New Revision: 333776

URL: http://llvm.org/viewvc/llvm-project?rev=333776=rev
Log:
Mark __c11_atomic_load as const

Summary:
C++11 onwards specs the non-member functions atomic_load and 
atomic_load_explicit as taking the atomic by const (potentially volatile) 
pointer. C11, in its infinite wisdom, decided to drop the const, and C17 will 
fix this with DR459 (the current draft forgot to fix B.16, but that’s not the 
normative part).

This patch fixes the libc++ version of the __c11_atomic_load builtins defined 
for GCC's compatibility sake.

D47618 takes care of the clang side.

Discussion: http://lists.llvm.org/pipermail/cfe-dev/2018-May/058129.html



Reviewers: EricWF, mclow.lists

Subscribers: christof, cfe-commits

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

Modified:
libcxx/trunk/include/atomic

Modified: libcxx/trunk/include/atomic
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/atomic?rev=333776=333775=333776=diff
==
--- libcxx/trunk/include/atomic (original)
+++ libcxx/trunk/include/atomic Fri Jun  1 11:02:53 2018
@@ -698,7 +698,7 @@ static inline void __c11_atomic_store(_A
 }
 
 template 
-static inline _Tp __c11_atomic_load(volatile _Atomic(_Tp)* __a,
+static inline _Tp __c11_atomic_load(const volatile _Atomic(_Tp)* __a,
 memory_order __order) {
   _Tp __ret;
   __atomic_load(&__a->__a_value, &__ret,
@@ -707,7 +707,7 @@ static inline _Tp __c11_atomic_load(vola
 }
 
 template 
-static inline _Tp __c11_atomic_load(_Atomic(_Tp)* __a, memory_order __order) {
+static inline _Tp __c11_atomic_load(const _Atomic(_Tp)* __a, memory_order 
__order) {
   _Tp __ret;
   __atomic_load(&__a->__a_value, &__ret,
 __gcc_atomic::__to_gcc_order(__order));


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


[PATCH] D47445: [ASTImporter] Corrected diagnostic client handling in tests.

2018-06-01 Thread Argyrios Kyrtzidis via Phabricator via cfe-commits
akyrtzi added a comment.

We could leave `disableSourceFileDiagnostics` off until someone finds a use 
case for it.


Repository:
  rC Clang

https://reviews.llvm.org/D47445



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


[PATCH] D45517: [analyzer] False positive refutation with Z3

2018-06-01 Thread George Karpenkov via Phabricator via cfe-commits
george.karpenkov added a comment.

@mikhail.ramalho I assume you know it, but just in case, you can mark 
dependencies in phabricator by adding "parent" revisions.


https://reviews.llvm.org/D45517



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


[PATCH] D47616: [CFG] [analyzer] Explain copy elision through construction contexts.

2018-06-01 Thread George Karpenkov via Phabricator via cfe-commits
george.karpenkov requested changes to this revision.
george.karpenkov added a comment.
This revision now requires changes to proceed.

There's quite a lot of code duplication here, I think we could do better with 
that. Great job modeling semantics though!




Comment at: lib/Analysis/CFG.cpp:1320
+auto *MTE = cast(Child);
+findConstructionContexts(ConstructionContextLayer::create(
+ cfg->getBumpVectorContext(), MTE, Layer),

There are three repeated calls to `findConstructionContexts`, with only the 
second argument changing. Perhaps a helper lambda closure would help?



Comment at: lib/Analysis/CFG.cpp:4959
+  const Stmt *S1 = nullptr, *S2 = nullptr, *S3 = nullptr;
+  const ConstructionContext *CC1 = nullptr;
   switch (CC->getKind()) {

begs for a comment differentiating CC from CC1



Comment at: lib/Analysis/CFG.cpp:5014
   }
   if (S1) {
 OS << ", ";

three blocks below could really benefit from a helper function.



Comment at: lib/Analysis/ConstructionContext.cpp:140
 
-  assert(TopLayer->isLast());
-  return create(C, nullptr, MTE);
+  // Handle pre-C++17 copy and move elision.
+  const CXXConstructExpr *ElidedCE = nullptr;

seems this chunk has a fair bit of code duplication vs. lines 79-99


Repository:
  rC Clang

https://reviews.llvm.org/D47616



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


[PATCH] D45015: [Preprocessor] Allow libc++ to detect when aligned allocation is unavailable.

2018-06-01 Thread Akira Hatanaka via Phabricator via cfe-commits
ahatanak added a comment.

In https://reviews.llvm.org/D45015#1105388, @rsmith wrote:

> In https://reviews.llvm.org/D45015#1105372, @vsapsai wrote:
>
> > What when compiler has `__builtin_operator_new`, 
> > `__builtin_operator_delete`? If I build libc++ tests with recent Clang 
> > which has these builtins and run tests with libc++.dylib from old Darwin, 
> > there are no linkage errors. Should we define `__cpp_aligned_allocation` in 
> > this case?
>
>
> I don't see why that should make any difference -- those builtins call the 
> same functions that the new and delete operator call. Perhaps libc++ isn't 
> calling the forms of those builtins that take an alignment argument yet?


It looks like clang currently doesn't issue a warning when a call to 
__builtin_operator_new or __builtin_operator_delete calls an aligned allocation 
function that is not support by the OS version. I suppose we should fix this?

  // no warning issued when triple is "thumbv7-apple-ios5.0.0" even though 
aligned allocation is unavailable.
  void *p = __builtin_operator_new(100, std::align_val_t(32));


Repository:
  rC Clang

https://reviews.llvm.org/D45015



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


[PATCH] D47617: [Analyzer] Fix Z3ConstraintManager crash (PR37646)

2018-06-01 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added a comment.

We might as well make a directory for z3-specific tests. Eg., 
`z3/bool-bit-width.c`.

Also does this test need to be z3-specific? We would also not like to crash 
here without z3.


Repository:
  rC Clang

https://reviews.llvm.org/D47617



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


[PATCH] D47617: [Analyzer] Fix Z3ConstraintManager crash (PR37646)

2018-06-01 Thread George Karpenkov via Phabricator via cfe-commits
george.karpenkov added a comment.

Thanks!


Repository:
  rC Clang

https://reviews.llvm.org/D47617



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


[PATCH] D47201: [CUDA] Implement nv_weak attribute for functions

2018-06-01 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In https://reviews.llvm.org/D47201#1119249, @tra wrote:

> IIUIC, nv_weak is a synonym for weak (why, oh why did they need 
> it?)
>  You may need to hunt down and change few other places that deal with the 
> weak attribute.
>  E.g.: 
> https://github.com/llvm-project/llvm-project-20170507/blob/master/clang/lib/AST/Decl.cpp#L4267
>  
> https://github.com/llvm-project/llvm-project-20170507/blob/master/clang/lib/CodeGen/ItaniumCXXABI.cpp#L3045


If it is truly a synonym for weak, then a better implementation would be to 
make no semantic distinction between the two attributes -- just add new 
spellings to weak. If you need to make minor distinctions between the 
spellings, you can do it using accessors on the attribute.




Comment at: include/clang/Basic/Attr.td:1515
   let LangOpts = [CUDA];
+  let Documentation = [Undocumented];
 }

No new, undocumented attributes, please.


Repository:
  rC Clang

https://reviews.llvm.org/D47201



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


[PATCH] D47617: [Analyzer] Fix Z3ConstraintManager crash (PR37646)

2018-06-01 Thread George Karpenkov via Phabricator via cfe-commits
george.karpenkov requested changes to this revision.
george.karpenkov added a comment.
This revision now requires changes to proceed.

LGTM with a nit on a test name.




Comment at: test/Analysis/pr37646.c:1
+// REQUIRES: z3
+// RUN: %clang_analyze_cc1 -triple x86_64-apple-darwin9 -analyzer-checker=core 
-analyzer-store=region -analyzer-constraints=z3 -verify %s

The tests are already quite messy, but adding a new file per each bug seems 
excessive. Could we take your test and `test/Analysis/apsint.c` and combine 
them into e.g. `z3_apsint_encoding.c` ? (also adding a link to bugzilla)


Repository:
  rC Clang

https://reviews.llvm.org/D47617



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


[PATCH] D47070: [CUDA] Upgrade linked bitcode to enable inlining

2018-06-01 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

IMO overriding TargetTransformInfo::areInlineCompatible to always return true 
on NVPTX is what we want to do instead of upgrading everything else.
AFAICT, on NVPTX there's no reason to prevent inlining due to those attributes 
-- we'll never generate code, nor will we ever execute it on any other GPU than 
we're currently compiling for.

This should get you going until I figure out how to have target-specific 
builtins without sticking target-cpu and target-features attributes on 
everything.


Repository:
  rC Clang

https://reviews.llvm.org/D47070



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


[PATCH] D47201: [CUDA] Implement nv_weak attribute for functions

2018-06-01 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

IIUIC, nv_weak is a synonym for weak (why, oh why did they need 
it?)
You may need to hunt down and change few other places that deal with the weak 
attribute.
E.g.: 
https://github.com/llvm-project/llvm-project-20170507/blob/master/clang/lib/AST/Decl.cpp#L4267
https://github.com/llvm-project/llvm-project-20170507/blob/master/clang/lib/CodeGen/ItaniumCXXABI.cpp#L3045


Repository:
  rC Clang

https://reviews.llvm.org/D47201



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


[PATCH] D47578: Do not enforce absolute path argv0 in windows

2018-06-01 Thread Rui Ueyama via Phabricator via cfe-commits
ruiu added a comment.

It seems like you are trying a bit too hard to keep the original code which is 
not always a good idea to keep the clarity of the code.

So, IIUC, you this function:

- returns a full filename of the current executable. That can be written using 
GetModuleFileName and GetLongPathName

then you basically do the following to

  sys::path::remove_filename(Arg0);
  sys::path::append(Arg0, sys::path::filename(ExectuablePath));
  





Comment at: llvm/lib/Support/Windows/Process.inc:211
 
 static std::error_code ExpandShortFileName(const wchar_t *Arg,
+   SmallVectorImpl ) 
{

This function is used only by your new function, so it is probably better to 
inline it.



Comment at: llvm/lib/Support/Windows/Process.inc:226
+
+static std::error_code GetLongArgv0FullPath(const wchar_t *Argv0,
+SmallVectorImpl 
) {

You can always ignore Argv0, no? Since GetModuleFileName is always available, 
you probably should use it unconditionally, ignoring the original argv[0].



Comment at: llvm/lib/Support/Windows/Process.inc:251
+  // This may change argv0 like below,
+  // * clang -> clang.exe (just add extension)
+  // * CLANG_~1.EXE -> clang++.exe (extend shorname)

I believe GetModuleFileName always returns a path with an extension, though it 
might be 8.3 path.



Comment at: llvm/lib/Support/Windows/Process.inc:268-269
+
+  return windows::UTF8ToUTF16(StringRef(UTF8Argv0.data(), UTF8Argv0.size()),
+  LongArgv0);
 }

Don't convert utf-8 to utf-16 only to convert it back to utf-8 immediately 
after returning from this function.


https://reviews.llvm.org/D47578



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


r333775 - [Coverage] Remove a test dependency on the itanium ABI

2018-06-01 Thread Vedant Kumar via cfe-commits
Author: vedantk
Date: Fri Jun  1 10:11:18 2018
New Revision: 333775

URL: http://llvm.org/viewvc/llvm-project?rev=333775=rev
Log:
[Coverage] Remove a test dependency on the itanium ABI

This should address a bot failure:
http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/9994/

Modified:
cfe/trunk/test/CoverageMapping/label.cpp

Modified: cfe/trunk/test/CoverageMapping/label.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CoverageMapping/label.cpp?rev=333775=333774=333775=diff
==
--- cfe/trunk/test/CoverageMapping/label.cpp (original)
+++ cfe/trunk/test/CoverageMapping/label.cpp Fri Jun  1 10:11:18 2018
@@ -48,7 +48,17 @@ b:   // CHECK-NE
   x = x + 1;
 }
 
- // CHECK-NEXT: main
+// CHECK-NEXT: test3
+#define a b
+void test3() {
+  if (0)
+goto b; // CHECK: Gap,File 0, [[@LINE]]:11 -> [[@LINE+1]]:1 = 
[[retnCount:#[0-9]+]]
+a: // CHECK-NEXT: Expansion,File 0, [[@LINE]]:1 -> [[@LINE]]:2 = [[retnCount]] 
(Expanded file = 1)
+  return; // CHECK-NEXT: File 0, [[@LINE-1]]:2 -> [[@LINE]]:9 = [[retnCount]]
+}
+#undef a
+
+ // CHECK: main
 int main() { // CHECK-NEXT: File 0, [[@LINE]]:12 -> 
{{[0-9]+}}:2 = #0
   int j = 0;
   for(int i = 0; i < 10; ++i) { // CHECK: File 0, [[@LINE]]:31 -> 
[[@LINE+13]]:4 = #1
@@ -69,12 +79,3 @@ int main() { // CHECK-NE
   test1(0);
   test2(2);
 }
-
-// CHECK-LABEL: _Z5test3v:
-#define a b
-void test3() {
-  if (0)
-goto b; // CHECK: Gap,File 0, [[@LINE]]:11 -> [[@LINE+1]]:1 = 
[[retnCount:#[0-9]+]]
-a: // CHECK-NEXT: Expansion,File 0, [[@LINE]]:1 -> [[@LINE]]:2 = [[retnCount]] 
(Expanded file = 1)
-  return; // CHECK-NEXT: File 0, [[@LINE-1]]:2 -> [[@LINE]]:9 = [[retnCount]]
-}


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


[PATCH] D47267: [UnrollAndJam] Add unroll_and_jam pragma handling

2018-06-01 Thread Michael Kruse via Phabricator via cfe-commits
Meinersbur added a comment.

The RFC: https://lists.llvm.org/pipermail/cfe-dev/2018-May/058141.html


https://reviews.llvm.org/D47267



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


[PATCH] D47623: [clangd] Avoid indexing decls associated with friend decls.

2018-06-01 Thread Sam McCall via Phabricator via cfe-commits
sammccall accepted this revision.
sammccall added a comment.
This revision is now accepted and ready to land.

This looks OK, the asymmetry still seems a little odd to me and could be 
reduced a little.

(Please also resolve Ilya's question about references with him, I don't have a 
strong opinion)




Comment at: clangd/index/SymbolCollector.cpp:303
+  // canonical declaration in the index.
+  if (D->getFriendObjectKind() != Decl::FriendObjectKind::FOK_None)
+D = ASTNode.OrigD;

Ah, now I understand - we're picking another to use as canonical. But the 
exception for definitions should apply here too. And there's nothing special 
about *OrigD* that makes it a good pick for canonical.

For determinism, can we instead iterate over the redecls of D and pick the 
first one that's not a friend or is a definition?

(I'd pull that check out into a function `shouldSkipDecl` and rename the 
existing one `shouldSkipSymbol`, but up to you)


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D47623



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


[PATCH] D43341: [clang-doc] Implement reducer portion of the frontend framework

2018-06-01 Thread Julie Hockett via Phabricator via cfe-commits
juliehockett updated this revision to Diff 149500.
juliehockett marked 8 inline comments as done.

https://reviews.llvm.org/D43341

Files:
  clang-doc/BitcodeReader.cpp
  clang-doc/BitcodeReader.h
  clang-doc/BitcodeWriter.cpp
  clang-doc/BitcodeWriter.h
  clang-doc/CMakeLists.txt
  clang-doc/Representation.cpp
  clang-doc/Representation.h
  clang-doc/tool/ClangDocMain.cpp
  test/clang-doc/bc-comment.cpp
  test/clang-doc/bc-namespace.cpp
  test/clang-doc/bc-record.cpp

Index: test/clang-doc/bc-record.cpp
===
--- /dev/null
+++ test/clang-doc/bc-record.cpp
@@ -0,0 +1,254 @@
+// This test requires Linux due to the system-dependent USR for the
+// inner class in function H.
+// REQUIRES: system-linux
+// RUN: rm -rf %t
+// RUN: mkdir %t
+// RUN: echo "" > %t/compile_flags.txt
+// RUN: cp "%s" "%t/test.cpp"
+// RUN: clang-doc --dump-intermediate -doxygen -p %t %t/test.cpp -output=%t/docs
+// RUN: llvm-bcanalyzer %t/docs/bc/ACE81AFA6627B4CEF2B456FB6E1252925674AF7E.bc --dump | FileCheck %s --check-prefix CHECK-A
+// RUN: llvm-bcanalyzer %t/docs/bc/FC07BD34D5E77782C263FA97929EA8753740.bc --dump | FileCheck %s --check-prefix CHECK-B
+// RUN: llvm-bcanalyzer %t/docs/bc/1E3438A08BA22025C0B46289FF0686F92C8924C5.bc --dump | FileCheck %s --check-prefix CHECK-BC
+// RUN: llvm-bcanalyzer %t/docs/bc/06B5F6A19BA9F6A832E127C9968282B94619B210.bc --dump | FileCheck %s --check-prefix CHECK-C
+// RUN: llvm-bcanalyzer %t/docs/bc/0921737541208B8FA9BB42B60F78AC1D779AA054.bc --dump | FileCheck %s --check-prefix CHECK-D
+// RUN: llvm-bcanalyzer %t/docs/bc/289584A8E0FF4178A794622A547AA622503967A1.bc --dump | FileCheck %s --check-prefix CHECK-E
+// RUN: llvm-bcanalyzer %t/docs/bc/DEB4AC1CD9253CD9EF7FBE6BCAC506D77984ABD4.bc --dump | FileCheck %s --check-prefix CHECK-ECON
+// RUN: llvm-bcanalyzer %t/docs/bc/BD2BDEBD423F80BACCEA75DE6D6622D355FC2D17.bc --dump | FileCheck %s --check-prefix CHECK-EDES
+// RUN: llvm-bcanalyzer %t/docs/bc/E3B54702FABFF4037025BA194FC27C47006330B5.bc --dump | FileCheck %s --check-prefix CHECK-F
+// RUN: llvm-bcanalyzer %t/docs/bc/B6AC4C5C9F2EA3F2B3ECE1A33D349F4EE502B24E.bc --dump | FileCheck %s --check-prefix CHECK-H
+// RUN: llvm-bcanalyzer %t/docs/bc/6BA1EE2B3DAEACF6E4306F10AF44908F4807927C.bc --dump | FileCheck %s --check-prefix CHECK-I
+// RUN: llvm-bcanalyzer %t/docs/bc/5093D428CDC62096A67547BA52566E4FB9404EEE.bc --dump | FileCheck %s --check-prefix CHECK-PM
+// RUN: llvm-bcanalyzer %t/docs/bc/CA7C7935730B5EACD25F080E9C83FA087CCDC75E.bc --dump | FileCheck %s --check-prefix CHECK-X
+// RUN: llvm-bcanalyzer %t/docs/bc/641AB4A3D36399954ACDE29C7A8833032BF40472.bc --dump | FileCheck %s --check-prefix CHECK-Y
+
+void H() {
+  class I {};
+}
+// CHECK-H: 
+  // CHECK-H-NEXT: 
+  // CHECK-H-NEXT:  blob data = 'H'
+  // CHECK-H-NEXT:  blob data = '{{.*}}'
+  // CHECK-H-NEXT: 
+// CHECK-H-NEXT: 
+  // CHECK-H-NEXT:  blob data = 'void'
+  // CHECK-H-NEXT: 
+// CHECK-H-NEXT: 
+  // CHECK-H-NEXT: 
+// CHECK-H-NEXT: 
+
+
+// CHECK-I: 
+  // CHECK-I-NEXT: 
+  // CHECK-I-NEXT:  blob data = 'I'
+  // CHECK-I-NEXT: 
+// CHECK-I-NEXT: 
+// CHECK-I-NEXT:  blob data = 'H'
+// CHECK-I-NEXT: 
+// CHECK-I-NEXT: 
+  // CHECK-I-NEXT: 
+  // CHECK-I-NEXT:  blob data = '{{.*}}'
+  // CHECK-I-NEXT: 
+// CHECK-I-NEXT: 
+
+union A { int X; int Y; };
+// CHECK-A: 
+  // CHECK-A-NEXT: 
+  // CHECK-A-NEXT:  blob data = 'A'
+  // CHECK-A-NEXT:  blob data = '{{.*}}'
+  // CHECK-A-NEXT: 
+  // CHECK-A-NEXT: 
+// CHECK-A-NEXT: 
+  // CHECK-A-NEXT:  blob data = 'int'
+  // CHECK-A-NEXT: 
+// CHECK-A-NEXT: 
+// CHECK-A-NEXT:  blob data = 'X'
+// CHECK-A-NEXT: 
+  // CHECK-A-NEXT: 
+  // CHECK-A-NEXT: 
+// CHECK-A-NEXT: 
+  // CHECK-A-NEXT:  blob data = 'int'
+  // CHECK-A-NEXT: 
+// CHECK-A-NEXT: 
+// CHECK-A-NEXT:  blob data = 'Y'
+// CHECK-A-NEXT: 
+  // CHECK-A-NEXT: 
+// CHECK-A-NEXT: 
+
+enum B { X, Y };
+// CHECK-B: 
+  // CHECK-B-NEXT: 
+  // CHECK-B-NEXT:  blob data = 'B'
+  // CHECK-B-NEXT:  blob data = '{{.*}}'
+  // CHECK-B-NEXT:  blob data = 'X'
+  // CHECK-B-NEXT:  blob data = 'Y'
+// CHECK-B-NEXT: 
+
+enum class Bc { A, B };
+// CHECK-BC: 
+  // CHECK-BC-NEXT: 
+  // CHECK-BC-NEXT:  blob data = 'Bc'
+  // CHECK-BC-NEXT:  blob data = '{{.*}}'
+  // CHECK-BC-NEXT: 
+  // CHECK-BC-NEXT:  blob data = 'A'
+  // CHECK-BC-NEXT:  blob data = 'B'
+// CHECK-BC-NEXT: 
+
+struct C { int i; };
+// CHECK-C: 
+  // CHECK-C-NEXT: 
+  // CHECK-C-NEXT:  blob data = 'C'
+  // CHECK-C-NEXT:  blob data = '{{.*}}'
+  // CHECK-C-NEXT: 
+// CHECK-C-NEXT: 
+  // CHECK-C-NEXT:  blob data = 'int'
+  // CHECK-C-NEXT: 
+// CHECK-C-NEXT: 
+// CHECK-C-NEXT:  blob data = 'i'
+// CHECK-C-NEXT: 
+  // CHECK-C-NEXT: 
+// CHECK-C-NEXT: 
+
+class D {};
+// CHECK-D: 
+  // CHECK-D-NEXT: 
+  // CHECK-D-NEXT:  blob data = 'D'
+  // CHECK-D-NEXT:  blob data = '{{.*}}'
+  // CHECK-D-NEXT: 
+// 

[PATCH] D47643: Rewrite JSON dispatcher loop using C IO (FILE*) instead of std::istream.

2018-06-01 Thread Sam McCall via Phabricator via cfe-commits
sammccall added a comment.

@malaperle: would you mind patching this in and checking whether attaching a 
debugger still works on Mac (this was the reason for the EINTR loop, right?)

I want to preserve this but now people other than me are complaining about old 
clangds hanging around and eating all their CPU :-)


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D47643



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


[PATCH] D47643: Rewrite JSON dispatcher loop using C IO (FILE*) instead of std::istream.

2018-06-01 Thread Sam McCall via Phabricator via cfe-commits
sammccall created this revision.
sammccall added reviewers: malaperle, ilya-biryukov.
Herald added subscribers: cfe-commits, jkorous, ioeric, klimek.

The EINTR loop around getline was added to fix an issue with mac gdb, but seems
to loop infinitely in rare cases on linux where the parent editor exits (most
reports with VSCode).
I can't work out how to fix this in a portable way with std::istream, but the
C APIs have clearer contracts and LLVM has a RetryAfterSignal function for use
with them which seems battle-tested.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D47643

Files:
  clangd/ClangdLSPServer.cpp
  clangd/ClangdLSPServer.h
  clangd/JSONRPCDispatcher.cpp
  clangd/JSONRPCDispatcher.h
  clangd/tool/ClangdMain.cpp
  test/clangd/too_large.test

Index: test/clangd/too_large.test
===
--- test/clangd/too_large.test
+++ test/clangd/too_large.test
@@ -4,4 +4,4 @@
 #
 Content-Length: 2147483648
 
-# STDERR: Skipped overly large message
+# STDERR: Refusing to read message
Index: clangd/tool/ClangdMain.cpp
===
--- clangd/tool/ClangdMain.cpp
+++ clangd/tool/ClangdMain.cpp
@@ -238,5 +238,5 @@
   llvm::set_thread_name("clangd.main");
   // Change stdin to binary to not lose \r\n on windows.
   llvm::sys::ChangeStdinToBinary();
-  return LSPServer.run(std::cin, InputStyle) ? 0 : NoShutdownRequestErrorCode;
+  return LSPServer.run(stdin, InputStyle) ? 0 : NoShutdownRequestErrorCode;
 }
Index: clangd/JSONRPCDispatcher.h
===
--- clangd/JSONRPCDispatcher.h
+++ clangd/JSONRPCDispatcher.h
@@ -102,7 +102,9 @@
 /// if it is.
 /// Input stream(\p In) must be opened in binary mode to avoid preliminary
 /// replacements of \r\n with \n.
-void runLanguageServerLoop(std::istream , JSONOutput ,
+/// We use C-style FILE* for reading as std::istream has unclear interaction
+/// with signals, which are sent by debuggers on some OSs.
+void runLanguageServerLoop(std::FILE *In, JSONOutput ,
JSONStreamStyle InputStyle,
JSONRPCDispatcher , bool );
 
Index: clangd/JSONRPCDispatcher.cpp
===
--- clangd/JSONRPCDispatcher.cpp
+++ clangd/JSONRPCDispatcher.cpp
@@ -14,6 +14,7 @@
 #include "llvm/ADT/SmallString.h"
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/Support/Chrono.h"
+#include "llvm/Support/Errno.h"
 #include "llvm/Support/SourceMgr.h"
 #include 
 
@@ -66,7 +67,7 @@
 Outs << "Content-Length: " << S.size() << "\r\n\r\n" << S;
 Outs.flush();
   }
-  log(llvm::Twine("--> ") + S);
+  log(llvm::Twine("--> ") + S + "\n");
 }
 
 void JSONOutput::log(const Twine ) {
@@ -180,47 +181,54 @@
   return true;
 }
 
-static llvm::Optional readStandardMessage(std::istream ,
+// Tries to read a line up to and including \n.
+// If failing, feof() or ferror() will be set.
+static bool readLine(std::FILE *In, std::string ) {
+  static constexpr int BufSize = 1024;
+  size_t Size = 0;
+  Out.clear();
+  for (;;) {
+Out.resize(Size + BufSize);
+// Handle EINTR which is sent when a debugger attaches on some platforms.
+if (!llvm::sys::RetryAfterSignal(nullptr, ::fgets, [Size], BufSize, In))
+  return false;
+size_t Read = std::strlen([Size]);
+if (Read < BufSize - 1) {
+  Out.resize(Size + Read);
+  return true;
+}
+Size += Read;
+  }
+}
+
+// Returns None when:
+//  - ferror() or feof() are set.
+//  - Content-Length is missing or empty (protocol error)
+static llvm::Optional readStandardMessage(std::FILE *In,
JSONOutput ) {
   // A Language Server Protocol message starts with a set of HTTP headers,
   // delimited  by \r\n, and terminated by an empty line (\r\n).
   unsigned long long ContentLength = 0;
-  while (In.good()) {
-std::string Line;
-std::getline(In, Line);
-if (!In.good() && errno == EINTR) {
-  In.clear();
-  continue;
-}
+  std::string Line;
+  while (true) {
+if (feof(In) || ferror(In) || !readLine(In, Line))
+  return llvm::None;
 
 Out.mirrorInput(Line);
-// Mirror '\n' that gets consumed by std::getline, but is not included in
-// the resulting Line.
-// Note that '\r' is part of Line, so we don't need to mirror it
-// separately.
-if (!In.eof())
-  Out.mirrorInput("\n");
-
 llvm::StringRef LineRef(Line);
 
 // We allow comments in headers. Technically this isn't part
 // of the LSP specification, but makes writing tests easier.
 if (LineRef.startswith("#"))
   continue;
 
-// Content-Type is a specified header, but does nothing.
-// Content-Length is a mandatory header. It specifies the length of the
-// following JSON.
-// It is unspecified what sequence headers must be supplied in, so we
-// allow any 

[PATCH] D45202: [X86] Replacing X86-specific floor and ceil vector intrinsics with generic LLVM intrinsics

2018-06-01 Thread Mikhail Dvoretckii via Phabricator via cfe-commits
mike.dvoretsky updated this revision to Diff 149484.
mike.dvoretsky added a comment.

Changed the scalar intrinsic lowering to work via extract-insert. 
https://reviews.llvm.org/D45203 contains tests for folding the resulting IR 
patterns.


https://reviews.llvm.org/D45202

Files:
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/avx-builtins.c
  clang/test/CodeGen/avx512f-builtins.c
  clang/test/CodeGen/sse41-builtins.c

Index: clang/test/CodeGen/sse41-builtins.c
===
--- clang/test/CodeGen/sse41-builtins.c
+++ clang/test/CodeGen/sse41-builtins.c
@@ -44,25 +44,31 @@
 
 __m128d test_mm_ceil_pd(__m128d x) {
   // CHECK-LABEL: test_mm_ceil_pd
-  // CHECK: call <2 x double> @llvm.x86.sse41.round.pd(<2 x double> %{{.*}}, i32 2)
+  // CHECK: @llvm.ceil.v2f64
+  // CHECK-NOT: select
   return _mm_ceil_pd(x);
 }
 
 __m128 test_mm_ceil_ps(__m128 x) {
   // CHECK-LABEL: test_mm_ceil_ps
-  // CHECK: call <4 x float> @llvm.x86.sse41.round.ps(<4 x float> %{{.*}}, i32 2)
+  // CHECK: @llvm.ceil.v4f32
+  // CHECK-NOT: select
   return _mm_ceil_ps(x);
 }
 
 __m128d test_mm_ceil_sd(__m128d x, __m128d y) {
   // CHECK-LABEL: test_mm_ceil_sd
-  // CHECK: call <2 x double> @llvm.x86.sse41.round.sd(<2 x double> %{{.*}}, <2 x double> %{{.*}}, i32 2)
+  // CHECK: extractelement
+  // CHECK: @llvm.ceil.f64
+  // CHECK: insertelement
   return _mm_ceil_sd(x, y);
 }
 
 __m128 test_mm_ceil_ss(__m128 x, __m128 y) {
   // CHECK-LABEL: test_mm_ceil_ss
-  // CHECK: call <4 x float> @llvm.x86.sse41.round.ss(<4 x float> %{{.*}}, <4 x float> %{{.*}}, i32 2)
+  // CHECK: extractelement
+  // CHECK: @llvm.ceil.f32
+  // CHECK: insertelement
   return _mm_ceil_ss(x, y);
 }
 
@@ -196,25 +202,31 @@
 
 __m128d test_mm_floor_pd(__m128d x) {
   // CHECK-LABEL: test_mm_floor_pd
-  // CHECK: call <2 x double> @llvm.x86.sse41.round.pd(<2 x double> %{{.*}}, i32 1)
+  // CHECK: @llvm.floor.v2f64
+  // CHECK-NOT: select
   return _mm_floor_pd(x);
 }
 
 __m128 test_mm_floor_ps(__m128 x) {
   // CHECK-LABEL: test_mm_floor_ps
-  // CHECK: call <4 x float> @llvm.x86.sse41.round.ps(<4 x float> %{{.*}}, i32 1)
+  // CHECK: @llvm.floor.v4f32
+  // CHECK-NOT: select
   return _mm_floor_ps(x);
 }
 
 __m128d test_mm_floor_sd(__m128d x, __m128d y) {
   // CHECK-LABEL: test_mm_floor_sd
-  // CHECK: call <2 x double> @llvm.x86.sse41.round.sd(<2 x double> %{{.*}}, <2 x double> %{{.*}}, i32 1)
+  // CHECK: extractelement
+  // CHECK: @llvm.floor.f64
+  // CHECK: insertelement
   return _mm_floor_sd(x, y);
 }
 
 __m128 test_mm_floor_ss(__m128 x, __m128 y) {
   // CHECK-LABEL: test_mm_floor_ss
-  // CHECK: call <4 x float> @llvm.x86.sse41.round.ss(<4 x float> %{{.*}}, <4 x float> %{{.*}}, i32 1)
+  // CHECK: extractelement
+  // CHECK: @llvm.floor.f32
+  // CHECK: insertelement
   return _mm_floor_ss(x, y);
 }
 
Index: clang/test/CodeGen/avx512f-builtins.c
===
--- clang/test/CodeGen/avx512f-builtins.c
+++ clang/test/CodeGen/avx512f-builtins.c
@@ -7565,46 +7565,98 @@
   return _mm512_min_round_ps(__A,__B,_MM_FROUND_CUR_DIRECTION);
 }
 
+__m512 test_mm512_floor_ps(__m512 __A)
+{
+  // CHECK-LABEL: @test_mm512_floor_ps
+  // CHECK: @llvm.floor.v16f32
+  // CHECK-NOT: select
+  return _mm512_floor_ps(__A);
+}
+
+__m512d test_mm512_floor_pd(__m512d __A)
+{
+  // CHECK-LABEL: @test_mm512_floor_pd
+  // CHECK: @llvm.floor.v8f64
+  // CHECK-NOT: select
+  return _mm512_floor_pd(__A);
+}
+
 __m512 test_mm512_mask_floor_ps (__m512 __W, __mmask16 __U, __m512 __A)
 {
-  // CHECK-LABEL: @test_mm512_mask_floor_ps 
-  // CHECK: @llvm.x86.avx512.mask.rndscale.ps.512
+  // CHECK-LABEL: @test_mm512_mask_floor_ps
+  // CHECK: @llvm.floor.v16f32
+  // CHECK: select <16 x i1> %{{.*}}, <16 x float> %{{.*}}, <16 x float> %{{.*}}
   return _mm512_mask_floor_ps (__W,__U,__A);
 }
 
 __m512d test_mm512_mask_floor_pd (__m512d __W, __mmask8 __U, __m512d __A)
 {
-  // CHECK-LABEL: @test_mm512_mask_floor_pd 
-  // CHECK: @llvm.x86.avx512.mask.rndscale.pd.512
+  // CHECK-LABEL: @test_mm512_mask_floor_pd
+  // CHECK: @llvm.floor.v8f64
+  // CHECK: select <8 x i1> %{{.*}}, <8 x double> %{{.*}}, <8 x double> %{{.*}}
   return _mm512_mask_floor_pd (__W,__U,__A);
 }
 
+__m512 test_mm512_ceil_ps(__m512 __A)
+{
+  // CHECK-LABEL: @test_mm512_ceil_ps
+  // CHECK: @llvm.ceil.v16f32
+  // CHECK-NOT: select
+  return _mm512_ceil_ps(__A);
+}
+
+__m512d test_mm512_ceil_pd(__m512d __A)
+{
+  // CHECK-LABEL: @test_mm512_ceil_pd
+  // CHECK: @llvm.ceil.v8f64
+  // CHECK-NOT: select
+  return _mm512_ceil_pd(__A);
+}
+
 __m512 test_mm512_mask_ceil_ps (__m512 __W, __mmask16 __U, __m512 __A)
 {
-  // CHECK-LABEL: @test_mm512_mask_ceil_ps 
-  // CHECK: @llvm.x86.avx512.mask.rndscale.ps.512
+  // CHECK-LABEL: @test_mm512_mask_ceil_ps
+  // CHECK: @llvm.ceil.v16f32
+  // CHECK: select <16 x i1> %{{.*}}, <16 x float> %{{.*}}, <16 x float> %{{.*}}
   return _mm512_mask_ceil_ps (__W,__U,__A);
 }

[PATCH] D47628: Detect an incompatible VLA pointer assignment

2018-06-01 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added inline comments.



Comment at: lib/AST/ASTContext.cpp:8588
+  Expr *E = VAT->getSizeExpr();
+  if (E && VAT->getSizeExpr()->isIntegerConstantExpr(TheInt, *this))
+return std::make_pair(true, TheInt);

`E && E->isIntegerConstantExpr`?



Comment at: lib/AST/ASTContext.cpp:8603
+  std::tie(HaveRSize, RSize) = SizeFetch(RVAT, RCAT);
+  if (HaveLSize && HaveRSize && LSize != RSize)
+return {}; // Definite, but unequal, array dimension

The != will hit an assertion failure if LSize and RSize don't have the same 
bitwidth.


Repository:
  rC Clang

https://reviews.llvm.org/D47628



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


[PATCH] D45532: [StaticAnalyzer] Checker to find uninitialized fields after a constructor call

2018-06-01 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun added inline comments.



Comment at: lib/StaticAnalyzer/Checkers/UninitializedObjectChecker.cpp:223-225
+  ExplodedNode *Node = Context.generateNonFatalErrorNode(Context.getState());
+  if (!Node)
+return;

Szelethus wrote:
> NoQ wrote:
> > Szelethus wrote:
> > > NoQ wrote:
> > > > I suspect that a fatal error is better here. We don't want the user to 
> > > > receive duplicate report from other checkers that catch uninitialized 
> > > > values; just one report is enough.
> > > I think that would be a bad idea. For example, this checker shouts so 
> > > loudly while checking the LLVM project, it would practically halt the 
> > > analysis of the code, reducing the coverage, which means that checkers 
> > > other then uninit value checkers would "suffer" from it.
> > > 
> > > However, I also think that having multiple uninit reports for the same 
> > > object might be good, especially with this checker, as it would be very 
> > > easy to see where the problem originated from.
> > > 
> > > What do you think?
> > Well, i guess that's the reason to not use the checker on LLVM. Regardless 
> > of fatal/nonfatal warnings, enabling this checker on LLVM regularly would 
> > be a bad idea because it's unlikely that anybody will be able to fix all 
> > the false positives to make it usable. And for other projects that don't 
> > demonstrate many false positives, this shouldn't be a problem.
> > 
> > In order to indicate where the problem originates from, we have our bug 
> > reporter visitors that try their best to add such info directly to the 
> > report. In particular, @george.karpenkov's recent `NoStoreFuncVisitor` 
> > highlights functions in which a variable was //not// initialized but was 
> > probably expected to be. Not sure if it highlights constructors in its 
> > current shape, but that's definitely a better way to give this piece of 
> > information to the user because it doesn't make the user look for a 
> > different report to understand the current report.
> LLVM is a special project in the fact that almost every part of it is so 
> performance critical, that leaving many fields uninit matters. However, I 
> would believe that in most projects, only a smaller portion of the code would 
> be like that.
> 
> Suppose that we have a project that also defines a set of ADTs, like an 
> `std::list`-like container. If that container had a field that would be left 
> uninit after a ctor call, analysis on every execution path would be halted 
> which would use an object like that.
> 
> My point is, as long as there is no way to tell the analyzer (or the checker) 
> to ignore certain constructor calls, I think it would be best not to generate 
> a fatal error.
> 
> >Regardless of fatal/nonfatal warnings, enabling this checker on LLVM 
> >regularly would be a bad idea because it's unlikely that anybody will be 
> >able to fix all the false positives to make it usable. And for other 
> >projects that don't demonstrate many false positives, this shouldn't be a 
> >problem.
> I wouldn't necessarily call them false positives. This checker doesn't look 
> for bugs, and all reports I checked were correct in the fact that those 
> fields really were left uninit. They just don't cause any trouble (just yet!).
I think of this check as a tool to support a specific programming model where 
every field needs to be initialized by the constructor. This programming model 
might be followed by some parts of the projects while a 3rd party library in 
the same project or some other files might not follow this model. Right now 
there is no easy way to turn off some checks for a set of files, and there is 
no way to turn off a set of checks for some headers. For this reason, I think 
it is not a good idea to make these errors fatal, as 3rd party headers might 
reduce the coverage of the analysis on a project in a way that the user cannot 
control.

If we are afraid of having multiple reports from this check we could turn off 
the check for that particular path, for example, we could have a bool stored in 
the GDM for each path whether this check is already reported an error or not 
and we can check that before emitting warnings. 


https://reviews.llvm.org/D45532



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


[PATCH] D46421: [analyzer][CrossTU] Extend CTU to VarDecls with initializer

2018-06-01 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun added a comment.

Sorry for the limited activity. Unfortunately, I have very little time 
reviewing patches lately.
I think we need to answer the following questions:

- Does this change affect the analysis of the constructors of global objects? 
If so, how?
- Do we want to import non-const object's initializer expressions? The analyzer 
might not end up using the value anyways.
- How big can the index get with this modification for large projects?

Overall the direction looks good to me, this will be a very useful addition, 
thanks for working on this.


https://reviews.llvm.org/D46421



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


[PATCH] D47480: clang-cl: Expose -no-canonical-prefixes

2018-06-01 Thread Nico Weber via Phabricator via cfe-commits
thakis marked 2 inline comments as done.
thakis added inline comments.



Comment at: test/Driver/cl-options.c:595
+// RUN: -no-canonical-prefixes \
+// RUN: -fno-coverage-mapping \
 // RUN: --version \

rnk wrote:
> takuto.ikuta wrote:
> > Is this related to this change?
> It's a test for a previous change that I made.
Sorry, I missed this. It was a mistake, I removed this line again in r333762.


https://reviews.llvm.org/D47480



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


[PATCH] D47630: [Sema] Allow creating types with multiple of the same addrspace.

2018-06-01 Thread Bevin Hansson via Phabricator via cfe-commits
ebevhan added inline comments.



Comment at: test/Sema/address_spaces.c:17
   int *_AS1 _AS2 *Z;  // expected-error {{multiple address spaces specified 
for type}}
+  int *_AS1 _AS1 *M;
 

bader wrote:
> I think it might be valuable to give a warning or remark to user. 
> Using the same address space qualifier multiple times is not something OpenCL 
> C developers are supposed to do.
> 
The test is obviously a bit contrived, but it could happen by mistake, or as a 
result of some typedef or macro combination. It also cannot go wrong, so 
there's no harm in it happening.

I see your point, though. A warning feels like a bit much, so I'm not sure what 
else to use. A note?


Repository:
  rC Clang

https://reviews.llvm.org/D47630



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


r333762 - Remove redundant -fno-coverage-mapping added in r333761 (already added in r333423)

2018-06-01 Thread Nico Weber via cfe-commits
Author: nico
Date: Fri Jun  1 08:02:43 2018
New Revision: 333762

URL: http://llvm.org/viewvc/llvm-project?rev=333762=rev
Log:
Remove redundant -fno-coverage-mapping added in r333761 (already added in 
r333423)

Modified:
cfe/trunk/test/Driver/cl-options.c

Modified: cfe/trunk/test/Driver/cl-options.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/cl-options.c?rev=333762=333761=333762=diff
==
--- cfe/trunk/test/Driver/cl-options.c (original)
+++ cfe/trunk/test/Driver/cl-options.c Fri Jun  1 08:02:43 2018
@@ -592,7 +592,6 @@
 // RUN: -flto \
 // RUN: -fmerge-all-constants \
 // RUN: -no-canonical-prefixes \
-// RUN: -fno-coverage-mapping \
 // RUN: --version \
 // RUN: -Werror /Zs -- %s 2>&1
 


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


[PATCH] D47480: clang-cl: Expose -no-canonical-prefixes

2018-06-01 Thread Nico Weber via Phabricator via cfe-commits
thakis closed this revision.
thakis added a comment.

r333761, thanks!


https://reviews.llvm.org/D47480



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


[PATCH] D47394: [OpenMP][Clang][NVPTX] Replace bundling with partial linking for the OpenMP NVPTX device offloading toolchain

2018-06-01 Thread Jonas Hahnfeld via Phabricator via cfe-commits
Hahnfeld added a comment.

Hmm, maybe the scope is much larger: I just tried linking an executable that 
references a `declare target` function in a shared library. My assumption was 
that this already works, given that `libomptarget`'s registration functions can 
be called multiple times. Am I doing something wrong?


Repository:
  rC Clang

https://reviews.llvm.org/D47394



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


r333761 - clang-cl: Expose -no-canonical-prefixes

2018-06-01 Thread Nico Weber via cfe-commits
Author: nico
Date: Fri Jun  1 07:59:57 2018
New Revision: 333761

URL: http://llvm.org/viewvc/llvm-project?rev=333761=rev
Log:
clang-cl: Expose -no-canonical-prefixes

-no-canonical-prefixes is a weird flag: In gcc, it controls whether realpath()
is called on the path of the driver binary. It's needed to support some
usecases where gcc is symlinked to, see
https://gcc.gnu.org/ml/gcc/2011-01/msg00429.html for some background.

In clang, the resource dir is found relative to the compiler binary, and
without -no-canonical-prefixes that's an absolute path. For clang, the main use
case for -no-canonical-prefixes is to make the -resource-dir path added by the
driver relative instead of absolute. Making it relative seems like the better
default, but since neither clang not gcc have -canonical-prefixes without no-
which makes changing the default tricky, and since some symlink behaviors do
depend on the realpath() call at least for gcc, just expose
-no-canonical-prefixes in clang-cl mode.

Alternatively we could default to no-canonical-prefix-mode for clang-cl since
it's less likely to be used in symlinked scenarios, but since you already need
to about -no-canonical-prefixes for the non-clang-cl bits of your build, not
hooking this of driver mode seems better to me.

https://reviews.llvm.org/D47480

Modified:
cfe/trunk/include/clang/Driver/Options.td
cfe/trunk/test/Driver/cl-options.c

Modified: cfe/trunk/include/clang/Driver/Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=333761=333760=333761=diff
==
--- cfe/trunk/include/clang/Driver/Options.td (original)
+++ cfe/trunk/include/clang/Driver/Options.td Fri Jun  1 07:59:57 2018
@@ -2261,7 +2261,7 @@ def multi__module : Flag<["-"], "multi_m
 def multiply__defined__unused : Separate<["-"], "multiply_defined_unused">;
 def multiply__defined : Separate<["-"], "multiply_defined">;
 def mwarn_nonportable_cfstrings : Flag<["-"], "mwarn-nonportable-cfstrings">, 
Group;
-def no_canonical_prefixes : Flag<["-"], "no-canonical-prefixes">, 
Flags<[HelpHidden]>,
+def no_canonical_prefixes : Flag<["-"], "no-canonical-prefixes">, 
Flags<[HelpHidden, CoreOption]>,
   HelpText<"Use relative instead of canonical paths">;
 def no_cpp_precomp : Flag<["-"], "no-cpp-precomp">, 
Group;
 def no_integrated_cpp : Flag<["-", "--"], "no-integrated-cpp">, 
Flags<[DriverOption]>;

Modified: cfe/trunk/test/Driver/cl-options.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/cl-options.c?rev=333761=333760=333761=diff
==
--- cfe/trunk/test/Driver/cl-options.c (original)
+++ cfe/trunk/test/Driver/cl-options.c Fri Jun  1 07:59:57 2018
@@ -591,6 +591,8 @@
 // RUN: -flimit-debug-info \
 // RUN: -flto \
 // RUN: -fmerge-all-constants \
+// RUN: -no-canonical-prefixes \
+// RUN: -fno-coverage-mapping \
 // RUN: --version \
 // RUN: -Werror /Zs -- %s 2>&1
 


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


[clang-tools-extra] r333758 - [clangd] Compute better estimates for memory usage of the AST

2018-06-01 Thread Ilya Biryukov via cfe-commits
Author: ibiryukov
Date: Fri Jun  1 07:44:57 2018
New Revision: 333758

URL: http://llvm.org/viewvc/llvm-project?rev=333758=rev
Log:
[clangd] Compute better estimates for memory usage of the AST

Also fix the return value of IdleASTs::getUsedBytes().
It was 'bool' instead of 'size_t' *facepalm*.

Modified:
clang-tools-extra/trunk/clangd/ClangdUnit.cpp
clang-tools-extra/trunk/clangd/TUScheduler.cpp

Modified: clang-tools-extra/trunk/clangd/ClangdUnit.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdUnit.cpp?rev=333758=333757=333758=diff
==
--- clang-tools-extra/trunk/clangd/ClangdUnit.cpp (original)
+++ clang-tools-extra/trunk/clangd/ClangdUnit.cpp Fri Jun  1 07:44:57 2018
@@ -220,8 +220,32 @@ std::size_t ParsedAST::getUsedBytes() co
   auto  = getASTContext();
   // FIXME(ibiryukov): we do not account for the dynamically allocated part of
   // Message and Fixes inside each diagnostic.
-  return AST.getASTAllocatedMemory() + AST.getSideTableAllocatedMemory() +
- ::getUsedBytes(LocalTopLevelDecls) + ::getUsedBytes(Diags);
+  std::size_t Total =
+  ::getUsedBytes(LocalTopLevelDecls) + ::getUsedBytes(Diags);
+
+  // FIXME: the rest of the function is almost a direct copy-paste from
+  // libclang's clang_getCXTUResourceUsage. We could share the implementation.
+
+  // Sum up variaous allocators inside the ast context and the preprocessor.
+  Total += AST.getASTAllocatedMemory();
+  Total += AST.getSideTableAllocatedMemory();
+  Total += AST.Idents.getAllocator().getTotalMemory();
+  Total += AST.Selectors.getTotalMemory();
+
+  Total += AST.getSourceManager().getContentCacheSize();
+  Total += AST.getSourceManager().getDataStructureSizes();
+  Total += AST.getSourceManager().getMemoryBufferSizes().malloc_bytes;
+
+  if (ExternalASTSource *Ext = AST.getExternalSource())
+Total += Ext->getMemoryBufferSizes().malloc_bytes;
+
+  const Preprocessor  = getPreprocessor();
+  Total += PP.getTotalMemory();
+  if (PreprocessingRecord *PRec = PP.getPreprocessingRecord())
+Total += PRec->getTotalMemory();
+  Total += PP.getHeaderSearchInfo().getTotalMemory();
+
+  return Total;
 }
 
 const std::vector ::getInclusions() const {

Modified: clang-tools-extra/trunk/clangd/TUScheduler.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/TUScheduler.cpp?rev=333758=333757=333758=diff
==
--- clang-tools-extra/trunk/clangd/TUScheduler.cpp (original)
+++ clang-tools-extra/trunk/clangd/TUScheduler.cpp Fri Jun  1 07:44:57 2018
@@ -75,7 +75,7 @@ public:
 
   /// Returns result of getUsedBytes() for the AST cached by \p K.
   /// If no AST is cached, 0 is returned.
-  bool getUsedBytes(Key K) {
+  std::size_t getUsedBytes(Key K) {
 std::lock_guard Lock(Mut);
 auto It = findByKey(K);
 if (It == LRU.end() || !It->second)


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


r333757 - [OpenMP] Fix typo in NVPTX linker, NFC.

2018-06-01 Thread Jonas Hahnfeld via cfe-commits
Author: hahnfeld
Date: Fri Jun  1 07:43:48 2018
New Revision: 333757

URL: http://llvm.org/viewvc/llvm-project?rev=333757=rev
Log:
[OpenMP] Fix typo in NVPTX linker, NFC.

Clang calls "nvlink" for linking multiple object files with OpenMP
target functions, so correct this information when printing errors.

Modified:
cfe/trunk/lib/Driver/ToolChains/Cuda.h

Modified: cfe/trunk/lib/Driver/ToolChains/Cuda.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Cuda.h?rev=333757=333756=333757=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Cuda.h (original)
+++ cfe/trunk/lib/Driver/ToolChains/Cuda.h Fri Jun  1 07:43:48 2018
@@ -115,7 +115,7 @@ class LLVM_LIBRARY_VISIBILITY Linker : p
 class LLVM_LIBRARY_VISIBILITY OpenMPLinker : public Tool {
  public:
OpenMPLinker(const ToolChain )
-   : Tool("NVPTX::OpenMPLinker", "fatbinary", TC, RF_Full, 
llvm::sys::WEM_UTF8,
+   : Tool("NVPTX::OpenMPLinker", "nvlink", TC, RF_Full, 
llvm::sys::WEM_UTF8,
   "--options-file") {}
 
bool hasIntegratedCPP() const override { return false; }


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


[PATCH] D47623: [clangd] Avoid indexing decls associated with friend decls.

2018-06-01 Thread Eric Liu via Phabricator via cfe-commits
ioeric added inline comments.



Comment at: clangd/index/SymbolCollector.cpp:297
+// If OrigD is an object of a friend declaration, skip it.
+if (ASTNode.OrigD->getFriendObjectKind() !=
+Decl::FriendObjectKind::FOK_None)

sammccall wrote:
> ioeric wrote:
> > sammccall wrote:
> > > this seems suspect, we're going to treat the third decl in `friend X; X; 
> > > friend X` differently from that in `X; friend X; friend X;`.
> > > 
> > > Why? i.e. why is the inner check necessary and why does it treat the 
> > > original (meaning first, I think) decl specially?
> > > this seems suspect, we're going to treat the third decl in `friend X; X; 
> > > friend X` differently from that in `X; friend X; friend X;`.
> > I'm not very sure if I understand the problem. But I'll try to explain what 
> > would happen for these two examples.
> > - For the first example, the first friend decl will be the canonical decl, 
> > and we would only index the second `X` since its `OrigD` is not in friend 
> > decl. Both the first and third friend decl will not be indexed. 
> > - For the second example, the first non-friend `X` will be the canonical 
> > decl, and all three occurrences will have the same `D` pointing to it. This 
> > probably means that the same X will be processed three times, but it's 
> > probably fine (we might want to optimize it). 
> > 
> > Basically, `D` is always the canonical declaration in AST and `OrigD` is  
> > the declaration that the indexer is currently visiting. I agree it's 
> > confusing...
> > 
> > > Why? i.e. why is the inner check necessary and why does it treat the 
> > > original (meaning first, I think) decl specially?
> > 
> > The inner check handles the following case:
> > ```
> > class X {
> >   friend void foo();
> > }
> > void foo();
> > ```
> > 
> > There will be two occurrences of `foo` in the index:
> > 1. The friend decl, where `D` will be the canonical decl (i.e. friend foo) 
> > and `OrigD` will also be friend foo.
> > 2. The non-friend decl, where `D` will still be the canonical decl (i.e. 
> > friend foo) and `OrigD` is now the non-friend decl.
> > Basically, D is always the canonical declaration in AST and OrigD is the 
> > declaration that the indexer is currently visiting. I agree it's 
> > confusing...
> 
> Whoops, I had this backwards. So I guess I mean the outer check.
> Fundamentally my question is: in an *arbitrary* list of redecls of a symbol, 
> what is special about the canonical declaration (D, which is just the first 
> in the list) that we particularly care whether it's a friend?
> I would expect that either we're ignoring the other redecls, or we're looping 
> over all redecls.
> 
> And here, I think we could just skip all friend decls (that are not 
> definitions), regardless of what `D->getFriendObjectKind()` is. If we have 
> other decls, the symbol was indexed already. If we do not, then we don't want 
> to index it anyway.
> Fundamentally my question is: in an *arbitrary* list of redecls of a symbol, 
> what is special about the canonical declaration (D, which is just the first 
> in the list) that we particularly care whether it's a friend?
It's because we have chosen to use `D` as a symbol's canonical declaration 
(line 332). Here we want to override the canonical declaration `D` when it's a 
friend decl, so that the first non-friend decl would become the canonical 
declaration of the symbol.

> And here, I think we could just skip all friend decls (that are not 
> definitions), regardless of what D->getFriendObjectKind() is. 
OK. I think I understand where the confusion came from now. The override of `D` 
should've been a separate check:
```
if (OrigD is non-definition friend)
  skip;
if (D is friend decl)
  D = OrigD;
```


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D47623



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


[PATCH] D47623: [clangd] Avoid indexing decls associated with friend decls.

2018-06-01 Thread Eric Liu via Phabricator via cfe-commits
ioeric updated this revision to Diff 149465.
ioeric added a comment.

- Clarify.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D47623

Files:
  clangd/index/SymbolCollector.cpp
  unittests/clangd/SymbolCollectorTests.cpp


Index: unittests/clangd/SymbolCollectorTests.cpp
===
--- unittests/clangd/SymbolCollectorTests.cpp
+++ unittests/clangd/SymbolCollectorTests.cpp
@@ -812,6 +812,31 @@
QName("nx::Kind"), QName("nx::Kind_Fine")));
 }
 
+TEST_F(SymbolCollectorTest, DoNotIndexSymbolsInFriendDecl) {
+  Annotations Header(R"(
+namespace nx {
+  class $z[[Z]] {};
+  class X {
+friend class Y;
+friend class Z;
+friend void foo();
+friend void $bar[[bar]]() {}
+  };
+  class $y[[Y]] {};
+  void $foo[[foo]]();
+}
+  )");
+  runSymbolCollector(Header.code(), /*Main=*/"");
+
+  EXPECT_THAT(Symbols,
+  UnorderedElementsAre(
+  QName("nx"), QName("nx::X"),
+  AllOf(QName("nx::Y"), DeclRange(Header.range("y"))),
+  AllOf(QName("nx::Z"), DeclRange(Header.range("z"))),
+  AllOf(QName("nx::foo"), DeclRange(Header.range("foo"))),
+  AllOf(QName("nx::bar"), DeclRange(Header.range("bar");
+}
+
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clangd/index/SymbolCollector.cpp
===
--- clangd/index/SymbolCollector.cpp
+++ clangd/index/SymbolCollector.cpp
@@ -290,6 +290,18 @@
 index::IndexDataConsumer::ASTNodeInfo ASTNode) {
   assert(ASTCtx && PP.get() && "ASTContext and Preprocessor must be set.");
   assert(CompletionAllocator && CompletionTUInfo);
+  assert(ASTNode.OrigD);
+  // If OrigD is an declaration associated with a friend declaration and it's
+  // not a definition, skip it. Note that OrigD is the occurrence that the
+  // collector is currently visiting.
+  if ((ASTNode.OrigD->getFriendObjectKind() !=
+   Decl::FriendObjectKind::FOK_None) &&
+  !(Roles & static_cast(index::SymbolRole::Definition)))
+return true;
+  // A declaration created for a friend declaration should not be used as the
+  // canonical declaration in the index.
+  if (D->getFriendObjectKind() != Decl::FriendObjectKind::FOK_None)
+D = ASTNode.OrigD;
   const NamedDecl *ND = llvm::dyn_cast(D);
   if (!ND)
 return true;


Index: unittests/clangd/SymbolCollectorTests.cpp
===
--- unittests/clangd/SymbolCollectorTests.cpp
+++ unittests/clangd/SymbolCollectorTests.cpp
@@ -812,6 +812,31 @@
QName("nx::Kind"), QName("nx::Kind_Fine")));
 }
 
+TEST_F(SymbolCollectorTest, DoNotIndexSymbolsInFriendDecl) {
+  Annotations Header(R"(
+namespace nx {
+  class $z[[Z]] {};
+  class X {
+friend class Y;
+friend class Z;
+friend void foo();
+friend void $bar[[bar]]() {}
+  };
+  class $y[[Y]] {};
+  void $foo[[foo]]();
+}
+  )");
+  runSymbolCollector(Header.code(), /*Main=*/"");
+
+  EXPECT_THAT(Symbols,
+  UnorderedElementsAre(
+  QName("nx"), QName("nx::X"),
+  AllOf(QName("nx::Y"), DeclRange(Header.range("y"))),
+  AllOf(QName("nx::Z"), DeclRange(Header.range("z"))),
+  AllOf(QName("nx::foo"), DeclRange(Header.range("foo"))),
+  AllOf(QName("nx::bar"), DeclRange(Header.range("bar");
+}
+
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clangd/index/SymbolCollector.cpp
===
--- clangd/index/SymbolCollector.cpp
+++ clangd/index/SymbolCollector.cpp
@@ -290,6 +290,18 @@
 index::IndexDataConsumer::ASTNodeInfo ASTNode) {
   assert(ASTCtx && PP.get() && "ASTContext and Preprocessor must be set.");
   assert(CompletionAllocator && CompletionTUInfo);
+  assert(ASTNode.OrigD);
+  // If OrigD is an declaration associated with a friend declaration and it's
+  // not a definition, skip it. Note that OrigD is the occurrence that the
+  // collector is currently visiting.
+  if ((ASTNode.OrigD->getFriendObjectKind() !=
+   Decl::FriendObjectKind::FOK_None) &&
+  !(Roles & static_cast(index::SymbolRole::Definition)))
+return true;
+  // A declaration created for a friend declaration should not be used as the
+  // canonical declaration in the index.
+  if (D->getFriendObjectKind() != Decl::FriendObjectKind::FOK_None)
+D = ASTNode.OrigD;
   const NamedDecl *ND = llvm::dyn_cast(D);
   if (!ND)
 return true;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D47630: [Sema] Allow creating types with multiple of the same addrspace.

2018-06-01 Thread Alexey Bader via Phabricator via cfe-commits
bader added inline comments.



Comment at: test/Sema/address_spaces.c:17
   int *_AS1 _AS2 *Z;  // expected-error {{multiple address spaces specified 
for type}}
+  int *_AS1 _AS1 *M;
 

I think it might be valuable to give a warning or remark to user. 
Using the same address space qualifier multiple times is not something OpenCL C 
developers are supposed to do.



Repository:
  rC Clang

https://reviews.llvm.org/D47630



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


r333752 - Fix unused variable warning from r333718

2018-06-01 Thread Erich Keane via cfe-commits
Author: erichkeane
Date: Fri Jun  1 07:16:18 2018
New Revision: 333752

URL: http://llvm.org/viewvc/llvm-project?rev=333752=rev
Log:
Fix unused variable warning from r333718 

Modified:
cfe/trunk/lib/Lex/ModuleMap.cpp

Modified: cfe/trunk/lib/Lex/ModuleMap.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/ModuleMap.cpp?rev=333752=333751=333752=diff
==
--- cfe/trunk/lib/Lex/ModuleMap.cpp (original)
+++ cfe/trunk/lib/Lex/ModuleMap.cpp Fri Jun  1 07:16:18 2018
@@ -234,7 +234,7 @@ const FileEntry *ModuleMap::findHeader(
 // framework style path.
 FullPathName.assign(Directory->getName());
 RelativePathName.clear();
-if (auto *FrameworkHdr = GetFrameworkFile()) {
+if (GetFrameworkFile()) {
   Diags.Report(Header.FileNameLoc,
diag::warn_mmap_incomplete_framework_module_declaration)
   << Header.FileName << M->getFullModuleName();


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


[PATCH] D44826: Add -Wunused-using, a warning that finds unused using declarations.

2018-06-01 Thread Carlos Alberto Enciso via Phabricator via cfe-commits
CarlosAlbertoEnciso added inline comments.



Comment at: include/clang/Basic/DiagnosticSemaKinds.td:282-290
+def warn_unused_using_declaration : Warning<
+  "unused using declaration %0">,
+  InGroup, DefaultIgnore;
+def warn_unused_using_directive : Warning<
+  "unused using directive %0">,
+  InGroup, DefaultIgnore;
+def warn_unused_using_alias : Warning<

lebedev.ri wrote:
> JFYI you can condense it down to just
> ```
> def warn_unused_using_declaration : Warning<
>   "unused %select{using declaration|using directive|namespace alias}0 %1">,
>   InGroup, DefaultIgnore;
> ```
> if that simplifies the code that actually emits that warning.
Thanks for the suggestion.

I will have a look at it and see if that simplifies the code that emits the 
warning.


https://reviews.llvm.org/D44826



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


[PATCH] D47394: [OpenMP][Clang][NVPTX] Replace bundling with partial linking for the OpenMP NVPTX device offloading toolchain

2018-06-01 Thread Jonas Hahnfeld via Phabricator via cfe-commits
Hahnfeld added a comment.

In https://reviews.llvm.org/D47394#1118957, @gtbercea wrote:

>   I'm surprised you now disagree with this technique, when I first introduced 
> you to this in an e-mail off list you agreed with it.


My words were `I agree this is the best solution for NVPTX.` In the same reply 
I asked how your proposal is supposed to work for other offloading targets 
which is now clear to require additional work, maybe even completely novel 
tools.
So now I disagree that it is the **right** solution for Clang because I think 
my proposal will cover all offloading targets. Please give me a bit time so 
that I can see if it works.


Repository:
  rC Clang

https://reviews.llvm.org/D47394



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


[PATCH] D46845: [libcxx][c++17] P0083R5: Splicing Maps and Sets

2018-06-01 Thread Erik Pilkington via Phabricator via cfe-commits
erik.pilkington added inline comments.



Comment at: libcxx/include/__hash_table:2261
+_NodeHandle
+__hash_table<_Tp, _Hash, _Equal, _Alloc>::__node_handle_extract_unique(
+key_type const& __key)

EricWF wrote:
> If I'm not mistaken, `__node_handle_extract_unique` and 
> `__node_handle_extract_multi` have the exact same implementation. This is 
> intentional, no? If so can't we just use one implementation? 
Yep, good point. The new patch just has `__node_handle_extract`.


https://reviews.llvm.org/D46845



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


[PATCH] D47480: clang-cl: Expose -no-canonical-prefixes

2018-06-01 Thread Takuto Ikuta via Phabricator via cfe-commits
takuto.ikuta accepted this revision.
takuto.ikuta added a comment.

I confirmed this CL and https://reviews.llvm.org/D47578 remove absolute path 
from /showIncludes when include paths are given in relative.


https://reviews.llvm.org/D47480



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


[PATCH] D47394: [OpenMP][Clang][NVPTX] Replace bundling with partial linking for the OpenMP NVPTX device offloading toolchain

2018-06-01 Thread Gheorghe-Teodor Bercea via Phabricator via cfe-commits
gtbercea added a comment.



> I disagree in this context because this patch currently means that static 
> archives will only work with NVPTX and there is no clear path how to "fix" 
> things for other offloading targets. I'll try to work on my proposal over the 
> next few days (sorry, very busy week...), maybe I can put together a 
> prototype of my idea.

Other toolchains can also have static linking if they:

1. ditch the clang-offload-bundler for generating/consuming object files.
2. implement a link step on the device toolchain which can identify the vendor 
specific object file inside the host object file. (this is how the so called 
"bunlding" should have been done in the first place not using a custom tool 
which limits the functionality of the compiler). Identifying toolchain-specific 
objects/binaries is a task that belongs within the device-specific toolchain 
and SHOULD NOT be factored out because you can't treat object that are 
different by definition in the same way. Ignoring their differences leads to 
those object not being link-able. On top of that, factoring out introduces 
custom object formats which only CLANG understands AND it introduces 
compilation steps that impede static linking.

I'm surprised you now disagree with this technique, when I first introduced you 
to this in an e-mail off list you agreed with it.

So this patch, the only new CUDA tool that it calls is the FATBINARY tool which 
is done on the device-specific side of the toolchain so you can't possibly 
object to that. The CUDA toolchain already calls FATBINARY so it's not a 
novelty. That step is essential to making device-side objects identifiable by 
NVLINK (which we already call).

The only step you might object to is the partial linking step which, as I 
explained in my original post, I envisage will be improved over time as more 
toolchains support this scheme. I think this is a true solution to the problem. 
What you are proposing is a workaround that doesn't tackle the problem head-on.


Repository:
  rC Clang

https://reviews.llvm.org/D47394



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


[PATCH] D47623: [clangd] Avoid indexing decls associated with friend decls.

2018-06-01 Thread Eric Liu via Phabricator via cfe-commits
ioeric added inline comments.



Comment at: clangd/index/SymbolCollector.cpp:293
   assert(CompletionAllocator && CompletionTUInfo);
+  // A declaration created for a friend declaration should not be used as the
+  // canonical declaration in the index.

ilya-biryukov wrote:
> ioeric wrote:
> > ilya-biryukov wrote:
> > > Maybe move this closer to `shouldFilterDecl()`? We have similar filters 
> > > there.
> > > That would also mean we properly add the reference counts for friend 
> > > declarations that get a normal declaration after their usage later.
> > I didn't put this filter there because I think it's a bit more special than 
> > those filters in `shouldFilterDecl`. We check the `OrigD` and we could 
> > potentially replace `D` with `OrigD`. We could change `shouldFilterDecl` to 
> > handle that, but I'm not sure if it's worth it.
> > 
> > Reference counting for friend declarations is actually a bit tricky as USRs 
> > of the generated declarations might be ambiguous.
> > 
> >  Consider the following exmaple:
> > ```
> > namespace a {
> > class A {};  
> > namespace b { class B { friend class A; };  }  // b 
> >  
> > } // a
> > ```
> > 
> > I would expect the generated friend decl to be `a::A`, but it's actually 
> > `a::b::A`! So getting USR right is a bit tricky, and I think it's probably 
> > ok to ignore references in friend decls.
> > 
> > For reference, `[namespace.memdef]p3`:
> > "If the name in a friend declaration is neither qualified nor a template-id 
> > and the declaration is a function or an elaborated-type-specifier, the 
> > lookup to determine whether the entity has been previously declared shall 
> > not consider any scopes outside the innermost enclosing namespace.
> > Reference counting for friend declarations is actually a bit tricky as USRs 
> > of the generated declarations might be ambiguous.
> This seems like an obvious bug in the USRs that we should fix. WDYT?
Sorry, I think I was not clear... I think this is intended according to the 
standard. So in the example, the qualified name of the friend decl `a::b::A` 
is, although confusing, correct, and o the actual problem is not with the USR.

See `[namespace.memdef]p3`:
"If the name in a friend declaration is neither qualified nor a template-id and 
the declaration is a function or an elaborated-type-specifier, the lookup to 
determine whether the entity has been previously declared shall not consider 
any scopes outside the innermost enclosing namespace.




Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D47623



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


[PATCH] D47623: [clangd] Avoid indexing decls associated with friend decls.

2018-06-01 Thread Sam McCall via Phabricator via cfe-commits
sammccall added inline comments.



Comment at: clangd/index/SymbolCollector.cpp:297
+// If OrigD is an object of a friend declaration, skip it.
+if (ASTNode.OrigD->getFriendObjectKind() !=
+Decl::FriendObjectKind::FOK_None)

ioeric wrote:
> sammccall wrote:
> > this seems suspect, we're going to treat the third decl in `friend X; X; 
> > friend X` differently from that in `X; friend X; friend X;`.
> > 
> > Why? i.e. why is the inner check necessary and why does it treat the 
> > original (meaning first, I think) decl specially?
> > this seems suspect, we're going to treat the third decl in `friend X; X; 
> > friend X` differently from that in `X; friend X; friend X;`.
> I'm not very sure if I understand the problem. But I'll try to explain what 
> would happen for these two examples.
> - For the first example, the first friend decl will be the canonical decl, 
> and we would only index the second `X` since its `OrigD` is not in friend 
> decl. Both the first and third friend decl will not be indexed. 
> - For the second example, the first non-friend `X` will be the canonical 
> decl, and all three occurrences will have the same `D` pointing to it. This 
> probably means that the same X will be processed three times, but it's 
> probably fine (we might want to optimize it). 
> 
> Basically, `D` is always the canonical declaration in AST and `OrigD` is  the 
> declaration that the indexer is currently visiting. I agree it's confusing...
> 
> > Why? i.e. why is the inner check necessary and why does it treat the 
> > original (meaning first, I think) decl specially?
> 
> The inner check handles the following case:
> ```
> class X {
>   friend void foo();
> }
> void foo();
> ```
> 
> There will be two occurrences of `foo` in the index:
> 1. The friend decl, where `D` will be the canonical decl (i.e. friend foo) 
> and `OrigD` will also be friend foo.
> 2. The non-friend decl, where `D` will still be the canonical decl (i.e. 
> friend foo) and `OrigD` is now the non-friend decl.
> Basically, D is always the canonical declaration in AST and OrigD is the 
> declaration that the indexer is currently visiting. I agree it's confusing...

Whoops, I had this backwards. So I guess I mean the outer check.
Fundamentally my question is: in an *arbitrary* list of redecls of a symbol, 
what is special about the canonical declaration (D, which is just the first in 
the list) that we particularly care whether it's a friend?
I would expect that either we're ignoring the other redecls, or we're looping 
over all redecls.

And here, I think we could just skip all friend decls (that are not 
definitions), regardless of what `D->getFriendObjectKind()` is. If we have 
other decls, the symbol was indexed already. If we do not, then we don't want 
to index it anyway.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D47623



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


  1   2   >