Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[Tim Northover via cfe-commits]

On 1 December 2015 at 10:42, James Molloy via cfe-commits
 wrote:
> W.r.t the test-suite, that is a possibility. There are currently no
> codegen-filecheck tests in the test-suite but there seems to be no reason I
> can see why not. The disadvantage there for me is that we take short
> running, simple tests and demote them to be run less often.

Compared to test-suite these are short-running. But compared to
virtually everything else in check-all they're beasts.

I've been meaning to do *something* about them for a long while.
They're not even particularly good: these days they're a huge
hand-written mess and they don't test data flow at all.

Given how the code is actually generated, it would be absurdly easy to
accidentally feed LHS into an LLVM instruction twice by mistake. For a
long while we randomly flipped the operand order in vfma_lane_* on
Darwin, and had to phase that out gradually.

Unfortunately, I haven't actually come up with a better replacement.
Even if we could magically replace each one with a test of LLVM IR I
don't think it would improve things massively.

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

r254455 - Clang-format an 80-column violation.

[Adrian Prantl via cfe-commits]

Author: adrian
Date: Tue Dec  1 14:19:44 2015
New Revision: 254455

URL: http://llvm.org/viewvc/llvm-project?rev=254455=rev
Log:
Clang-format an 80-column violation.

Modified:
cfe/trunk/include/clang/AST/Decl.h

Modified: cfe/trunk/include/clang/AST/Decl.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Decl.h?rev=254455=254454=254455=diff
==
--- cfe/trunk/include/clang/AST/Decl.h (original)
+++ cfe/trunk/include/clang/AST/Decl.h Tue Dec  1 14:19:44 2015
@@ -3307,8 +3307,12 @@ public:
   bool hasVolatileMember() const { return HasVolatileMember; }
   void setHasVolatileMember (bool val) { HasVolatileMember = val; }
 
-  bool hasLoadedFieldsFromExternalStorage() const { return 
LoadedFieldsFromExternalStorage; }
-  void setHasLoadedFieldsFromExternalStorage (bool val) { 
LoadedFieldsFromExternalStorage = val; }
+  bool hasLoadedFieldsFromExternalStorage() const {
+return LoadedFieldsFromExternalStorage;
+  }
+  void setHasLoadedFieldsFromExternalStorage(bool val) {
+LoadedFieldsFromExternalStorage = val;
+  }
 
   /// \brief Determines whether this declaration represents the
   /// injected class name.


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

Re: [PATCH] D14779: Adding checker to detect excess padding in records

[Anna Zaks via cfe-commits]

zaks.anna added a comment.

> An analysis of llvm+clang+compiler-rt now only generates 16 excessive padding 
> reports in index.html.


Should those be fixed or are they all false positives?



Comment at: lib/StaticAnalyzer/Checkers/PaddingChecker.cpp:48
@@ +47,3 @@
+// The calls to checkAST* from AnalysisConsumer don't end
+// visit template instantiations or lambda classes.  We
+// want to visit those, so make our own RecursiveASTVisitor.

Wording is off here.
Would it be possible to provide a checkAST method that does visit temple 
instantiations and lambdas? What if another checker wants the same 
functionality?


Comment at: lib/StaticAnalyzer/Checkers/PaddingChecker.cpp:70
@@ +69,3 @@
+
+  void visitRecord(const RecordDecl *RD, uint64_t PadMultiplier = 1) const {
+if (shouldSkipDecl(RD))

Could you add a comment explaining what is PadMultiplier and why it is needed?


Comment at: lib/StaticAnalyzer/Checkers/PaddingChecker.cpp:196
@@ +195,3 @@
+auto LeftFoldFunc =
+[, ](const CharUnitInfo , const CharUnitInfo ) {
+  CharUnitInfo Retval;

Is this doing more than just accumulating the padding for every field in the  
record? For example, it seems we could do it with a simple loop the does:
  PadSum += Current.Offset - (Prev.Offset + Prev.Size)


Comment at: lib/StaticAnalyzer/Checkers/PaddingChecker.cpp:213
@@ +212,3 @@
+
+  static CharUnits calculateOptimalPad(const RecordDecl *RD,
+   const ASTContext ,

Please, add a high-level description of how optimal pad is calculated.



Comment at: lib/StaticAnalyzer/Checkers/PaddingChecker.cpp:223
@@ +222,3 @@
+// In the typical case, this will result in us popping
+// the back element of the vector, instead of shifting lots
+// of elements.

The second comment is unclear. Which vector are you talking about here?

I think it would be better to just move the comments to the places where the 
action is performed; ex std::sort(Fields.begin(), Fields.end()) in this case.


Comment at: lib/StaticAnalyzer/Checkers/PaddingChecker.cpp:230
@@ +229,3 @@
+SmallVector Fields;
+auto Transformation = [](const FieldDecl *FD) {
+  CharUnitPair RetVal;

Please, pick a more descriptive name.


Comment at: lib/StaticAnalyzer/Checkers/PaddingChecker.cpp:249
@@ +248,3 @@
+CharUnits NewOffset = ASTContext.toCharUnitsFromBits(RL.getFieldOffset(0));
+CharUnits NewPad;
+

Is NewPad initialized?


http://reviews.llvm.org/D14779



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

Re: [PATCH] D15121: A new clang-tidy module to find calls to `std::swap`, and change them to use ADL

[Marshall Clow via cfe-commits]

mclow.lists updated the summary for this revision.
mclow.lists updated this revision to Diff 41559.
mclow.lists added a comment.

Suggestions from @AaronBallman; now does the substitution correctly, and passes 
the tests.

Note: The diagnostics that clang emits are still whacko.


http://reviews.llvm.org/D15121

Files:
  clang-tidy/misc/CMakeLists.txt
  clang-tidy/misc/MiscTidyModule.cpp
  clang-tidy/misc/StdSwapCheck.cpp
  clang-tidy/misc/StdSwapCheck.h
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/misc-StdSwap.rst
  test/clang-tidy/misc-StdSwap.cpp

Index: test/clang-tidy/misc-StdSwap.cpp
===
--- test/clang-tidy/misc-StdSwap.cpp
+++ test/clang-tidy/misc-StdSwap.cpp
@@ -0,0 +1,62 @@
+// RUN: %check_clang_tidy %s misc-std-swap %t
+
+#include 
+
+// FIXME: Add something that triggers the check here.
+// FIXME: Verify the applied fix.
+//   * Make the CHECK patterns specific enough and try to make verified lines
+// unique to avoid incorrect matches.
+//   * Use {{}} for regular expressions.
+
+// Bad code; don't overload in namespace std
+struct S1 { int x; };
+namespace std { void swap(S1& x, S1 ) { swap(x.x, y.x); } };
+
+// Swap in namespace with type
+namespace foo { struct S2 { int i; }; void swap(S2& x, S2& y) {std::swap(x.i, y.i); } }
+
+// Swap in namespace.
+namespace bar { void swap(int, int) {} }
+
+void test0()
+{
+  S1 i,j;
+  std::swap(i,j);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: let the compiler find the right swap via ADL
+  // CHECK-FIXES: { using std::swap; swap(i,j); }
+}
+
+void test1(bool b)
+{
+  foo::S2 x,y;
+  if ( b )
+std::swap(x,y);
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: let the compiler find the right swap via ADL
+  // CHECK-FIXES: { using std::swap; swap(x,y); }
+}
+
+void test_neg0()// Swap two builtins
+{
+{
+int i,j;
+std::swap(i,j);
+}
+{
+float i,j;
+std::swap(i,j);
+}
+}
+
+void test_neg1()// std::swap two pointers
+
+{
+S1 *i, *j;
+std::swap(i,j);
+}
+
+void test_neg2()  // Call a namespace-qualified swap that isn't "std::"
+{
+int i,j;
+bar::swap(i,j);
+}
+
Index: docs/clang-tidy/checks/misc-StdSwap.rst
===
--- docs/clang-tidy/checks/misc-StdSwap.rst
+++ docs/clang-tidy/checks/misc-StdSwap.rst
@@ -0,0 +1,19 @@
+misc-StdSwap
+
+
+Adding an overload for `std:swap` (in the `std` namespace) is explicitly forbidden by the standard. 
+
+The best practices for implementing swap for user-defined data structures is to implement a non-member swap in the same namespace as the type. Then, when you wish to swap to values `x` and `y`, you call `swap(x,y)` without a namespace, and ADL lookup will find it. Unfortunately this will not work for types that have overloads of swap in namespace std (standard library types and primitive types). So you have to bring them into play with a "using" statement.
+
+Instead of writing:
+> std::swap(x,y);
+
+you should write:
+> using std::swap; swap(x,y);
+
+This checker find this pattern and replaces it with the recommended usage; wrapping the call in a pair of brackets to scope the using directive. For builtin types (such as `int` and `float`), as well as pointers, it leaves the calls to `std::swap` alone, because those are correct.
+
+FUTURE WORK: 
+
+Find overloads of `swap` in namespace std and put them in the correct namespace.
+
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -32,6 +32,7 @@
llvm-include-order
llvm-namespace-comment
llvm-twine-local
+   misc-StdSwap
misc-argument-comment
misc-assert-side-effect
misc-assign-operator-signature
@@ -46,6 +47,7 @@
misc-non-copyable-objects
misc-sizeof-container
misc-static-assert
+   misc-std-swap
misc-swapped-arguments
misc-throw-by-value-catch-by-reference
misc-undelegated-constructor
Index: clang-tidy/misc/StdSwapCheck.h
===
--- clang-tidy/misc/StdSwapCheck.h
+++ clang-tidy/misc/StdSwapCheck.h
@@ -0,0 +1,34 @@
+//===--- StdSwapCheck.h - clang-tidy-*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MISC_STD_SWAP_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MISC_STD_SWAP_H
+
+#include "../ClangTidy.h"
+
+namespace clang {
+namespace tidy {
+
+/// FIXME: Write a short description.
+///
+/// For the user-facing documentation see:
+/// http://clang.llvm.org/extra/clang-tidy/checks/misc-std-swap.html
+class StdSwapCheck : public 

r254464 - docs: Add design documentation for forward-edge CFI for indirect calls.

[Peter Collingbourne via cfe-commits]

Author: pcc
Date: Tue Dec  1 15:58:54 2015
New Revision: 254464

URL: http://llvm.org/viewvc/llvm-project?rev=254464=rev
Log:
docs: Add design documentation for forward-edge CFI for indirect calls.

Modified:
cfe/trunk/docs/ControlFlowIntegrityDesign.rst

Modified: cfe/trunk/docs/ControlFlowIntegrityDesign.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ControlFlowIntegrityDesign.rst?rev=254464=254463=254464=diff
==
--- cfe/trunk/docs/ControlFlowIntegrityDesign.rst (original)
+++ cfe/trunk/docs/ControlFlowIntegrityDesign.rst Tue Dec  1 15:58:54 2015
@@ -277,7 +277,92 @@ likely to occur if the virtual tables ar
 Forward-Edge CFI for Indirect Function Calls
 
 
-Sorry, no documentation yet, but see the comments at the top of
-``LowerBitSets::buildBitSetsFromFunctions`` in `LowerBitSets.cpp`_.
+Under forward-edge CFI for indirect function calls, each unique function
+type has its own bit vector, and at each call site we need to check that the
+function pointer is a member of the function type's bit vector. This scheme
+works in a similar way to forward-edge CFI for virtual calls, the distinction
+being that we need to build bit vectors of function entry points rather than
+of virtual tables.
 
-.. _LowerBitSets.cpp: 
http://llvm.org/klaus/llvm/blob/master/lib/Transforms/IPO/LowerBitSets.cpp
+Unlike when re-arranging global variables, we cannot re-arrange functions
+in a particular order and base our calculations on the layout of the
+functions' entry points, as we have no idea how large a particular function
+will end up being (the function sizes could even depend on how we arrange
+the functions). Instead, we build a jump table, which is a block of code
+consisting of one branch instruction for each of the functions in the bit
+set that branches to the target function, and redirect any taken function
+addresses to the corresponding jump table entry. In this way, the distance
+between function entry points is predictable and controllable. In the object
+file's symbol table, the symbols for the target functions also refer to the
+jump table entries, so that addresses taken outside the module will pass
+any verification done inside the module.
+
+In more concrete terms, suppose we have three functions ``f``, ``g``, ``h``
+which are members of a single bitset, and a function foo that returns their
+addresses:
+
+.. code-block:: none
+
+  f:
+  mov 0, %eax
+  ret
+
+  g:
+  mov 1, %eax
+  ret
+
+  h:
+  mov 2, %eax
+  ret
+
+  foo:
+  mov f, %eax
+  mov g, %edx
+  mov h, %ecx
+  ret
+
+Our jump table will (conceptually) look like this:
+
+.. code-block:: none
+
+  f:
+  jmp .Ltmp0 ; 5 bytes
+  int3   ; 1 byte
+  int3   ; 1 byte
+  int3   ; 1 byte
+
+  g:
+  jmp .Ltmp1 ; 5 bytes
+  int3   ; 1 byte
+  int3   ; 1 byte
+  int3   ; 1 byte
+
+  h:
+  jmp .Ltmp2 ; 5 bytes
+  int3   ; 1 byte
+  int3   ; 1 byte
+  int3   ; 1 byte
+
+  .Ltmp0:
+  mov 0, %eax
+  ret
+
+  .Ltmp1:
+  mov 1, %eax
+  ret
+
+  .Ltmp2:
+  mov 2, %eax
+  ret
+
+  foo:
+  mov f, %eax
+  mov g, %edx
+  mov h, %ecx
+  ret
+
+Because the addresses of ``f``, ``g``, ``h`` are evenly spaced at a power of
+2, and function types do not overlap (unlike class types with base classes),
+we can normally apply the `Alignment`_ and `Eliminating Bit Vector Checks
+for All-Ones Bit Vectors`_ optimizations thus simplifying the check at each
+call site to a range and alignment check.


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

[PATCH] D15125: [OPENMP] 'omp distribute' directive basic support.

[Carlo Bertolli via cfe-commits]

carlo.bertolli created this revision.
carlo.bertolli added reviewers: hfinkel, ABataev, rjmccall.
carlo.bertolli added subscribers: sfantao, cfe-commits.
carlo.bertolli set the repository for this revision to rL LLVM.

This patch includes parsing and semantic analysis for 'omp distribute' 
directive for OpenMP 4.5 and regression tests. All clauses  present in OpenMP 
4.5 for the 'omp distribute' directive are present.

Repository:
  rL LLVM

http://reviews.llvm.org/D15125

Files:
  include/clang-c/Index.h
  include/clang/AST/OpenMPClause.h
  include/clang/AST/RecursiveASTVisitor.h
  include/clang/AST/StmtOpenMP.h
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/OpenMPKinds.def
  include/clang/Basic/OpenMPKinds.h
  include/clang/Basic/StmtNodes.td
  include/clang/Sema/Sema.h
  include/clang/Serialization/ASTBitCodes.h
  lib/AST/StmtOpenMP.cpp
  lib/AST/StmtPrinter.cpp
  lib/AST/StmtProfile.cpp
  lib/Basic/OpenMPKinds.cpp
  lib/CodeGen/CGStmt.cpp
  lib/CodeGen/CGStmtOpenMP.cpp
  lib/CodeGen/CodeGenFunction.h
  lib/Parse/ParseOpenMP.cpp
  lib/Sema/SemaOpenMP.cpp
  lib/Sema/TreeTransform.h
  lib/Serialization/ASTReaderStmt.cpp
  lib/Serialization/ASTWriterStmt.cpp
  lib/StaticAnalyzer/Core/ExprEngine.cpp
  test/OpenMP/distribute_ast_print.cpp
  test/OpenMP/distribute_collapse_messages.cpp
  test/OpenMP/distribute_dist_schedule_messages.cpp
  test/OpenMP/distribute_firstprivate_messages.cpp
  test/OpenMP/distribute_private_messages.cpp
  test/OpenMP/nesting_of_regions.cpp
  tools/libclang/CIndex.cpp
  tools/libclang/CXCursor.cpp

Index: tools/libclang/CXCursor.cpp
===
--- tools/libclang/CXCursor.cpp
+++ tools/libclang/CXCursor.cpp
@@ -607,9 +607,12 @@
   case Stmt::OMPCancelDirectiveClass:
 K = CXCursor_OMPCancelDirective;
 break;
-  case Stmt::OMPTaskLoopDirectiveClass:
+ case Stmt::OMPTaskLoopDirectiveClass:
 K = CXCursor_OMPTaskLoopDirective;
 break;
+  case Stmt::OMPDistributeDirectiveClass:
+K = CXCursor_OMPDistributeDirective;
+break;
   }
 
   CXCursor C = { K, 0, { Parent, S, TU } };
Index: tools/libclang/CIndex.cpp
===
--- tools/libclang/CIndex.cpp
+++ tools/libclang/CIndex.cpp
@@ -1942,7 +1942,8 @@
   void VisitOMPTargetDirective(const OMPTargetDirective *D);
   void VisitOMPTargetDataDirective(const OMPTargetDataDirective *D);
   void VisitOMPTeamsDirective(const OMPTeamsDirective *D);
-  void VisitOMPTaskLoopDirective(const OMPTaskLoopDirective *D);
+  void VisitOMPTaskLoopDirective(const OMPTaskLoopDirective *D);  
+  void VisitOMPDistributeDirective(const OMPDistributeDirective *D);
 
 private:
   void AddDeclarationNameInfo(const Stmt *S);
@@ -2195,6 +2196,11 @@
   VisitOMPClauseList(C);
 }
 }
+void OMPClauseEnqueue::VisitOMPDistScheduleClause(
+const OMPDistScheduleClause *C) {
+  Visitor->AddStmt(C->getChunkSize());
+  Visitor->AddStmt(C->getHelperChunkSize());
+}
 
 void EnqueueVisitor::EnqueueChildren(const OMPClause *S) {
   unsigned size = WL.size();
@@ -2616,6 +2622,11 @@
   VisitOMPLoopDirective(D);
 }
 
+void EnqueueVisitor::VisitOMPDistributeDirective(
+const OMPDistributeDirective *D) {
+  VisitOMPLoopDirective(D);
+}
+
 void CursorVisitor::EnqueueWorkList(VisitorWorkList , const Stmt *S) {
   EnqueueVisitor(WL, MakeCXCursor(S, StmtParent, TU,RegionOfInterest)).Visit(S);
 }
@@ -4474,6 +4485,8 @@
 return cxstring::createRef("OMPCancelDirective");
   case CXCursor_OMPTaskLoopDirective:
 return cxstring::createRef("OMPTaskLoopDirective");
+  case CXCursor_OMPDistributeDirective:
+return cxstring::createRef("OMPForDirective");
   case CXCursor_OverloadCandidate:
   return cxstring::createRef("OverloadCandidate");
   case CXCursor_TypeAliasTemplateDecl:
Index: test/OpenMP/nesting_of_regions.cpp
===
--- test/OpenMP/nesting_of_regions.cpp
+++ test/OpenMP/nesting_of_regions.cpp
@@ -106,6 +106,12 @@
   for (int i = 0; i < 10; ++i)
 ++a;
   }
+#pragma omp parallel
+  {
+#pragma omp distribute // expected-error {{'#pragma omp distribute' must be strictly nested in '#pragma omp teams'}}
+for (int i = 0; i < 10; ++i)
+  ;
+  }
 
 // SIMD DIRECTIVE
 #pragma omp simd
@@ -239,6 +245,12 @@
   for (int i = 0; i < 10; ++i)
 ++a;
   }
+#pragma omp simd
+  for (int i = 0; i < 10; ++i) {
+#pragma omp distribute // expected-error {{OpenMP constructs may not be nested inside a simd region}}
+for (int j = 0; j < 10; ++j)
+  ;
+  }
 
 // FOR DIRECTIVE
 #pragma omp for
@@ -395,6 +407,12 @@
   for (int i = 0; i < 10; ++i)
 ++a;
   }
+#pragma omp for
+  for (int i = 0; i < 10; ++i) {
+#pragma omp distribute // expected-error {{'#pragma omp distribute' must be strictly nested in '#pragma omp teams'}}
+for (int j = 0; j < 10; ++j)
+  ;
+  }
 
 // FOR SIMD DIRECTIVE
 #pragma omp for simd
@@ -528,6 +546,12 @@
   for (int i = 0; 

Re: [PATCH] D13263: Addition of __attribute__((pass_object_size)) to Clang

[David Majnemer via cfe-commits]

majnemer added inline comments.


Comment at: lib/AST/MicrosoftMangle.cpp:1844-1857
@@ -1843,4 +1843,16 @@
 // Happens for function pointer type arguments for example.
-for (const QualType  : Proto->param_types())
-  mangleArgumentType(Arg, Range);
+for (unsigned I = 0, E = Proto->getNumParams(); I != E; ++I) {
+  mangleArgumentType(Proto->getParamType(I), Range);
+  // Mangle each pass_object_size parameter as if it's a paramater of enum
+  // type passed directly after the parameter with the pass_object_size
+  // attribute. The aforementioned enum's name is __pass_object_size, and 
we
+  // pretend it resides in a top-level namespace called __ext.
+  //
+  // FIXME: Is there a defined extension notation for the MS ABI, or is it
+  // necessary to just cross our fingers and hope this type+namespace
+  // combination doesn't conflict with anything?
+  if (D)
+if (auto *P = D->getParamDecl(I)->getAttr())
+  Out << "W4__pass_object_size" << P->getType() << "@__ext@@";
+}
 //   ::= Z  # ellipsis

This seems fine to me, I'd change the namespace to something like `__clang` 
though.


http://reviews.llvm.org/D13263



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

Re: [PATCH] D14639: LLDB JIT needs android vector passing rules.

[Stephen Hines via cfe-commits]

srhines commandeered this revision.
srhines added a reviewer: ADodds.
srhines added a comment.

Commandeering, since I am going to upload a version with the updated tests.


Repository:
  rL LLVM

http://reviews.llvm.org/D14639



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

[PATCH] D15127: Move _mm256_cvtps_ph and _mm256_cvtph_ps to immintrin.h.

[Paul Robinson via cfe-commits]

probinson created this revision.
probinson added a reviewer: mkuper.
probinson added a subscriber: cfe-commits.

This more closely matches their locations as described by Intel documentation, 
and lets us remove a pair of redundant typedefs.

http://reviews.llvm.org/D15127

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

Index: lib/Headers/immintrin.h
===
--- lib/Headers/immintrin.h
+++ lib/Headers/immintrin.h
@@ -42,6 +42,19 @@
 
 #include 
 
+/* The 256-bit versions of functions in f16cintrin.h.
+   Intel documents these as being in immintrin.h, and
+   they depend on typedefs from avxintrin.h. */
+
+#define _mm256_cvtps_ph(a, imm) __extension__ ({ \
+ (__m128i)__builtin_ia32_vcvtps2ph256((__v8sf)(__m256)(a), (imm)); })
+
+static __inline __m256 __attribute__((__always_inline__, __nodebug__, 
__target__("f16c")))
+_mm256_cvtph_ps(__m128i __a)
+{
+  return (__m256)__builtin_ia32_vcvtph2ps256((__v8hi)__a);
+}
+
 #include 
 
 #include 
Index: lib/Headers/f16cintrin.h
===
--- lib/Headers/f16cintrin.h
+++ lib/Headers/f16cintrin.h
@@ -28,30 +28,18 @@
 #ifndef __F16CINTRIN_H
 #define __F16CINTRIN_H
 
-typedef float __v8sf __attribute__ ((__vector_size__ (32)));
-typedef float __m256 __attribute__ ((__vector_size__ (32)));
-
 /* Define the default attributes for the functions in this file. */
 #define __DEFAULT_FN_ATTRS __attribute__((__always_inline__, __nodebug__, 
__target__("f16c")))
 
 #define _mm_cvtps_ph(a, imm) __extension__ ({ \
  (__m128i)__builtin_ia32_vcvtps2ph((__v4sf)(__m128)(a), (imm)); })
 
-#define _mm256_cvtps_ph(a, imm) __extension__ ({ \
- (__m128i)__builtin_ia32_vcvtps2ph256((__v8sf)(__m256)(a), (imm)); })
-
 static __inline __m128 __DEFAULT_FN_ATTRS
 _mm_cvtph_ps(__m128i __a)
 {
   return (__m128)__builtin_ia32_vcvtph2ps((__v8hi)__a);
 }
 
-static __inline __m256 __DEFAULT_FN_ATTRS
-_mm256_cvtph_ps(__m128i __a)
-{
-  return (__m256)__builtin_ia32_vcvtph2ps256((__v8hi)__a);
-}
-
 #undef __DEFAULT_FN_ATTRS
 
 #endif /* __F16CINTRIN_H */


Index: lib/Headers/immintrin.h
===
--- lib/Headers/immintrin.h
+++ lib/Headers/immintrin.h
@@ -42,6 +42,19 @@
 
 #include 
 
+/* The 256-bit versions of functions in f16cintrin.h.
+   Intel documents these as being in immintrin.h, and
+   they depend on typedefs from avxintrin.h. */
+
+#define _mm256_cvtps_ph(a, imm) __extension__ ({ \
+ (__m128i)__builtin_ia32_vcvtps2ph256((__v8sf)(__m256)(a), (imm)); })
+
+static __inline __m256 __attribute__((__always_inline__, __nodebug__, __target__("f16c")))
+_mm256_cvtph_ps(__m128i __a)
+{
+  return (__m256)__builtin_ia32_vcvtph2ps256((__v8hi)__a);
+}
+
 #include 
 
 #include 
Index: lib/Headers/f16cintrin.h
===
--- lib/Headers/f16cintrin.h
+++ lib/Headers/f16cintrin.h
@@ -28,30 +28,18 @@
 #ifndef __F16CINTRIN_H
 #define __F16CINTRIN_H
 
-typedef float __v8sf __attribute__ ((__vector_size__ (32)));
-typedef float __m256 __attribute__ ((__vector_size__ (32)));
-
 /* Define the default attributes for the functions in this file. */
 #define __DEFAULT_FN_ATTRS __attribute__((__always_inline__, __nodebug__, __target__("f16c")))
 
 #define _mm_cvtps_ph(a, imm) __extension__ ({ \
  (__m128i)__builtin_ia32_vcvtps2ph((__v4sf)(__m128)(a), (imm)); })
 
-#define _mm256_cvtps_ph(a, imm) __extension__ ({ \
- (__m128i)__builtin_ia32_vcvtps2ph256((__v8sf)(__m256)(a), (imm)); })
-
 static __inline __m128 __DEFAULT_FN_ATTRS
 _mm_cvtph_ps(__m128i __a)
 {
   return (__m128)__builtin_ia32_vcvtph2ps((__v8hi)__a);
 }
 
-static __inline __m256 __DEFAULT_FN_ATTRS
-_mm256_cvtph_ps(__m128i __a)
-{
-  return (__m256)__builtin_ia32_vcvtph2ps256((__v8hi)__a);
-}
-
 #undef __DEFAULT_FN_ATTRS
 
 #endif /* __F16CINTRIN_H */
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D15121: A new clang-tidy module to find calls to `std::swap`, and change them to use ADL

[Richard via cfe-commits]

LegalizeAdulthood added a subscriber: LegalizeAdulthood.
LegalizeAdulthood added a comment.

I'm wondering if there isn't an existing module that would be a good fit for 
this check.  Why not in the modernize module?


http://reviews.llvm.org/D15121



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

Re: r254423 - It appears that this horrible mutating copy constructor is unused. Kill it with fire.

[Richard Smith via cfe-commits]

On Tue, Dec 1, 2015 at 3:42 PM, Duncan P. N. Exon Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
> > On 2015-Dec-01, at 09:15, Aaron Ballman via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
> >
> > Author: aaronballman
> > Date: Tue Dec  1 11:15:13 2015
> > New Revision: 254423
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=254423=rev
> > Log:
> > It appears that this horrible mutating copy constructor is unused. Kill
> it with fire.
> >
> > Modified:
> >cfe/trunk/include/clang/Sema/AttributeList.h
> >
> > Modified: cfe/trunk/include/clang/Sema/AttributeList.h
> > URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/AttributeList.h?rev=254423=254422=254423=diff
> >
> ==
> > --- cfe/trunk/include/clang/Sema/AttributeList.h (original)
> > +++ cfe/trunk/include/clang/Sema/AttributeList.h Tue Dec  1 11:15:13 2015
> > @@ -557,11 +557,6 @@ public:
> >   /// Create a new pool for a factory.
> >   AttributePool(AttributeFactory ) : Factory(factory),
> Head(nullptr) {}
> >
> > -  /// Move the given pool's allocations to this pool.
> > -  AttributePool(AttributePool ) : Factory(pool.Factory),
> Head(pool.Head) {
> > -pool.Head = nullptr;
> > -  }
> > -
>
> Moving without R-value references is weird, but it seems to me like
> at least this was preventing double-ownership of the Head.
>
> I'm pretty sure now that this function has been removed, the copy
> constructor will be auto-generated.  Should you `= delete` it?


Or, preferably, reinstate it but make it a move constructor.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D15130: Fix the clang driver when "-nostdlib" is present

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

Testcase?

> On 2015-Dec-01, at 14:58, Sumanth Gundapaneni via cfe-commits 
>  wrote:
> 
> sgundapa created this revision.
> sgundapa added reviewers: vkalintiris, echristo.
> sgundapa added a subscriber: cfe-commits.
> 
> This patch is a fix to r252901 which changed the behavior of 
> clang driver. In the presence of "-nostdlib" none of the standard
> libraries should be passed to link line. 
> 
> http://reviews.llvm.org/D15130
> 
> Files:
>  lib/Driver/Tools.cpp
> 
> Index: lib/Driver/Tools.cpp
> ===
> --- lib/Driver/Tools.cpp
> +++ lib/Driver/Tools.cpp
> @@ -8694,8 +8694,7 @@
>   if (!isAndroid)
> 
> CmdArgs.push_back(Args.MakeArgString(ToolChain.GetFilePath("crtn.o")));
> }
> -  } else if (Args.hasArg(options::OPT_rtlib_EQ))
> -AddRunTimeLibs(ToolChain, D, CmdArgs, Args);
> +  }
> 
>   C.addCommand(llvm::make_unique(JA, *this, Exec, CmdArgs, Inputs));
> }
> 
> 
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

Re: r254423 - It appears that this horrible mutating copy constructor is unused. Kill it with fire.

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

> On 2015-Dec-01, at 09:15, Aaron Ballman via cfe-commits 
>  wrote:
> 
> Author: aaronballman
> Date: Tue Dec  1 11:15:13 2015
> New Revision: 254423
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=254423=rev
> Log:
> It appears that this horrible mutating copy constructor is unused. Kill it 
> with fire.
> 
> Modified:
>cfe/trunk/include/clang/Sema/AttributeList.h
> 
> Modified: cfe/trunk/include/clang/Sema/AttributeList.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/AttributeList.h?rev=254423=254422=254423=diff
> ==
> --- cfe/trunk/include/clang/Sema/AttributeList.h (original)
> +++ cfe/trunk/include/clang/Sema/AttributeList.h Tue Dec  1 11:15:13 2015
> @@ -557,11 +557,6 @@ public:
>   /// Create a new pool for a factory.
>   AttributePool(AttributeFactory ) : Factory(factory), Head(nullptr) 
> {}
> 
> -  /// Move the given pool's allocations to this pool.
> -  AttributePool(AttributePool ) : Factory(pool.Factory), 
> Head(pool.Head) {
> -pool.Head = nullptr;
> -  }
> -

Moving without R-value references is weird, but it seems to me like
at least this was preventing double-ownership of the Head.

I'm pretty sure now that this function has been removed, the copy
constructor will be auto-generated.  Should you `= delete` it?

>   AttributeFactory () const { return Factory; }
> 
>   void clear() {
> 
> 
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

Re: [PATCH] D14731: [libcxx] Add clang thread safety annotations to mutex and lock_guard

[James Robinson via cfe-commits]

jamesr updated this revision to Diff 41581.
jamesr added a comment.

Updates the macros to avoid defining anything if _LIBCPP_THREAD_ANNOTATION is 
already defined and to define _LIBCPP_THREAD_ANNOTATION to nothing if __clang__ 
is not set, __has_attribute(acquire_capability) is not set, or 
_LIBCPP_HAS_NO_THREAD_ANNOTATIONS is set.

It turns out there's not a clean feature guard for the thread safety 
annotations (i.e. no __has_feature() guard).  The annotations were added over 
time to clang.  I'm not sure at which point the feature was considered stable 
enough for general use.  Looking at clang's history the most recently added 
annotation out of the ones this patch uses is acquire_capability which was 
added in this commit: https://llvm.org/svn/llvm-project/cfe/trunk@201890, so 
I'm testing for that annotation to test for support for the feature as a whole. 
 It's quite possible that there are revisions of clang after the annotation 
support was added that contain bugs that make the annotations not very useful 
but the fix for any users trying to use such versions of clang is easy - just 
avoid passing -Wthread-safety to these versions of clang.


http://reviews.llvm.org/D14731

Files:
  include/__config
  include/__mutex_base

Index: include/__mutex_base
===
--- include/__mutex_base
+++ include/__mutex_base
@@ -26,7 +26,15 @@
 
 #ifndef _LIBCPP_HAS_NO_THREADS
 
-class _LIBCPP_TYPE_VIS mutex
+#ifndef _LIBCPP_THREAD_ANNOTATION
+#  ifndef _LIBCPP_HAS_NO_THREAD_ANNOTATIONS
+#define _LIBCPP_THREAD_ANNOTATION(x) __attribute__((x))
+#  else
+#define _LIBCPP_THREAD_ANNOTATION(x)
+#  endif
+#endif  // _LIBCPP_THREAD_ANNOTATION
+
+class _LIBCPP_TYPE_VIS _LIBCPP_THREAD_ANNOTATION(capability("mutex")) mutex
 {
 pthread_mutex_t __m_;
 
@@ -44,9 +52,9 @@
 mutex& operator=(const mutex&);// = delete;
 
 public:
-void lock();
-bool try_lock() _NOEXCEPT;
-void unlock() _NOEXCEPT;
+void lock() _LIBCPP_THREAD_ANNOTATION(acquire_capability());
+bool try_lock() _NOEXCEPT 
_LIBCPP_THREAD_ANNOTATION(try_acquire_capability(true));
+void unlock() _NOEXCEPT _LIBCPP_THREAD_ANNOTATION(release_capability());
 
 typedef pthread_mutex_t* native_handle_type;
 _LIBCPP_INLINE_VISIBILITY native_handle_type native_handle() {return 
&__m_;}
@@ -71,7 +79,7 @@
 #endif
 
 template 
-class _LIBCPP_TYPE_VIS_ONLY lock_guard
+class _LIBCPP_TYPE_VIS_ONLY _LIBCPP_THREAD_ANNOTATION(scoped_lockable) 
lock_guard
 {
 public:
 typedef _Mutex mutex_type;
@@ -81,13 +89,13 @@
 public:
 
 _LIBCPP_INLINE_VISIBILITY
-explicit lock_guard(mutex_type& __m)
+explicit lock_guard(mutex_type& __m) 
_LIBCPP_THREAD_ANNOTATION(acquire_capability(__m))
 : __m_(__m) {__m_.lock();}
 _LIBCPP_INLINE_VISIBILITY
-lock_guard(mutex_type& __m, adopt_lock_t)
+lock_guard(mutex_type& __m, adopt_lock_t) 
_LIBCPP_THREAD_ANNOTATION(requires_capability(__m))
 : __m_(__m) {}
 _LIBCPP_INLINE_VISIBILITY
-~lock_guard() {__m_.unlock();}
+~lock_guard() _LIBCPP_THREAD_ANNOTATION(release_capability()) 
{__m_.unlock();}
 
 private:
 lock_guard(lock_guard const&);// = delete;
Index: include/__config
===
--- include/__config
+++ include/__config
@@ -825,6 +825,11 @@
 #define _LIBCPP_HAS_NO_ATOMIC_HEADER
 #endif
 
+#if (!defined(_LIBCPP_HAS_NO_THREAD_ANNOTATIONS) && (!defined(__clang__) \
+  || !__has_attribute(acquire_capability)))
+#define _LIBCPP_HAS_NO_THREAD_ANNOTATIONS
+#endif
+
 #endif // __cplusplus
 
 #endif // _LIBCPP_CONFIG


Index: include/__mutex_base
===
--- include/__mutex_base
+++ include/__mutex_base
@@ -26,7 +26,15 @@
 
 #ifndef _LIBCPP_HAS_NO_THREADS
 
-class _LIBCPP_TYPE_VIS mutex
+#ifndef _LIBCPP_THREAD_ANNOTATION
+#  ifndef _LIBCPP_HAS_NO_THREAD_ANNOTATIONS
+#define _LIBCPP_THREAD_ANNOTATION(x) __attribute__((x))
+#  else
+#define _LIBCPP_THREAD_ANNOTATION(x)
+#  endif
+#endif  // _LIBCPP_THREAD_ANNOTATION
+
+class _LIBCPP_TYPE_VIS _LIBCPP_THREAD_ANNOTATION(capability("mutex")) mutex
 {
 pthread_mutex_t __m_;
 
@@ -44,9 +52,9 @@
 mutex& operator=(const mutex&);// = delete;
 
 public:
-void lock();
-bool try_lock() _NOEXCEPT;
-void unlock() _NOEXCEPT;
+void lock() _LIBCPP_THREAD_ANNOTATION(acquire_capability());
+bool try_lock() _NOEXCEPT _LIBCPP_THREAD_ANNOTATION(try_acquire_capability(true));
+void unlock() _NOEXCEPT _LIBCPP_THREAD_ANNOTATION(release_capability());
 
 typedef pthread_mutex_t* native_handle_type;
 _LIBCPP_INLINE_VISIBILITY native_handle_type native_handle() {return &__m_;}
@@ -71,7 +79,7 @@
 #endif
 
 template 
-class _LIBCPP_TYPE_VIS_ONLY lock_guard
+class _LIBCPP_TYPE_VIS_ONLY _LIBCPP_THREAD_ANNOTATION(scoped_lockable) lock_guard
 {
 public:
 typedef _Mutex mutex_type;
@@ -81,13 +89,13 @@
 public:
 
 

Re: [PATCH] D14731: [libcxx] Add clang thread safety annotations to mutex and lock_guard

[James Robinson via cfe-commits]

jamesr added a subscriber: aaron.ballman.
jamesr added a comment.

It looks like Aaron Ballman was involved with adding parsing for these 
attributes in clang - perhaps he has an idea of a better way to detect these 
than __has_attribute(acquire_capability).


http://reviews.llvm.org/D14731



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

r254481 - [sanitizer coverage] document -fsanitize-coverage=trace-bb

[Kostya Serebryany via cfe-commits]

Author: kcc
Date: Tue Dec  1 20:08:26 2015
New Revision: 254481

URL: http://llvm.org/viewvc/llvm-project?rev=254481=rev
Log:
[sanitizer coverage] document -fsanitize-coverage=trace-bb

Modified:
cfe/trunk/docs/SanitizerCoverage.rst

Modified: cfe/trunk/docs/SanitizerCoverage.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/SanitizerCoverage.rst?rev=254481=254480=254481=diff
==
--- cfe/trunk/docs/SanitizerCoverage.rst (original)
+++ cfe/trunk/docs/SanitizerCoverage.rst Tue Dec  1 20:08:26 2015
@@ -249,6 +249,13 @@ These counters may also be used for in-p
 uintptr_t
 __sanitizer_update_counter_bitset_and_clear_counters(uint8_t *bitset);
 
+Tracing basic blocks
+
+An *experimental* feature to support basic block (or edge) tracing.
+With ``-fsanitize-coverage=trace-bb`` the compiler will insert
+``__sanitizer_cov_trace_basic_block(s32 *id)`` before every function, basic 
block, or edge
+(depending on the value of ``-fsanitize-coverage=[func,bb,edge]``).
+
 Tracing data flow
 =
 


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

Re: [PATCH] D14731: [libcxx] Add clang thread safety annotations to mutex and lock_guard

[James Robinson via cfe-commits]

jamesr added a comment.

In http://reviews.llvm.org/D14731#299152, @mclow.lists wrote:

> Where are the tests?


There aren't any yet.  I investigated a few avenues for testing but none seem 
very useful.

The most obvious testing strategy would be to write some code that fails the 
-Wthread-safety checks such as

  std::mutex m; m.lock(); m.lock();

and verify that this generates the expected warning.  There's a harness for 
expected warnings that does this in the clang repo but no such harness exists 
in libcxx.  Depending on the text of warnings from clang in libcxx tests seems 
like a layering violation, anyway.  Another check would be to test that such 
code fails to compile with -Wthread-safety -Werror set.  libcxx's test suite 
does support negative compilation tests but I can't find any way to specify 
that particular tests should be compiled with particular flags.  I tried 
enabling -Wthread-safety for all tests, but other tests fail because they do 
things that the annotations do not understand (deliberately, the annotations 
are for static checking not dynamic code analysis).  I could add suppressions 
to all of these tests but that seems backwards.  This also hits the problem 
that such annotations would only have meaning for new-enough versions of clang 
and there's no way for the driver to cleanly tell if the cxx being used 
supports the annotations or not.

The annotations are (by design) not supposed to have an influence on the 
program other than generating warnings in non-default configs so there isn't 
any  other testing hook I can think of.


http://reviews.llvm.org/D14731



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

[clang-tools-extra] r254477 - Force test to a target that supports thread_local

[Matthias Braun via cfe-commits]

Author: matze
Date: Tue Dec  1 19:12:06 2015
New Revision: 254477

URL: http://llvm.org/viewvc/llvm-project?rev=254477=rev
Log:
Force test to a target that supports thread_local

This should fix darwin bots.

Modified:
clang-tools-extra/trunk/test/clang-tidy/cert-static-object-exception.cpp

Modified: 
clang-tools-extra/trunk/test/clang-tidy/cert-static-object-exception.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/cert-static-object-exception.cpp?rev=254477=254476=254477=diff
==
--- clang-tools-extra/trunk/test/clang-tidy/cert-static-object-exception.cpp 
(original)
+++ clang-tools-extra/trunk/test/clang-tidy/cert-static-object-exception.cpp 
Tue Dec  1 19:12:06 2015
@@ -1,4 +1,4 @@
-// RUN: %check_clang_tidy %s cert-err58-cpp %t
+// RUN: %check_clang_tidy %s cert-err58-cpp %t -- -- -std=c++11 -target 
x86_64-pc-linux-gnu
 
 struct S {
   S() noexcept(false);


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

Re: [PATCH] D14639: LLDB JIT needs android vector passing rules.

[Reid Kleckner via cfe-commits]

rnk added a subscriber: rnk.
rnk added a comment.

Were these changes made to AOSP Clang to match upstream GCC, or some custom 
Android version of GCC? Where would one go to find ground truth on how these 
types should be passed?


http://reviews.llvm.org/D14639



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

Re: [PATCH] D15121: A new clang-tidy module to find calls to `std::swap`, and change them to use ADL

[Richard Smith via cfe-commits]

rsmith added a comment.

In http://reviews.llvm.org/D15121#300033, @LegalizeAdulthood wrote:

> I'm wondering if there isn't an existing module that would be a good fit for 
> this check.  Why not in the modernize module?


This isn't really modernization, it's a bug fix. ADL has always been the right 
way to find `swap`.



Comment at: clang-tidy/misc/StdSwapCheck.cpp:24
@@ +23,3 @@
+/// source location will be invalid.
+static SourceLocation findSemiAfterLocation(SourceLocation loc,
+ASTContext ,

Is there somewhere more central where this can live?


Comment at: clang-tidy/misc/StdSwapCheck.cpp:67
@@ +66,3 @@
+callExpr(callee(namedDecl(hasName("swap"))),
+
callee(expr(ignoringParenImpCasts(declRefExpr(has(nestedNameSpecifierLoc().bind("namespace"))).bind("swap"),
+this);

I think the two `callee` checks can be folded into one. Can you put the check 
that the namespace name is "std" in here too?


Comment at: clang-tidy/misc/StdSwapCheck.cpp:67
@@ +66,3 @@
+callExpr(callee(namedDecl(hasName("swap"))),
+
callee(expr(ignoringParenImpCasts(declRefExpr(has(nestedNameSpecifierLoc().bind("namespace"))).bind("swap"),
+this);

rsmith wrote:
> I think the two `callee` checks can be folded into one. Can you put the check 
> that the namespace name is "std" in here too?
Ignoring parens here will lead to your fixit not working. Instead of trying to 
replace the "std::" with "{ using std::swap; ", maybe it'd be better and safer 
to replace the entire callee with "{ using std::swap; swap"?


Comment at: clang-tidy/misc/StdSwapCheck.cpp:77
@@ +76,3 @@
+
+  if (nsStr == "std") {
+   const auto *swapNode = Result.Nodes.getNodeAs("swap");

Presumably this should also be checking that the parent of `nsNode` is the 
translation unit; we're not looking for a `std` nested within some other 
namespace here.


Comment at: clang-tidy/misc/StdSwapCheck.cpp:78-82
@@ +77,7 @@
+  if (nsStr == "std") {
+   const auto *swapNode = Result.Nodes.getNodeAs("swap");
+   QualType argType = swapNode->getArg(0)->getType();
+
+   if (!argType->isAnyPointerType() && !argType->isBuiltinType()) {
+ auto Diag = diag(nsNode->getBeginLoc(), "let the compiler find the 
right swap via ADL");
+

These lines seem underindented.


Comment at: clang-tidy/misc/StdSwapCheck.cpp:84-91
@@ +83,10 @@
+
+ const auto swapSourceRange = 
CharSourceRange::getCharRange(swapNode->getSourceRange());
+ SourceLocation semiLoc = 
findSemiAfterLocation(swapSourceRange.getEnd(), *Result.Context, false);
+ assert(semiLoc != SourceLocation());
+
+  nsSourceRange.setEnd(nsSourceRange.getEnd().getLocWithOffset(2));
+  Diag << FixItHint::CreateReplacement(nsSourceRange, "{ using std::swap; 
")
+   << FixItHint::CreateInsertion(semiLoc.getLocWithOffset(1), " }");
+}
+  }

This will do bad things if the `std::swap` is not at the start of the enclosing 
statement (or if there is no enclosing statement).


Comment at: docs/clang-tidy/checks/list.rst:35
@@ -34,2 +34,3 @@
llvm-twine-local
+   misc-StdSwap
misc-argument-comment

Why is it called StdSwap here and std-swap below?


Comment at: docs/clang-tidy/checks/misc-StdSwap.rst:6
@@ +5,3 @@
+
+The best practices for implementing swap for user-defined data structures is 
to implement a non-member swap in the same namespace as the type. Then, when 
you wish to swap to values `x` and `y`, you call `swap(x,y)` without a 
namespace, and ADL lookup will find it. Unfortunately this will not work for 
types that have overloads of swap in namespace std (standard library types and 
primitive types). So you have to bring them into play with a "using" statement.
+

practices -> practice
ADL lookup -> ADL / argument dependent lookup / argument dependent name lookup
swap -> `swap`
std -> `std`
"using" statement -> `using` declaration


Comment at: docs/clang-tidy/checks/misc-StdSwap.rst:14
@@ +13,3 @@
+
+This checker find this pattern and replaces it with the recommended usage; 
wrapping the call in a pair of brackets to scope the using directive. For 
builtin types (such as `int` and `float`), as well as pointers, it leaves the 
calls to `std::swap` alone, because those are correct.
+

brackets -> braces [the term "brackets" is ambiguous and implies different 
things in different dialects]


http://reviews.llvm.org/D15121



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

Re: [PATCH] D15025: [ThinLTO] Option to invoke ThinLTO backend passes and importing

[Mehdi AMINI via cfe-commits]

joker.eph added inline comments.


Comment at: lib/CodeGen/BackendUtil.cpp:290
@@ +289,3 @@
+  // setup for LTO compiles invoked via the gold plugin and the llvm-lto tool.
+  if (!CodeGenOpts.ThinLTOIndexFile.empty() && !CodeGenOpts.DisableLLVMOpts) {
+legacy::PassManager *MPM = getPerModulePasses();

The `!CodeGenOpts.DisableLLVMOpts` part is unclear to me. This may lead to 
unexpected user experience?


Comment at: lib/CodeGen/BackendUtil.cpp:308
@@ +307,3 @@
+PMB.populateLTOPassManager(*MPM);
+return;
+  }

This duplication of PMBuilder / CodeGenOpts setup is what triggered my initial 
comment.


Comment at: lib/CodeGen/BackendUtil.cpp:323
@@ -298,3 +322,3 @@
   PMBuilder.RerollLoops = CodeGenOpts.RerollLoops;
 
   PMBuilder.addExtension(PassManagerBuilder::EP_EarlyAsPossible,

Could you move your code here and reuse the same PBBuilder initialized here?
I expect that you don't need to do (almost) anything else than:

```
if (!CodeGenOpts.ThinLTOIndexFile.empty()) {
  legacy::PassManager *MPM = getPerModulePasses();
  PMB.populateLTOPassManager(MPM);
  return;
}
```


Comment at: lib/CodeGen/BackendUtil.cpp:390
@@ -365,3 +389,3 @@
   Triple TargetTriple(TheModule->getTargetTriple());
   PMBuilder.LibraryInfo = createTLII(TargetTriple, CodeGenOpts);
 

Could this be moved earlier so that it is before your code and you don't need 
to duplicate it?


Comment at: lib/CodeGen/BackendUtil.cpp:406-407
@@ -381,4 +405,4 @@
   PMBuilder.Inliner = createAlwaysInlinerPass();
 break;
   }
 

Could we move the inlining setup before your code so that you don't need to it?


Comment at: lib/CodeGen/CodeGenAction.cpp:796
@@ +795,3 @@
+std::function DiagHandler =
+std::bind(::diagnosticHandler, this, _1);
+

I think I didn't express what I meant by "name it", it can still be a lambda:

```
  auto DiagHandler = [&] (const DiagnosticInfo ) {
 linkerDiagnosticHandler(DI, TheModule.get(),
  getCompilerInstance().getDiagnostics());
  };
```

(there not real reason to use std::bind() for anything now that we have lambda 
I think)


Comment at: lib/CodeGen/CodeGenAction.cpp:824
@@ +823,3 @@
+
+  TheModule = std::move(Combined);
+  // Stash on the module object so it can be used by the function

Side note: I found terrible that we can't do the renaming/linkage upgrade 
in-place :(



http://reviews.llvm.org/D15025



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

Re: [PATCH] D14639: LLDB JIT needs android vector passing rules.

[Stephen Hines via cfe-commits]

srhines added a comment.

In http://reviews.llvm.org/D14639#300077, @rnk wrote:

> Were these changes made to AOSP Clang to match upstream GCC, or some custom 
> Android version of GCC? Where would one go to find ground truth on how these 
> types should be passed?


These changes are reverting to an existing behavior before it was changed in 
r166043. This has nothing to do with GCC, and is purely related to Clang/LLVM 
as used on Android starting with the Honeycomb release in 2011. Android had 
already shipped APIs that used ARM's original ext-vector calling conventions 
(which treated them more like homogeneous aggregates). Later on, the ARM ABI 
was amended to reflect what Apple shipped in this change:

  commit 97f81573636068fb9536436188caadf030584e58
  Author: Manman Ren 
  Date:   Tue Oct 16 19:18:39 2012 +
  
  ARM ABI: passing illegal vector types as varargs.
  
  We expand varargs in clang and the call site is handled in the back end, 
it 
  is
  hard to match exactly how illegal vectors are handled in the backend. 
Theref
  ore,
  we legalize the illegal vector types in clang:
  if (Size <= 32), legalize to i32.
  if (Size == 64), legalize to v2i32.
  if (Size == 128), legalize to v4i32.
  if (Size > 128), use indirect.
  
  rdar://12439123
  
  
  git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166043 
91177308-0d34-0410-b5e6-96231b3b80d8

This basically removes the need for a local patch that Android's platform 
toolchain/NDK has (and will continue to have), while other upstream users of 
Clang continue to generate potentially broken ext-vector code if they try to 
build using their own compiler.


http://reviews.llvm.org/D14639



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

Re: [PATCH] D15130: Fix the clang driver when "-nostdlib" is present

[Sumanth Gundapaneni via cfe-commits]

sgundapa updated this revision to Diff 41582.

http://reviews.llvm.org/D15130

Files:
  lib/Driver/Tools.cpp
  test/Driver/nostdlib.c

Index: test/Driver/nostdlib.c
===
--- test/Driver/nostdlib.c
+++ test/Driver/nostdlib.c
@@ -9,3 +9,19 @@
 // RUN: %clang -### -nostartfiles -nostdlib -target i386-apple-darwin %s \
 // RUN:   2>&1 | FileCheck %s -check-prefix=ARGSCLAIMED
 // ARGSCLAIMED-NOT: warning:
+
+// In the presence of -nostdlib, the standard libraries should not be
+// passed down to link line
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: -target i686-pc-linux-gnu -nostdlib --rtlib=compiler-rt \
+// RUN: -resource-dir=%S/Inputs/resource_dir -lclang_rt.builtins-i686 \
+// RUN:   | FileCheck --check-prefix=CHECK-LINUX-NOSTDLIB %s
+//
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: -target i686-pc-linux-gnu --rtlib=compiler-rt -nostdlib \
+// RUN: -resource-dir=%S/Inputs/resource_dir -lclang_rt.builtins-i686 \
+// RUN:   | FileCheck --check-prefix=CHECK-LINUX-NOSTDLIB %s
+//
+// CHECK-LINUX-NOSTDLIB: warning: argument unused during compilation: 
'--rtlib=compiler-rt'
+// CHECK-LINUX-NOSTDLIB: "{{(.*[^.0-9A-Z_a-z])?}}ld{{(.exe)?}}"
+// CHECK-LINUX-NOSTDLIB-NOT: 
"{{.*}}/Inputs/resource_dir{{/|}}lib{{/|}}linux{{/|}}libclang_rt.builtins-i686.a"
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -8694,8 +8694,7 @@
   if (!isAndroid)
 CmdArgs.push_back(Args.MakeArgString(ToolChain.GetFilePath("crtn.o")));
 }
-  } else if (Args.hasArg(options::OPT_rtlib_EQ))
-AddRunTimeLibs(ToolChain, D, CmdArgs, Args);
+  }
 
   C.addCommand(llvm::make_unique(JA, *this, Exec, CmdArgs, Inputs));
 }


Index: test/Driver/nostdlib.c
===
--- test/Driver/nostdlib.c
+++ test/Driver/nostdlib.c
@@ -9,3 +9,19 @@
 // RUN: %clang -### -nostartfiles -nostdlib -target i386-apple-darwin %s \
 // RUN:   2>&1 | FileCheck %s -check-prefix=ARGSCLAIMED
 // ARGSCLAIMED-NOT: warning:
+
+// In the presence of -nostdlib, the standard libraries should not be
+// passed down to link line
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: -target i686-pc-linux-gnu -nostdlib --rtlib=compiler-rt \
+// RUN: -resource-dir=%S/Inputs/resource_dir -lclang_rt.builtins-i686 \
+// RUN:   | FileCheck --check-prefix=CHECK-LINUX-NOSTDLIB %s
+//
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: -target i686-pc-linux-gnu --rtlib=compiler-rt -nostdlib \
+// RUN: -resource-dir=%S/Inputs/resource_dir -lclang_rt.builtins-i686 \
+// RUN:   | FileCheck --check-prefix=CHECK-LINUX-NOSTDLIB %s
+//
+// CHECK-LINUX-NOSTDLIB: warning: argument unused during compilation: '--rtlib=compiler-rt'
+// CHECK-LINUX-NOSTDLIB: "{{(.*[^.0-9A-Z_a-z])?}}ld{{(.exe)?}}"
+// CHECK-LINUX-NOSTDLIB-NOT: "{{.*}}/Inputs/resource_dir{{/|}}lib{{/|}}linux{{/|}}libclang_rt.builtins-i686.a"
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -8694,8 +8694,7 @@
   if (!isAndroid)
 CmdArgs.push_back(Args.MakeArgString(ToolChain.GetFilePath("crtn.o")));
 }
-  } else if (Args.hasArg(options::OPT_rtlib_EQ))
-AddRunTimeLibs(ToolChain, D, CmdArgs, Args);
+  }
 
   C.addCommand(llvm::make_unique(JA, *this, Exec, CmdArgs, Inputs));
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r254485 - clang/test/Driver/crash-report-modules.m: Avoid using /tmp/.

[NAKAMURA Takumi via cfe-commits]

Author: chapuni
Date: Tue Dec  1 21:13:50 2015
New Revision: 254485

URL: http://llvm.org/viewvc/llvm-project?rev=254485=rev
Log:
clang/test/Driver/crash-report-modules.m: Avoid using /tmp/.

Temporary directories should be controlled with $LIT_PRESERVES_TMP.

Modified:
cfe/trunk/test/Driver/crash-report-modules.m

Modified: cfe/trunk/test/Driver/crash-report-modules.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/crash-report-modules.m?rev=254485=254484=254485=diff
==
--- cfe/trunk/test/Driver/crash-report-modules.m (original)
+++ cfe/trunk/test/Driver/crash-report-modules.m Tue Dec  1 21:13:50 2015
@@ -1,9 +1,9 @@
 // RUN: rm -rf %t
-// RUN: mkdir %t
+// RUN: mkdir -p %t/i %t/m %t
 
 // RUN: not env FORCE_CLANG_DIAGNOSTICS_CRASH= TMPDIR=%t TEMP=%t TMP=%t \
-// RUN: %clang -fsyntax-only %s -I %S/Inputs/module -isysroot /tmp/ \
-// RUN: -fmodules -fmodules-cache-path=/tmp/ -DFOO=BAR 2>&1 | FileCheck %s
+// RUN: %clang -fsyntax-only %s -I %S/Inputs/module -isysroot %/t/i/\
+// RUN: -fmodules -fmodules-cache-path=%t/m/ -DFOO=BAR 2>&1 | FileCheck %s
 
 // RUN: FileCheck --check-prefix=CHECKSRC %s -input-file %t/crash-report-*.m
 // RUN: FileCheck --check-prefix=CHECKSH %s -input-file %t/crash-report-*.sh
@@ -30,8 +30,8 @@ const int x = MODULE_MACRO;
 // CHECKSH-SAME: "-D" "FOO=BAR"
 // CHECKSH-NEXT: # Original command: {{.*$}}
 // CHECKSH-NEXT: "-cc1"
-// CHECKSH: "-isysroot" "/tmp/"
+// CHECKSH: "-isysroot" "{{[^"]*}}/i/"
 // CHECKSH: "-D" "FOO=BAR"
-// CHECKSH-NOT: "-fmodules-cache-path=/tmp/"
+// CHECKSH-NOT: "-fmodules-cache-path="
 // CHECKSH: "crash-report-modules-{{[^ ]*}}.m"
 // CHECKSH: "-ivfsoverlay" "crash-report-modules-{{[^ ]*}}.cache/vfs/vfs.yaml"


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

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[Eric Christopher via cfe-commits]

Hi James,

I disagree with you completely on every point except that you need to write
new tests.

There is absolutely, as I said in the thread where I noticed this for the
x86 intrinsics, that you cannot supply this test up and test it in the
front and the back end separately. If you believe this is impossible please
let me know why, but clang and llvm are designed to be tested as I stated.
As far as prior art, I can only apologize that I didn't see them before,
I'm sure you know how hard it is to review everything.

Thanks

-eric

On Tue, Dec 1, 2015, 3:44 AM James Molloy  wrote:

Hi Eric,

While I agree with you in principle, Alexandros has just pointed out to me
that all the other NEON intrinsics have such -O3 tests, and thinking about
it I do think they add value. They test the full-trip through the compiler
and ensure that Clang and LLVM have matching ideas of the IR interface
exposed by the intrinsics.

AIUI, Alexandros wrote LLVM backend tests in addition to these. It does
look like there are no tests just checking Clang's IR output - I think
these should indeed be written.

In summary, I agree with you that we need tests for both Clang and LLVM
separately. However I also think the full-trip tests add significant value
and wouldn't like to see them removed, and there's significant prior art in
this area so if we did decide they needed to be gone, we'd need a good
discussion on how to regain the testing coverage we'd lose.



Cheers,

James

On Sun, 29 Nov 2015 at 20:40 Eric Christopher via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

Hi,

This is entirely the wrong way to do these tests. They shouldn't depend on
assembly output or optimization. Please split them onto frontend IR tests
and backend assembly tests.

Thanks!

On Sun, Nov 29, 2015, 2:56 AM Alexandros Lamprineas via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

Author: alelab01
Date: Sun Nov 29 04:53:28 2015
New Revision: 254251

URL: http:// 
llvm.org /
viewvc
/
llvm-project

?rev=254251=rev

Log:
ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply
Add/Subtract.

Add missing tests that accidentally were not committed in rL254250.

Differential Revision: http:// 
reviews.llvm.org /D14982


Added:
cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c
cfe/trunk/test/CodeGen/arm-v8.1a-neon-intrinsics.c

Added: cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c
URL: http://

llvm.org

/

viewvc

/

llvm-project

/

cfe

/trunk/test/

CodeGen

/

aarch64-v8.1a-neon-intrinsics.c

?rev=254251=auto

==
--- cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c (added)
+++ cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c Sun Nov 29
04:53:28 2015
@@ -0,0 +1,128 @@
+// REQUIRES: aarch64-registered-target
+
+// RUN: %clang_cc1 -triple aarch64-linux-gnu -target-feature +neon \
+// RUN:  -target-feature +v8.1a -O3 -S -o - %s \
+// RUN:  | FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-AARCH64
+
+ #include 
+
+// CHECK-AARCH64-LABEL: test_vqrdmlah_laneq_s16
+int16x4_t 

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[James Molloy via cfe-commits]

Hi Eric,

This isn't just a NEON intrinsics thing, and this isn't just an ARM/AArch64
thing. There needs to be some way to test the compiler from start to
finish. Not being able to do so leaves serious coverage holes.

Unit testing is great, but integration testing is required sometimes to
ensure multiple units interface as expected. I could grab a bunch of
examples from the clang tests directory that my grep has just thrown up -
CodeGen/nobuiltin.c, for example, or
CodeGen/aarch64-fix-cortex-a53-835769.c, where we absolutely 100% must
ensure that the -mfix-cortex-a53-835769 flag gets properly respected in the
compiler output.

If you can describe a way to get the same strength of testing without
running the backend during clang tests, I'm all ears!

James

On Tue, 1 Dec 2015 at 16:59 Eric Christopher  wrote:

> Hi James,
>
> I disagree with you completely on every point except that you need to
> write new tests.
>
> There is absolutely, as I said in the thread where I noticed this for the
> x86 intrinsics, that you cannot supply this test up and test it in the
> front and the back end separately. If you believe this is impossible please
> let me know why, but clang and llvm are designed to be tested as I stated.
> As far as prior art, I can only apologize that I didn't see them before,
> I'm sure you know how hard it is to review everything.
>
> Thanks
>
> -eric
>
> On Tue, Dec 1, 2015, 3:44 AM James Molloy  wrote:
>
> Hi Eric,
>
> While I agree with you in principle, Alexandros has just pointed out to me
> that all the other NEON intrinsics have such -O3 tests, and thinking about
> it I do think they add value. They test the full-trip through the compiler
> and ensure that Clang and LLVM have matching ideas of the IR interface
> exposed by the intrinsics.
>
> AIUI, Alexandros wrote LLVM backend tests in addition to these. It does
> look like there are no tests just checking Clang's IR output - I think
> these should indeed be written.
>
> In summary, I agree with you that we need tests for both Clang and LLVM
> separately. However I also think the full-trip tests add significant value
> and wouldn't like to see them removed, and there's significant prior art in
> this area so if we did decide they needed to be gone, we'd need a good
> discussion on how to regain the testing coverage we'd lose.
>
>
>
> Cheers,
>
> James
>
> On Sun, 29 Nov 2015 at 20:40 Eric Christopher via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> Hi,
>
> This is entirely the wrong way to do these tests. They shouldn't depend on
> assembly output or optimization. Please split them onto frontend IR tests
> and backend assembly tests.
>
> Thanks!
>
> On Sun, Nov 29, 2015, 2:56 AM Alexandros Lamprineas via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> Author: alelab01
> Date: Sun Nov 29 04:53:28 2015
> New Revision: 254251
>
> URL: http:// 
> llvm.org /
> viewvc
> /
> llvm-project
> 
> ?rev=254251=rev
> 
> Log:
> ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply
> Add/Subtract.
>
> Add missing tests that accidentally were not committed in rL254250.
>
> Differential Revision: http:// 
> reviews.llvm.org /D14982
> 
>
> Added:
> cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c
> cfe/trunk/test/CodeGen/arm-v8.1a-neon-intrinsics.c
>
> Added: cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c
> URL: http://
> 
> llvm.org
> 
> /
> 
> viewvc
> 
> /
> 
> llvm-project
> 
> /
> 
> cfe
> 
> /trunk/test/
> 
> CodeGen
> 

Re: [PATCH] D14180: enable -fms-extensions by default on the mingw-w64 target

[Reid Kleckner via cfe-commits]

rnk added a comment.

In http://reviews.llvm.org/D14180#299183, @martell wrote:

> I tried testing __has_builtin(_InterlockedCompareExchangeAdd) as it seem to 
> not exist even when -fms-extensions is passed
>  Is this a bug or it is intended ?


Neither Clang nor MSDN have anything by that name. Do you mean 
_InterlockedExchangeAdd? __has_builtin should find that.


http://reviews.llvm.org/D14180



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

r254423 - It appears that this horrible mutating copy constructor is unused. Kill it with fire.

[Aaron Ballman via cfe-commits]

Author: aaronballman
Date: Tue Dec  1 11:15:13 2015
New Revision: 254423

URL: http://llvm.org/viewvc/llvm-project?rev=254423=rev
Log:
It appears that this horrible mutating copy constructor is unused. Kill it with 
fire.

Modified:
cfe/trunk/include/clang/Sema/AttributeList.h

Modified: cfe/trunk/include/clang/Sema/AttributeList.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/AttributeList.h?rev=254423=254422=254423=diff
==
--- cfe/trunk/include/clang/Sema/AttributeList.h (original)
+++ cfe/trunk/include/clang/Sema/AttributeList.h Tue Dec  1 11:15:13 2015
@@ -557,11 +557,6 @@ public:
   /// Create a new pool for a factory.
   AttributePool(AttributeFactory ) : Factory(factory), Head(nullptr) {}
 
-  /// Move the given pool's allocations to this pool.
-  AttributePool(AttributePool ) : Factory(pool.Factory), Head(pool.Head) {
-pool.Head = nullptr;
-  }
-
   AttributeFactory () const { return Factory; }
 
   void clear() {


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

Re: [PATCH] D14180: enable -fms-extensions by default on the mingw-w64 target

[Ismail Donmez via cfe-commits]

On Tue, Dec 1, 2015 at 8:06 PM, Ismail Donmez  wrote:
> Hi,
>
> On Tue, Dec 1, 2015 at 7:45 PM, Reid Kleckner via cfe-commits
>  wrote:
>> rnk added a comment.
>>
>> In http://reviews.llvm.org/D14180#299183, @martell wrote:
>>
>>> I tried testing __has_builtin(_InterlockedCompareExchangeAdd) as it seem to 
>>> not exist even when -fms-extensions is passed
>>>  Is this a bug or it is intended ?
>>
>>
>> Neither Clang nor MSDN have anything by that name. Do you mean 
>> _InterlockedExchangeAdd? __has_builtin should find that.
>
> MSDN knows about it though:
> https://msdn.microsoft.com/en-us/library/windows/desktop/ttk2z1ws(v=vs.85).aspx

Never mind, misread the function name.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D14180: enable -fms-extensions by default on the mingw-w64 target

[Ismail Donmez via cfe-commits]

Hi,

On Tue, Dec 1, 2015 at 7:45 PM, Reid Kleckner via cfe-commits
 wrote:
> rnk added a comment.
>
> In http://reviews.llvm.org/D14180#299183, @martell wrote:
>
>> I tried testing __has_builtin(_InterlockedCompareExchangeAdd) as it seem to 
>> not exist even when -fms-extensions is passed
>>  Is this a bug or it is intended ?
>
>
> Neither Clang nor MSDN have anything by that name. Do you mean 
> _InterlockedExchangeAdd? __has_builtin should find that.

MSDN knows about it though:
https://msdn.microsoft.com/en-us/library/windows/desktop/ttk2z1ws(v=vs.85).aspx
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D13015: [X86] Make f16c intrinsics accessible through emmintrin.h, per Intel docs

[Paul Robinson via cfe-commits]

probinson added a comment.

Thanks Michael!  Moving the mm256 stuff to immintrin.h ought to work.  What 
actually motivates this is mucking around with modularizing the intrinsic 
headers, and the immediate problem is the duplicate typedefs for __v8sf and 
__m256 (which are in both f16cintrin.h and avxintrin.h).  If we move the mm256 
intrinsics to a point in immintrin.h that comes after where it includes 
avxintrin.h, then the duplicate typedefs can go away.

I'll see if I can get a patch for this up today.


Repository:
  rL LLVM

http://reviews.llvm.org/D13015



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

[PATCH] D15121: A new clang-tidy module to find calls to `std::swap`, and change them to use ADL

[Marshall Clow via cfe-commits]

mclow.lists created this revision.
mclow.lists added reviewers: klimek, aaron.ballman, chandlerc.
mclow.lists added a subscriber: cfe-commits.

Motivation: LLVM has many overloads of `std::swap` for its own types. This is 
technically forbidden by the standard, but is pervasive in the LLVM code base. 
The correct fix for this is to put them in the same namespace as the thing that 
they are swapping - but do do this, we have to find (and fix) all the places 
where we call `std::swap` explicitly, and let ADL do the finding instead.

The basic transform is:
std::swap(x, y) --> { using std::swap; swap(x, y); }

This is the first cut at a tool to do this.
It's not quite right, in that it does this instead:
std::swap(x, y) --> { using std::swap; :swap(x, y); }
and I'm not quite sure why.

Also, the checking for builtin types and pointers needs to go into the matcher 
instead of the code. 

Thanks to Manuel and Aaron for helping with this


http://reviews.llvm.org/D15121

Files:
  clang-tidy/misc/CMakeLists.txt
  clang-tidy/misc/MiscTidyModule.cpp
  clang-tidy/misc/StdSwapCheck.cpp
  clang-tidy/misc/StdSwapCheck.h
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/misc-StdSwap.rst
  test/clang-tidy/misc-StdSwap.cpp

Index: test/clang-tidy/misc-StdSwap.cpp
===
--- test/clang-tidy/misc-StdSwap.cpp
+++ test/clang-tidy/misc-StdSwap.cpp
@@ -0,0 +1,63 @@
+// RUN: %check_clang_tidy %s misc-StdSwap %t
+
+#include 
+
+// FIXME: Add something that triggers the check here.
+// FIXME: Verify the applied fix.
+//   * Make the CHECK patterns specific enough and try to make verified lines
+// unique to avoid incorrect matches.
+//   * Use {{}} for regular expressions.
+
+// Bad code; don't overload in namespace std
+struct S1 { int x; };
+namespace std { void swap(S1& x, S1 ) { swap(x.x, y.x); } };
+
+// Swap in namespace with type
+namespace foo { struct S2 { int i; }; void swap(S2& x, S2& y) {std::swap(x.i, y.i); } }
+
+// Swap in namespace.
+namespace bar { void swap(int, int) {} }
+
+void test0()
+{
+	S1 i,j;
+	std::swap(i,j);
+  // CHECK-MESSAGES: :[[@LINE-1]]:31: warning: let the compiler find the right swap via ADL:
+  // CHECK-FIXES: { using std::swap; swap(i,j); }
+}
+
+void test1(bool b)
+{
+	foo::S2 x,y;
+	if ( b )
+		std::swap(x,y);
+  // CHECK-MESSAGES: :[[@LINE-1]]:31: warning: let the compiler find the right swap via ADL:
+  // CHECK-FIXES: { using std::swap; swap(x,y); }
+}
+
+
+void test_neg0()	// Swap two builtins
+{
+	{
+	int i,j;
+	std::swap(i,j);
+	}
+	{
+	float i,j;
+	std::swap(i,j);
+	}
+}
+
+void test_neg1()	// std::swap two pointers
+
+{
+	S1 *i, *j;
+	std::swap(i,j);
+}
+
+void test_neg2()  // Call a namespace-qualified swap that isn't "std::"
+{
+	int i,j;
+	bar::swap(i,j);
+}
+
Index: docs/clang-tidy/checks/misc-StdSwap.rst
===
--- docs/clang-tidy/checks/misc-StdSwap.rst
+++ docs/clang-tidy/checks/misc-StdSwap.rst
@@ -0,0 +1,19 @@
+misc-StdSwap
+
+
+Adding an overload for `std:swap` (in the `std` namespace) is explicitly forbidden by the standard. 
+
+The best practices for implementing swap for user-defined data structures is to implement a non-member swap in the same namespace as the type. Then, when you wish to swap to values `x` and `y`, you call `swap(x,y)` without a namespace, and ADL lookup will find it. Unfortunately this will not work for types that have overloads of swap in namespace std (standard library types and primitive types). So you have to bring them into play with a "using" statement.
+
+Instead of writing:
+> std::swap(x,y);
+
+you should write:
+> using std::swap; swap(x,y);
+
+This checker find this pattern and replaces it with the recommended usage; wrapping the call in a pair of brackets to scope the using directive. For builtin types (such as `int` and `float`), as well as pointers, it leaves the calls to `std::swap` alone, because those are correct.
+
+FUTURE WORK: 
+
+Find overloads of `swap` in namespace std and put them in the correct namespace.
+
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -32,6 +32,7 @@
llvm-include-order
llvm-namespace-comment
llvm-twine-local
+   misc-StdSwap
misc-argument-comment
misc-assert-side-effect
misc-assign-operator-signature
@@ -46,6 +47,7 @@
misc-non-copyable-objects
misc-sizeof-container
misc-static-assert
+   misc-std-swap
misc-swapped-arguments
misc-throw-by-value-catch-by-reference
misc-undelegated-constructor
Index: clang-tidy/misc/StdSwapCheck.h
===
--- clang-tidy/misc/StdSwapCheck.h
+++ clang-tidy/misc/StdSwapCheck.h
@@ -0,0 +1,34 @@
+//===--- StdSwapCheck.h - clang-tidy-*- C++ -*-===//
+//
+//  

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[David Blaikie via cfe-commits]

On Tue, Dec 1, 2015 at 9:56 AM, Renato Golin via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On 1 December 2015 at 17:23, James Molloy via cfe-commits
>  wrote:
> > This isn't just a NEON intrinsics thing, and this isn't just an
> ARM/AArch64
> > thing. There needs to be some way to test the compiler from start to
> finish.
> > Not being able to do so leaves serious coverage holes.
>
> Just for the sake of completeness, a hole that the test-suite doesn't
> cover.
>

Are they things the test-suite couldn't (either technically or
philosophically) cover, or only that it doesn't cover it at the moment, but
could do so?


>
>
> > CodeGen/aarch64-fix-cortex-a53-835769.c, where we absolutely 100% must
> > ensure that the -mfix-cortex-a53-835769 flag gets properly respected in
> the
> > compiler output.
>
> SIMD intrinsics (including NEON, SSE), Errata fixes, Procedure call
> tests, ELF section placement, FP contracts, Debug info, Inline
> assembly, Unicode support, object creation, library symbol clashes,
> back-end diagnostics are some of the examples that need to go all the
> way to asm or object code.
>
>
> > If you can describe a way to get the same strength of testing without
> > running the backend during clang tests, I'm all ears!
>
> I'm particularly interested in how do we keep the IR printed in the
> Clang tests in sync with the IR sent to the LLVM tests if/when they
> change, to guarantee that Clang changes don't generate silent codegen
> faults down the line in LLVM and vice-versa.
>

That would sort of defeat the point of having the testing and projects
separated though - it would tie the tests together and produce most of the
undesirable outcomes of having single end-to-end tests.

(it would mean that at least the pure (or at least non-Clang) LLVM
developer would have a test to run where they would not if the test
remained in Clang only)


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

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[Renato Golin via cfe-commits]

On 1 December 2015 at 17:23, James Molloy via cfe-commits
 wrote:
> This isn't just a NEON intrinsics thing, and this isn't just an ARM/AArch64
> thing. There needs to be some way to test the compiler from start to finish.
> Not being able to do so leaves serious coverage holes.

Just for the sake of completeness, a hole that the test-suite doesn't cover.


> CodeGen/aarch64-fix-cortex-a53-835769.c, where we absolutely 100% must
> ensure that the -mfix-cortex-a53-835769 flag gets properly respected in the
> compiler output.

SIMD intrinsics (including NEON, SSE), Errata fixes, Procedure call
tests, ELF section placement, FP contracts, Debug info, Inline
assembly, Unicode support, object creation, library symbol clashes,
back-end diagnostics are some of the examples that need to go all the
way to asm or object code.


> If you can describe a way to get the same strength of testing without
> running the backend during clang tests, I'm all ears!

I'm particularly interested in how do we keep the IR printed in the
Clang tests in sync with the IR sent to the LLVM tests if/when they
change, to guarantee that Clang changes don't generate silent codegen
faults down the line in LLVM and vice-versa.

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

[PATCH] D15120: Add support for __float128 type to be used by targets that support it

[Nemanja Ivanovic via cfe-commits]

nemanjai created this revision.
nemanjai added reviewers: hfinkel, wschmidt, kbarton, rsmith.
nemanjai added a subscriber: cfe-commits.
nemanjai set the repository for this revision to rL LLVM.
Herald added a subscriber: klimek.

This patch adds support for the __float128 keyword and literals for IEEE Quad 
Precision.

There are still unanswered questions so this is not meant as an approval draft. 
I am hoping to solicit feedback regarding various aspects of this patch - 
particularly the FIXME's that I've put into the code.

Repository:
  rL LLVM

http://reviews.llvm.org/D15120

Files:
  bindings/python/clang/cindex.py
  include/clang-c/Index.h
  include/clang/AST/ASTContext.h
  include/clang/AST/BuiltinTypes.def
  include/clang/AST/Type.h
  include/clang/AST/TypeLoc.h
  include/clang/Analysis/Analyses/ThreadSafetyTIL.h
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/Specifiers.h
  include/clang/Basic/TargetInfo.h
  include/clang/Basic/TokenKinds.def
  include/clang/Driver/Options.td
  include/clang/Lex/LiteralSupport.h
  include/clang/Sema/DeclSpec.h
  include/clang/Serialization/ASTBitCodes.h
  lib/AST/ASTContext.cpp
  lib/AST/ItaniumMangle.cpp
  lib/AST/MicrosoftMangle.cpp
  lib/AST/NSAPI.cpp
  lib/AST/StmtPrinter.cpp
  lib/AST/Type.cpp
  lib/AST/TypeLoc.cpp
  lib/Analysis/PrintfFormatString.cpp
  lib/Basic/TargetInfo.cpp
  lib/Basic/Targets.cpp
  lib/CodeGen/CGDebugInfo.cpp
  lib/CodeGen/CGExprScalar.cpp
  lib/CodeGen/CodeGenTypes.cpp
  lib/CodeGen/ItaniumCXXABI.cpp
  lib/CodeGen/TargetInfo.cpp
  lib/Format/FormatToken.cpp
  lib/Frontend/InitPreprocessor.cpp
  lib/Index/USRGeneration.cpp
  lib/Lex/LiteralSupport.cpp
  lib/Parse/ParseDecl.cpp
  lib/Parse/ParseExpr.cpp
  lib/Parse/ParseExprCXX.cpp
  lib/Parse/ParseTentative.cpp
  lib/Sema/DeclSpec.cpp
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaLookup.cpp
  lib/Sema/SemaOverload.cpp
  lib/Sema/SemaTemplateVariadic.cpp
  lib/Sema/SemaType.cpp
  lib/Serialization/ASTCommon.cpp
  lib/Serialization/ASTReader.cpp
  test/CodeGenCXX/float128-declarations.cpp
  test/Sema/128bitfloat.cpp
  test/SemaCXX/deleted-operator.cpp
  test/SemaCXX/overloaded-builtin-operators.cpp
  tools/libclang/CXType.cpp

Index: tools/libclang/CXType.cpp
===
--- tools/libclang/CXType.cpp
+++ tools/libclang/CXType.cpp
@@ -51,6 +51,7 @@
 BTCASE(Float);
 BTCASE(Double);
 BTCASE(LongDouble);
+BTCASE(Float128);
 BTCASE(NullPtr);
 BTCASE(Overload);
 BTCASE(Dependent);
@@ -460,6 +461,7 @@
 TKIND(Float);
 TKIND(Double);
 TKIND(LongDouble);
+TKIND(Float128);
 TKIND(NullPtr);
 TKIND(Overload);
 TKIND(Dependent);
Index: test/SemaCXX/overloaded-builtin-operators.cpp
===
--- test/SemaCXX/overloaded-builtin-operators.cpp
+++ test/SemaCXX/overloaded-builtin-operators.cpp
@@ -183,7 +183,7 @@
   // FIXME: lots of candidates here!
   (void)(1.0f * a); // expected-error{{ambiguous}} \
 // expected-note 4{{candidate}} \
-// expected-note {{remaining 117 candidates omitted; pass -fshow-overloads=all to show them}}
+// expected-note {{remaining 140 candidates omitted; pass -fshow-overloads=all to show them}}
 }
 
 // pr5432
Index: test/SemaCXX/deleted-operator.cpp
===
--- test/SemaCXX/deleted-operator.cpp
+++ test/SemaCXX/deleted-operator.cpp
@@ -9,7 +9,7 @@
   PR10757 a1;
   // FIXME: We get a ridiculous number of "built-in candidate" notes here...
   if(~a1) {} // expected-error {{overload resolution selected deleted operator}} expected-note 8 {{built-in candidate}}
-  if(a1==a1) {} // expected-error {{overload resolution selected deleted operator}} expected-note 121 {{built-in candidate}}
+  if(a1==a1) {} // expected-error {{overload resolution selected deleted operator}} expected-note 144 {{built-in candidate}}
 }
 
 struct DelOpDel {
Index: test/Sema/128bitfloat.cpp
===
--- test/Sema/128bitfloat.cpp
+++ test/Sema/128bitfloat.cpp
@@ -2,23 +2,23 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -std=c++11 %s
 
 #if !defined(__STRICT_ANSI__)
-__float128 f;  // expected-error {{support for type '__float128' is not yet implemented}}
+__float128 f;  // expected-error {{__float128 is not supported on this target}}
 // But this should work:
 template struct __is_floating_point_helper {};
-template<> struct __is_floating_point_helper<__float128> {};
+template<> struct __is_floating_point_helper<__float128> {};  // expected-error {{__float128 is not supported on this target}}
 
 // FIXME: This could have a better diag.
-void g(int x, __float128 *y) {
-  x + *y;  // expected-error {{invalid operands to binary expression ('int' and '__float128')}}
+int g(int x, __float128 *y) {  // expected-error {{__float128 is not 

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[Eric Christopher via cfe-commits]

On Tue, Dec 1, 2015 at 9:23 AM James Molloy  wrote:

> Hi Eric,
>
> This isn't just a NEON intrinsics thing, and this isn't just an
> ARM/AArch64 thing. There needs to be some way to test the compiler from
> start to finish. Not being able to do so leaves serious coverage holes.
>
> Unit testing is great, but integration testing is required sometimes to
> ensure multiple units interface as expected. I could grab a bunch of
> examples from the clang tests directory that my grep has just thrown up -
> CodeGen/nobuiltin.c, for example, or
> CodeGen/aarch64-fix-cortex-a53-835769.c, where we absolutely 100% must
> ensure that the -mfix-cortex-a53-835769 flag gets properly respected in the
> compiler output.
>
>
The code gen one is easy. "Did the subtarget feature get passed to the
backend"?

Then in the backend make sure that the pass ran by either checking the
output or checking the debug output. Simple.

I haven't looked at the other one at the moment.

-eric


> If you can describe a way to get the same strength of testing without
> running the backend during clang tests, I'm all ears!
>
> James
>
> On Tue, 1 Dec 2015 at 16:59 Eric Christopher  wrote:
>
>> Hi James,
>>
>> I disagree with you completely on every point except that you need to
>> write new tests.
>>
>> There is absolutely, as I said in the thread where I noticed this for the
>> x86 intrinsics, that you cannot supply this test up and test it in the
>> front and the back end separately. If you believe this is impossible please
>> let me know why, but clang and llvm are designed to be tested as I stated.
>> As far as prior art, I can only apologize that I didn't see them before,
>> I'm sure you know how hard it is to review everything.
>>
>> Thanks
>>
>> -eric
>>
>> On Tue, Dec 1, 2015, 3:44 AM James Molloy 
>> wrote:
>>
>> Hi Eric,
>>
>> While I agree with you in principle, Alexandros has just pointed out to
>> me that all the other NEON intrinsics have such -O3 tests, and thinking
>> about it I do think they add value. They test the full-trip through the
>> compiler and ensure that Clang and LLVM have matching ideas of the IR
>> interface exposed by the intrinsics.
>>
>> AIUI, Alexandros wrote LLVM backend tests in addition to these. It does
>> look like there are no tests just checking Clang's IR output - I think
>> these should indeed be written.
>>
>> In summary, I agree with you that we need tests for both Clang and LLVM
>> separately. However I also think the full-trip tests add significant value
>> and wouldn't like to see them removed, and there's significant prior art in
>> this area so if we did decide they needed to be gone, we'd need a good
>> discussion on how to regain the testing coverage we'd lose.
>>
>>
>>
>> Cheers,
>>
>> James
>>
>> On Sun, 29 Nov 2015 at 20:40 Eric Christopher via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>> Hi,
>>
>> This is entirely the wrong way to do these tests. They shouldn't depend
>> on assembly output or optimization. Please split them onto frontend IR
>> tests and backend assembly tests.
>>
>> Thanks!
>>
>> On Sun, Nov 29, 2015, 2:56 AM Alexandros Lamprineas via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>> Author: alelab01
>> Date: Sun Nov 29 04:53:28 2015
>> New Revision: 254251
>>
>> URL: http:// 
>> llvm.org /
>> viewvc
>> /
>> llvm-project
>> 
>> ?rev=254251=rev
>> 
>> Log:
>> ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply
>> Add/Subtract.
>>
>> Add missing tests that accidentally were not committed in rL254250.
>>
>> Differential Revision: http:// 
>> reviews.llvm.org /D14982
>> 
>>
>> Added:
>> cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c
>> cfe/trunk/test/CodeGen/arm-v8.1a-neon-intrinsics.c
>>
>> Added: cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c
>> URL: http://
>> 
>> llvm.org
>> 
>> /
>> 
>> viewvc
>> 
>> /
>> 
>> llvm-project
>> 

Re: [PATCH] D15127: Move _mm256_cvtps_ph and _mm256_cvtph_ps to immintrin.h.

[Michael Kuperstein via cfe-commits]

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

Thanks Paul, LGTM.


http://reviews.llvm.org/D15127



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

[PATCH] D15140: Update clang to use the updated LLVM EH instructions

[David Majnemer via cfe-commits]

majnemer created this revision.
majnemer added a reviewer: rnk.
majnemer added a subscriber: cfe-commits.
majnemer added a dependency: D15139: [IR] Reformulate LLVM's EH funclet IR.

Depends on D15139.

http://reviews.llvm.org/D15140

Files:
  lib/CodeGen/CGCall.cpp
  lib/CodeGen/CGCleanup.cpp
  lib/CodeGen/CGCleanup.h
  lib/CodeGen/CGException.cpp
  lib/CodeGen/CodeGenFunction.h
  lib/CodeGen/EHScopeStack.h
  lib/CodeGen/MicrosoftCXXABI.cpp
  test/CodeGen/exceptions-seh-finally.c
  test/CodeGen/exceptions-seh-leave.c
  test/CodeGen/exceptions-seh.c
  test/CodeGenCXX/exceptions-cxx-new.cpp
  test/CodeGenCXX/exceptions-seh.cpp
  test/CodeGenCXX/microsoft-abi-arg-order.cpp
  test/CodeGenCXX/microsoft-abi-eh-catch.cpp
  test/CodeGenCXX/microsoft-abi-eh-cleanups.cpp
  test/CodeGenCXX/microsoft-abi-eh-terminate.cpp
  test/CodeGenCXX/microsoft-abi-thread-safe-statics.cpp
  test/CodeGenCXX/microsoft-abi-try-throw.cpp

Index: test/CodeGenCXX/microsoft-abi-try-throw.cpp
===
--- test/CodeGenCXX/microsoft-abi-try-throw.cpp
+++ test/CodeGenCXX/microsoft-abi-try-throw.cpp
@@ -19,7 +19,7 @@
 external(); // TRY: invoke void @"\01?external@@YAXXZ"
   } catch (int) {
 rv = 1;
-// TRY: catchpad [%rtti.TypeDescriptor2* @"\01??_R0H@8", i32 0, i8* null]
+// TRY: catchpad %0 [%rtti.TypeDescriptor2* @"\01??_R0H@8", i32 0, i8* null]
 // TRY: catchret
   }
 #endif
@@ -39,7 +39,7 @@
 external();
   } catch (const int *) {
   }
-  // TRY: catchpad [%rtti.TypeDescriptor4* @"\01??_R0PAH@8", i32 1, i8* null]
+  // TRY: catchpad %0 [%rtti.TypeDescriptor4* @"\01??_R0PAH@8", i32 1, i8* null]
   // TRY: catchret
 }
 #endif
Index: test/CodeGenCXX/microsoft-abi-thread-safe-statics.cpp
===
--- test/CodeGenCXX/microsoft-abi-thread-safe-statics.cpp
+++ test/CodeGenCXX/microsoft-abi-thread-safe-statics.cpp
@@ -39,7 +39,7 @@
 // CHECK-NEXT:  ret %struct.S* @"\01?s@?1??f@@YAAAUS@@XZ@4U2@A"
 
 // CHECK: [[lpad:.*]]:
-// CHECK-NEXT: cleanuppad []
+// CHECK-NEXT: cleanuppad none []
 // CHECK:   %[[guard:.*]] = load i32, i32* @"\01??__J?1??f@@YAAAUS@@XZ@51"
 // CHECK-NEXT:  %[[mask:.*]] = and i32 %[[guard]], -2
 // CHECK-NEXT:  store i32 %[[mask]], i32* @"\01??__J?1??f@@YAAAUS@@XZ@51"
@@ -75,7 +75,7 @@
 // CHECK-NEXT:  ret %struct.S* @"\01?s@?1??g@@YAAAUS@@XZ@4U2@A"
 //
 // CHECK: [[lpad]]:
-// CHECK-NEXT: cleanuppad []
+// CHECK-NEXT: cleanuppad none []
 // CHECK:   call void @_Init_thread_abort(i32* @"\01?$TSS0@?1??g@@YAAAUS@@XZ")
 // CHECK-NEXT:  cleanupret {{.*}} unwind to caller
   return s;
Index: test/CodeGenCXX/microsoft-abi-eh-terminate.cpp
===
--- test/CodeGenCXX/microsoft-abi-eh-terminate.cpp
+++ test/CodeGenCXX/microsoft-abi-eh-terminate.cpp
@@ -9,6 +9,6 @@
 // CHECK-LABEL: define void @"\01?never_throws@@YAXXZ"()
 // CHECK-SAME:  personality i8* bitcast (i32 (...)* @__CxxFrameHandler3 to i8*)
 // CHECK:  invoke void @"\01?may_throw@@YAXXZ"()
-// MSVC2013:  terminatepad [void ()* @"\01?terminate@@YAXXZ"]
-// MSVC2015:  terminatepad [void ()* @__std_terminate]
+// MSVC2013:  terminatepad none [void ()* @"\01?terminate@@YAXXZ"]
+// MSVC2015:  terminatepad none [void ()* @__std_terminate]
 // CHECK-NEXT: unreachable
Index: test/CodeGenCXX/microsoft-abi-eh-cleanups.cpp
===
--- test/CodeGenCXX/microsoft-abi-eh-cleanups.cpp
+++ test/CodeGenCXX/microsoft-abi-eh-cleanups.cpp
@@ -27,7 +27,7 @@
 //
 //There should be one dtor call for unwinding from the second getA.
 // WIN32:   cleanuppad
-// WIN32:   call x86_thiscallcc void @"\01??1A@@QAE@XZ"({{.*}}) #[[noinline:[0-9]+]]
+// WIN32:   call x86_thiscallcc void @"\01??1A@@QAE@XZ"({{.*}})
 // WIN32-NOT: @"\01??1A@@QAE@XZ"
 // WIN32: }
 
@@ -62,7 +62,7 @@
 //Conditionally destroy arg1.
 // WIN32:   %[[cond:.*]] = load i1, i1* %[[isactive]]
 // WIN32:   br i1 %[[cond]]
-// WIN32:   call x86_thiscallcc void @"\01??1A@@QAE@XZ"(%struct.A* %[[arg1]]) #[[noinline]]
+// WIN32:   call x86_thiscallcc void @"\01??1A@@QAE@XZ"(%struct.A* %[[arg1]])
 // WIN32: }
 
 // Test putting the cleanups inside a conditional.
@@ -85,7 +85,7 @@
 // WIN32:   call i32 @"\01?CouldThrow@@YAHXZ"()
 //
 //Only one dtor in the invoke for arg1
-// WIN32:   call x86_thiscallcc void @"\01??1A@@QAE@XZ"({{.*}}) #[[noinline]]
+// WIN32:   call x86_thiscallcc void @"\01??1A@@QAE@XZ"({{.*}})
 // WIN32-NOT: invoke x86_thiscallcc void @"\01??1A@@QAE@XZ"
 // WIN32: }
 
@@ -126,7 +126,7 @@
 //Somewhere in the landing pad soup, we conditionally destroy arg1.
 // WIN32:   %[[isactive:.*]] = load i1, i1* %[[arg1_cond]]
 // WIN32:   br i1 %[[isactive]]
-// WIN32:   call x86_thiscallcc void @"\01??1A@@QAE@XZ"({{.*}}) #[[noinline]]
+// WIN32:   call x86_thiscallcc void @"\01??1A@@QAE@XZ"({{.*}})
 // 

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[Renato Golin via cfe-commits]

On 1 December 2015 at 18:29, David Blaikie  wrote:
> Are they things the test-suite couldn't (either technically or
> philosophically) cover, or only that it doesn't cover it at the moment, but
> could do so?

IMO, it's a philosophical issue. The test-suite is a whole-program
execution, and all that matters is the end result, the output of the
program, not the program itself.

Those tests are mostly large (> 3 lines of code) so, if we were trying
to objdump and match for instruction patterns, any optimisation
variance could destroy them, as well as you may find the pattern
elsewhere in the same object, not belonging to the function you want
(inlining, etc). All in all, all the problems with reducing C code
would be pertinent here, so a big hammer to kill small issues. On the
other hand, the Clang based asm/obj examples are all small, and
hand-crafted to suit the problem being tested.

We could, however, add a new directory in the test-suite for that kind
of tests, like we already have for regressions in C/C++. That would
dissociate the front-end from the back-end, and essentially any
compiler used would have to abide by the rules of the test (which may
not be true for some compilers).

I don't mind where they end up, really, but we need that kind of test
somewhere. Clang is an easy place because we know we have it built
when the Clang repo is checked out.


> That would sort of defeat the point of having the testing and projects
> separated though - it would tie the tests together and produce most of the
> undesirable outcomes of having single end-to-end tests.

Right, I agree, but since the relationship between Clang and LLVM is
non-trivial, and there are lots of changes that need to be done on
both sides, I can't see why we shouldn't have tests that span across
projects.

Clearly, the sanitizer tests need Clang and Compiler-RT. Some Libc++
tests need Compiler-RT, others need libunwind, on ARM I need Clang to
build it. There are a lot of dependencies that are not there by
accident, but by design.

The more you move tests away from the big targets (LLVM, Clang), the
less they're ran by people committing patches, and the harder will be
to pick up the failures. Having said that, a decent buildbot coverage
would account for most of those problems, but it would also put a
stress on slow/expensive/experimental hardware support. It's a
balance, I think.


> (it would mean that at least the pure (or at least non-Clang) LLVM developer
> would have a test to run where they would not if the test remained in Clang
> only)

That is a good point. Right now, RT/libc++ tests in that category are
controlled by enabling/disabling support via CMake flags. We may be
able to do the same with Clang (if LLVM is not built with it, disable
asm/obj tests). Moving them all to a regression package in the
test-suite would be another option, but one that would take a lot
longer...

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

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[James Molloy via cfe-commits]

Hi,

> That would sort of defeat the point of having the testing and projects
separated though - it would tie the tests together and produce most of the
undesirable outcomes of having single end-to-end tests.

End to end tests have significant disadvantages as we all know. However
they do have some advantages too( that I have already enumerated) and the
question currently as I see it is how do we best get/keep those advantages
in our testing strategy?

W.r.t the test-suite, that is a possibility. There are currently no
codegen-filecheck tests in the test-suite but there seems to be no reason I
can see why not. The disadvantage there for me is that we take short
running, simple tests and demote them to be run less often.

Would it make sense to have a dedicated subdirectory in clang/test for
these kind of tests, so they can be directly enumerated and therefore kept
to a minimum , yet be allowed when they add value?

James
On Tue, 1 Dec 2015 at 18:29, David Blaikie  wrote:

> On Tue, Dec 1, 2015 at 9:56 AM, Renato Golin via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> On 1 December 2015 at 17:23, James Molloy via cfe-commits
>>  wrote:
>> > This isn't just a NEON intrinsics thing, and this isn't just an
>> ARM/AArch64
>> > thing. There needs to be some way to test the compiler from start to
>> finish.
>> > Not being able to do so leaves serious coverage holes.
>>
>> Just for the sake of completeness, a hole that the test-suite doesn't
>> cover.
>>
>
> Are they things the test-suite couldn't (either technically or
> philosophically) cover, or only that it doesn't cover it at the moment, but
> could do so?
>
>
>>
>>
>> > CodeGen/aarch64-fix-cortex-a53-835769.c, where we absolutely 100% must
>> > ensure that the -mfix-cortex-a53-835769 flag gets properly respected in
>> the
>> > compiler output.
>>
>> SIMD intrinsics (including NEON, SSE), Errata fixes, Procedure call
>> tests, ELF section placement, FP contracts, Debug info, Inline
>> assembly, Unicode support, object creation, library symbol clashes,
>> back-end diagnostics are some of the examples that need to go all the
>> way to asm or object code.
>>
>>
>> > If you can describe a way to get the same strength of testing without
>> > running the backend during clang tests, I'm all ears!
>>
>> I'm particularly interested in how do we keep the IR printed in the
>> Clang tests in sync with the IR sent to the LLVM tests if/when they
>> change, to guarantee that Clang changes don't generate silent codegen
>> faults down the line in LLVM and vice-versa.
>>
>
> That would sort of defeat the point of having the testing and projects
> separated though - it would tie the tests together and produce most of the
> undesirable outcomes of having single end-to-end tests.
>
> (it would mean that at least the pure (or at least non-Clang) LLVM
> developer would have a test to run where they would not if the test
> remained in Clang only)
>
>
>>
>> cheers,
>> --renato
>
>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[Eric Christopher via cfe-commits]

On Tue, Dec 1, 2015 at 10:43 AM James Molloy via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Hi,
>
> > That would sort of defeat the point of having the testing and projects
> separated though - it would tie the tests together and produce most of the
> undesirable outcomes of having single end-to-end tests.
>
> End to end tests have significant disadvantages as we all know. However
> they do have some advantages too( that I have already enumerated) and the
> question currently as I see it is how do we best get/keep those advantages
> in our testing strategy?
>
> W.r.t the test-suite, that is a possibility. There are currently no
> codegen-filecheck tests in the test-suite but there seems to be no reason I
> can see why not. The disadvantage there for me is that we take short
> running, simple tests and demote them to be run less often.
>
> Would it make sense to have a dedicated subdirectory in clang/test for
> these kind of tests, so they can be directly enumerated and therefore kept
> to a minimum , yet be allowed when they add value?
>
>
There are a few cases where we can't currently test something, but none of
the cases you or Renato have brought up qualify. I'm curious what you'd put
in this directory?

-eric


> James
> On Tue, 1 Dec 2015 at 18:29, David Blaikie  wrote:
>
>> On Tue, Dec 1, 2015 at 9:56 AM, Renato Golin via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> On 1 December 2015 at 17:23, James Molloy via cfe-commits
>>>  wrote:
>>> > This isn't just a NEON intrinsics thing, and this isn't just an
>>> ARM/AArch64
>>> > thing. There needs to be some way to test the compiler from start to
>>> finish.
>>> > Not being able to do so leaves serious coverage holes.
>>>
>>> Just for the sake of completeness, a hole that the test-suite doesn't
>>> cover.
>>>
>>
>> Are they things the test-suite couldn't (either technically or
>> philosophically) cover, or only that it doesn't cover it at the moment, but
>> could do so?
>>
>>
>>>
>>>
>>> > CodeGen/aarch64-fix-cortex-a53-835769.c, where we absolutely 100% must
>>> > ensure that the -mfix-cortex-a53-835769 flag gets properly respected
>>> in the
>>> > compiler output.
>>>
>>> SIMD intrinsics (including NEON, SSE), Errata fixes, Procedure call
>>> tests, ELF section placement, FP contracts, Debug info, Inline
>>> assembly, Unicode support, object creation, library symbol clashes,
>>> back-end diagnostics are some of the examples that need to go all the
>>> way to asm or object code.
>>>
>>>
>>> > If you can describe a way to get the same strength of testing without
>>> > running the backend during clang tests, I'm all ears!
>>>
>>> I'm particularly interested in how do we keep the IR printed in the
>>> Clang tests in sync with the IR sent to the LLVM tests if/when they
>>> change, to guarantee that Clang changes don't generate silent codegen
>>> faults down the line in LLVM and vice-versa.
>>>
>>
>> That would sort of defeat the point of having the testing and projects
>> separated though - it would tie the tests together and produce most of the
>> undesirable outcomes of having single end-to-end tests.
>>
>> (it would mean that at least the pure (or at least non-Clang) LLVM
>> developer would have a test to run where they would not if the test
>> remained in Clang only)
>>
>>
>>>
>>> cheers,
>>> --renato
>>
>>
>>> ___
>>> 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
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D15121: A new clang-tidy module to find calls to `std::swap`, and change them to use ADL

[Marshall Clow via cfe-commits]

mclow.lists added a comment.

Also, even though the `--fix` done by the tool is (almost) correct, the display 
of the fixit hint by clang is really confusing, even wrong


http://reviews.llvm.org/D15121



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

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[James Molloy via cfe-commits]

You cannot test the intrinsic emission with the same quality when splitting
the test in two. You miss testing the producer consumer relationship
between the two components.

I'm sorry that this use case appears to you as not qualifying.
On Tue, 1 Dec 2015 at 18:45, Eric Christopher  wrote:

> On Tue, Dec 1, 2015 at 10:43 AM James Molloy via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Hi,
>>
>> > That would sort of defeat the point of having the testing and projects
>> separated though - it would tie the tests together and produce most of the
>> undesirable outcomes of having single end-to-end tests.
>>
>> End to end tests have significant disadvantages as we all know. However
>> they do have some advantages too( that I have already enumerated) and the
>> question currently as I see it is how do we best get/keep those advantages
>> in our testing strategy?
>>
>> W.r.t the test-suite, that is a possibility. There are currently no
>> codegen-filecheck tests in the test-suite but there seems to be no reason I
>> can see why not. The disadvantage there for me is that we take short
>> running, simple tests and demote them to be run less often.
>>
>> Would it make sense to have a dedicated subdirectory in clang/test for
>> these kind of tests, so they can be directly enumerated and therefore kept
>> to a minimum , yet be allowed when they add value?
>>
>>
> There are a few cases where we can't currently test something, but none of
> the cases you or Renato have brought up qualify. I'm curious what you'd put
> in this directory?
>
> -eric
>
>
>> James
>> On Tue, 1 Dec 2015 at 18:29, David Blaikie  wrote:
>>
>>> On Tue, Dec 1, 2015 at 9:56 AM, Renato Golin via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 On 1 December 2015 at 17:23, James Molloy via cfe-commits
  wrote:
 > This isn't just a NEON intrinsics thing, and this isn't just an
 ARM/AArch64
 > thing. There needs to be some way to test the compiler from start to
 finish.
 > Not being able to do so leaves serious coverage holes.

 Just for the sake of completeness, a hole that the test-suite doesn't
 cover.

>>>
>>> Are they things the test-suite couldn't (either technically or
>>> philosophically) cover, or only that it doesn't cover it at the moment, but
>>> could do so?
>>>
>>>


 > CodeGen/aarch64-fix-cortex-a53-835769.c, where we absolutely 100% must
 > ensure that the -mfix-cortex-a53-835769 flag gets properly respected
 in the
 > compiler output.

 SIMD intrinsics (including NEON, SSE), Errata fixes, Procedure call
 tests, ELF section placement, FP contracts, Debug info, Inline
 assembly, Unicode support, object creation, library symbol clashes,
 back-end diagnostics are some of the examples that need to go all the
 way to asm or object code.


 > If you can describe a way to get the same strength of testing without
 > running the backend during clang tests, I'm all ears!

 I'm particularly interested in how do we keep the IR printed in the
 Clang tests in sync with the IR sent to the LLVM tests if/when they
 change, to guarantee that Clang changes don't generate silent codegen
 faults down the line in LLVM and vice-versa.

>>>
>>> That would sort of defeat the point of having the testing and projects
>>> separated though - it would tie the tests together and produce most of the
>>> undesirable outcomes of having single end-to-end tests.
>>>
>>> (it would mean that at least the pure (or at least non-Clang) LLVM
>>> developer would have a test to run where they would not if the test
>>> remained in Clang only)
>>>
>>>

 cheers,
 --renato
>>>
>>>
 ___
 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
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[Eric Christopher via cfe-commits]

Could you provide an example proving this? I answered your question with
exactly how to split it up.

On Tue, Dec 1, 2015, 10:54 AM James Molloy  wrote:

> You cannot test the intrinsic emission with the same quality when
> splitting the test in two. You miss testing the producer consumer
> relationship between the two components.
>
> I'm sorry that this use case appears to you as not qualifying.
> On Tue, 1 Dec 2015 at 18:45, Eric Christopher  wrote:
>
>> On Tue, Dec 1, 2015 at 10:43 AM James Molloy via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Hi,
>>>
>>> > That would sort of defeat the point of having the testing and projects
>>> separated though - it would tie the tests together and produce most of the
>>> undesirable outcomes of having single end-to-end tests.
>>>
>>> End to end tests have significant disadvantages as we all know. However
>>> they do have some advantages too( that I have already enumerated) and the
>>> question currently as I see it is how do we best get/keep those advantages
>>> in our testing strategy?
>>>
>>> W.r.t the test-suite, that is a possibility. There are currently no
>>> codegen-filecheck tests in the test-suite but there seems to be no reason I
>>> can see why not. The disadvantage there for me is that we take short
>>> running, simple tests and demote them to be run less often.
>>>
>>> Would it make sense to have a dedicated subdirectory in clang/test for
>>> these kind of tests, so they can be directly enumerated and therefore kept
>>> to a minimum , yet be allowed when they add value?
>>>
>>>
>> There are a few cases where we can't currently test something, but none
>> of the cases you or Renato have brought up qualify. I'm curious what you'd
>> put in this directory?
>>
>> -eric
>>
>>
>>> James
>>> On Tue, 1 Dec 2015 at 18:29, David Blaikie  wrote:
>>>
 On Tue, Dec 1, 2015 at 9:56 AM, Renato Golin via cfe-commits <
 cfe-commits@lists.llvm.org> wrote:

> On 1 December 2015 at 17:23, James Molloy via cfe-commits
>  wrote:
> > This isn't just a NEON intrinsics thing, and this isn't just an
> ARM/AArch64
> > thing. There needs to be some way to test the compiler from start to
> finish.
> > Not being able to do so leaves serious coverage holes.
>
> Just for the sake of completeness, a hole that the test-suite doesn't
> cover.
>

 Are they things the test-suite couldn't (either technically or
 philosophically) cover, or only that it doesn't cover it at the moment, but
 could do so?


>
>
> > CodeGen/aarch64-fix-cortex-a53-835769.c, where we absolutely 100%
> must
> > ensure that the -mfix-cortex-a53-835769 flag gets properly respected
> in the
> > compiler output.
>
> SIMD intrinsics (including NEON, SSE), Errata fixes, Procedure call
> tests, ELF section placement, FP contracts, Debug info, Inline
> assembly, Unicode support, object creation, library symbol clashes,
> back-end diagnostics are some of the examples that need to go all the
> way to asm or object code.
>
>
> > If you can describe a way to get the same strength of testing without
> > running the backend during clang tests, I'm all ears!
>
> I'm particularly interested in how do we keep the IR printed in the
> Clang tests in sync with the IR sent to the LLVM tests if/when they
> change, to guarantee that Clang changes don't generate silent codegen
> faults down the line in LLVM and vice-versa.
>

 That would sort of defeat the point of having the testing and projects
 separated though - it would tie the tests together and produce most of the
 undesirable outcomes of having single end-to-end tests.

 (it would mean that at least the pure (or at least non-Clang) LLVM
 developer would have a test to run where they would not if the test
 remained in Clang only)


>
> cheers,
> --renato


> ___
> 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
>>>
>>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D15025: [ThinLTO] Option to invoke ThinLTO backend passes and importing

[Teresa Johnson via cfe-commits]

tejohnson marked an inline comment as done.
tejohnson added a comment.

Updated patch coming shortly.



Comment at: lib/CodeGen/BackendUtil.cpp:308
@@ +307,3 @@
+return;
+  }
+

joker.eph wrote:
> It does not seem to be nicely integrated within the context of this function. 
> What about all the options set just a few line below? It is not clear if 
> `CodeGenOpts.DisableLLVMOpts` is well honored either.
This is basically the same LTO pipeline we setup in both gold-plugin.cpp and in 
LTOCodeGenerator::optimize (used by the llvm-lto tool and presumably ld64). I 
added that info to the comments. It is a special pipeline for this mode. That 
being said, I have made a couple of changes in my latest version to be uploaded 
shortly: Skip this special pipeline if DisableLLVMOpts is true; set 
LoopVectorize to CodeGenOpts.VectorizeLoop as in the below code; set 
SLPVectorize to CodeGenOpts.VectorizeSLP as in the below code.

One thing I may do first actually is to refactor this code out of gold-plugin 
and LTOCodeGenerator into a PassManagerBuilder helper function.


http://reviews.llvm.org/D15025



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

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[David Blaikie via cfe-commits]

On Tue, Dec 1, 2015 at 10:43 AM, Renato Golin 
wrote:

> On 1 December 2015 at 18:29, David Blaikie  wrote:
> > Are they things the test-suite couldn't (either technically or
> > philosophically) cover, or only that it doesn't cover it at the moment,
> but
> > could do so?
>
> IMO, it's a philosophical issue. The test-suite is a whole-program
> execution, and all that matters is the end result, the output of the
> program, not the program itself.
>
> Those tests are mostly large (> 3 lines of code) so, if we were trying
> to objdump and match for instruction patterns, any optimisation
> variance could destroy them, as well as you may find the pattern
> elsewhere in the same object, not belonging to the function you want
> (inlining, etc).


Not sure I follow - I'm not suggesting adding objdump/instruction checking
to existing large programs in the test-suite, but adding other tests to the
test-suite that do this and have appropriate input for it to be a
reliable/useful form of testing.


> All in all, all the problems with reducing C code
> would be pertinent here, so a big hammer to kill small issues. On the
> other hand, the Clang based asm/obj examples are all small, and
> hand-crafted to suit the problem being tested.
>
> We could, however, add a new directory in the test-suite for that kind
> of tests, like we already have for regressions in C/C++.


If a separate directory makes it more clear what the purpose is, sure,
seems fine to me, but I don't have strong or informed opinions on exactly
how the test-suite is laid out.


> That would
> dissociate the front-end from the back-end, and essentially any
> compiler used would have to abide by the rules of the test (which may
> not be true for some compilers).
>

This is perhaps an interesting part/point: In theory I would think that
these tests should be able to be phrased in a compiler-agnostic way, since
they're testing the compiler as a whole and testing behavior that the
source code demands, no?


> I don't mind where they end up, really, but we need that kind of test
> somewhere. Clang is an easy place because we know we have it built
> when the Clang repo is checked out.
>
>
> > That would sort of defeat the point of having the testing and projects
> > separated though - it would tie the tests together and produce most of
> the
> > undesirable outcomes of having single end-to-end tests.
>
> Right, I agree, but since the relationship between Clang and LLVM is
> non-trivial, and there are lots of changes that need to be done on
> both sides, I can't see why we shouldn't have tests that span across
> projects.
>
> Clearly, the sanitizer tests need Clang and Compiler-RT. Some Libc++
> tests need Compiler-RT, others need libunwind, on ARM I need Clang to
> build it. There are a lot of dependencies that are not there by
> accident, but by design.
>
> The more you move tests away from the big targets (LLVM, Clang), the
> less they're ran by people committing patches, and the harder will be
> to pick up the failures. Having said that, a decent buildbot coverage
> would account for most of those problems, but it would also put a
> stress on slow/expensive/experimental hardware support. It's a
> balance, I think.
>

Why would it require slow/expensive/experimental hardware? (& if it does
require that, how do you expect average developers to run them on a regular
basis?)


>
>
> > (it would mean that at least the pure (or at least non-Clang) LLVM
> developer
> > would have a test to run where they would not if the test remained in
> Clang
> > only)
>
> That is a good point. Right now, RT/libc++ tests in that category are
> controlled by enabling/disabling support via CMake flags. We may be
> able to do the same with Clang (if LLVM is not built with it, disable
> asm/obj tests). Moving them all to a regression package in the
> test-suite would be another option, but one that would take a lot
> longer...
>
> cheers,
> --renato
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[James Molloy via cfe-commits]

Hi,

FWIW, I'm happy with moving these tests into the test-suite. They do make
sense to be expressed in a compiler-neutral manner, even though some may
test clang-specific behaviour.

There is a UnitTests directory already, and adding the ability to run LIT
tests should be simple within the new CMake framework.

James
On Tue, 1 Dec 2015 at 19:09, David Blaikie  wrote:

> On Tue, Dec 1, 2015 at 10:43 AM, Renato Golin 
> wrote:
>
>> On 1 December 2015 at 18:29, David Blaikie  wrote:
>> > Are they things the test-suite couldn't (either technically or
>> > philosophically) cover, or only that it doesn't cover it at the moment,
>> but
>> > could do so?
>>
>> IMO, it's a philosophical issue. The test-suite is a whole-program
>> execution, and all that matters is the end result, the output of the
>> program, not the program itself.
>>
>> Those tests are mostly large (> 3 lines of code) so, if we were trying
>> to objdump and match for instruction patterns, any optimisation
>> variance could destroy them, as well as you may find the pattern
>> elsewhere in the same object, not belonging to the function you want
>> (inlining, etc).
>
>
> Not sure I follow - I'm not suggesting adding objdump/instruction checking
> to existing large programs in the test-suite, but adding other tests to the
> test-suite that do this and have appropriate input for it to be a
> reliable/useful form of testing.
>
>
>> All in all, all the problems with reducing C code
>> would be pertinent here, so a big hammer to kill small issues. On the
>> other hand, the Clang based asm/obj examples are all small, and
>> hand-crafted to suit the problem being tested.
>>
>> We could, however, add a new directory in the test-suite for that kind
>> of tests, like we already have for regressions in C/C++.
>
>
> If a separate directory makes it more clear what the purpose is, sure,
> seems fine to me, but I don't have strong or informed opinions on exactly
> how the test-suite is laid out.
>
>
>> That would
>> dissociate the front-end from the back-end, and essentially any
>> compiler used would have to abide by the rules of the test (which may
>> not be true for some compilers).
>>
>
> This is perhaps an interesting part/point: In theory I would think that
> these tests should be able to be phrased in a compiler-agnostic way, since
> they're testing the compiler as a whole and testing behavior that the
> source code demands, no?
>
>
>> I don't mind where they end up, really, but we need that kind of test
>> somewhere. Clang is an easy place because we know we have it built
>> when the Clang repo is checked out.
>>
>>
>> > That would sort of defeat the point of having the testing and projects
>> > separated though - it would tie the tests together and produce most of
>> the
>> > undesirable outcomes of having single end-to-end tests.
>>
>> Right, I agree, but since the relationship between Clang and LLVM is
>> non-trivial, and there are lots of changes that need to be done on
>> both sides, I can't see why we shouldn't have tests that span across
>> projects.
>>
>> Clearly, the sanitizer tests need Clang and Compiler-RT. Some Libc++
>> tests need Compiler-RT, others need libunwind, on ARM I need Clang to
>> build it. There are a lot of dependencies that are not there by
>> accident, but by design.
>>
>> The more you move tests away from the big targets (LLVM, Clang), the
>> less they're ran by people committing patches, and the harder will be
>> to pick up the failures. Having said that, a decent buildbot coverage
>> would account for most of those problems, but it would also put a
>> stress on slow/expensive/experimental hardware support. It's a
>> balance, I think.
>>
>
> Why would it require slow/expensive/experimental hardware? (& if it does
> require that, how do you expect average developers to run them on a regular
> basis?)
>
>
>>
>>
>> > (it would mean that at least the pure (or at least non-Clang) LLVM
>> developer
>> > would have a test to run where they would not if the test remained in
>> Clang
>> > only)
>>
>> That is a good point. Right now, RT/libc++ tests in that category are
>> controlled by enabling/disabling support via CMake flags. We may be
>> able to do the same with Clang (if LLVM is not built with it, disable
>> asm/obj tests). Moving them all to a regression package in the
>> test-suite would be another option, but one that would take a lot
>> longer...
>>
>> cheers,
>> --renato
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r254439 - [MS ABI] Correctly mangle nullptr member pointers for variable templates

[David Majnemer via cfe-commits]

Author: majnemer
Date: Tue Dec  1 13:13:51 2015
New Revision: 254439

URL: http://llvm.org/viewvc/llvm-project?rev=254439=rev
Log:
[MS ABI] Correctly mangle nullptr member pointers for variable templates

Variable templates behave the same as class templates with regard to
nullptr memeber pointers.

Modified:
cfe/trunk/lib/AST/MicrosoftMangle.cpp
cfe/trunk/test/CodeGenCXX/mangle-ms-cxx14.cpp

Modified: cfe/trunk/lib/AST/MicrosoftMangle.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/MicrosoftMangle.cpp?rev=254439=254438=254439=diff
==
--- cfe/trunk/lib/AST/MicrosoftMangle.cpp (original)
+++ cfe/trunk/lib/AST/MicrosoftMangle.cpp Tue Dec  1 13:13:51 2015
@@ -697,7 +697,6 @@ void MicrosoftCXXNameMangler::mangleUnqu
 // Function templates aren't considered for name back referencing.  This
 // makes sense since function templates aren't likely to occur multiple
 // times in a symbol.
-// FIXME: Test alias template mangling with MSVC 2013.
 if (!isa(TD)) {
   mangleTemplateInstantiationName(TD, *TemplateArgs);
   Out << '@';
@@ -1226,12 +1225,13 @@ void MicrosoftCXXNameMangler::mangleTemp
 QualType T = TA.getNullPtrType();
 if (const MemberPointerType *MPT = T->getAs()) {
   const CXXRecordDecl *RD = MPT->getMostRecentCXXRecordDecl();
-  if (MPT->isMemberFunctionPointerType() && isa(TD)) {
+  if (MPT->isMemberFunctionPointerType() &&
+  !isa(TD)) {
 mangleMemberFunctionPointer(RD, nullptr);
 return;
   }
   if (MPT->isMemberDataPointer()) {
-if (isa(TD)) {
+if (!isa(TD)) {
   mangleMemberDataPointer(RD, nullptr);
   return;
 }

Modified: cfe/trunk/test/CodeGenCXX/mangle-ms-cxx14.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/mangle-ms-cxx14.cpp?rev=254439=254438=254439=diff
==
--- cfe/trunk/test/CodeGenCXX/mangle-ms-cxx14.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/mangle-ms-cxx14.cpp Tue Dec  1 13:13:51 2015
@@ -3,27 +3,27 @@
 
 template  int x = 0;
 
-// CHECK: "\01??$x@X@@3HA"
+// CHECK-DAG: "\01??$x@X@@3HA"
 template <> int x;
-// CHECK: "\01??$x@H@@3HA"
+// CHECK-DAG: "\01??$x@H@@3HA"
 template <> int x;
 
-// CHECK: "\01?FunctionWithLocalType@@YA?A?@@XZ"
+// CHECK-DAG: "\01?FunctionWithLocalType@@YA?A?@@XZ"
 auto FunctionWithLocalType() {
   struct LocalType {};
   return LocalType{};
 }
 
-// CHECK: 
"\01?ValueFromFunctionWithLocalType@@3ULocalType@?1??FunctionWithLocalType@@YA?A?@@XZ@A"
+// CHECK-DAG: 
"\01?ValueFromFunctionWithLocalType@@3ULocalType@?1??FunctionWithLocalType@@YA?A?@@XZ@A"
 auto ValueFromFunctionWithLocalType = FunctionWithLocalType();
 
-// CHECK: "\01??R@@QBE?A?@@XZ"
+// CHECK-DAG: "\01??R@@QBE?A?@@XZ"
 auto LambdaWithLocalType = [] {
   struct LocalType {};
   return LocalType{};
 };
 
-// CHECK: 
"\01?ValueFromLambdaWithLocalType@@3ULocalType@?1???R@@QBE?A?@@XZ@A"
+// CHECK-DAG: 
"\01?ValueFromLambdaWithLocalType@@3ULocalType@?1???R@@QBE?A?@@XZ@A"
 auto ValueFromLambdaWithLocalType = LambdaWithLocalType();
 
 template 
@@ -39,6 +39,13 @@ auto TemplateFuncionWithLocalLambda(T) {
 // MSVC2013-DAG: 
"\01?ValueFromTemplateFuncionWithLocalLambda@@3ULocalType@?2???R@??$TemplateFuncionWithLocalLambda@H@@YA?A?@@H@Z@QBE?A?3@XZ@A"
 // MSVC2015-DAG: 
"\01?ValueFromTemplateFuncionWithLocalLambda@@3ULocalType@?1???R@??$TemplateFuncionWithLocalLambda@H@@YA?A?@@H@Z@QBE?A?3@XZ@A"
 // MSVC2015-DAG: 
"\01?ValueFromTemplateFuncionWithLocalLambda@@3ULocalType@?1???R@??$TemplateFuncionWithLocalLambda@H@@YA?A?@@H@Z@QBE?A?3@XZ@A"
-// CHECK: "\01??$TemplateFuncionWithLocalLambda@H@@YA?A?@@H@Z"
-// CHECK: 
"\01??R@??$TemplateFuncionWithLocalLambda@H@@YA?A?@@H@Z@QBE?A?1@XZ"
+// CHECK-DAG: "\01??$TemplateFuncionWithLocalLambda@H@@YA?A?@@H@Z"
+// CHECK-DAG: 
"\01??R@??$TemplateFuncionWithLocalLambda@H@@YA?A?@@H@Z@QBE?A?1@XZ"
 auto ValueFromTemplateFuncionWithLocalLambda = 
TemplateFuncionWithLocalLambda(0);
+
+struct S;
+template 
+int WithPMD = 0;
+
+template <> int WithPMD;
+// CHECK-DAG: "\01??$WithPMD@$GA@A@?0@@3HA"


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

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[Eric Christopher via cfe-commits]

On Tue, Dec 1, 2015 at 10:45 AM Eric Christopher  wrote:

> On Tue, Dec 1, 2015 at 10:43 AM James Molloy via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Hi,
>>
>> > That would sort of defeat the point of having the testing and projects
>> separated though - it would tie the tests together and produce most of the
>> undesirable outcomes of having single end-to-end tests.
>>
>> End to end tests have significant disadvantages as we all know. However
>> they do have some advantages too( that I have already enumerated) and the
>> question currently as I see it is how do we best get/keep those advantages
>> in our testing strategy?
>>
>> W.r.t the test-suite, that is a possibility. There are currently no
>> codegen-filecheck tests in the test-suite but there seems to be no reason I
>> can see why not. The disadvantage there for me is that we take short
>> running, simple tests and demote them to be run less often.
>>
>> Would it make sense to have a dedicated subdirectory in clang/test for
>> these kind of tests, so they can be directly enumerated and therefore kept
>> to a minimum , yet be allowed when they add value?
>>
>>
> There are a few cases where we can't currently test something, but none of
> the cases you or Renato have brought up qualify. I'm curious what you'd put
> in this directory?
>
>
FWIW to elaborate here on a place I know we can't test well at the moment
is the creation of the TargetMachine itself. This is why I've been trying
to pull as much stuff out of the API call and put it into the IR where
possible. It's a lot of refactoring to keep it particularly clean which is
why it's slow going.

-eric


> -eric
>
>
>> James
>> On Tue, 1 Dec 2015 at 18:29, David Blaikie  wrote:
>>
>>> On Tue, Dec 1, 2015 at 9:56 AM, Renato Golin via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 On 1 December 2015 at 17:23, James Molloy via cfe-commits
  wrote:
 > This isn't just a NEON intrinsics thing, and this isn't just an
 ARM/AArch64
 > thing. There needs to be some way to test the compiler from start to
 finish.
 > Not being able to do so leaves serious coverage holes.

 Just for the sake of completeness, a hole that the test-suite doesn't
 cover.

>>>
>>> Are they things the test-suite couldn't (either technically or
>>> philosophically) cover, or only that it doesn't cover it at the moment, but
>>> could do so?
>>>
>>>


 > CodeGen/aarch64-fix-cortex-a53-835769.c, where we absolutely 100% must
 > ensure that the -mfix-cortex-a53-835769 flag gets properly respected
 in the
 > compiler output.

 SIMD intrinsics (including NEON, SSE), Errata fixes, Procedure call
 tests, ELF section placement, FP contracts, Debug info, Inline
 assembly, Unicode support, object creation, library symbol clashes,
 back-end diagnostics are some of the examples that need to go all the
 way to asm or object code.


 > If you can describe a way to get the same strength of testing without
 > running the backend during clang tests, I'm all ears!

 I'm particularly interested in how do we keep the IR printed in the
 Clang tests in sync with the IR sent to the LLVM tests if/when they
 change, to guarantee that Clang changes don't generate silent codegen
 faults down the line in LLVM and vice-versa.

>>>
>>> That would sort of defeat the point of having the testing and projects
>>> separated though - it would tie the tests together and produce most of the
>>> undesirable outcomes of having single end-to-end tests.
>>>
>>> (it would mean that at least the pure (or at least non-Clang) LLVM
>>> developer would have a test to run where they would not if the test
>>> remained in Clang only)
>>>
>>>

 cheers,
 --renato
>>>
>>>
 ___
 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
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D15025: [ThinLTO] Option to invoke ThinLTO backend passes and importing

[Teresa Johnson via cfe-commits]

tejohnson updated this revision to Diff 41542.
tejohnson added a comment.

- Address Mehdi's comments.


http://reviews.llvm.org/D15025

Files:
  include/clang/CodeGen/CodeGenAction.h
  include/clang/Driver/Options.td
  include/clang/Driver/Types.h
  include/clang/Frontend/CodeGenOptions.h
  lib/CodeGen/BackendUtil.cpp
  lib/CodeGen/CodeGenAction.cpp
  lib/Driver/Tools.cpp
  lib/Driver/Types.cpp
  lib/Frontend/CompilerInvocation.cpp
  test/CodeGen/thinlto_backend.c
  test/Driver/thinlto_backend.c

Index: test/Driver/thinlto_backend.c
===
--- /dev/null
+++ test/Driver/thinlto_backend.c
@@ -0,0 +1,12 @@
+// RUN: %clang -target x86_64-unknown-linux -O2 %s -flto=thin -c -o %t.o
+// RUN: %clang -target x86_64-unknown-linux -O2 -flto=thin -fuse-ld=gold -o %t %t.o
+
+// -fthinlto_backend should be passed to cc1
+// RUN: %clang -target x86_64-unknown-linux -O2 -o %t1.o -x ir %t.o -c -fthinlto-backend=%t.thinlto.bc -### 2> %t
+// RUN: FileCheck -check-prefix=CHECK-THINLTOBE-ACTION < %t %s
+// CHECK-THINLTOBE-ACTION: -fthinlto-backend=
+
+// Ensure clang driver gives the expected error for incorrect input type
+// RUN: not %clang -target x86_64-unknown-linux -O2 -o %t1.o %s -c -fthinlto-backend=%t.thinlto.bc 2> %t
+// RUN: FileCheck -check-prefix=CHECK-WARNING < %t %s
+// CHECK-WARNING: error: invalid argument '-fthinlto-backend={{.*}}' only allowed with '-x ir'
Index: test/CodeGen/thinlto_backend.c
===
--- /dev/null
+++ test/CodeGen/thinlto_backend.c
@@ -0,0 +1,17 @@
+// RUN: %clang -target x86_64-unknown-linux -O2 %s -flto=thin -c -o %t.o
+// RUN: %clang -target x86_64-unknown-linux -O2 -flto=thin -fuse-ld=gold -o %t %t.o
+
+// Ensure clang -cc1 give expected error for incorrect input type
+// RUN: not %clang_cc1 -target x86_64-unknown-linux -O2 -o %t1.o %s -c -fthinlto-backend=%t.thinlto.bc 2> %t
+// RUN: FileCheck -check-prefix=CHECK-WARNING < %t %s
+// CHECK-WARNING: error: invalid argument '-fthinlto-backend={{.*}}' only allowed with '-x ir'
+
+// Ensure we get expected error for missing index file
+// RUN: %clang -target x86_64-unknown-linux -O2 -o %t1.o -x ir %t.o -c -fthinlto-backend=bad.thinlto.bc 2> %t
+// RUN: FileCheck -check-prefix=CHECK-ERROR < %t %s
+// CHECK-ERROR: Error loading index file 'bad.thinlto.bc': No such file or directory
+
+// Ensure Function Importing pass added
+// RUN: %clang -target x86_64-unknown-linux -O2 -o %t1.o -x ir %t.o -c -fthinlto-backend=%t.thinlto.bc -mllvm -debug-pass=Structure 2> %t
+// RUN: FileCheck -check-prefix=CHECK-PASS < %t %s
+// CHECK-PASS: Function Importing
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -521,6 +521,12 @@
   Opts.PrepareForLTO = Args.hasArg(OPT_flto, OPT_flto_EQ);
   const Arg *A = Args.getLastArg(OPT_flto, OPT_flto_EQ);
   Opts.EmitFunctionSummary = A && A->containsValue("thin");
+  if (Arg *A = Args.getLastArg(OPT_fthinlto_backend_EQ)) {
+if (IK != IK_LLVM_IR)
+  Diags.Report(diag::err_drv_argument_only_allowed_with)
+  << A->getAsString(Args) << "-x ir";
+Opts.ThinLTOIndexFile = Args.getLastArgValue(OPT_fthinlto_backend_EQ);
+  }
 
   Opts.MSVolatile = Args.hasArg(OPT_fms_volatile);
 
Index: lib/Driver/Types.cpp
===
--- lib/Driver/Types.cpp
+++ lib/Driver/Types.cpp
@@ -128,6 +128,19 @@
   }
 }
 
+bool types::isLLVMIR(ID Id) {
+  switch (Id) {
+  default:
+return false;
+
+  case TY_LLVM_IR:
+  case TY_LLVM_BC:
+  case TY_LTO_IR:
+  case TY_LTO_BC:
+return true;
+  }
+}
+
 bool types::isCuda(ID Id) {
   switch (Id) {
   default:
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -3413,6 +3413,13 @@
   Args.AddLastArg(CmdArgs, options::OPT_flto, options::OPT_flto_EQ);
   }
 
+  if (const Arg *A = Args.getLastArg(options::OPT_fthinlto_backend_EQ)) {
+if (!types::isLLVMIR(Input.getType()))
+  D.Diag(diag::err_drv_argument_only_allowed_with) << A->getAsString(Args)
+   << "-x ir";
+Args.AddLastArg(CmdArgs, options::OPT_fthinlto_backend_EQ);
+  }
+
   // We normally speed up the clang process a bit by skipping destructors at
   // exit, but when we're generating diagnostics we can rely on some of the
   // cleanup.
Index: lib/CodeGen/CodeGenAction.cpp
===
--- lib/CodeGen/CodeGenAction.cpp
+++ lib/CodeGen/CodeGenAction.cpp
@@ -26,10 +26,12 @@
 #include "llvm/IR/DebugInfo.h"
 #include "llvm/IR/DiagnosticInfo.h"
 #include "llvm/IR/DiagnosticPrinter.h"
+#include "llvm/IR/FunctionInfo.h"
 #include "llvm/IR/LLVMContext.h"
 #include "llvm/IR/Module.h"
 #include 

Re: [PATCH] D14980: PR18513: make gcc compatible layout for bit-fields with explicit aligned attribute

[John McCall via cfe-commits]

rjmccall added a comment.

I don't mean the actual layout used by Windows targets; I mean the layout used 
by the ms_struct pragma / attribute.



Comment at: lib/AST/RecordLayoutBuilder.cpp:1606
@@ -1605,1 +1605,3 @@
+} else if (ExplicitFieldAlign)
+  FieldOffset = llvm::RoundUpToAlignment(FieldOffset, ExplicitFieldAlign);
 

It does still seem to be limited by platforms that ignore natural alignment, 
though, and by #pragma pack (2) and so on, so at least some of the 
modifications made to FieldAlign need to be reflected in ExplicitFieldAlign.

I had to spend some time trying to work out counter-examples, but I did 
convince myself that the effect of the fallback here is correct.  My concern 
was that there was a way we might round up to FieldAlign when we only needed to 
round up to ExplicitFieldAlign, which could matter if there were another 
properly-aligned position within the current storage unit.  However, the second 
clause of the first condition will only trigger at the very end of a storage 
unit, which means that there cannot be any other properly-aligned positions 
within it.

It might be wrong for zero-width bit-fields, though, since we'll always round 
up to FieldAlign instead of ExplicitFieldAlign.


Comment at: lib/AST/RecordLayoutBuilder.cpp:1614
@@ -1610,3 +1613,3 @@
   UnpackedFieldOffset = llvm::RoundUpToAlignment(UnpackedFieldOffset,
  UnpackedFieldAlign);
   }

This should follow the same logic that you use for FieldOffset, unless I'm 
missing something.


http://reviews.llvm.org/D14980



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

Re: [PATCH] D14871: [Power PC] fix calculating address of arguments on stack for variadic functions

[John McCall via cfe-commits]

rjmccall added a comment.

Please feel free to commit after you make this last change.



Comment at: lib/CodeGen/TargetInfo.cpp:216
@@ +215,3 @@
+  }
+  else {
+Addr = Address(Ptr, SlotSize); 

LLVM code style is to put the else on the same line as the closing brace.


http://reviews.llvm.org/D14871



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

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[Renato Golin via cfe-commits]

On 1 December 2015 at 19:09, David Blaikie  wrote:
> Not sure I follow - I'm not suggesting adding objdump/instruction checking
> to existing large programs in the test-suite, but adding other tests to the
> test-suite that do this and have appropriate input for it to be a
> reliable/useful form of testing.

Sorry, I was building to that... But currently, the test-suite
compiles the code into an executable, then run it. Changing that
premise means we'll have something other than the test-suite we always
had, and may bring other problems, like too many hats for the
infrastructure to keep, especially now that James is moving it to
integrate with lit. We may decide this is the way to go, but we need
to make clear all the pros and cons of doing so beforehand.


> This is perhaps an interesting part/point: In theory I would think that
> these tests should be able to be phrased in a compiler-agnostic way, since
> they're testing the compiler as a whole and testing behavior that the source
> code demands, no?

There's where things get interesting. Say we change the test-suite to
instead of compiling and running, just compile to asm/obj and
grep/objdump to match instructions, ELF sections, debug symbols, etc.

Some tests are easy to make compiler independent. Intrinsics tests
fall into that category. Most currently in Clang tests could move
directly to the test-suite as soon as we have such infrastructure.

Other tests, however, are specific to Clang+LLVM that may make no
sense to GCC or ICC, ARMCC etc. Those tests, would have to be in yet
another separate directory, that is only enabled if the compiler is
Clang, assuming the back-end is always LLVM.

These are all options that, for me, have equal value with keeping them
in Clang. AFAICS, they stir the same kind of problems wherever they
are tested.


>> would account for most of those problems, but it would also put a
>> stress on slow/expensive/experimental hardware support. It's a
>> balance, I think.
>
> Why would it require slow/expensive/experimental hardware? (& if it does
> require that, how do you expect average developers to run them on a regular
> basis?)

You misunderstood. It would "put a stress on", not "require".
Basically, it would increase the cost of testing on those classes of
hardware more than off-the-shelf hardware by a non-trivial amount.

This goes back to our discussion on buildbots, where some targets are
harder to find hardware than others, and when you do, they're slower.
Meaning the more variations we need to test, the more hardware you
have to have to make it in any reasonable time. While a single 64-core
Xeon can cope with most testing (including self-hosting, test-suite,
sanitizers, libc++) on a per-commit basis, there is nothing similar,
widely available, today for most other targets.

But that's another discussion entirely, let's not dwell into that again. :)

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

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[James Molloy via cfe-commits]

Hi Renato,

> by a non-trivial amount.

Why do you think it would be non trivial? Some simple lit tests aren't
exactly arduous on most targets.

James
On Tue, 1 Dec 2015 at 19:39, Renato Golin  wrote:

> On 1 December 2015 at 19:09, David Blaikie  wrote:
> > Not sure I follow - I'm not suggesting adding objdump/instruction
> checking
> > to existing large programs in the test-suite, but adding other tests to
> the
> > test-suite that do this and have appropriate input for it to be a
> > reliable/useful form of testing.
>
> Sorry, I was building to that... But currently, the test-suite
> compiles the code into an executable, then run it. Changing that
> premise means we'll have something other than the test-suite we always
> had, and may bring other problems, like too many hats for the
> infrastructure to keep, especially now that James is moving it to
> integrate with lit. We may decide this is the way to go, but we need
> to make clear all the pros and cons of doing so beforehand.
>
>
> > This is perhaps an interesting part/point: In theory I would think that
> > these tests should be able to be phrased in a compiler-agnostic way,
> since
> > they're testing the compiler as a whole and testing behavior that the
> source
> > code demands, no?
>
> There's where things get interesting. Say we change the test-suite to
> instead of compiling and running, just compile to asm/obj and
> grep/objdump to match instructions, ELF sections, debug symbols, etc.
>
> Some tests are easy to make compiler independent. Intrinsics tests
> fall into that category. Most currently in Clang tests could move
> directly to the test-suite as soon as we have such infrastructure.
>
> Other tests, however, are specific to Clang+LLVM that may make no
> sense to GCC or ICC, ARMCC etc. Those tests, would have to be in yet
> another separate directory, that is only enabled if the compiler is
> Clang, assuming the back-end is always LLVM.
>
> These are all options that, for me, have equal value with keeping them
> in Clang. AFAICS, they stir the same kind of problems wherever they
> are tested.
>
>
> >> would account for most of those problems, but it would also put a
> >> stress on slow/expensive/experimental hardware support. It's a
> >> balance, I think.
> >
> > Why would it require slow/expensive/experimental hardware? (& if it does
> > require that, how do you expect average developers to run them on a
> regular
> > basis?)
>
> You misunderstood. It would "put a stress on", not "require".
> Basically, it would increase the cost of testing on those classes of
> hardware more than off-the-shelf hardware by a non-trivial amount.
>
> This goes back to our discussion on buildbots, where some targets are
> harder to find hardware than others, and when you do, they're slower.
> Meaning the more variations we need to test, the more hardware you
> have to have to make it in any reasonable time. While a single 64-core
> Xeon can cope with most testing (including self-hosting, test-suite,
> sanitizers, libc++) on a per-commit basis, there is nothing similar,
> widely available, today for most other targets.
>
> But that's another discussion entirely, let's not dwell into that again. :)
>
> cheers,
> --renato
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r254446 - Avoid picking up system headers in unittest by providing a fake libstdc++ with a ridiculously high version number.

[Benjamin Kramer via cfe-commits]

Author: d0k
Date: Tue Dec  1 13:42:07 2015
New Revision: 254446

URL: http://llvm.org/viewvc/llvm-project?rev=254446=rev
Log:
Avoid picking up system headers in unittest by providing a fake libstdc++ with 
a ridiculously high version number.

The host libstdc++ may be horribly broken and we want the fake one to be
picked up. This workaround is lame but I don't see a better way.

Modified:
cfe/trunk/unittests/libclang/LibclangTest.cpp

Modified: cfe/trunk/unittests/libclang/LibclangTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/libclang/LibclangTest.cpp?rev=254446=254445=254446=diff
==
--- cfe/trunk/unittests/libclang/LibclangTest.cpp (original)
+++ cfe/trunk/unittests/libclang/LibclangTest.cpp Tue Dec  1 13:42:07 2015
@@ -469,9 +469,11 @@ TEST_F(LibclangReparseTest, ReparseWithM
 }
 
 TEST_F(LibclangReparseTest, clang_parseTranslationUnit2FullArgv) {
-  std::string EmptyFiles[] = {"lib/gcc/arm-linux-gnueabi/4.6.1/crtbegin.o",
+  // Provide a fake GCC 99.9.9 standard library that always overrides any local
+  // GCC installation.
+  std::string EmptyFiles[] = {"lib/gcc/arm-linux-gnueabi/99.9.9/crtbegin.o",
   "include/arm-linux-gnueabi/.keep",
-  "include/c++/4.6.1/vector"};
+  "include/c++/99.9.9/vector"};
 
   for (auto  : EmptyFiles)
 WriteFile(Name, "\n");


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

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[David Blaikie via cfe-commits]

On Tue, Dec 1, 2015 at 11:39 AM, Renato Golin 
wrote:

> On 1 December 2015 at 19:09, David Blaikie  wrote:
> > Not sure I follow - I'm not suggesting adding objdump/instruction
> checking
> > to existing large programs in the test-suite, but adding other tests to
> the
> > test-suite that do this and have appropriate input for it to be a
> > reliable/useful form of testing.
>
> Sorry, I was building to that... But currently, the test-suite
> compiles the code into an executable, then run it. Changing that
> premise means we'll have something other than the test-suite we always
> had, and may bring other problems, like too many hats for the
> infrastructure to keep, especially now that James is moving it to
> integrate with lit. We may decide this is the way to go, but we need
> to make clear all the pros and cons of doing so beforehand.
>
>
> > This is perhaps an interesting part/point: In theory I would think that
> > these tests should be able to be phrased in a compiler-agnostic way,
> since
> > they're testing the compiler as a whole and testing behavior that the
> source
> > code demands, no?
>
> There's where things get interesting. Say we change the test-suite to
> instead of compiling and running, just compile to asm/obj and
> grep/objdump to match instructions, ELF sections, debug symbols, etc.
>
> Some tests are easy to make compiler independent. Intrinsics tests
> fall into that category. Most currently in Clang tests could move
> directly to the test-suite as soon as we have such infrastructure.
>
> Other tests, however, are specific to Clang+LLVM that may make no
> sense to GCC or ICC, ARMCC etc. Those tests, would have to be in yet
> another separate directory, that is only enabled if the compiler is
> Clang, assuming the back-end is always LLVM.
>

These cases I don't understand - if they're features LLVM supports we'd
just test them straight up. If you run our test suite against another
compiler it should tell you if it's compatible with our compiler (does it
offer the same functionality), so we don't have to maintain a distinction
between functionality we support and other compilers support, and
functionality we support and no other compiler support.

If the test isn't testing observable functionality, but some implementation
detail, that's a separate question and one I'd probably say shouldn't go in
the test-suite.


> These are all options that, for me, have equal value with keeping them
> in Clang. AFAICS, they stir the same kind of problems wherever they
> are tested.
>
>
> >> would account for most of those problems, but it would also put a
> >> stress on slow/expensive/experimental hardware support. It's a
> >> balance, I think.
> >
> > Why would it require slow/expensive/experimental hardware? (& if it does
> > require that, how do you expect average developers to run them on a
> regular
> > basis?)
>
> You misunderstood. It would "put a stress on", not "require".
> Basically, it would increase the cost of testing on those classes of
> hardware more than off-the-shelf hardware by a non-trivial amount.
>
> This goes back to our discussion on buildbots, where some targets are
> harder to find hardware than others, and when you do, they're slower.
> Meaning the more variations we need to test, the more hardware you
> have to have to make it in any reasonable time. While a single 64-core
> Xeon can cope with most testing (including self-hosting, test-suite,
> sanitizers, libc++) on a per-commit basis, there is nothing similar,
> widely available, today for most other targets.
>
> But that's another discussion entirely, let's not dwell into that again. :)
>

If you say so :)

- Dave


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

Re: [PATCH] D14872: PR25575: Make GCC 4.4+ comatible layout for packed bit-fileds of char type

[John McCall via cfe-commits]

rjmccall added inline comments.


Comment at: include/clang/Basic/DiagnosticSemaKinds.td:2790
@@ -2790,1 +2789,3 @@
+  "version 4.4 - the newer offset is used here">,
+  InGroup>;
 def warn_transparent_union_attribute_field_size_align : Warning<

No, this diagnostic shouldn't make such an affirmative statement about the 
offset changing.  I would instead suggest:
  warning: 'packed' attribute was ignored on bit-fields with alignment 1 in 
older versions of GCC and Clang


http://reviews.llvm.org/D14872



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

r254450 - Update for llvm api change.

[Rafael Espindola via cfe-commits]

Author: rafael
Date: Tue Dec  1 13:51:03 2015
New Revision: 254450

URL: http://llvm.org/viewvc/llvm-project?rev=254450=rev
Log:
Update for llvm api change.

Modified:
cfe/trunk/lib/CodeGen/CodeGenAction.cpp

Modified: cfe/trunk/lib/CodeGen/CodeGenAction.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenAction.cpp?rev=254450=254449=254450=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenAction.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenAction.cpp Tue Dec  1 13:51:03 2015
@@ -165,7 +165,7 @@ namespace clang {
   for (auto  : LinkModules) {
 unsigned LinkFlags = I.first;
 llvm::Module *LinkModule = I.second.get();
-if (Linker::LinkModules(M, LinkModule,
+if (Linker::linkModules(*M, *LinkModule,
 [=](const DiagnosticInfo ) {
   linkerDiagnosticHandler(DI, LinkModule);
 },


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

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[James Molloy via cfe-commits]

Ok, understood.

I think I'd be OK with demoting these tests to the test-suite, and dealing
with the slightly lower amount of testing that comes with it if it means we
can keep the clang tests in a nice shape.

We'd need to ensure there were equivalent tests written that test only
clang produced IR - many tests will have this already but some don't.

James
On Tue, 1 Dec 2015 at 19:51, Renato Golin  wrote:

> On 1 December 2015 at 19:42, James Molloy  wrote:
> > Why do you think it would be non trivial? Some simple lit tests aren't
> > exactly arduous on most targets.
>
> I mean having more points in the testing matrix.
>
> Clang check-all is cheaper than running the test-suite, but if we
> start moving more tests to the suite, we'll have to run it for more
> combinations. For slow targets, that mostly means a new buildbot,
> because you want the "fast" check-all to not be impeded by the "slow"
> test-suite for every commit.
>
> The "non-trivial" amount is the sole difference in how many machines
> you can get to have a reasonable amount of commits in the blame-list
> for everything we test, which is trivial on fast x86_64 servers.
>
> --renato
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r254451 - Add an accessor to Decl::LoadedFieldsFromExternalStorage for LLDB.

[Adrian Prantl via cfe-commits]

Author: adrian
Date: Tue Dec  1 13:54:07 2015
New Revision: 254451

URL: http://llvm.org/viewvc/llvm-project?rev=254451=rev
Log:
Add an accessor to Decl::LoadedFieldsFromExternalStorage for LLDB.

Patch by Greg Clayton
Reviewed by Doug Gregor

Modified:
cfe/trunk/include/clang/AST/Decl.h

Modified: cfe/trunk/include/clang/AST/Decl.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Decl.h?rev=254451=254450=254451=diff
==
--- cfe/trunk/include/clang/AST/Decl.h (original)
+++ cfe/trunk/include/clang/AST/Decl.h Tue Dec  1 13:54:07 2015
@@ -3306,7 +3306,10 @@ public:
 
   bool hasVolatileMember() const { return HasVolatileMember; }
   void setHasVolatileMember (bool val) { HasVolatileMember = val; }
-  
+
+  bool hasLoadedFieldsFromExternalStorage() const { return 
LoadedFieldsFromExternalStorage; }
+  void setHasLoadedFieldsFromExternalStorage (bool val) { 
LoadedFieldsFromExternalStorage = val; }
+
   /// \brief Determines whether this declaration represents the
   /// injected class name.
   ///


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

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[Renato Golin via cfe-commits]

On 1 December 2015 at 19:53, James Molloy  wrote:
> I think I'd be OK with demoting these tests to the test-suite, and dealing
> with the slightly lower amount of testing that comes with it if it means we
> can keep the clang tests in a nice shape.

If the tests are independent of sub-architecture and instruction set, then yes.

If not, it means we'll have to have one test-suite per ISA / sub-arch
combination, in the same way we already (try to) have one Clang+LLVM
for each. This shows how it can go exponential.

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

Re: [PATCH] D7718: Itanium ABI: Properly mangle extern "C" template arguments

[Yaron Keren via cfe-commits]

yaron.keren added a subscriber: yaron.keren.
yaron.keren added a comment.

There is another copy of getEffectiveDeclContext in MicrosoftMangle.cpp which 
pre-commit was identical to this one.
Should it get this commit as well to keep both identical?
If so, could both copies of getEffectiveDeclContext be merged?


Repository:
  rL LLVM

http://reviews.llvm.org/D7718



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

r254394 - [analyzer] Fix IssueHash generation.

[Gabor Horvath via cfe-commits]

Author: xazax
Date: Tue Dec  1 03:00:41 2015
New Revision: 254394

URL: http://llvm.org/viewvc/llvm-project?rev=254394=rev
Log:
[analyzer] Fix IssueHash generation.

Differential Revision: http://reviews.llvm.org/D14919 

Original patch by: Gyorgy Orban!

Modified:
cfe/trunk/include/clang/StaticAnalyzer/Core/IssueHash.h
cfe/trunk/lib/Basic/SourceManager.cpp
cfe/trunk/lib/StaticAnalyzer/Checkers/DebugCheckers.cpp
cfe/trunk/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
cfe/trunk/lib/StaticAnalyzer/Core/IssueHash.cpp
cfe/trunk/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
cfe/trunk/test/Analysis/bug_hash_test.cpp
cfe/trunk/test/Analysis/diagnostics/report-issues-within-main-file.cpp

Modified: cfe/trunk/include/clang/StaticAnalyzer/Core/IssueHash.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/StaticAnalyzer/Core/IssueHash.h?rev=254394=254393=254394=diff
==
--- cfe/trunk/include/clang/StaticAnalyzer/Core/IssueHash.h (original)
+++ cfe/trunk/include/clang/StaticAnalyzer/Core/IssueHash.h Tue Dec  1 03:00:41 
2015
@@ -15,6 +15,7 @@ namespace clang {
 class Decl;
 class SourceManager;
 class FullSourceLoc;
+class LangOptions;
 
 /// \brief Get an MD5 hash to help identify bugs.
 ///
@@ -37,13 +38,14 @@ class FullSourceLoc;
 llvm::SmallString<32> GetIssueHash(const SourceManager ,
FullSourceLoc ,
llvm::StringRef CheckerName,
-   llvm::StringRef BugType, const Decl *D);
+   llvm::StringRef BugType, const Decl *D,
+   const LangOptions );
 
 /// \brief Get the string representation of issue hash. See GetIssueHash() for
 /// more information.
 std::string GetIssueString(const SourceManager , FullSourceLoc ,
llvm::StringRef CheckerName, llvm::StringRef 
BugType,
-   const Decl *D);
+   const Decl *D, const LangOptions );
 } // namespace clang
 
 #endif

Modified: cfe/trunk/lib/Basic/SourceManager.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/SourceManager.cpp?rev=254394=254393=254394=diff
==
--- cfe/trunk/lib/Basic/SourceManager.cpp (original)
+++ cfe/trunk/lib/Basic/SourceManager.cpp Tue Dec  1 03:00:41 2015
@@ -1717,7 +1717,7 @@ SourceLocation SourceManager::translateL
unsigned Col) const {
   // Lines are used as a one-based index into a zero-based array. This assert
   // checks for possible buffer underruns.
-  assert(Line != 0 && "Passed a zero-based line");
+  assert(Line && Col && "Line and column should start from 1!");
 
   if (FID.isInvalid())
 return SourceLocation();

Modified: cfe/trunk/lib/StaticAnalyzer/Checkers/DebugCheckers.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Checkers/DebugCheckers.cpp?rev=254394=254393=254394=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Checkers/DebugCheckers.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Checkers/DebugCheckers.cpp Tue Dec  1 03:00:41 
2015
@@ -230,11 +230,12 @@ public:
 if (!N)
   return;
 
+const LangOptions  = C.getLangOpts();
 const SourceManager  = C.getSourceManager();
 FullSourceLoc FL(S->getLocStart(), SM);
 std::string HashContent =
 GetIssueString(SM, FL, getCheckName().getName(), BT->getCategory(),
-   C.getLocationContext()->getDecl());
+   C.getLocationContext()->getDecl(), Opts);
 
 C.emitReport(llvm::make_unique(*BT, HashContent, N));
   }

Modified: cfe/trunk/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp?rev=254394=254393=254394=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp Tue Dec  1 03:00:41 
2015
@@ -255,8 +255,8 @@ void HTMLDiagnostics::ReportDiag(const P
 os  << "\n\n";
 
 os << "\n\n";
+   << GetIssueHash(SMgr, L, D.getCheckName(), D.getBugType(), 
DeclWithIssue,
+   PP.getLangOpts()) << " -->\n";
 
 os << "\n
-// CHECK-NEXT:   
issue_hash_content_of_line_in_contextf8ee38da3de42e209c4afa886b5531ab
+// CHECK-NEXT:   
issue_hash_content_of_line_in_contextf5471f52854dc14167fe96db50c4ba5f
 // CHECK-NEXT:  issue_context_kindfunction
 // CHECK-NEXT:  issue_contextf
 // CHECK-NEXT:  issue_hash_function_offset0

Modified: cfe/trunk/test/Analysis/diagnostics/report-issues-within-main-file.cpp
URL: 

Re: [PATCH] D15090: [Static Analyzer] New checker hook: checkInitialState

[Artem Dergachev via cfe-commits]

NoQ added a subscriber: NoQ.
NoQ added a comment.

Yeah, that's what i had in mind. Additionally, `Decl` can be obtained as 
`Context.getStackFrame().getDecl()` (and in fact the `getStackFrame()` thing 
itself is of interest as well), so there's no need to pass it as an extra 
argument. On the other hand, `CallEvent` might be of interest to have easier 
access to function arguments (not sure how much sense there is in a `CallEvent` 
object corresponding to the //top frame//, even though values inside it are 
pretty obvious).


http://reviews.llvm.org/D15090



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

Re: [PATCH] D14919: Fix IssueHash generation

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

xazax.hun closed this revision.
xazax.hun added a comment.

Committed in r254394.


http://reviews.llvm.org/D14919



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

r254392 - Remove superfluous StringRef casts, NFC.

[Yaron Keren via cfe-commits]

Author: yrnkrn
Date: Tue Dec  1 02:14:39 2015
New Revision: 254392

URL: http://llvm.org/viewvc/llvm-project?rev=254392=rev
Log:
Remove superfluous StringRef casts, NFC.


Modified:
cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp

Modified: cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp?rev=254392=254391=254392=diff
==
--- cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp (original)
+++ cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp Tue Dec  1 02:14:39 2015
@@ -3487,7 +3487,7 @@ llvm::GlobalVariable *MSRTTIBuilder::get
   auto Type = ABI.getClassHierarchyDescriptorType();
   auto CHD = new llvm::GlobalVariable(Module, Type, /*Constant=*/true, Linkage,
   /*Initializer=*/nullptr,
-  StringRef(MangledName));
+  MangledName);
   if (CHD->isWeakForLinker())
 CHD->setComdat(CGM.getModule().getOrInsertComdat(CHD->getName()));
 
@@ -3525,7 +3525,7 @@ MSRTTIBuilder::getBaseClassArray(SmallVe
   auto *BCA =
   new llvm::GlobalVariable(Module, ArrType,
/*Constant=*/true, Linkage,
-   /*Initializer=*/nullptr, 
StringRef(MangledName));
+   /*Initializer=*/nullptr, MangledName);
   if (BCA->isWeakForLinker())
 BCA->setComdat(CGM.getModule().getOrInsertComdat(BCA->getName()));
 
@@ -3567,7 +3567,7 @@ MSRTTIBuilder::getBaseClassDescriptor(co
   auto Type = ABI.getBaseClassDescriptorType();
   auto BCD =
   new llvm::GlobalVariable(Module, Type, /*Constant=*/true, Linkage,
-   /*Initializer=*/nullptr, 
StringRef(MangledName));
+   /*Initializer=*/nullptr, MangledName);
   if (BCD->isWeakForLinker())
 BCD->setComdat(CGM.getModule().getOrInsertComdat(BCD->getName()));
 
@@ -3613,7 +3613,7 @@ MSRTTIBuilder::getCompleteObjectLocator(
   // Forward-declare the complete object locator.
   llvm::StructType *Type = ABI.getCompleteObjectLocatorType();
   auto COL = new llvm::GlobalVariable(Module, Type, /*Constant=*/true, Linkage,
-/*Initializer=*/nullptr, StringRef(MangledName));
+/*Initializer=*/nullptr, MangledName);
 
   // Initialize the CompleteObjectLocator.
   llvm::Constant *Fields[] = {
@@ -3721,7 +3721,7 @@ llvm::Constant *MicrosoftCXXABI::getAddr
   CGM.getModule(), TypeDescriptorType, /*Constant=*/false,
   getLinkageForRTTI(Type),
   llvm::ConstantStruct::get(TypeDescriptorType, Fields),
-  StringRef(MangledName));
+  MangledName);
   if (Var->isWeakForLinker())
 Var->setComdat(CGM.getModule().getOrInsertComdat(Var->getName()));
   return llvm::ConstantExpr::getBitCast(Var, CGM.Int8PtrTy);
@@ -3964,7 +3964,7 @@ llvm::Constant *MicrosoftCXXABI::getCatc
   llvm::StructType *CTType = getCatchableTypeType();
   auto *GV = new llvm::GlobalVariable(
   CGM.getModule(), CTType, /*Constant=*/true, getLinkageForRTTI(T),
-  llvm::ConstantStruct::get(CTType, Fields), StringRef(MangledName));
+  llvm::ConstantStruct::get(CTType, Fields), MangledName);
   GV->setUnnamedAddr(true);
   GV->setSection(".xdata");
   if (GV->isWeakForLinker())
@@ -4082,7 +4082,7 @@ llvm::GlobalVariable *MicrosoftCXXABI::g
   }
   CTA = new llvm::GlobalVariable(
   CGM.getModule(), CTAType, /*Constant=*/true, getLinkageForRTTI(T),
-  llvm::ConstantStruct::get(CTAType, Fields), StringRef(MangledName));
+  llvm::ConstantStruct::get(CTAType, Fields), MangledName);
   CTA->setUnnamedAddr(true);
   CTA->setSection(".xdata");
   if (CTA->isWeakForLinker())


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

Re: [PATCH] D14872: PR25575: Make GCC 4.4+ comatible layout for packed bit-fileds of char type

[Dmitry Polukhin via cfe-commits]

DmitryPolukhin updated this revision to Diff 41510.
DmitryPolukhin marked an inline comment as done.
DmitryPolukhin added a comment.

Don't call getDeclName() that it is not required. PTAL


http://reviews.llvm.org/D14872

Files:
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/Sema/SemaDeclAttr.cpp
  test/Sema/struct-packed-align.c

Index: test/Sema/struct-packed-align.c
===
--- test/Sema/struct-packed-align.c
+++ test/Sema/struct-packed-align.c
@@ -1,5 +1,5 @@
 // RUN: %clang_cc1 %s -fsyntax-only -verify
-// expected-no-diagnostics
+// RUN: %clang_cc1 %s -fsyntax-only -triple=x86_64-windows-coff -verify
 
 // Packed structs.
 struct s {
@@ -138,3 +138,24 @@
 extern int n1[sizeof(struct nS) == 9 ? 1 : -1];
 extern int n2[__alignof(struct nS) == 1 ? 1 : -1];
 #endif
+
+// Packed attribute shouldn't be ignored for bit-field of char types.
+// Note from GCC reference manual: The 4.1, 4.2 and 4.3 series of GCC ignore
+// the packed attribute on bit-fields of type char. This has been fixed in
+// GCC 4.4 but the change can lead to differences in the structure layout.
+// See the documentation of -Wpacked-bitfield-compat for more information.
+struct packed_chars {
+  char a:4;
+  char b:8 __attribute__ ((packed));
+  // expected-warning@-1 {{the offset assigned to packed bit-field member 'b' 
changed with GCC version 4.4 - the newer offset is used here}}
+  char c:4;
+};
+
+#if defined(_WIN32)
+// On Windows clang ignores uses MSVC compatible layout in this case.
+extern int o1[sizeof(struct packed_chars) == 3 ? 1 : -1];
+extern int o2[__alignof(struct packed_chars) == 1 ? 1 : -1];
+#else
+extern int o1[sizeof(struct packed_chars) == 2 ? 1 : -1];
+extern int o2[__alignof(struct packed_chars) == 1 ? 1 : -1];
+#endif
Index: lib/Sema/SemaDeclAttr.cpp
===
--- lib/Sema/SemaDeclAttr.cpp
+++ lib/Sema/SemaDeclAttr.cpp
@@ -1036,17 +1036,15 @@
 TD->addAttr(::new (S.Context) PackedAttr(Attr.getRange(), S.Context,
 Attr.getAttributeSpellingListIndex()));
   else if (FieldDecl *FD = dyn_cast(D)) {
-// If the alignment is less than or equal to 8 bits, the packed attribute
-// has no effect.
+// Report warning about changed offset in the newer compiler versions.
 if (!FD->getType()->isDependentType() &&
-!FD->getType()->isIncompleteType() &&
+!FD->getType()->isIncompleteType() && FD->isBitField() &&
 S.Context.getTypeAlign(FD->getType()) <= 8)
-  S.Diag(Attr.getLoc(), diag::warn_attribute_ignored_for_field_of_type)
-<< Attr.getName() << FD->getType();
-else
-  FD->addAttr(::new (S.Context)
-  PackedAttr(Attr.getRange(), S.Context,
- Attr.getAttributeSpellingListIndex()));
+  S.Diag(Attr.getLoc(),
+ diag::note_attribute_packed_for_bitfield_offset_changed) << FD;
+
+FD->addAttr(::new (S.Context) PackedAttr(
+Attr.getRange(), S.Context, Attr.getAttributeSpellingListIndex()));
   } else
 S.Diag(Attr.getLoc(), diag::warn_attribute_ignored) << Attr.getName();
 }
Index: include/clang/Basic/DiagnosticSemaKinds.td
===
--- include/clang/Basic/DiagnosticSemaKinds.td
+++ include/clang/Basic/DiagnosticSemaKinds.td
@@ -2784,9 +2784,10 @@
   "cast to %1 from smaller integer type %0">,
   InGroup;
 
-def warn_attribute_ignored_for_field_of_type : Warning<
-  "%0 attribute ignored for field of type %1">,
-  InGroup;
+def note_attribute_packed_for_bitfield_offset_changed : Warning<
+  "the offset assigned to packed bit-field member %0 changed with GCC "
+  "version 4.4 - the newer offset is used here">,
+  InGroup>;
 def warn_transparent_union_attribute_field_size_align : Warning<
   "%select{alignment|size}0 of field %1 (%2 bits) does not match the "
   "%select{alignment|size}0 of the first field in transparent union; "


Index: test/Sema/struct-packed-align.c
===
--- test/Sema/struct-packed-align.c
+++ test/Sema/struct-packed-align.c
@@ -1,5 +1,5 @@
 // RUN: %clang_cc1 %s -fsyntax-only -verify
-// expected-no-diagnostics
+// RUN: %clang_cc1 %s -fsyntax-only -triple=x86_64-windows-coff -verify
 
 // Packed structs.
 struct s {
@@ -138,3 +138,24 @@
 extern int n1[sizeof(struct nS) == 9 ? 1 : -1];
 extern int n2[__alignof(struct nS) == 1 ? 1 : -1];
 #endif
+
+// Packed attribute shouldn't be ignored for bit-field of char types.
+// Note from GCC reference manual: The 4.1, 4.2 and 4.3 series of GCC ignore
+// the packed attribute on bit-fields of type char. This has been fixed in
+// GCC 4.4 but the change can lead to differences in the structure layout.
+// See the documentation of -Wpacked-bitfield-compat for more information.
+struct packed_chars {
+  

Re: [PATCH] D13980: Add "x87" in x86 target feature map

[Andrey Turetskiy via cfe-commits]

aturetsk updated this revision to Diff 41511.
aturetsk added a comment.

Enable X87 back for all X86 processors.


http://reviews.llvm.org/D13980

Files:
  lib/Basic/Targets.cpp
  test/CodeGen/attr-target-x86-mmx.c
  test/CodeGen/attr-target-x86.c

Index: test/CodeGen/attr-target-x86.c
===
--- test/CodeGen/attr-target-x86.c
+++ test/CodeGen/attr-target-x86.c
@@ -31,9 +31,9 @@
 // CHECK: qux{{.*}} #1
 // CHECK: qax{{.*}} #4
 // CHECK: qq{{.*}} #5
-// CHECK: #0 = {{.*}}"target-cpu"="x86-64" 
"target-features"="+fxsr,+mmx,+sse,+sse2"
-// CHECK: #1 = {{.*}}"target-cpu"="ivybridge" 
"target-features"="+aes,+avx,+cx16,+f16c,+fsgsbase,+fxsr,+mmx,+pclmul,+popcnt,+rdrnd,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+ssse3,+xsave,+xsaveopt"
-// CHECK: #2 = {{.*}}"target-cpu"="x86-64" 
"target-features"="+fxsr,+mmx,+sse,-aes,-avx,-avx2,-avx512bw,-avx512cd,-avx512dq,-avx512er,-avx512f,-avx512pf,-avx512vl,-f16c,-fma,-fma4,-pclmul,-sha,-sse2,-sse3,-sse4.1,-sse4.2,-sse4a,-ssse3,-xop,-xsave,-xsaveopt"
-// CHECK: #3 = {{.*}}"target-cpu"="x86-64" 
"target-features"="+fxsr,+mmx,+popcnt,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+ssse3"
-// CHECK: #4 = {{.*}}"target-cpu"="ivybridge" 
"target-features"="+avx,+cx16,+f16c,+fsgsbase,+fxsr,+mmx,+pclmul,+popcnt,+rdrnd,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+ssse3,+xsave,+xsaveopt,-aes"
-// CHECK: #5 = {{.*}}"target-cpu"="x86-64" 
"target-features"="+fxsr,+sse,+sse2,-3dnow,-3dnowa,-mmx"
+// CHECK: #0 = {{.*}}"target-cpu"="x86-64" 
"target-features"="+fxsr,+mmx,+sse,+sse2,+x87"
+// CHECK: #1 = {{.*}}"target-cpu"="ivybridge" 
"target-features"="+aes,+avx,+cx16,+f16c,+fsgsbase,+fxsr,+mmx,+pclmul,+popcnt,+rdrnd,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+ssse3,+x87,+xsave,+xsaveopt"
+// CHECK: #2 = {{.*}}"target-cpu"="x86-64" 
"target-features"="+fxsr,+mmx,+sse,+x87,-aes,-avx,-avx2,-avx512bw,-avx512cd,-avx512dq,-avx512er,-avx512f,-avx512pf,-avx512vl,-f16c,-fma,-fma4,-pclmul,-sha,-sse2,-sse3,-sse4.1,-sse4.2,-sse4a,-ssse3,-xop,-xsave,-xsaveopt"
+// CHECK: #3 = {{.*}}"target-cpu"="x86-64" 
"target-features"="+fxsr,+mmx,+popcnt,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+ssse3,+x87"
+// CHECK: #4 = {{.*}}"target-cpu"="ivybridge" 
"target-features"="+avx,+cx16,+f16c,+fsgsbase,+fxsr,+mmx,+pclmul,+popcnt,+rdrnd,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+ssse3,+x87,+xsave,+xsaveopt,-aes"
+// CHECK: #5 = {{.*}}"target-cpu"="x86-64" 
"target-features"="+fxsr,+sse,+sse2,+x87,-3dnow,-3dnowa,-mmx"
Index: test/CodeGen/attr-target-x86-mmx.c
===
--- test/CodeGen/attr-target-x86-mmx.c
+++ test/CodeGen/attr-target-x86-mmx.c
@@ -19,4 +19,4 @@
   _mm_srai_pi32(a, c);
 }
 
-// CHECK: "target-features"="+mmx,+sse"
+// CHECK: "target-features"="+mmx,+sse,+x87"
Index: lib/Basic/Targets.cpp
===
--- lib/Basic/Targets.cpp
+++ lib/Basic/Targets.cpp
@@ -2542,6 +2542,9 @@
   if (getTriple().getArch() == llvm::Triple::x86_64)
 setFeatureEnabledImpl(Features, "sse2", true);
 
+  // Enable X87 for all X86 processors.
+  setFeatureEnabledImpl(Features, "x87", true);
+
   switch (getCPUKind(CPU)) {
   case CK_Generic:
   case CK_i386:


Index: test/CodeGen/attr-target-x86.c
===
--- test/CodeGen/attr-target-x86.c
+++ test/CodeGen/attr-target-x86.c
@@ -31,9 +31,9 @@
 // CHECK: qux{{.*}} #1
 // CHECK: qax{{.*}} #4
 // CHECK: qq{{.*}} #5
-// CHECK: #0 = {{.*}}"target-cpu"="x86-64" "target-features"="+fxsr,+mmx,+sse,+sse2"
-// CHECK: #1 = {{.*}}"target-cpu"="ivybridge" "target-features"="+aes,+avx,+cx16,+f16c,+fsgsbase,+fxsr,+mmx,+pclmul,+popcnt,+rdrnd,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+ssse3,+xsave,+xsaveopt"
-// CHECK: #2 = {{.*}}"target-cpu"="x86-64" "target-features"="+fxsr,+mmx,+sse,-aes,-avx,-avx2,-avx512bw,-avx512cd,-avx512dq,-avx512er,-avx512f,-avx512pf,-avx512vl,-f16c,-fma,-fma4,-pclmul,-sha,-sse2,-sse3,-sse4.1,-sse4.2,-sse4a,-ssse3,-xop,-xsave,-xsaveopt"
-// CHECK: #3 = {{.*}}"target-cpu"="x86-64" "target-features"="+fxsr,+mmx,+popcnt,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+ssse3"
-// CHECK: #4 = {{.*}}"target-cpu"="ivybridge" "target-features"="+avx,+cx16,+f16c,+fsgsbase,+fxsr,+mmx,+pclmul,+popcnt,+rdrnd,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+ssse3,+xsave,+xsaveopt,-aes"
-// CHECK: #5 = {{.*}}"target-cpu"="x86-64" "target-features"="+fxsr,+sse,+sse2,-3dnow,-3dnowa,-mmx"
+// CHECK: #0 = {{.*}}"target-cpu"="x86-64" "target-features"="+fxsr,+mmx,+sse,+sse2,+x87"
+// CHECK: #1 = {{.*}}"target-cpu"="ivybridge" "target-features"="+aes,+avx,+cx16,+f16c,+fsgsbase,+fxsr,+mmx,+pclmul,+popcnt,+rdrnd,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+ssse3,+x87,+xsave,+xsaveopt"
+// CHECK: #2 = {{.*}}"target-cpu"="x86-64" "target-features"="+fxsr,+mmx,+sse,+x87,-aes,-avx,-avx2,-avx512bw,-avx512cd,-avx512dq,-avx512er,-avx512f,-avx512pf,-avx512vl,-f16c,-fma,-fma4,-pclmul,-sha,-sse2,-sse3,-sse4.1,-sse4.2,-sse4a,-ssse3,-xop,-xsave,-xsaveopt"
+// CHECK: #3 = 

Re: [PATCH] D13980: Add "x87" in x86 target feature map

[Andrey Turetskiy via cfe-commits]

aturetsk added inline comments.


Comment at: lib/Basic/Targets.cpp:2551
@@ -2547,3 +2550,3 @@
   case CK_i386:
   case CK_i486:
   case CK_i586:

"x87 instructions probably work" is more like it, and having feature x87 
disabled would mean "x87 instructions definitely don't work". That's what I 
intended. If feature soft float is specified it takes precedence over feature 
x87 causing compiler to generate calls instead of X87 instructions.
Support of -m80387/-mno-80387 seems to be a good thing to have in Clang to be 
compatible with GCC (although briefly looking at GCC's sources these options 
just seem to be synonyms to -mhard-float/-msoft-float). I can add the flags, 
but I think that's better to be done in a separate patch.


http://reviews.llvm.org/D13980



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

Re: [PATCH] D14980: PR18513: make gcc compatible layout for bit-fields with explicit aligned attribute

[Dmitry Polukhin via cfe-commits]

DmitryPolukhin updated this revision to Diff 41481.
DmitryPolukhin added a comment.

Added more testcases to cover combination of explicit alignment of bit-filed 
with packed attribute. Also added testing on ARM for bit-filed layout test.


http://reviews.llvm.org/D14980

Files:
  lib/AST/RecordLayoutBuilder.cpp
  test/Sema/bitfield-layout.c

Index: test/Sema/bitfield-layout.c
===
--- test/Sema/bitfield-layout.c
+++ test/Sema/bitfield-layout.c
@@ -1,41 +1,72 @@
 // RUN: %clang_cc1 %s -fsyntax-only -verify -triple=i686-apple-darwin9
+// RUN: %clang_cc1 %s -fsyntax-only -verify -triple=armv7
 // expected-no-diagnostics
+#include 
 
-#define CHECK_SIZE(kind, name, size) extern int name##1[sizeof(kind name) == size ? 1 : -1];
-#define CHECK_ALIGN(kind, name, size) extern int name##2[__alignof(kind name) == size ? 1 : -1];
+#define CHECK_SIZE(kind, name, size) \
+  extern int name##1[sizeof(kind name) == size ? 1 : -1];
+#define CHECK_ALIGN(kind, name, size) \
+  extern int name##2[__alignof(kind name) == size ? 1 : -1];
+#define CHECK_OFFSET(kind, name, member, offset) \
+  extern int name##2[offsetof(kind name, member) == offset ? 1 : -1];
 
 // Zero-width bit-fields
 struct a {char x; int : 0; char y;};
+#ifdef __ARM_EABI__
+CHECK_SIZE(struct, a, 8)
+CHECK_ALIGN(struct, a, 4)
+#else
 CHECK_SIZE(struct, a, 5)
 CHECK_ALIGN(struct, a, 1)
+#endif
 
 // Zero-width bit-fields with packed
 struct __attribute__((packed)) a2 { short x : 9; char : 0; int y : 17; };
 CHECK_SIZE(struct, a2, 5)
 CHECK_ALIGN(struct, a2, 1)
 
 // Zero-width bit-fields at the end of packed struct
 struct __attribute__((packed)) a3 { short x : 9; int : 0; };
+#ifdef __ARM_EABI__
+CHECK_SIZE(struct, a3, 4)
+CHECK_ALIGN(struct, a3, 4)
+#else
 CHECK_SIZE(struct, a3, 4)
 CHECK_ALIGN(struct, a3, 1)
+#endif
 
 // For comparison, non-zero-width bit-fields at the end of packed struct
 struct __attribute__((packed)) a4 { short x : 9; int : 1; };
 CHECK_SIZE(struct, a4, 2)
 CHECK_ALIGN(struct, a4, 1)
 
 union b {char x; int : 0; char y;};
+#ifdef __ARM_EABI__
+CHECK_SIZE(union, b, 4)
+CHECK_ALIGN(union, b, 4)
+#else
 CHECK_SIZE(union, b, 1)
 CHECK_ALIGN(union, b, 1)
+#endif
 
 // Unnamed bit-field align
 struct c {char x; int : 20;};
+#ifdef __ARM_EABI__
+CHECK_SIZE(struct, c, 4)
+CHECK_ALIGN(struct, c, 4)
+#else
 CHECK_SIZE(struct, c, 4)
 CHECK_ALIGN(struct, c, 1)
+#endif
 
 union d {char x; int : 20;};
+#ifdef __ARM_EABI__
+CHECK_SIZE(union, d, 4)
+CHECK_ALIGN(union, d, 4)
+#else
 CHECK_SIZE(union, d, 3)
 CHECK_ALIGN(union, d, 1)
+#endif
 
 // Bit-field packing
 struct __attribute__((packed)) e {int x : 4, y : 30, z : 30;};
@@ -56,3 +87,99 @@
 CHECK_SIZE(struct, s0, 0x3218)
 CHECK_ALIGN(struct, s0, 4)
 
+// Bit-field with explicit align bigger than normal.
+struct g0 {
+  char a;
+  __attribute__((aligned(16))) int b : 1;
+  char c;
+};
+
+CHECK_SIZE(struct, g0, 32);
+CHECK_ALIGN(struct, g0, 16);
+CHECK_OFFSET(struct, g0, c, 17);
+
+// Bit-field with explicit align smaller than normal.
+struct g1 {
+  char a;
+  __attribute__((aligned(2))) int b : 1;
+  char c;
+};
+
+CHECK_SIZE(struct, g1, 4);
+CHECK_ALIGN(struct, g1, 4);
+CHECK_OFFSET(struct, g1, c, 3);
+
+// Same as above but without explicit align.
+struct g2 {
+  char a;
+  int b : 1;
+  char c;
+};
+
+CHECK_SIZE(struct, g2, 4);
+CHECK_ALIGN(struct, g2, 4);
+CHECK_OFFSET(struct, g2, c, 2);
+
+// Explicit attribute align on bit-field has precedence over packed attribute
+// applied too the struct.
+struct __attribute__((packed)) g3 {
+  char a;
+  __attribute__((aligned(16))) int b : 1;
+  char c;
+};
+
+CHECK_SIZE(struct, g3, 32);
+CHECK_ALIGN(struct, g3, 16);
+CHECK_OFFSET(struct, g3, c, 17);
+
+struct __attribute__((packed)) g4 {
+  char a;
+  __attribute__((aligned(2))) int b : 1;
+  char c;
+};
+
+CHECK_SIZE(struct, g4, 4);
+CHECK_ALIGN(struct, g4, 2);
+CHECK_OFFSET(struct, g4, c, 3);
+
+struct g5 {
+  char : 1;
+  __attribute__((aligned(1))) int n : 24;
+};
+CHECK_SIZE(struct, g5, 4);
+CHECK_ALIGN(struct, g5, 4);
+
+struct __attribute__((packed)) g6 {
+  char : 1;
+  __attribute__((aligned(1))) int n : 24;
+};
+CHECK_SIZE(struct, g6, 4);
+CHECK_ALIGN(struct, g6, 1);
+
+struct g7 {
+  char : 1;
+  __attribute__((aligned(1))) int n : 25;
+};
+CHECK_SIZE(struct, g7, 8);
+CHECK_ALIGN(struct, g7, 4);
+
+struct __attribute__((packed)) g8 {
+  char : 1;
+  __attribute__((aligned(1))) int n : 25;
+};
+CHECK_SIZE(struct, g8, 5);
+CHECK_ALIGN(struct, g8, 1);
+
+struct g9 {
+  __attribute__((aligned(1))) char a : 2, b : 2, c : 2, d : 2, e : 2;
+  int i;
+};
+CHECK_SIZE(struct, g9, 12);
+CHECK_ALIGN(struct, g9, 4);
+
+struct __attribute__((packed)) g10 {
+  __attribute__((aligned(1))) char a : 2, b : 2, c : 2, d : 2, e : 2;
+  int i;
+};
+CHECK_SIZE(struct, g10, 9);
+CHECK_ALIGN(struct, g10, 1);
Index: lib/AST/RecordLayoutBuilder.cpp
===
--- 

Re: [PATCH] D14727: [Driver] Adapt Linux::GCCVersion::Parse to match GCC 5 installations

[Jonathan Roelofs via cfe-commits]

jroelofs requested changes to this revision.
jroelofs added a reviewer: jroelofs.
jroelofs added a comment.
This revision now requires changes to proceed.

I'm getting a couple of test failures from this patch:

  Clang :: Driver/linux-header-search.cpp
  Clang :: Driver/solaris-header-search.cpp

For the latter of the two, the driver picks:

  
test/Driver/Inputs/sparc-sun-solaris2.11/usr/gcc/.8/include/c++/4.8.2/sparc-sun-solaris2.11

as the `-internal-isystem` directory, which doesn't exist. It should be finding:

  
test/Driver/Inputs/sparc-sun-solaris2.11/usr/gcc/4.8.2/include/c++/4.8.2/sparc-sun-solaris2.11

I think it might be because `GoodVersion.MajorStr` is no longer set.


http://reviews.llvm.org/D14727



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

Re: [PATCH] D14653: [libcxx] Introduce the mechanism for fixing -fno-exceptions test failures.

[Asiri Rathnayake via cfe-commits]

rmaprath added a comment.

Ping?


http://reviews.llvm.org/D14653



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

Re: [PATCH] D14325: [clang-format] Do not align assignments that aren't after the same number of commas. (Closes: 25329)

[Daniel Jasper via cfe-commits]

djasper closed this revision.
djasper added a comment.

Submitted as r254406.

Note that I had to make the struct "Change" public. How did this compile on 
your end?


http://reviews.llvm.org/D14325



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

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[Renato Golin via cfe-commits]

On 1 December 2015 at 11:44, James Molloy via cfe-commits
 wrote:
> In summary, I agree with you that we need tests for both Clang and LLVM
> separately. However I also think the full-trip tests add significant value
> and wouldn't like to see them removed, and there's significant prior art in
> this area so if we did decide they needed to be gone, we'd need a good
> discussion on how to regain the testing coverage we'd lose.

I agree with James on all accounts. IR tests need to be written, but
assembly tests in Clang are not a bad idea at all.

You can have a Clang test to IR and an LLVM test form IR to assembly,
but if these IRs are not the same (because time passes, people forget
about updating tests), then you have a serious problem that you can't
see.

Having assembly tests in Clang mean that the right instructions are
being picked from the right high-level C code. If Clang stops
producing them, especially in the case of SIMD, then the patch who
broke it needs fixing or reverting.

I'd only make one observation regarding -O3 vs. a specific list of
passes. Each way has its own faults and I'm not particularly pending
to either one, but one has to consider what -O3 means and what you
really want. If you want vectorization, or hard-fp, then you should
ask them by name. If all you want is "optimal" code, and the source is
simple enough that it'd be impossible not to get them, then -O3 should
suffice.

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

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[James Molloy via cfe-commits]

Hi Eric,

While I agree with you in principle, Alexandros has just pointed out to me
that all the other NEON intrinsics have such -O3 tests, and thinking about
it I do think they add value. They test the full-trip through the compiler
and ensure that Clang and LLVM have matching ideas of the IR interface
exposed by the intrinsics.

AIUI, Alexandros wrote LLVM backend tests in addition to these. It does
look like there are no tests just checking Clang's IR output - I think
these should indeed be written.

In summary, I agree with you that we need tests for both Clang and LLVM
separately. However I also think the full-trip tests add significant value
and wouldn't like to see them removed, and there's significant prior art in
this area so if we did decide they needed to be gone, we'd need a good
discussion on how to regain the testing coverage we'd lose.

Cheers,

James

On Sun, 29 Nov 2015 at 20:40 Eric Christopher via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Hi,
>
> This is entirely the wrong way to do these tests. They shouldn't depend on
> assembly output or optimization. Please split them onto frontend IR tests
> and backend assembly tests.
>
> Thanks!
>
> On Sun, Nov 29, 2015, 2:56 AM Alexandros Lamprineas via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: alelab01
>> Date: Sun Nov 29 04:53:28 2015
>> New Revision: 254251
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=254251=rev
>> Log:
>> ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply
>> Add/Subtract.
>>
>> Add missing tests that accidentally were not committed in rL254250.
>>
>> Differential Revision: http://reviews.llvm.org/D14982
>>
>> Added:
>> cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c
>> cfe/trunk/test/CodeGen/arm-v8.1a-neon-intrinsics.c
>>
>> Added: cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c?rev=254251=auto
>>
>> ==
>> --- cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c (added)
>> +++ cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c Sun Nov 29
>> 04:53:28 2015
>> @@ -0,0 +1,128 @@
>> +// REQUIRES: aarch64-registered-target
>> +
>> +// RUN: %clang_cc1 -triple aarch64-linux-gnu -target-feature +neon \
>> +// RUN:  -target-feature +v8.1a -O3 -S -o - %s \
>> +// RUN:  | FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-AARCH64
>> +
>> + #include 
>> +
>> +// CHECK-AARCH64-LABEL: test_vqrdmlah_laneq_s16
>> +int16x4_t test_vqrdmlah_laneq_s16(int16x4_t a, int16x4_t b, int16x8_t v)
>> {
>> +// CHECK-AARCH64: sqrdmlah {{v[0-9]+}}.4h, {{v[0-9]+}}.4h,
>> {{v[0-9]+}}.h[7]
>> +  return vqrdmlah_laneq_s16(a, b, v, 7);
>> +}
>> +
>> +// CHECK-AARCH64-LABEL: test_vqrdmlah_laneq_s32
>> +int32x2_t test_vqrdmlah_laneq_s32(int32x2_t a, int32x2_t b, int32x4_t v)
>> {
>> +// CHECK-AARCH64: sqrdmlah {{v[0-9]+}}.2s, {{v[0-9]+}}.2s,
>> {{v[0-9]+}}.s[3]
>> +  return vqrdmlah_laneq_s32(a, b, v, 3);
>> +}
>> +
>> +// CHECK-AARCH64-LABEL: test_vqrdmlahq_laneq_s16
>> +int16x8_t test_vqrdmlahq_laneq_s16(int16x8_t a, int16x8_t b, int16x8_t
>> v) {
>> +// CHECK-AARCH64: sqrdmlah {{v[0-9]+}}.8h, {{v[0-9]+}}.8h,
>> {{v[0-9]+}}.h[7]
>> +  return vqrdmlahq_laneq_s16(a, b, v, 7);
>> +}
>> +
>> +// CHECK-AARCH64-LABEL: test_vqrdmlahq_laneq_s32
>> +int32x4_t test_vqrdmlahq_laneq_s32(int32x4_t a, int32x4_t b, int32x4_t
>> v) {
>> +// CHECK-AARCH64: sqrdmlah {{v[0-9]+}}.4s, {{v[0-9]+}}.4s,
>> {{v[0-9]+}}.s[3]
>> +  return vqrdmlahq_laneq_s32(a, b, v, 3);
>> +}
>> +
>> +// CHECK-AARCH64-LABEL: test_vqrdmlahh_s16
>> +int16_t test_vqrdmlahh_s16(int16_t a, int16_t b, int16_t c) {
>> +// CHECK-AARCH64: sqrdmlah {{h[0-9]+|v[0-9]+.4h}},
>> {{h[0-9]+|v[0-9]+.4h}}, {{h[0-9]+|v[0-9]+.4h}}
>> +  return vqrdmlahh_s16(a, b, c);
>> +}
>> +
>> +// CHECK-AARCH64-LABEL: test_vqrdmlahs_s32
>> +int32_t test_vqrdmlahs_s32(int32_t a, int32_t b, int32_t c) {
>> +// CHECK-AARCH64: sqrdmlah {{s[0-9]+}}, {{s[0-9]+}}, {{s[0-9]+}}
>> +  return vqrdmlahs_s32(a, b, c);
>> +}
>> +
>> +// CHECK-AARCH64-LABEL: test_vqrdmlahh_lane_s16
>> +int16_t test_vqrdmlahh_lane_s16(int16_t a, int16_t b, int16x4_t c) {
>> +// CHECK-AARCH64: sqrdmlah {{h[0-9]+|v[0-9]+.4h}},
>> {{h[0-9]+|v[0-9]+.4h}}, {{v[0-9]+}}.h[3]
>> +  return vqrdmlahh_lane_s16(a, b, c, 3);
>> +}
>> +
>> +// CHECK-AARCH64-LABEL: test_vqrdmlahs_lane_s32
>> +int32_t test_vqrdmlahs_lane_s32(int32_t a, int32_t b, int32x2_t c) {
>> +// CHECK-AARCH64: sqrdmlah {{s[0-9]+}}, {{s[0-9]+}}, {{v[0-9]+}}.s[1]
>> +  return vqrdmlahs_lane_s32(a, b, c, 1);
>> +}
>> +
>> +// CHECK-AARCH64-LABEL: test_vqrdmlahh_laneq_s16
>> +int16_t test_vqrdmlahh_laneq_s16(int16_t a, int16_t b, int16x8_t c) {
>> +// CHECK-AARCH64: sqrdmlah {{h[0-9]+|v[0-9]+.4h}},
>> {{h[0-9]+|v[0-9]+.4h}}, {{v[0-9]+}}.h[7]
>> +  return vqrdmlahh_laneq_s16(a, b, c, 7);
>> +}
>> +
>> +// CHECK-AARCH64-LABEL: test_vqrdmlahs_laneq_s32

r254407 - clang-format: treat Q_SIGNALS as an access modifier

[Daniel Jasper via cfe-commits]

Author: djasper
Date: Tue Dec  1 06:05:04 2015
New Revision: 254407

URL: http://llvm.org/viewvc/llvm-project?rev=254407=rev
Log:
clang-format: treat Q_SIGNALS as an access modifier

Patch by Alexander Richardson, thank you!

Modified:
cfe/trunk/lib/Format/FormatToken.h
cfe/trunk/lib/Format/UnwrappedLineFormatter.cpp
cfe/trunk/lib/Format/UnwrappedLineParser.cpp
cfe/trunk/unittests/Format/FormatTest.cpp

Modified: cfe/trunk/lib/Format/FormatToken.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/FormatToken.h?rev=254407=254406=254407=diff
==
--- cfe/trunk/lib/Format/FormatToken.h (original)
+++ cfe/trunk/lib/Format/FormatToken.h Tue Dec  1 06:05:04 2015
@@ -561,6 +561,7 @@ struct AdditionalKeywords {
 kw_returns = ("returns");
 
 kw_signals = ("signals");
+kw_qsignals = ("Q_SIGNALS");
 kw_slots = ("slots");
 kw_qslots = ("Q_SLOTS");
   }
@@ -607,6 +608,7 @@ struct AdditionalKeywords {
 
   // QT keywords.
   IdentifierInfo *kw_signals;
+  IdentifierInfo *kw_qsignals;
   IdentifierInfo *kw_slots;
   IdentifierInfo *kw_qslots;
 };

Modified: cfe/trunk/lib/Format/UnwrappedLineFormatter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/UnwrappedLineFormatter.cpp?rev=254407=254406=254407=diff
==
--- cfe/trunk/lib/Format/UnwrappedLineFormatter.cpp (original)
+++ cfe/trunk/lib/Format/UnwrappedLineFormatter.cpp Tue Dec  1 06:05:04 2015
@@ -90,8 +90,8 @@ private:
   return 0;
 if (RootToken.isAccessSpecifier(false) ||
 RootToken.isObjCAccessSpecifier() ||
-(RootToken.is(Keywords.kw_signals) && RootToken.Next &&
- RootToken.Next->is(tok::colon)))
+(RootToken.isOneOf(Keywords.kw_signals, Keywords.kw_qsignals) &&
+ RootToken.Next && RootToken.Next->is(tok::colon)))
   return Style.AccessModifierOffset;
 return 0;
   }

Modified: cfe/trunk/lib/Format/UnwrappedLineParser.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/UnwrappedLineParser.cpp?rev=254407=254406=254407=diff
==
--- cfe/trunk/lib/Format/UnwrappedLineParser.cpp (original)
+++ cfe/trunk/lib/Format/UnwrappedLineParser.cpp Tue Dec  1 06:05:04 2015
@@ -784,7 +784,8 @@ void UnwrappedLineParser::parseStructura
   parseJavaScriptEs6ImportExport();
   return;
 }
-if (FormatTok->is(Keywords.kw_signals)) {
+if (FormatTok->isOneOf(Keywords.kw_signals, Keywords.kw_qsignals,
+   Keywords.kw_slots, Keywords.kw_qslots)) {
   nextToken();
   if (FormatTok->is(tok::colon)) {
 nextToken();

Modified: cfe/trunk/unittests/Format/FormatTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTest.cpp?rev=254407=254406=254407=diff
==
--- cfe/trunk/unittests/Format/FormatTest.cpp (original)
+++ cfe/trunk/unittests/Format/FormatTest.cpp Tue Dec  1 06:05:04 2015
@@ -1867,11 +1867,21 @@ TEST_F(FormatTest, UnderstandsAccessSpec
  "};");
   verifyFormat("class A {\n"
"public slots:\n"
-   "  void f() {}\n"
+   "  void f1() {}\n"
"public Q_SLOTS:\n"
-   "  void f() {}\n"
+   "  void f2() {}\n"
+   "protected slots:\n"
+   "  void f3() {}\n"
+   "protected Q_SLOTS:\n"
+   "  void f4() {}\n"
+   "private slots:\n"
+   "  void f5() {}\n"
+   "private Q_SLOTS:\n"
+   "  void f6() {}\n"
"signals:\n"
-   "  void g();\n"
+   "  void g1();\n"
+   "Q_SIGNALS:\n"
+   "  void g2();\n"
"};");
 
   // Don't interpret 'signals' the wrong way.


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

Re: [PATCH] D15007: [analyzer] Improve modelling of nullptr_t in the analyzer. Fix PR25414.

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

xazax.hun added a comment.

In http://reviews.llvm.org/D15007#298086, @dcoughlin wrote:

> Gabor, thanks for taking a look at this!
>
> I'm not sure `RegionStore::getBinding()` is the right place to put this logic.
>
> First, not all dereferences of a `std::nullptr_t` value go through 
> `getBinding()`, so, for example, the following snippet triggers the assertion 
> even with your patch:
>
>   decltype(nullptr) returnsNullPtrType();
>   void fromReturnType() {
> ((X *)returnsNullPtrType())->f(); // Crash in analysis!
>   }
>


Thank you for spotting this, I will definitely try the approach you suggested.

> Second, not all locations of type `std::nullptr_t` contain `0`. For example, 
> the following prints "1" on my machine:

> 

>   #include 

>   

>   int main() {

> decltype(nullptr) x;

> std::cout << (bool)x << "\n";

>   }

> 

> 

> That is, a default-initialized (garbage) nullptr_t may not be '0'. Prior to 
> your patch the analyzer would warn here about `x` being uninitialized (when 
> the analyzer is compiled without asserts) -- but with your patch we lose that 
> warning.


I am not entirely sure what the correct behavior is here. According to the 
standard (2.14.7): "std::nullptr_t is a distinct type that is neither a pointer 
type nor a pointer to member type; rather, a prvalue of this type is a null 
pointer constant and can be converted to a null pointer value or null member 
pointer value." My interpretation is that, the std::nullptr_t does not have a 
state, it just converts to a null pointer value regardless what value is at the 
location of the nullptr_t. Regardless what the standard says it looks like the 
value of std::nullptr_t can be (ab)used in the current clang implementation.

> What do you think about moving your new logic to the symbol value creation 
> methods in SValBuilder? More specifically, you could add the check for 
> nullptr_t to `getRegionValueSymbolVal()`, `conjureSymbolVal()` (both 
> variants), `getConjuredHeapSymbolVal()`, and 
> `getDerivedRegionValueSymbolVal()`. This would let the analyzer warn when it 
> knows there is a garbage value in a location of type nullptr_t but still 
> optimistically assume that the value is is '0' when the value would otherwise 
> be symbolic.

> 

> With this approach we would retain uninitialization warnings about accesses 
> via definitely uninitialized storage:

> 

>   void fromUninitializedLocal() {

> decltype(nullptr) p;

> ((X *)p)->f(); // Warn about p being uninitialized

>   }

>   

>   void fromUninitializedLocalStruct() {

> Type t;

> ((X *)t.x)->f(); // Warn about t.x being uninitialized.

>   }

> 

> 

> but would warn about about a null access in `returnsNullPtrType()` and would 
> keep the behavior you specify in your `f()` test because `p` is a parameter 
> (and thus its value is symbolic).


I will look into this thank you.


http://reviews.llvm.org/D15007



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

Re: [PATCH] D14872: PR25575: Make GCC 4.4+ comatible layout for packed bit-fileds of char type

[Dmitry Polukhin via cfe-commits]

DmitryPolukhin added a comment.

This is another GCC ABI compatibility issue. If there is no more comments, 
could someone please approve this CL?


http://reviews.llvm.org/D14872



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

Re: [PATCH] D14980: PR18513: make gcc compatible layout for bit-fields with explicit aligned attribute

[Dmitry Polukhin via cfe-commits]

DmitryPolukhin added a comment.

I added more testcases and they all pass identically on GCC and clang with my 
patch. Please let me know if you think, that some cases are not covered or 
doesn't work with my patch. Perhaps we can reduce number of test-cases because 
some of them almost duplicates but for now I added them all.

As for MS compatibility mode, I think we shouldn't worry about them because MS 
does't support __attrbute__(aligned) and #pragma pack seems to have no 
influence on bit-filed layout as far as I tested. If you think that 
__attrbute__(aligned) should work in MS compatibility mode and use GCC 
semantic, please let me know, I'll update my patch accordingly.



Comment at: lib/AST/RecordLayoutBuilder.cpp:1606
@@ -1605,1 +1605,3 @@
+} else if (ExplicitFieldAlign)
+  FieldOffset = llvm::RoundUpToAlignment(FieldOffset, ExplicitFieldAlign);
 

rsmith wrote:
> You should round up to `FieldAlign` here.
Unfortunately, I cannot use FieldAlign here because FieldAlign = 
max(ExplicitFieldAlign, alignof(field_type)). But GCC allows to specify 
alignment less than normal type alignment for bit-field, see 'struct g2' case 
in my testcase (it will fail if I round up to FieldAlign here).


http://reviews.llvm.org/D14980



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

r254406 - This fixes https://llvm.org/bugs/show_bug.cgi?id=25329, as well as

[Daniel Jasper via cfe-commits]

Author: djasper
Date: Tue Dec  1 06:00:43 2015
New Revision: 254406

URL: http://llvm.org/viewvc/llvm-project?rev=254406=rev
Log:
This fixes https://llvm.org/bugs/show_bug.cgi?id=25329, as well as
misalignments like the following:

  int a, b = 2;
  int c= 3;

Patch by Beren Minor, thanks!

Modified:
cfe/trunk/lib/Format/WhitespaceManager.cpp
cfe/trunk/lib/Format/WhitespaceManager.h
cfe/trunk/unittests/Format/FormatTest.cpp

Modified: cfe/trunk/lib/Format/WhitespaceManager.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/WhitespaceManager.cpp?rev=254406=254405=254406=diff
==
--- cfe/trunk/lib/Format/WhitespaceManager.cpp (original)
+++ cfe/trunk/lib/Format/WhitespaceManager.cpp Tue Dec  1 06:00:43 2015
@@ -148,125 +148,24 @@ void WhitespaceManager::calculateLineBre
   }
 }
 
-// Walk through all of the changes and find sequences of "=" to align.  To do
-// so, keep track of the lines and whether or not an "=" was found on align. If
-// a "=" is found on a line, extend the current sequence. If the current line
-// cannot be part of a sequence, e.g. because there is an empty line before it
-// or it contains non-assignments, finalize the previous sequence.
-//
-// FIXME: The code between assignment and declaration alignment is mostly
-// duplicated and would benefit from factorization.
-void WhitespaceManager::alignConsecutiveAssignments() {
-  if (!Style.AlignConsecutiveAssignments)
-return;
-
-  unsigned MinColumn = 0;
-  unsigned MaxColumn = UINT_MAX;
-  unsigned StartOfSequence = 0;
-  unsigned EndOfSequence = 0;
-  bool FoundAssignmentOnLine = false;
-  bool FoundLeftBraceOnLine = false;
-  bool FoundLeftParenOnLine = false;
-
-  // Aligns a sequence of assignment tokens, on the MinColumn column.
-  //
-  // Sequences start from the first assignment token to align, and end at the
-  // first token of the first line that doesn't need to be aligned.
-  //
-  // We need to adjust the StartOfTokenColumn of each Change that is on a line
-  // containing any assignment to be aligned and located after such assignment
-  auto AlignSequence = [&] {
-if (StartOfSequence > 0 && StartOfSequence < EndOfSequence)
-  alignConsecutiveAssignments(StartOfSequence, EndOfSequence, MinColumn);
-MinColumn = 0;
-MaxColumn = UINT_MAX;
-StartOfSequence = 0;
-EndOfSequence = 0;
-  };
-
-  for (unsigned i = 0, e = Changes.size(); i != e; ++i) {
-if (Changes[i].NewlinesBefore != 0) {
-  EndOfSequence = i;
-  // If there is a blank line, if the last line didn't contain any
-  // assignment, or if we found an open brace or paren, the sequence ends
-  // here.
-  if (Changes[i].NewlinesBefore > 1 || !FoundAssignmentOnLine ||
-  FoundLeftBraceOnLine || FoundLeftParenOnLine) {
-// NB: In the latter case, the sequence should end at the beggining of
-// the previous line, but it doesn't really matter as there is no
-// assignment on it
-AlignSequence();
-  }
-
-  FoundAssignmentOnLine = false;
-  FoundLeftBraceOnLine = false;
-  FoundLeftParenOnLine = false;
-}
-
-// If there is more than one "=" per line, or if the "=" appears first on
-// the line of if it appears last, end the sequence
-if (Changes[i].Kind == tok::equal &&
-(FoundAssignmentOnLine || Changes[i].NewlinesBefore > 0 ||
- Changes[i + 1].NewlinesBefore > 0)) {
-  AlignSequence();
-} else if (Changes[i].Kind == tok::r_brace) {
-  if (!FoundLeftBraceOnLine)
-AlignSequence();
-  FoundLeftBraceOnLine = false;
-} else if (Changes[i].Kind == tok::l_brace) {
-  FoundLeftBraceOnLine = true;
-  if (!FoundAssignmentOnLine)
-AlignSequence();
-} else if (Changes[i].Kind == tok::r_paren) {
-  if (!FoundLeftParenOnLine)
-AlignSequence();
-  FoundLeftParenOnLine = false;
-} else if (Changes[i].Kind == tok::l_paren) {
-  FoundLeftParenOnLine = true;
-  if (!FoundAssignmentOnLine)
-AlignSequence();
-} else if (!FoundAssignmentOnLine && !FoundLeftBraceOnLine &&
-   !FoundLeftParenOnLine && Changes[i].Kind == tok::equal) {
-  FoundAssignmentOnLine = true;
-  if (StartOfSequence == 0)
-StartOfSequence = i;
-
-  unsigned ChangeMinColumn = Changes[i].StartOfTokenColumn;
-  int LineLengthAfter = -Changes[i].Spaces;
-  for (unsigned j = i; j != e && Changes[j].NewlinesBefore == 0; ++j)
-LineLengthAfter += Changes[j].Spaces + Changes[j].TokenLength;
-  unsigned ChangeMaxColumn = Style.ColumnLimit - LineLengthAfter;
-
-  if (ChangeMinColumn > MaxColumn || ChangeMaxColumn < MinColumn) {
-AlignSequence();
-StartOfSequence = i;
-  }
-
-  MinColumn = std::max(MinColumn, ChangeMinColumn);
-  MaxColumn = std::min(MaxColumn, ChangeMaxColumn);
-}
-  }
-
-  EndOfSequence = Changes.size();

Re: [PATCH] D15007: [analyzer] Improve modelling of nullptr_t in the analyzer. Fix PR25414.

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

xazax.hun updated this revision to Diff 41494.
xazax.hun added a comment.

- Added the test case Devin suggested.
- Implemented the fix Devin suggested.
- Updated to latest trunk.


http://reviews.llvm.org/D15007

Files:
  lib/StaticAnalyzer/Core/SValBuilder.cpp
  test/Analysis/nullptr.cpp

Index: test/Analysis/nullptr.cpp
===
--- test/Analysis/nullptr.cpp
+++ test/Analysis/nullptr.cpp
@@ -1,4 +1,6 @@
-// RUN: %clang_cc1 -std=c++11 -Wno-conversion-null -analyze -analyzer-checker=core -analyzer-store region -verify %s
+// RUN: %clang_cc1 -std=c++11 -Wno-conversion-null -analyze -analyzer-checker=core,debug.ExprInspection -analyzer-store region -verify %s
+
+void clang_analyzer_eval(int);
 
 // test to see if nullptr is detected as a null pointer
 void foo1(void) {
@@ -87,3 +89,40 @@
   // Create MaterializeTemporaryExpr with a nullptr inside.
   const nullptr_t  = nullptr;
 }
+
+int getSymbol();
+
+struct X {
+  virtual void f() {}
+};
+
+void invokeF(X* x) {
+  x->f(); // expected-warning{{Called C++ object pointer is null}}
+}
+
+struct Type {
+  decltype(nullptr) x;
+};
+
+void shouldNotCrash() {
+  decltype(nullptr) p;
+  if (getSymbol())
+invokeF(p); // expected-warning{{Function call argument is an uninit}}
+  if (getSymbol())
+invokeF(nullptr);
+  if (getSymbol()) {
+X *x = Type().x;
+x->f(); // expected-warning{{Called C++ object pointer is null}}
+  }
+}
+
+void f(decltype(nullptr) p) {
+  int *q = nullptr;
+  clang_analyzer_eval(p == 0); // expected-warning{{TRUE}}
+  clang_analyzer_eval(q == 0); // expected-warning{{TRUE}}
+}
+
+decltype(nullptr) returnsNullPtrType();
+void fromReturnType() {
+  ((X *)returnsNullPtrType())->f(); // expected-warning{{Called C++ object pointer is null}}
+}
Index: lib/StaticAnalyzer/Core/SValBuilder.cpp
===
--- lib/StaticAnalyzer/Core/SValBuilder.cpp
+++ lib/StaticAnalyzer/Core/SValBuilder.cpp
@@ -95,6 +95,9 @@
 SValBuilder::getRegionValueSymbolVal(const TypedValueRegion* region) {
   QualType T = region->getValueType();
 
+  if (T->isNullPtrType())
+return makeZeroVal(T);
+  
   if (!SymbolManager::canSymbolicate(T))
 return UnknownVal();
 
@@ -112,6 +115,9 @@
unsigned Count) {
   QualType T = Ex->getType();
 
+  if (T->isNullPtrType())
+return makeZeroVal(T);
+
   // Compute the type of the result. If the expression is not an R-value, the
   // result should be a location.
   QualType ExType = Ex->getType();
@@ -126,6 +132,9 @@
const LocationContext *LCtx,
QualType type,
unsigned count) {
+  if (type->isNullPtrType())
+return makeZeroVal(type);
+
   if (!SymbolManager::canSymbolicate(type))
 return UnknownVal();
 
@@ -142,6 +151,9 @@
const LocationContext *LCtx,
QualType type,
unsigned visitCount) {
+  if (type->isNullPtrType())
+return makeZeroVal(type);
+
   if (!SymbolManager::canSymbolicate(type))
 return UnknownVal();
 
@@ -160,6 +172,8 @@
   QualType T = E->getType();
   assert(Loc::isLocType(T));
   assert(SymbolManager::canSymbolicate(T));
+  if (T->isNullPtrType())
+return makeZeroVal(T);
 
   SymbolRef sym = SymMgr.conjureSymbol(E, LCtx, T, VisitCount);
   return loc::MemRegionVal(MemMgr.getSymbolicHeapRegion(sym));
@@ -185,6 +199,9 @@
  const TypedValueRegion *region) {
   QualType T = region->getValueType();
 
+  if (T->isNullPtrType())
+return makeZeroVal(T);
+
   if (!SymbolManager::canSymbolicate(T))
 return UnknownVal();
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D14824: [PATCH] Add clang-tidy check for static or thread_local objects where construction may throw

[Aaron Ballman via cfe-commits]

aaron.ballman closed this revision.
aaron.ballman added a comment.

Commit in r254415.



Comment at: clang-tidy/utils/Matchers.h:26
@@ -25,1 +25,3 @@
 
+AST_MATCHER(FunctionDecl, isNoThrow) {
+  const auto *FnTy = Node.getType()->getAs();

alexfh wrote:
> Anything wrong with putting this to the astmatchers library?
I may move that there post-commit because it seems general-purpose enough for 
that.


http://reviews.llvm.org/D14824



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

Re: [PATCH] D14871: [Power PC] fix calculating address of arguments on stack for variadic functions

[Strahinja Petrovic via cfe-commits]

spetrovic updated this revision to Diff 41498.
spetrovic marked 3 inline comments as done.

http://reviews.llvm.org/D14871

Files:
  lib/CodeGen/TargetInfo.cpp
  test/CodeGen/ppc-varargs-struct.c
  test/CodeGen/x86_64-arguments.c

Index: test/CodeGen/x86_64-arguments.c
===
--- test/CodeGen/x86_64-arguments.c
+++ test/CodeGen/x86_64-arguments.c
@@ -336,7 +336,8 @@
 
 // CHECK-LABEL: define i32 @f44
 // CHECK: ptrtoint
-// CHECK-NEXT: and {{.*}}, -32
+// CHECK-NEXT: add i64 %{{[0-9]+}}, 31
+// CHECK-NEXT: and i64 %{{[0-9]+}}, -32
 // CHECK-NEXT: inttoptr
 typedef int T44 __attribute((vector_size(32)));
 struct s44 { T44 x; int y; };
Index: test/CodeGen/ppc-varargs-struct.c
===
--- test/CodeGen/ppc-varargs-struct.c
+++ test/CodeGen/ppc-varargs-struct.c
@@ -39,9 +39,13 @@
 // CHECK-PPC:[[USING_OVERFLOW]]
 // CHECK-PPC-NEXT:  [[OVERFLOW_AREA_P:%[0-9]+]] = getelementptr inbounds %struct.__va_list_tag, %struct.__va_list_tag* [[ARRAYDECAY]], i32 0, i32 3
 // CHECK-PPC-NEXT:  [[OVERFLOW_AREA:%.+]] = load i8*, i8** [[OVERFLOW_AREA_P]], align 4
-// CHECK-PPC-NEXT:  [[MEMADDR:%.+]] = bitcast i8* [[OVERFLOW_AREA]] to %struct.x**
-// CHECK-PPC-NEXT:  [[NEW_OVERFLOW_AREA:%[0-9]+]] = getelementptr inbounds i8, i8* [[OVERFLOW_AREA]], i32 4
-// CHECK-PPC-NEXT:  store i8* [[NEW_OVERFLOW_AREA]], i8** [[OVERFLOW_AREA_P]]
+// CHECK-PPC-NEXT:  %{{[0-9]+}} =  ptrtoint i8* %argp.cur to i32
+// CHECK-PPC-NEXT:  %{{[0-9]+}} = add i32 %{{[0-9]+}}, 7
+// CHECK-PPC-NEXT:  %{{[0-9]+}} = and i32 %{{[0-9]+}}, -8
+// CHECK-PPC-NEXT:  %argp.cur.aligned = inttoptr i32 %{{[0-9]+}} to i8*
+// CHECK-PPC-NEXT:  [[MEMADDR:%.+]] = bitcast i8* %argp.cur.aligned to %struct.x**
+// CHECK-PPC-NEXT:  [[NEW_OVERFLOW_AREA:%[0-9]+]] = getelementptr inbounds i8, i8* %argp.cur.aligned, i32 4
+// CHECK-PPC-NEXT:  store i8* [[NEW_OVERFLOW_AREA:%[0-9]+]], i8** [[OVERFLOW_AREA_P]], align 4
 // CHECK-PPC-NEXT:  br label %[[CONT]]
 //
 // CHECK-PPC:[[CONT]]
Index: lib/CodeGen/TargetInfo.cpp
===
--- lib/CodeGen/TargetInfo.cpp
+++ lib/CodeGen/TargetInfo.cpp
@@ -162,6 +162,23 @@
   OS << ")\n";
 }
 
+// Dynamically round a pointer up to a multiple of the given alignment.
+static llvm::Value *emitRoundPointerUpToAlignment(CodeGenFunction ,
+  llvm::Value *Ptr,
+  CharUnits Align) {
+  llvm::Value *PtrAsInt = Ptr;
+  // OverflowArgArea = (OverflowArgArea + Align - 1) & -Align;
+  PtrAsInt = CGF.Builder.CreatePtrToInt(PtrAsInt, CGF.IntPtrTy);
+  PtrAsInt = CGF.Builder.CreateAdd(PtrAsInt,
+llvm::ConstantInt::get(CGF.IntPtrTy, Align.getQuantity() - 1));
+  PtrAsInt = CGF.Builder.CreateAnd(PtrAsInt,
+   llvm::ConstantInt::get(CGF.IntPtrTy, -Align.getQuantity()));
+  PtrAsInt = CGF.Builder.CreateIntToPtr(PtrAsInt,
+Ptr->getType(),
+Ptr->getName() + ".aligned");
+  return PtrAsInt;
+}
+
 /// Emit va_arg for a platform using the common void* representation,
 /// where arguments are simply emitted in an array of slots on the stack.
 ///
@@ -193,17 +210,11 @@
   // If the CC aligns values higher than the slot size, do so if needed.
   Address Addr = Address::invalid();
   if (AllowHigherAlign && DirectAlign > SlotSize) {
-llvm::Value *PtrAsInt = Ptr;
-PtrAsInt = CGF.Builder.CreatePtrToInt(PtrAsInt, CGF.IntPtrTy);
-PtrAsInt = CGF.Builder.CreateAdd(PtrAsInt,
-  llvm::ConstantInt::get(CGF.IntPtrTy, DirectAlign.getQuantity() - 1));
-PtrAsInt = CGF.Builder.CreateAnd(PtrAsInt,
- llvm::ConstantInt::get(CGF.IntPtrTy, -DirectAlign.getQuantity()));
-Addr = Address(CGF.Builder.CreateIntToPtr(PtrAsInt, Ptr->getType(),
-  "argp.cur.aligned"),
-   DirectAlign);
-  } else {
-Addr = Address(Ptr, SlotSize);
+Addr = Address(emitRoundPointerUpToAlignment(CGF, Ptr, DirectAlign),
+ DirectAlign);
+  }
+  else {
+Addr = Address(Ptr, SlotSize); 
   }
 
   // Advance the pointer past the argument, then store that back.
@@ -3072,19 +3083,10 @@
   // byte boundary if alignment needed by type exceeds 8 byte boundary.
   // It isn't stated explicitly in the standard, but in practice we use
   // alignment greater than 16 where necessary.
-  uint64_t Align = CGF.getContext().getTypeAlignInChars(Ty).getQuantity();
-  if (Align > 8) {
-// overflow_arg_area = (overflow_arg_area + align - 1) & -align;
-llvm::Value *Offset =
-  llvm::ConstantInt::get(CGF.Int64Ty, Align - 1);
-overflow_arg_area = CGF.Builder.CreateGEP(overflow_arg_area, Offset);
-llvm::Value *AsInt = CGF.Builder.CreatePtrToInt(overflow_arg_area,
-  

r254414 - clang-format: Make it possible to turn off comment reflowing.

[Daniel Jasper via cfe-commits]

Author: djasper
Date: Tue Dec  1 07:28:53 2015
New Revision: 254414

URL: http://llvm.org/viewvc/llvm-project?rev=254414=rev
Log:
clang-format: Make it possible to turn off comment reflowing.

Modified:
cfe/trunk/include/clang/Format/Format.h
cfe/trunk/lib/Format/ContinuationIndenter.cpp
cfe/trunk/lib/Format/Format.cpp
cfe/trunk/unittests/Format/FormatTest.cpp

Modified: cfe/trunk/include/clang/Format/Format.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Format/Format.h?rev=254414=254413=254414=diff
==
--- cfe/trunk/include/clang/Format/Format.h (original)
+++ cfe/trunk/include/clang/Format/Format.h Tue Dec  1 07:28:53 2015
@@ -466,9 +466,12 @@ struct FormatStyle {
 PAS_Middle
   };
 
-  /// Pointer and reference alignment style.
+  /// \brief Pointer and reference alignment style.
   PointerAlignmentStyle PointerAlignment;
 
+  /// \brief If true, clang-format will attempt to re-flow comments.
+  bool ReflowComments;
+
   /// \brief If true, clang-format will sort #includes.
   bool SortIncludes;
 

Modified: cfe/trunk/lib/Format/ContinuationIndenter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/ContinuationIndenter.cpp?rev=254414=254413=254414=diff
==
--- cfe/trunk/lib/Format/ContinuationIndenter.cpp (original)
+++ cfe/trunk/lib/Format/ContinuationIndenter.cpp Tue Dec  1 07:28:53 2015
@@ -1076,7 +1076,8 @@ unsigned ContinuationIndenter::breakProt
   return 0;
 }
   } else if (Current.is(TT_BlockComment) && Current.isTrailingComment()) {
-if (CommentPragmasRegex.match(Current.TokenText.substr(2)))
+if (!Style.ReflowComments ||
+CommentPragmasRegex.match(Current.TokenText.substr(2)))
   return 0;
 Token.reset(new BreakableBlockComment(
 Current, State.Line->Level, StartColumn, Current.OriginalColumn,
@@ -1084,7 +1085,8 @@ unsigned ContinuationIndenter::breakProt
   } else if (Current.is(TT_LineComment) &&
  (Current.Previous == nullptr ||
   Current.Previous->isNot(TT_ImplicitStringLiteral))) {
-if (CommentPragmasRegex.match(Current.TokenText.substr(2)))
+if (!Style.ReflowComments ||
+CommentPragmasRegex.match(Current.TokenText.substr(2)))
   return 0;
 Token.reset(new BreakableLineComment(Current, State.Line->Level,
  StartColumn, /*InPPDirective=*/false,

Modified: cfe/trunk/lib/Format/Format.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/Format.cpp?rev=254414=254413=254414=diff
==
--- cfe/trunk/lib/Format/Format.cpp (original)
+++ cfe/trunk/lib/Format/Format.cpp Tue Dec  1 07:28:53 2015
@@ -284,8 +284,9 @@ template <> struct MappingTraitshttp://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTest.cpp?rev=254414=254413=254414=diff
==
--- cfe/trunk/unittests/Format/FormatTest.cpp (original)
+++ cfe/trunk/unittests/Format/FormatTest.cpp Tue Dec  1 07:28:53 2015
@@ -1197,6 +1197,13 @@ TEST_F(FormatTest, AlignsBlockComments)
"comment */"));
 }
 
+TEST_F(FormatTest, CommentReflowingCanBeTurnedOff) {
+  FormatStyle Style = getLLVMStyleWithColumns(20);
+  Style.ReflowComments = false;
+  verifyFormat("// a aa aa", Style);
+  verifyFormat("/* a aa aa */", Style);
+}
+
 TEST_F(FormatTest, CorrectlyHandlesLengthOfBlockComments) {
   EXPECT_EQ("double *x; /* aa\n"
 "  aaa */",
@@ -9639,6 +9646,7 @@ TEST_F(FormatTest, ParsesConfigurationBo
   CHECK_PARSE_BOOL(ObjCSpaceAfterProperty);
   CHECK_PARSE_BOOL(ObjCSpaceBeforeProtocolList);
   CHECK_PARSE_BOOL(Cpp11BracedListStyle);
+  CHECK_PARSE_BOOL(ReflowComments);
   CHECK_PARSE_BOOL(SortIncludes);
   CHECK_PARSE_BOOL(SpacesInParentheses);
   CHECK_PARSE_BOOL(SpacesInSquareBrackets);


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

[clang-tools-extra] r254415 - Add a new checker, cert-err58-cpp, that checks for static or thread_local objects that use a throwing constructor.

[Aaron Ballman via cfe-commits]

Author: aaronballman
Date: Tue Dec  1 08:05:39 2015
New Revision: 254415

URL: http://llvm.org/viewvc/llvm-project?rev=254415=rev
Log:
Add a new checker, cert-err58-cpp, that checks for static or thread_local 
objects that use a throwing constructor.

This check corresponds to the CERT secure coding rule: 
https://www.securecoding.cert.org/confluence/display/cplusplus/ERR58-CPP.+Constructors+of+objects+with+static+or+thread+storage+duration+must+not+throw+exceptions

Added:
clang-tools-extra/trunk/clang-tidy/cert/StaticObjectExceptionCheck.cpp
clang-tools-extra/trunk/clang-tidy/cert/StaticObjectExceptionCheck.h

clang-tools-extra/trunk/docs/clang-tidy/checks/cert-static-object-exception.rst
clang-tools-extra/trunk/test/clang-tidy/cert-static-object-exception.cpp
Modified:
clang-tools-extra/trunk/clang-tidy/cert/CERTTidyModule.cpp
clang-tools-extra/trunk/clang-tidy/cert/CMakeLists.txt
clang-tools-extra/trunk/clang-tidy/cert/ThrownExceptionTypeCheck.cpp
clang-tools-extra/trunk/clang-tidy/utils/Matchers.h
clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst

Modified: clang-tools-extra/trunk/clang-tidy/cert/CERTTidyModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/cert/CERTTidyModule.cpp?rev=254415=254414=254415=diff
==
--- clang-tools-extra/trunk/clang-tidy/cert/CERTTidyModule.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/cert/CERTTidyModule.cpp Tue Dec  1 
08:05:39 2015
@@ -17,6 +17,7 @@
 #include "../misc/StaticAssertCheck.h"
 #include "../misc/ThrowByValueCatchByReferenceCheck.h"
 #include "SetLongJmpCheck.h"
+#include "StaticObjectExceptionCheck.h"
 #include "ThrownExceptionTypeCheck.h"
 #include "VariadicFunctionDefCheck.h"
 
@@ -41,6 +42,8 @@ public:
 // ERR
 CheckFactories.registerCheck(
 "cert-err52-cpp");
+CheckFactories.registerCheck(
+"cert-err58-cpp");
 CheckFactories.registerCheck(
 "cert-err60-cpp");
 CheckFactories.registerCheck(

Modified: clang-tools-extra/trunk/clang-tidy/cert/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/cert/CMakeLists.txt?rev=254415=254414=254415=diff
==
--- clang-tools-extra/trunk/clang-tidy/cert/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clang-tidy/cert/CMakeLists.txt Tue Dec  1 08:05:39 
2015
@@ -3,6 +3,7 @@ set(LLVM_LINK_COMPONENTS support)
 add_clang_library(clangTidyCERTModule
   CERTTidyModule.cpp
   SetLongJmpCheck.cpp
+  StaticObjectExceptionCheck.cpp
   ThrownExceptionTypeCheck.cpp
   VariadicFunctionDefCheck.cpp
 
@@ -14,4 +15,5 @@ add_clang_library(clangTidyCERTModule
   clangTidy
   clangTidyGoogleModule
   clangTidyMiscModule
+  clangTidyUtils
   )

Added: clang-tools-extra/trunk/clang-tidy/cert/StaticObjectExceptionCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/cert/StaticObjectExceptionCheck.cpp?rev=254415=auto
==
--- clang-tools-extra/trunk/clang-tidy/cert/StaticObjectExceptionCheck.cpp 
(added)
+++ clang-tools-extra/trunk/clang-tidy/cert/StaticObjectExceptionCheck.cpp Tue 
Dec  1 08:05:39 2015
@@ -0,0 +1,49 @@
+//===--- StaticObjectExceptionCheck.cpp - 
clang-tidy---===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "StaticObjectExceptionCheck.h"
+#include "../utils/Matchers.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang {
+namespace tidy {
+
+void StaticObjectExceptionCheck::registerMatchers(MatchFinder *Finder) {
+  if (!getLangOpts().CPlusPlus)
+return;
+
+  // Match any static or thread_local variable declaration that is initialized
+  // with a constructor that can throw.
+  Finder->addMatcher(
+  varDecl(anyOf(hasThreadStorageDuration(), hasStaticStorageDuration()),
+  hasInitializer(cxxConstructExpr(hasDeclaration(
+  cxxConstructorDecl(unless(matchers::isNoThrow()))
+  .bind("ctor")
+  .bind("var"),
+  this);
+}
+
+void StaticObjectExceptionCheck::check(const MatchFinder::MatchResult ) 
{
+  const auto *VD = Result.Nodes.getNodeAs("var");
+  const auto *Ctor = Result.Nodes.getNodeAs("ctor");
+
+  diag(VD->getLocation(),
+   "construction of %0 with %select{static|thread_local}1 storage "
+   "duration may throw an exception that cannot be caught")
+  << VD << (VD->getStorageDuration() == SD_Static ? 0 : 1);
+  diag(Ctor->getLocation(), "possibly throwing constructor 

Re: [PATCH] D14872: PR25575: Make GCC 4.4+ comatible layout for packed bit-fileds of char type

[Aaron Ballman via cfe-commits]

aaron.ballman added inline comments.


Comment at: lib/Sema/SemaDeclAttr.cpp:1046
@@ +1045,3 @@
+ diag::note_attribute_packed_for_bitfield_offset_changed)
+<< FD->getDeclName();
+

No need to call getDeclName(), the diagnostic can accept a NamedDecl directly 
(which properly quotes the name in the diagnostic).


http://reviews.llvm.org/D14872



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