Re: [PATCH] D13582: [DEBUG INFO] Emit debug info for type used in explicit cast only.

[Alexey Bataev via cfe-commits]

ABataev added reviewers: rjmccall, dblaikie.
ABataev updated this revision to Diff 37476.
ABataev added a comment.

Update after review


http://reviews.llvm.org/D13582

Files:
  lib/CodeGen/CGExpr.cpp
  lib/CodeGen/CGExprAgg.cpp
  lib/CodeGen/CGExprCXX.cpp
  lib/CodeGen/CGExprComplex.cpp
  lib/CodeGen/CGExprConstant.cpp
  lib/CodeGen/CGExprScalar.cpp
  lib/CodeGen/CodeGenModule.h
  test/CodeGenCXX/debug-info-explicit-cast.cpp

Index: lib/CodeGen/CGExprCXX.cpp
===
--- lib/CodeGen/CGExprCXX.cpp
+++ lib/CodeGen/CGExprCXX.cpp
@@ -1806,6 +1806,7 @@
 
 llvm::Value *CodeGenFunction::EmitDynamicCast(Address ThisAddr,
   const CXXDynamicCastExpr *DCE) {
+  CGM.EmitExplicitCastExprType(DCE, this);
   QualType DestTy = DCE->getTypeAsWritten();
 
   if (DCE->isAlwaysNull())
Index: lib/CodeGen/CGExprAgg.cpp
===
--- lib/CodeGen/CGExprAgg.cpp
+++ lib/CodeGen/CGExprAgg.cpp
@@ -571,6 +571,8 @@
 }
 
 void AggExprEmitter::VisitCastExpr(CastExpr *E) {
+  if (const auto *ECE = dyn_cast(E))
+CGF.CGM.EmitExplicitCastExprType(ECE, );
   switch (E->getCastKind()) {
   case CK_Dynamic: {
 // FIXME: Can this actually happen? We have no test coverage for it.
Index: lib/CodeGen/CGExpr.cpp
===
--- lib/CodeGen/CGExpr.cpp
+++ lib/CodeGen/CGExpr.cpp
@@ -780,6 +780,16 @@
   return isPre ? IncVal : InVal;
 }
 
+void CodeGenModule::EmitExplicitCastExprType(const ExplicitCastExpr *E,
+ CodeGenFunction *CGF) {
+  // Bind VLAs in the cast type.
+  if (CGF && E->getType()->isVariablyModifiedType())
+CGF->EmitVariablyModifiedType(E->getType());
+
+  if (CGDebugInfo *DI = getModuleDebugInfo())
+DI->EmitExplicitCastType(E->getType());
+}
+
 //===--===//
 // LValue Expression Emission
 //===--===//
@@ -795,9 +805,8 @@
 
   // Casts:
   if (const CastExpr *CE = dyn_cast(E)) {
-// Bind VLAs in the cast type.
-if (E->getType()->isVariablyModifiedType())
-  EmitVariablyModifiedType(E->getType());
+if (const auto *ECE = dyn_cast(CE))
+  CGM.EmitExplicitCastExprType(ECE, this);
 
 switch (CE->getCastKind()) {
 // Non-converting casts (but not C's implicit conversion from void*).
@@ -3427,6 +3436,7 @@
 // This must be a reinterpret_cast (or c-style equivalent).
 const auto *CE = cast(E);
 
+CGM.EmitExplicitCastExprType(CE, this);
 LValue LV = EmitLValue(E->getSubExpr());
 Address V = Builder.CreateBitCast(LV.getAddress(),
   ConvertType(CE->getTypeAsWritten()));
Index: lib/CodeGen/CGExprComplex.cpp
===
--- lib/CodeGen/CGExprComplex.cpp
+++ lib/CodeGen/CGExprComplex.cpp
@@ -154,6 +154,8 @@
 return EmitCast(E->getCastKind(), E->getSubExpr(), E->getType());
   }
   ComplexPairTy VisitCastExpr(CastExpr *E) {
+if (const auto *ECE = dyn_cast(E))
+  CGF.CGM.EmitExplicitCastExprType(ECE, );
 return EmitCast(E->getCastKind(), E->getSubExpr(), E->getType());
   }
   ComplexPairTy VisitCallExpr(const CallExpr *E);
Index: lib/CodeGen/CGExprScalar.cpp
===
--- lib/CodeGen/CGExprScalar.cpp
+++ lib/CodeGen/CGExprScalar.cpp
@@ -314,12 +314,7 @@
 return EmitNullValue(E->getType());
   }
   Value *VisitExplicitCastExpr(ExplicitCastExpr *E) {
-if (E->getType()->isVariablyModifiedType())
-  CGF.EmitVariablyModifiedType(E->getType());
-
-if (CGDebugInfo *DI = CGF.getDebugInfo())
-  DI->EmitExplicitCastType(E->getType());
-
+CGF.CGM.EmitExplicitCastExprType(E, );
 return VisitCastExpr(E);
   }
   Value *VisitCastExpr(CastExpr *E);
Index: lib/CodeGen/CGExprConstant.cpp
===
--- lib/CodeGen/CGExprConstant.cpp
+++ lib/CodeGen/CGExprConstant.cpp
@@ -636,6 +636,8 @@
   }
 
   llvm::Constant *VisitCastExpr(CastExpr* E) {
+if (const auto *ECE = dyn_cast(E))
+  CGM.EmitExplicitCastExprType(ECE, CGF);
 Expr *subExpr = E->getSubExpr();
 llvm::Constant *C = CGM.EmitConstantExpr(subExpr, subExpr->getType(), CGF);
 if (!C) return nullptr;
Index: lib/CodeGen/CodeGenModule.h
===
--- lib/CodeGen/CodeGenModule.h
+++ lib/CodeGen/CodeGenModule.h
@@ -923,6 +923,11 @@
  QualType DestType,
  CodeGenFunction *CGF = nullptr);
 
+  /// \brief Emit type info if type of an expression is a variably modified
+  /// type. Also emit proper debug info for cast types.
+  void 

Re: [PATCH] D13731: [RFC][Analyzer] Supporting function attributes in .model files.

[pierre gousseau via cfe-commits]

pgousseau updated this revision to Diff 37466.
pgousseau added a comment.

Fix incorrect caching of model files declarations.


http://reviews.llvm.org/D13731

Files:
  include/clang/Analysis/AnalysisContext.h
  include/clang/Analysis/CodeInjector.h
  include/clang/StaticAnalyzer/Frontend/FrontendActions.h
  include/clang/StaticAnalyzer/Frontend/ModelConsumer.h
  lib/Analysis/AnalysisDeclContext.cpp
  lib/Analysis/BodyFarm.cpp
  lib/Analysis/BodyFarm.h
  lib/StaticAnalyzer/Checkers/CheckSecuritySyntaxOnly.cpp
  lib/StaticAnalyzer/Frontend/FrontendActions.cpp
  lib/StaticAnalyzer/Frontend/ModelConsumer.cpp
  lib/StaticAnalyzer/Frontend/ModelInjector.cpp
  lib/StaticAnalyzer/Frontend/ModelInjector.h
  test/Analysis/Inputs/Models/returnNeedsCheckHasModelFile.model
  test/Analysis/unchecked-return.cpp

Index: test/Analysis/unchecked-return.cpp
===
--- /dev/null
+++ test/Analysis/unchecked-return.cpp
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -analyze -analyzer-checker=core,security.insecureAPI.UncheckedReturn -analyzer-config faux-bodies=true,model-path=%S/Inputs/Models %s -verify
+
+int returnNeedsCheckHasModelFile();
+
+int f0() {
+  returnNeedsCheckHasModelFile(); // expected-warning{{The return value from the call to 'returnNeedsCheckHasModelFile' is not checked.}}
+  return 0;
+}
Index: test/Analysis/Inputs/Models/returnNeedsCheckHasModelFile.model
===
--- /dev/null
+++ test/Analysis/Inputs/Models/returnNeedsCheckHasModelFile.model
@@ -0,0 +1 @@
+int returnNeedsCheckHasModelFile() __attribute__((warn_unused_result));
Index: lib/StaticAnalyzer/Frontend/ModelInjector.h
===
--- lib/StaticAnalyzer/Frontend/ModelInjector.h
+++ lib/StaticAnalyzer/Frontend/ModelInjector.h
@@ -45,6 +45,7 @@
   ModelInjector(CompilerInstance );
   Stmt *getBody(const FunctionDecl *D) override;
   Stmt *getBody(const ObjCMethodDecl *D) override;
+  FunctionDecl *getModelDecl(const FunctionDecl *D) override;
 
 private:
   /// \brief Synthesize a body for a declaration
@@ -67,6 +68,9 @@
   // FIXME: double memoization is redundant, with memoization both here and in
   // BodyFarm.
   llvm::StringMap Bodies;
+
+  // Store the model's function declaration if provided.
+  llvm::StringMap Decls;
 };
 }
 }
Index: lib/StaticAnalyzer/Frontend/ModelInjector.cpp
===
--- lib/StaticAnalyzer/Frontend/ModelInjector.cpp
+++ lib/StaticAnalyzer/Frontend/ModelInjector.cpp
@@ -37,11 +37,16 @@
   return Bodies[D->getName()];
 }
 
+FunctionDecl *ModelInjector::getModelDecl(const FunctionDecl *D) {
+  onBodySynthesis(D);
+  return Decls[D->getName()];
+}
+
 void ModelInjector::onBodySynthesis(const NamedDecl *D) {
 
   // FIXME: what about overloads? Declarations can be used as keys but what
   // about file name index? Mangled names may not be suitable for that either.
-  if (Bodies.count(D->getName()) != 0)
+  if (Bodies.count(D->getName()) != 0 || Decls.count(D->getName()) != 0)
 return;
 
   SourceManager  = CI.getSourceManager();
@@ -60,6 +65,7 @@
 
   if (!llvm::sys::fs::exists(fileName.str())) {
 Bodies[D->getName()] = nullptr;
+Decls[D->getName()] = nullptr;
 return;
   }
 
@@ -95,7 +101,7 @@
 
   Instance.getPreprocessor().InitializeForModelFile();
 
-  ParseModelFileAction parseModelFile(Bodies);
+  ParseModelFileAction parseModelFile(Bodies, Decls);
 
   const unsigned ThreadStackSize = 8 << 20;
   llvm::CrashRecoveryContext CRC;
Index: lib/StaticAnalyzer/Frontend/ModelConsumer.cpp
===
--- lib/StaticAnalyzer/Frontend/ModelConsumer.cpp
+++ lib/StaticAnalyzer/Frontend/ModelConsumer.cpp
@@ -26,16 +26,20 @@
 using namespace clang;
 using namespace ento;
 
-ModelConsumer::ModelConsumer(llvm::StringMap )
-: Bodies(Bodies) {}
+ModelConsumer::ModelConsumer(llvm::StringMap ,
+ llvm::StringMap )
+: Bodies(Bodies), Decls(Decls) {}
 
 bool ModelConsumer::HandleTopLevelDecl(DeclGroupRef D) {
   for (DeclGroupRef::iterator I = D.begin(), E = D.end(); I != E; ++I) {
 
-// Only interested in definitions.
-const FunctionDecl *func = llvm::dyn_cast(*I);
-if (func && func->hasBody()) {
-  Bodies.insert(std::make_pair(func->getName(), func->getBody()));
+// We are interested in definitions and declarations.
+FunctionDecl *func = llvm::dyn_cast(*I);
+if (func) {
+  Decls.insert(std::make_pair(func->getName(), func));
+  if (func->hasBody()) {
+Bodies.insert(std::make_pair(func->getName(), func->getBody()));
+  }
 }
   }
   return true;
Index: lib/StaticAnalyzer/Frontend/FrontendActions.cpp
===
--- lib/StaticAnalyzer/Frontend/FrontendActions.cpp
+++ 

r250388 - Headers: Switch some headers to LF line endings for consistency.

[Peter Collingbourne via cfe-commits]

Author: pcc
Date: Thu Oct 15 05:33:27 2015
New Revision: 250388

URL: http://llvm.org/viewvc/llvm-project?rev=250388=rev
Log:
Headers: Switch some headers to LF line endings for consistency.

Modified:
cfe/trunk/lib/Headers/avx512cdintrin.h
cfe/trunk/lib/Headers/xsavecintrin.h
cfe/trunk/lib/Headers/xsaveintrin.h
cfe/trunk/lib/Headers/xsaveoptintrin.h
cfe/trunk/lib/Headers/xsavesintrin.h

Modified: cfe/trunk/lib/Headers/avx512cdintrin.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/avx512cdintrin.h?rev=250388=250387=250388=diff
==
--- cfe/trunk/lib/Headers/avx512cdintrin.h (original)
+++ cfe/trunk/lib/Headers/avx512cdintrin.h Thu Oct 15 05:33:27 2015
@@ -1,131 +1,131 @@
-/*===- avx512cdintrin.h - AVX512CD intrinsics --===
- *
- *
- * Permission is hereby granted, free of charge, to any person obtaining a copy
- * of this software and associated documentation files (the "Software"), to 
deal
- * in the Software without restriction, including without limitation the rights
- * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
- * copies of the Software, and to permit persons to whom the Software is
- * furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice shall be included in
- * all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
- * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
- * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
- * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
- * THE SOFTWARE.
- *
- *===---===
- */
-#ifndef __IMMINTRIN_H
-#error "Never use  directly; include  instead."
-#endif
-
-#ifndef __AVX512CDINTRIN_H
-#define __AVX512CDINTRIN_H
-
-/* Define the default attributes for the functions in this file. */
-#define __DEFAULT_FN_ATTRS __attribute__((__always_inline__, __nodebug__, 
__target__("avx512cd")))
-
-static __inline__ __m512i __DEFAULT_FN_ATTRS
-_mm512_conflict_epi64 (__m512i __A)
-{
-  return (__m512i) __builtin_ia32_vpconflictdi_512_mask ((__v8di) __A,
- (__v8di) _mm512_setzero_si512 (),
- (__mmask8) -1);
-}
-
-static __inline__ __m512i __DEFAULT_FN_ATTRS
-_mm512_mask_conflict_epi64 (__m512i __W, __mmask8 __U, __m512i __A)
-{
-  return (__m512i) __builtin_ia32_vpconflictdi_512_mask ((__v8di) __A,
-   (__v8di) __W,
-   (__mmask8) __U);
-}
-
-static __inline__ __m512i __DEFAULT_FN_ATTRS
-_mm512_maskz_conflict_epi64 (__mmask8 __U, __m512i __A)
-{
-  return (__m512i) __builtin_ia32_vpconflictdi_512_mask ((__v8di) __A,
- (__v8di) _mm512_setzero_si512 (),
- (__mmask8) __U);
-}
-
-static __inline__ __m512i __DEFAULT_FN_ATTRS
-_mm512_conflict_epi32 (__m512i __A)
-{
-  return (__m512i) __builtin_ia32_vpconflictsi_512_mask ((__v16si) __A,
- (__v16si) _mm512_setzero_si512 (),
- (__mmask16) -1);
-}
-
-static __inline__ __m512i __DEFAULT_FN_ATTRS
-_mm512_mask_conflict_epi32 (__m512i __W, __mmask16 __U, __m512i __A)
-{
-  return (__m512i) __builtin_ia32_vpconflictsi_512_mask ((__v16si) __A,
-   (__v16si) __W,
-   (__mmask16) __U);
-}
-
-static __inline__ __m512i __DEFAULT_FN_ATTRS
-_mm512_maskz_conflict_epi32 (__mmask16 __U, __m512i __A)
-{
-  return (__m512i) __builtin_ia32_vpconflictsi_512_mask ((__v16si) __A,
- (__v16si) _mm512_setzero_si512 (),
- (__mmask16) __U);
-}
-
-static __inline__ __m512i __DEFAULT_FN_ATTRS
-_mm512_lzcnt_epi32 (__m512i __A)
-{
-  return (__m512i) __builtin_ia32_vplzcntd_512_mask ((__v16si) __A,
- (__v16si) _mm512_setzero_si512 (),
- (__mmask16) -1);
-}
-
-static __inline__ __m512i __DEFAULT_FN_ATTRS
-_mm512_mask_lzcnt_epi32 (__m512i __W, __mmask16 __U, __m512i __A)
-{
-  return (__m512i) __builtin_ia32_vplzcntd_512_mask ((__v16si) __A,
- (__v16si) __W,
- (__mmask16) __U);
-}
-
-static __inline__ __m512i __DEFAULT_FN_ATTRS
-_mm512_maskz_lzcnt_epi32 (__mmask16 __U, __m512i __A)
-{
-  return (__m512i) __builtin_ia32_vplzcntd_512_mask ((__v16si) __A,
- (__v16si) _mm512_setzero_si512 (),
- (__mmask16) __U);
-}
-
-static __inline__ __m512i __DEFAULT_FN_ATTRS
-_mm512_lzcnt_epi64 (__m512i __A)
-{
-  return (__m512i) __builtin_ia32_vplzcntq_512_mask ((__v8di) __A,
- (__v8di) _mm512_setzero_si512 (),
- (__mmask8) -1);
-}
-
-static __inline__ __m512i __DEFAULT_FN_ATTRS
-_mm512_mask_lzcnt_epi64 

Re: [PATCH] D13549: Added new options to ClangFormat VSIX package.

[Marek Kurdej via cfe-commits]

curdeius added a comment.

Ping?


http://reviews.llvm.org/D13549



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

Re: [PATCH] D12358: [Analyzer] Widening loops which do not exit

[Sean Eveson via cfe-commits]

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

In http://reviews.llvm.org/D12358#266391, @dcoughlin wrote:

> I think this is an acceptable loss of precision because, in general, it is 
> unlikely that a concrete-bounded loop will be executed *exactly* 
> maxBlockVisitOnPath times. You could add special syntactic checks to try to 
> detect this, but I think it is unlikely to make much different in practice.


I agree.

The problem can be solved by executing the widened state after the last 
iteration, rather than instead of it. This can only really be done by changing 
the max block visit approach. This needs to be done in the future in order to 
support nested loops. This precision issue could also be resolved at that time.



Comment at: include/clang/StaticAnalyzer/Core/PathSensitive/CoreEngine.h:84
@@ +83,3 @@
+  /// The blocks that have been visited during analysis
+  llvm::DenseSet blocksVisited;
+

The BlockCount is specific to the path of analysis, so it can't be used to 
check if a loop has been exited before. I've added this set to store and 
identify previously visited blocks. Is there a better way this can/could be 
done?


Comment at: lib/StaticAnalyzer/Core/LoopWidening.cpp:65
@@ +64,3 @@
+  if (FalseBranch)
+return FalseBranch;
+  // If there isn't a false branch we still have to check for break points

Perfect, thanks.

Perhaps it could be changed back to false when the invalidation is better? Then 
it could catch true positives e.g.
```
int *a = new int[10]
for (int i = 0; i < 100; ++i) {
  if (i > 90) 
++a;
  ...
}
```


Comment at: test/Analysis/loop-widening.c:159
@@ +158,3 @@
+
+void variable_bound_exiting_loops_not_widened(int x) {
+  int i = 0;

Thank you for the example tests.

When an inner loop is widened, any outer loops are widened 'coincidentally' 
since everything is invalidated. This means the second example test passes. 
When an inner loop is not widened the outer loop will not be widened. This is 
because a sink is generated when the max block count is reached the second time 
through the outer loop. i.e.
```
for (i = 0; i < 10; i++) {
  for (j = 0; j < 2; j++) {
// A sink is generated here on the second iteration of the outer loop,
// since this block was already visited twice (when i == 0).
...
  }
}
// Never reach here
```
This means the first example test does not pass. I’ve added the tests with a 
FIXME comment.



http://reviews.llvm.org/D12358



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

Re: [PATCH] D13744: Update clang as per D13683

[Eric Christopher via cfe-commits]

Done in r250373.

Thanks!

-eric

On Wed, Oct 14, 2015 at 2:18 PM Amaury SECHET <
deadalnix+llvmrev...@gmail.com> wrote:

> deadalnix created this revision.
> deadalnix added reviewers: chandlerc, dexonsmith, echristo.
> deadalnix added a subscriber: cfe-commits.
>
> This diffs remove use of deprecated API.
>
> http://reviews.llvm.org/D13744
>
> Files:
>   lib/CodeGen/CGDebugInfo.cpp
>
> Index: lib/CodeGen/CGDebugInfo.cpp
> ===
> --- lib/CodeGen/CGDebugInfo.cpp
> +++ lib/CodeGen/CGDebugInfo.cpp
> @@ -844,7 +844,7 @@
>}
>
>llvm::DITypeRefArray EltTypeArray =
> DBuilder.getOrCreateTypeArray(EltTys);
> -  return DBuilder.createSubroutineType(Unit, EltTypeArray);
> +  return DBuilder.createSubroutineType(EltTypeArray);
>  }
>
>  /// Convert an AccessSpecifier into the corresponding DINode flag.
> @@ -1095,7 +1095,7 @@
>if (Func->getExtProtoInfo().RefQualifier == RQ_RValue)
>  Flags |= llvm::DINode::FlagRValueReference;
>
> -  return DBuilder.createSubroutineType(Unit, EltTypeArray, Flags);
> +  return DBuilder.createSubroutineType(EltTypeArray, Flags);
>  }
>
>  /// isFunctionLocalClass - Return true if CXXRecordDecl is defined
> @@ -1395,7 +1395,7 @@
>/* Function type */
>llvm::Metadata *STy = getOrCreateType(Context.IntTy, Unit);
>llvm::DITypeRefArray SElements = DBuilder.getOrCreateTypeArray(STy);
> -  llvm::DIType *SubTy = DBuilder.createSubroutineType(Unit, SElements);
> +  llvm::DIType *SubTy = DBuilder.createSubroutineType(SElements);
>unsigned Size = Context.getTypeSize(Context.VoidPtrTy);
>llvm::DIType *vtbl_ptr_type =
>DBuilder.createPointerType(SubTy, Size, 0, "__vtbl_ptr_type");
> @@ -2599,8 +2599,7 @@
>if (!D || DebugKind <= CodeGenOptions::DebugLineTablesOnly)
>  // Create fake but valid subroutine type. Otherwise -verify would
> fail, and
>  // subprogram DIE will miss DW_AT_decl_file and DW_AT_decl_line
> fields.
> -return DBuilder.createSubroutineType(F,
> -
>  DBuilder.getOrCreateTypeArray(None));
> +return
> DBuilder.createSubroutineType(DBuilder.getOrCreateTypeArray(None));
>
>if (const CXXMethodDecl *Method = dyn_cast(D))
>  return getOrCreateMethodType(Method, F);
> @@ -2637,7 +2636,7 @@
>Elts.push_back(DBuilder.createUnspecifiedParameter());
>
>  llvm::DITypeRefArray EltTypeArray =
> DBuilder.getOrCreateTypeArray(Elts);
> -return DBuilder.createSubroutineType(F, EltTypeArray);
> +return DBuilder.createSubroutineType(EltTypeArray);
>}
>
>// Handle variadic function types; they need an additional
> @@ -2651,7 +2650,7 @@
>EltTys.push_back(getOrCreateType(FPT->getParamType(i), F));
>EltTys.push_back(DBuilder.createUnspecifiedParameter());
>llvm::DITypeRefArray EltTypeArray =
> DBuilder.getOrCreateTypeArray(EltTys);
> -  return DBuilder.createSubroutineType(F, EltTypeArray);
> +  return DBuilder.createSubroutineType(EltTypeArray);
>  }
>
>return cast(getOrCreateType(FnType, F));
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D13765: clang-format: [JS] Handle string literals spanning character classes.

[Martin Probst via cfe-commits]

mprobst updated this revision to Diff 37447.
mprobst added a comment.

Simplified escape handling.


http://reviews.llvm.org/D13765

Files:
  lib/Format/Format.cpp
  unittests/Format/FormatTestJS.cpp

Index: unittests/Format/FormatTestJS.cpp
===
--- unittests/Format/FormatTestJS.cpp
+++ unittests/Format/FormatTestJS.cpp
@@ -625,6 +625,9 @@
   verifyFormat("var regex = /[\\/]/;");
   verifyFormat("var regex = /\\[/;");
   verifyFormat("var regex = /[/]/;");
+  verifyFormat("var regex = /}[\"]/;");
+  verifyFormat("var regex = /}[/\"]/;");
+  verifyFormat("var regex = /}[\"/]/;");
 
   verifyFormat("var regex = /\\b/;");
   verifyFormat("var regex = /\\B/;");
Index: lib/Format/Format.cpp
===
--- lib/Format/Format.cpp
+++ lib/Format/Format.cpp
@@ -730,6 +730,8 @@
 assert(FirstInLineIndex == 0);
 do {
   Tokens.push_back(getNextToken());
+  if (Style.Language == FormatStyle::LK_JavaScript)
+tryParseJSRegexLiteral();
   tryMergePreviousTokens();
   if (Tokens.back()->NewlinesBefore > 0 || Tokens.back()->IsMultiline)
 FirstInLineIndex = Tokens.size() - 1;
@@ -749,10 +751,6 @@
   return;
 
 if (Style.Language == FormatStyle::LK_JavaScript) {
-  if (tryMergeJSRegexLiteral())
-return;
-  if (tryMergeEscapeSequence())
-return;
   if (tryMergeTemplateString())
 return;
 
@@ -824,107 +822,91 @@
 return true;
   }
 
-  // Tries to merge an escape sequence, i.e. a "\\" and the following
-  // character. Use e.g. inside JavaScript regex literals.
-  bool tryMergeEscapeSequence() {
-if (Tokens.size() < 2)
-  return false;
-FormatToken *Previous = Tokens[Tokens.size() - 2];
-if (Previous->isNot(tok::unknown) || Previous->TokenText != "\\")
-  return false;
-++Previous->ColumnWidth;
-StringRef Text = Previous->TokenText;
-Previous->TokenText = StringRef(Text.data(), Text.size() + 1);
-resetLexer(SourceMgr.getFileOffset(Tokens.back()->Tok.getLocation()) + 1);
-Tokens.resize(Tokens.size() - 1);
-Column = Previous->OriginalColumn + Previous->ColumnWidth;
-return true;
+  // Returns \c true if \p Tok can only be followed by an operand in JavaScript.
+  bool PrecedesOperand(FormatToken *Tok) {
+// NB: This is not entirely correct, as an r_paren can introduce an operand
+// location in e.g. `if (foo) /bar/.exec(...);`. That is a rare enough
+// corner case to not matter in practice, though.
+return (Tok->isOneOf(tok::period, tok::l_paren, tok::comma, tok::l_brace,
+ tok::r_brace, tok::l_square, tok::semi, tok::exclaim,
+ tok::colon, tok::question, tok::tilde) ||
+Tok->isOneOf(tok::kw_return, tok::kw_do, tok::kw_case,
+ tok::kw_throw, tok::kw_else, tok::kw_new,
+ tok::kw_delete, tok::kw_void, tok::kw_typeof,
+ Keywords.kw_instanceof, Keywords.kw_in) ||
+Tok->isBinaryOperator());
   }
 
-  // Try to determine whether the current token ends a JavaScript regex literal.
-  // We heuristically assume that this is a regex literal if we find two
-  // unescaped slashes on a line and the token before the first slash is one of
-  // "(;,{}![:?", a binary operator or 'return', as those cannot be followed by
-  // a division.
-  bool tryMergeJSRegexLiteral() {
-if (Tokens.size() < 2)
-  return false;
+  // Tries to parse a JavaScript Regex literal starting at the current token,
+  // if that begins with a slash and is in a location where JavaScript allows
+  // regex literals. Changes the current token to a regex literal and updates
+  // its text if successful.
+  void tryParseJSRegexLiteral() {
+FormatToken *RegexToken = Tokens.back();
+if (!RegexToken->isOneOf(tok::slash, tok::slashequal))
+  return;
 
-// If this is a string literal with a slash inside, compute the slash's
-// offset and try to find the beginning of the regex literal.
-// Also look at tok::unknown, as it can be an unterminated char literal.
-size_t SlashInStringPos = StringRef::npos;
-if (Tokens.back()->isOneOf(tok::string_literal, tok::char_constant,
-   tok::unknown)) {
-  // Start search from position 1 as otherwise, this is an unknown token
-  // for an unterminated /*-comment which is handled elsewhere.
-  SlashInStringPos = Tokens.back()->TokenText.find('/', 1);
-  if (SlashInStringPos == StringRef::npos)
-return false;
+FormatToken *Prev = nullptr;
+for (auto I = Tokens.rbegin() + 1, E = Tokens.rend(); I != E; ++I) {
+  // NB: Because previous pointers are not initialized yet, this cannot use
+  // Token.getPreviousNonComment.
+  if ((*I)->isNot(tok::comment)) {
+Prev = *I;
+break;
+  }
+}
+if (Prev) {
+   

Re: [PATCH] D13516: Fix overlapping replacements in clang-tidy.

[Angel Garcia via cfe-commits]

angelgarcia updated this revision to Diff 37465.
angelgarcia added a comment.

I did several mutations and the only case were a test didn't break was when I 
removed the sort, but it turned out that we don't need it. I changed the tests 
to apply the checks in both orders to ensure that a test will break if the 
errors are not sorted.

I am still thinking about how to complete Daniel's idea.


http://reviews.llvm.org/D13516

Files:
  clang-tidy/ClangTidyDiagnosticConsumer.cpp
  clang-tidy/ClangTidyDiagnosticConsumer.h
  unittests/clang-tidy/OverlappingReplacementsTest.cpp

Index: unittests/clang-tidy/OverlappingReplacementsTest.cpp
===
--- unittests/clang-tidy/OverlappingReplacementsTest.cpp
+++ unittests/clang-tidy/OverlappingReplacementsTest.cpp
@@ -77,11 +77,12 @@
 auto *VD = Result.Nodes.getNodeAs(BoundDecl);
 std::string NewName = newName(VD->getName());
 
-auto Diag = diag(VD->getLocation(), "refactor")
+auto Diag = diag(VD->getLocation(), "refactor %0 into %1")
+<< VD->getName() << NewName
 << FixItHint::CreateReplacement(
-CharSourceRange::getTokenRange(VD->getLocation(),
-   VD->getLocation()),
-NewName);
+   CharSourceRange::getTokenRange(VD->getLocation(),
+  VD->getLocation()),
+   NewName);
 
 class UsageVisitor : public RecursiveASTVisitor {
 public:
@@ -281,7 +282,7 @@
 
   // Apply the UseCharCheck together with the IfFalseCheck.
   //
-  // The 'If' fix is bigger, so that is the one that has to be applied.
+  // The 'If' fix contains the other, so that is the one that has to be applied.
   // } else if (int a = 0) {
   //^^^ -> char
   //~ -> false
@@ -294,16 +295,18 @@
   }
 })";
   Res = runCheckOnCode(Code);
-  // FIXME: EXPECT_EQ(CharIfFix, Res);
+  EXPECT_EQ(CharIfFix, Res);
+  Res = runCheckOnCode(Code);
+  EXPECT_EQ(CharIfFix, Res);
 
   // Apply the IfFalseCheck with the StartsWithPotaCheck.
   //
   // The 'If' replacement is bigger here.
   // if (char potato = 0) {
   //  ^^ -> tomato
   // ~~~ -> false
   //
-  // But the refactoring is bigger here:
+  // But the refactoring is the one that contains the other here:
   // char potato = 0;
   //  ^^ -> tomato
   // if (potato) potato;
@@ -318,60 +321,80 @@
   }
 })";
   Res = runCheckOnCode(Code);
-  // FIXME: EXPECT_EQ(IfStartsFix, Res);
-
-  // Silence warnings.
-  (void)CharIfFix;
-  (void)IfStartsFix;
+  EXPECT_EQ(IfStartsFix, Res);
+  Res = runCheckOnCode(Code);
+  EXPECT_EQ(IfStartsFix, Res);
 }
 
-TEST(OverlappingReplacementsTest, ApplyFullErrorOrNothingWhenOverlapping) {
+TEST(OverlappingReplacements, TwoReplacementsInsideOne) {
   std::string Res;
   const char Code[] =
   R"(void f() {
-  int potato = 0;
-  potato += potato * potato;
-  if (char this_name_make_this_if_really_long = potato) potato;
+  if (int potato = 0) {
+int a = 0;
+  }
 })";
 
-  // StartsWithPotaCheck will try to refactor 'potato' into 'tomato',
-  // and EndsWithTatoCheck will try to use 'pomelo'. We have to apply
-  // either all conversions from one check, or all from the other.
-  const char StartsFix[] =
+  // The two smallest replacements should not be applied.
+  // if (int potato = 0) {
+  // ^^ -> tomato
+  // *** -> char
+  // ~~ -> false
+  // But other errors from the same checks should not be affected.
+  //   int a = 0;
+  //   *** -> char
+  const char Fix[] =
   R"(void f() {
-  int tomato = 0;
-  tomato += tomato * tomato;
-  if (char this_name_make_this_if_really_long = tomato) tomato;
+  if (false) {
+char a = 0;
+  }
 })";
-  const char EndsFix[] =
+  Res = runCheckOnCode(Code);
+  EXPECT_EQ(Fix, Res);
+  Res = runCheckOnCode(Code);
+  EXPECT_EQ(Fix, Res);
+}
+
+TEST(OverlappingReplacementsTest, DiscardBothChangesWhenPartialOverlapping) {
+std::string Res;
+  const char Code[] =
   R"(void f() {
-  int pomelo = 0;
-  pomelo += pomelo * pomelo;
-  if (char this_name_make_this_if_really_long = pomelo) pomelo;
+  if (int potato = 0) {
+int a = potato;
+  }
 })";
-  // In case of overlapping, we will prioritize the biggest fix. However, these
-  // two fixes have the same size and position, so we don't know yet which one
-  // will have preference.
-  Res = runCheckOnCode(Code);
-  // FIXME: EXPECT_TRUE(Res == StartsFix || Res == EndsFix);
 
-  // StartsWithPotaCheck will try to refactor 'potato' into 'tomato', but
-  // replacing the 'if' condition is a 

r250373 - Update clang for DIBuilder::createSubroutineType API change.

[Eric Christopher via cfe-commits]

Author: echristo
Date: Thu Oct 15 01:56:08 2015
New Revision: 250373

URL: http://llvm.org/viewvc/llvm-project?rev=250373=rev
Log:
Update clang for DIBuilder::createSubroutineType API change.

Patch by Amaury Sechet!

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

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=250373=250372=250373=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Thu Oct 15 01:56:08 2015
@@ -844,7 +844,7 @@ llvm::DIType *CGDebugInfo::CreateType(co
   }
 
   llvm::DITypeRefArray EltTypeArray = DBuilder.getOrCreateTypeArray(EltTys);
-  return DBuilder.createSubroutineType(Unit, EltTypeArray);
+  return DBuilder.createSubroutineType(EltTypeArray);
 }
 
 /// Convert an AccessSpecifier into the corresponding DINode flag.
@@ -1095,7 +1095,7 @@ llvm::DISubroutineType *CGDebugInfo::get
   if (Func->getExtProtoInfo().RefQualifier == RQ_RValue)
 Flags |= llvm::DINode::FlagRValueReference;
 
-  return DBuilder.createSubroutineType(Unit, EltTypeArray, Flags);
+  return DBuilder.createSubroutineType(EltTypeArray, Flags);
 }
 
 /// isFunctionLocalClass - Return true if CXXRecordDecl is defined
@@ -1395,7 +1395,7 @@ llvm::DIType *CGDebugInfo::getOrCreateVT
   /* Function type */
   llvm::Metadata *STy = getOrCreateType(Context.IntTy, Unit);
   llvm::DITypeRefArray SElements = DBuilder.getOrCreateTypeArray(STy);
-  llvm::DIType *SubTy = DBuilder.createSubroutineType(Unit, SElements);
+  llvm::DIType *SubTy = DBuilder.createSubroutineType(SElements);
   unsigned Size = Context.getTypeSize(Context.VoidPtrTy);
   llvm::DIType *vtbl_ptr_type =
   DBuilder.createPointerType(SubTy, Size, 0, "__vtbl_ptr_type");
@@ -2599,8 +2599,7 @@ llvm::DISubroutineType *CGDebugInfo::get
   if (!D || DebugKind <= CodeGenOptions::DebugLineTablesOnly)
 // Create fake but valid subroutine type. Otherwise -verify would fail, and
 // subprogram DIE will miss DW_AT_decl_file and DW_AT_decl_line fields.
-return DBuilder.createSubroutineType(F,
- DBuilder.getOrCreateTypeArray(None));
+return DBuilder.createSubroutineType(DBuilder.getOrCreateTypeArray(None));
 
   if (const CXXMethodDecl *Method = dyn_cast(D))
 return getOrCreateMethodType(Method, F);
@@ -2637,7 +2636,7 @@ llvm::DISubroutineType *CGDebugInfo::get
   Elts.push_back(DBuilder.createUnspecifiedParameter());
 
 llvm::DITypeRefArray EltTypeArray = DBuilder.getOrCreateTypeArray(Elts);
-return DBuilder.createSubroutineType(F, EltTypeArray);
+return DBuilder.createSubroutineType(EltTypeArray);
   }
 
   // Handle variadic function types; they need an additional
@@ -2651,7 +2650,7 @@ llvm::DISubroutineType *CGDebugInfo::get
   EltTys.push_back(getOrCreateType(FPT->getParamType(i), F));
   EltTys.push_back(DBuilder.createUnspecifiedParameter());
   llvm::DITypeRefArray EltTypeArray = 
DBuilder.getOrCreateTypeArray(EltTys);
-  return DBuilder.createSubroutineType(F, EltTypeArray);
+  return DBuilder.createSubroutineType(EltTypeArray);
 }
 
   return cast(getOrCreateType(FnType, F));


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

[PATCH] Add customizable clang-format options variable

[Syohei Yoshida via cfe-commits]

Hi.

At r249567, '-sort-includes' option is set to clang-format-region
command in clang-format.el. This option can be used only with
development version clang-format. and users get error if they use old
version clang-format. And I suppose clang-format options should not be
hard corded and should be customizable.

This attached patch adds customize variable about clang-format options
and its default value is '("-sort-includes") if users use clang-format
3.8 or higher, while it is nil if not.

Regards.

See also
  - https://github.com/syl20bnr/spacemacs/issues/3408 (older
clang-format user's issue)

-- 
Syohei YOSHIDA(syo...@gmail.com)
Index: clang-format.el
===
--- clang-format.el	(revision 250381)
+++ clang-format.el	(working copy)
@@ -56,6 +56,20 @@
   :safe #'stringp)
 (make-variable-buffer-local 'clang-format-style)

+(defun clang-format--default-options ()
+  (with-temp-buffer
+(when (and (executable-find clang-format-executable)
+   (= (process-file clang-format-executable nil t nil "--version") 0))
+  (goto-char (point-min))
+  (when (re-search-forward "clang-format version \\([0-9.]+\\)" nil t)
+(when (version<= "3.8.0" (match-string-no-properties 1))
+  '("-sort-includes"))
+
+(defcustom clang-format-options (clang-format--default-options)
+  "Optional arguments to pass to clang-format"
+  :group 'clang-format
+  :type '(repeat string))
+
 (defun clang-format--extract (xml-node)
   "Extract replacements and cursor information from XML-NODE."
   (unless (and (listp xml-node) (eq (xml-node-name xml-node) 'replacements))
@@ -100,6 +114,16 @@
 (when text
   (insert text

+(defun clang-format--construct-options (start end cursor style)
+  (append (list
+   "-output-replacements-xml"
+   "-assume-filename" (or (buffer-file-name) "")
+   "-style" style
+   "-offset" (number-to-string start)
+   "-length" (number-to-string (- end start))
+   "-cursor" (number-to-string cursor))
+  clang-format-options))
+
 ;;;###autoload
 (defun clang-format-region (char-start char-end  style)
   "Use clang-format to format the code between START and END according to STYLE.
@@ -121,17 +145,10 @@
 (unwind-protect
 (let (status stderr operations)
   (setq status
-(call-process-region
+(apply #'call-process-region
  (point-min) (point-max) clang-format-executable
  nil `(,temp-buffer ,temp-file) nil
-
- "-output-replacements-xml"
- "-sort-includes"
- "-assume-filename" (or (buffer-file-name) "")
- "-style" style
- "-offset" (number-to-string start)
- "-length" (number-to-string (- end start))
- "-cursor" (number-to-string cursor)))
+ (clang-format--construct-options start end cursor style)))
   (setq stderr
 (with-temp-buffer
   (insert-file-contents temp-file)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D12358: [Analyzer] Widening loops which do not exit

[Sean Eveson via cfe-commits]

seaneveson updated this revision to Diff 37462.
seaneveson added a comment.

Set CausedByPointerEscape to true
Check if the loop has already been exited before widening
Changed tests to use void clang_analyze_eval(int)
Added variable bound loop tests
Added nested loop tests


http://reviews.llvm.org/D12358

Files:
  include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
  include/clang/StaticAnalyzer/Core/PathSensitive/CoreEngine.h
  include/clang/StaticAnalyzer/Core/PathSensitive/LoopWidening.h
  lib/StaticAnalyzer/Core/AnalyzerOptions.cpp
  lib/StaticAnalyzer/Core/CMakeLists.txt
  lib/StaticAnalyzer/Core/CoreEngine.cpp
  lib/StaticAnalyzer/Core/ExprEngine.cpp
  lib/StaticAnalyzer/Core/LoopWidening.cpp
  test/Analysis/analyzer-config.c
  test/Analysis/analyzer-config.cpp
  test/Analysis/loop-widening.c

Index: test/Analysis/loop-widening.c
===
--- test/Analysis/loop-widening.c
+++ test/Analysis/loop-widening.c
@@ -0,0 +1,202 @@
+// RUN: %clang_cc1 -analyze -analyzer-checker=core,unix.Malloc,debug.ExprInspection -analyzer-store=region -analyzer-max-loop 4 -analyzer-config widen-loops=true -verify %s
+
+void clang_analyzer_eval(int);
+void clang_analyzer_warnIfReached();
+
+typedef __typeof(sizeof(int)) size_t;
+void *malloc(size_t);
+void free(void *);
+
+void loop_which_iterates_limit_times_not_widened() {
+  int i;
+  int x = 1;
+  // Check loop isn't widened by checking x isn't invalidated
+  for (i = 0; i < 1; ++i) {}
+  clang_analyzer_eval(x == 1); // expected-warning {{TRUE}}
+  for (i = 0; i < 2; ++i) {}
+  clang_analyzer_eval(x == 1); // expected-warning {{TRUE}}
+  for (i = 0; i < 3; ++i) {}
+  // FIXME loss of precision as a result of evaluating the widened loop body
+  //   *instead* of the last iteration.
+  clang_analyzer_eval(x == 1); // expected-warning {{UNKNOWN}}
+}
+
+int a_global;
+
+void loop_evaluated_before_widening() {
+  int i;
+  a_global = 1;
+  for (i = 0; i < 10; ++i) {
+if (i == 2) {
+  // True before widening then unknown after.
+  clang_analyzer_eval(a_global == 1); // expected-warning{{TRUE}} expected-warning{{UNKNOWN}}
+}
+  }
+  clang_analyzer_warnIfReached(); // expected-warning{{REACHABLE}}
+}
+
+void warnings_after_loop() {
+  int i;
+  for (i = 0; i < 10; ++i) {}
+  char *m = (char*)malloc(12);
+} // expected-warning {{Potential leak of memory pointed to by 'm'}}
+
+void for_loop_exits() {
+  int i;
+  for (i = 0; i < 10; ++i) {}
+  clang_analyzer_warnIfReached(); // expected-warning{{REACHABLE}}
+}
+
+void while_loop_exits() {
+  int i = 0;
+  while (i < 10) {++i;}
+  clang_analyzer_warnIfReached(); // expected-warning{{REACHABLE}}
+}
+
+void do_while_loop_exits() {
+  int i = 0;
+  do {++i;} while (i < 10);
+  clang_analyzer_warnIfReached(); // expected-warning{{REACHABLE}}
+}
+
+void loop_body_is_widened() {
+  int i = 0;
+  while (i < 100) {
+if (i > 10) {
+  clang_analyzer_warnIfReached(); // expected-warning{{REACHABLE}}
+}
+++i;
+  }
+  clang_analyzer_warnIfReached(); // expected-warning{{REACHABLE}}
+}
+
+void invariably_infinite_loop() {
+  int i = 0;
+  while (1) { ++i; }
+  clang_analyzer_warnIfReached(); // no-warning
+}
+
+void invariably_infinite_break_loop() {
+  int i = 0;
+  while (1) {
+++i;
+int x = 1;
+if (!x) break;
+  }
+  clang_analyzer_warnIfReached(); // no-warning
+}
+
+void reachable_break_loop() {
+  int i = 0;
+  while (1) {
+++i;
+if (i == 100) break;
+  }
+  clang_analyzer_warnIfReached(); // expected-warning{{REACHABLE}}
+}
+
+void condition_constrained_true_in_loop() {
+  int i = 0;
+  while (i < 50) {
+clang_analyzer_eval(i < 50); // expected-warning {{TRUE}}
+++i;
+  }
+  clang_analyzer_warnIfReached(); // expected-warning{{REACHABLE}}
+}
+
+void condition_constrained_false_after_loop() {
+  int i = 0;
+  while (i < 50) {
+++i;
+  }
+  clang_analyzer_eval(i >= 50); // expected-warning {{TRUE}}
+  clang_analyzer_warnIfReached(); // expected-warning{{REACHABLE}}
+}
+
+void multiple_exit_test() {
+  int x = 0;
+  int i = 0;
+  while (i < 50) {
+if (x) {
+  i = 10;
+  break;
+}
+++i;
+  }
+  // Reachable by 'normal' exit
+  if (i == 50) clang_analyzer_warnIfReached(); // expected-warning{{REACHABLE}}
+  // Reachable by break point
+  if (i == 10) clang_analyzer_warnIfReached(); // expected-warning{{REACHABLE}}
+  // Not reachable
+  if (i < 10) clang_analyzer_warnIfReached(); // no-warning
+  if (i > 10 && i < 50) clang_analyzer_warnIfReached(); // no-warning
+}
+
+void pointer_doesnt_leak_from_loop() {
+  int *h_ptr = (int *) malloc(sizeof(int));
+  for (int i = 0; i < 2; ++i) {}
+  for (int i = 0; i < 10; ++i) {} // no-warning
+  free(h_ptr);
+}
+
+int g_global;
+
+void unknown_after_loop(int s_arg) {
+  g_global = 0;
+  s_arg = 1;
+  int s_local = 2;
+  int *h_ptr = malloc(sizeof(int));
+  
+  for (int i = 0; i < 10; ++i) {}
+  
+  clang_analyzer_eval(g_global); // expected-warning 

Re: [PATCH] D13731: [RFC][Analyzer] Supporting function attributes in .model files.

[pierre gousseau via cfe-commits]

pgousseau added a comment.

In http://reviews.llvm.org/D13731#267905, @xazax.hun wrote:

> Hi!


Hi! Thank you for reviewing.

> I have some high level questions and notes about this patch.

> 

> I implemented the function modelling as a Google Summer of Code project and 
> Ted Kremenek was my mentor. I am happy that you found an useful application 
> of the function modeling system, and I think, in general, it is a good idea 
> to be able to store attributes for the modelled functions. However I am a bit 
> surprised, when I saw this patch. The main reason is that, models lack a lot 
> of functionality right now.

> 

> Main missing features:

> 

> - Ability to specify multiple model paths similar to how header include paths 
> are specified.

> - Support for methods, namespaces, overloaded functions.

> 

>   Did you find the feature useful despite those limitations? I am interested 
> to improve the situation in the future, unfortunately I find very little time 
> to work on this area recently, but I do welcome every changes.


Yes I think this is useful despite the missing features. With the current model 
file design I am confident those features could be easily added at a later 
stage?

> I have two comments before I start to review the patch itself. Right now this 
> patch contains two modifications. One for the .model files and one for a 
> checker. I think it would be better to separate these two changes into two 
> separate patches. If the motivation behind the merge of those patches is 
> that, you want to test a feature you implemented in .model files, than I 
> think there are other checker that are using attributes, so I think you 
> should be able to provide a test case with the two changes separated. (For 
> example using the nonnull parameter checker.)


I see, yes using the nonnull param checker for testing seems a better fit, I 
will update the patch.

> The other comment is that, the .model files are intended to work in a way, 
> that checkers should not be able utilize the information whether some data is 
> coming from a model file or the analyzed translation unit. In fact, this is 
> an abstraction, that makes it possible to develop the checkers and the 
> modelling mechanism independently. With you patch, the checker should observe 
> the model declaration explicitly. I think, a better design would somehow 
> merge the attributes that are coming from the original translation unit with 
> the attributes coming from the model files, and expore that set of 
> attributes. This way the checker could not tell what the source of the 
> information is. Unfortunately I do not know what would be the best way to 
> enfore this, since the checkers can just observe the AST of the original 
> translation unit and bypassing the models.


I agree, abstracting the attributes' origin is nicer, hopefully we can find a 
solution that is elegant enough. I will have a look.
Thanks!

Pierre


http://reviews.llvm.org/D13731



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

r250422 - clang-format/java: Break after annotations on fields in Chromium style.

[Nico Weber via cfe-commits]

Author: nico
Date: Thu Oct 15 11:03:01 2015
New Revision: 250422

URL: http://llvm.org/viewvc/llvm-project?rev=250422=rev
Log:
clang-format/java: Break after annotations on fields in Chromium style.

Chromium follows the Android style guide for Java code, and that doesn't make
the distinction between fields and non-fields that the Google Java style guide
makes:

https://source.android.com/source/code-style.html#use-standard-java-annotations
https://google.github.io/styleguide/javaguide.html#s4.8.5-annotations


Modified:
cfe/trunk/include/clang/Format/Format.h
cfe/trunk/lib/Format/Format.cpp
cfe/trunk/lib/Format/TokenAnnotator.cpp
cfe/trunk/unittests/Format/FormatTestJava.cpp

Modified: cfe/trunk/include/clang/Format/Format.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Format/Format.h?rev=250422=250421=250422=diff
==
--- cfe/trunk/include/clang/Format/Format.h (original)
+++ cfe/trunk/include/clang/Format/Format.h Thu Oct 15 11:03:01 2015
@@ -236,6 +236,9 @@ struct FormatStyle {
   /// the commas with the colon.
   bool BreakConstructorInitializersBeforeComma;
 
+  /// \brief Break after each annotation on a field in Java files.
+  bool BreakAfterJavaFieldAnnotations;
+
   /// \brief The column limit.
   ///
   /// A column limit of \c 0 means that there is no column limit. In this case,
@@ -560,8 +563,8 @@ struct FormatStyle {
BreakBeforeTernaryOperators == R.BreakBeforeTernaryOperators &&
BreakConstructorInitializersBeforeComma ==
R.BreakConstructorInitializersBeforeComma &&
-   ColumnLimit == R.ColumnLimit &&
-   CommentPragmas == R.CommentPragmas &&
+   BreakAfterJavaFieldAnnotations == R.BreakAfterJavaFieldAnnotations 
&&
+   ColumnLimit == R.ColumnLimit && CommentPragmas == R.CommentPragmas 
&&
ConstructorInitializerAllOnOneLineOrOnePerLine ==
R.ConstructorInitializerAllOnOneLineOrOnePerLine &&
ConstructorInitializerIndentWidth ==
@@ -604,8 +607,7 @@ struct FormatStyle {
SpacesInCStyleCastParentheses == R.SpacesInCStyleCastParentheses &&
SpacesInParentheses == R.SpacesInParentheses &&
SpacesInSquareBrackets == R.SpacesInSquareBrackets &&
-   Standard == R.Standard &&
-   TabWidth == R.TabWidth &&
+   Standard == R.Standard && TabWidth == R.TabWidth &&
UseTab == R.UseTab;
   }
 };

Modified: cfe/trunk/lib/Format/Format.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/Format.cpp?rev=250422=250421=250422=diff
==
--- cfe/trunk/lib/Format/Format.cpp (original)
+++ cfe/trunk/lib/Format/Format.cpp Thu Oct 15 11:03:01 2015
@@ -447,6 +447,7 @@ FormatStyle getLLVMStyle() {
   LLVMStyle.BraceWrapping = {false, false, false, false, false, false,
  false, false, false, false, false};
   LLVMStyle.BreakConstructorInitializersBeforeComma = false;
+  LLVMStyle.BreakAfterJavaFieldAnnotations = false;
   LLVMStyle.ColumnLimit = 80;
   LLVMStyle.CommentPragmas = "^ IWYU pragma:";
   LLVMStyle.ConstructorInitializerAllOnOneLineOrOnePerLine = false;
@@ -550,8 +551,9 @@ FormatStyle getChromiumStyle(FormatStyle
   FormatStyle ChromiumStyle = getGoogleStyle(Language);
   if (Language == FormatStyle::LK_Java) {
 ChromiumStyle.AllowShortIfStatementsOnASingleLine = true;
-ChromiumStyle.IndentWidth = 4;
+ChromiumStyle.BreakAfterJavaFieldAnnotations = true;
 ChromiumStyle.ContinuationIndentWidth = 8;
+ChromiumStyle.IndentWidth = 4;
   } else {
 ChromiumStyle.AllowAllParametersOfDeclarationOnNextLine = false;
 ChromiumStyle.AllowShortFunctionsOnASingleLine = FormatStyle::SFS_Inline;

Modified: cfe/trunk/lib/Format/TokenAnnotator.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/TokenAnnotator.cpp?rev=250422=250421=250422=diff
==
--- cfe/trunk/lib/Format/TokenAnnotator.cpp (original)
+++ cfe/trunk/lib/Format/TokenAnnotator.cpp Thu Oct 15 11:03:01 2015
@@ -2176,7 +2176,7 @@ bool TokenAnnotator::mustBreakBefore(con
Style.Language == FormatStyle::LK_JavaScript) &&
   Left.is(TT_LeadingJavaAnnotation) &&
   Right.isNot(TT_LeadingJavaAnnotation) && Right.isNot(tok::l_paren) &&
-  Line.Last->is(tok::l_brace))
+  (Line.Last->is(tok::l_brace) || Style.BreakAfterJavaFieldAnnotations))
 return true;
 
   return false;

Modified: cfe/trunk/unittests/Format/FormatTestJava.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTestJava.cpp?rev=250422=250421=250422=diff
==
--- cfe/trunk/unittests/Format/FormatTestJava.cpp (original)
+++ cfe/trunk/unittests/Format/FormatTestJava.cpp Thu 

r250418 - [CodeGen] Remove dead code. NFC.

[Benjamin Kramer via cfe-commits]

Author: d0k
Date: Thu Oct 15 10:29:40 2015
New Revision: 250418

URL: http://llvm.org/viewvc/llvm-project?rev=250418=rev
Log:
[CodeGen] Remove dead code. NFC.

Modified:
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/lib/CodeGen/CGCleanup.cpp
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/lib/CodeGen/CGDebugInfo.h
cfe/trunk/lib/CodeGen/CGObjC.cpp
cfe/trunk/lib/CodeGen/CGObjCMac.cpp
cfe/trunk/lib/CodeGen/CGVTables.h
cfe/trunk/lib/CodeGen/CodeGenABITypes.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.h
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/lib/CodeGen/CodeGenModule.h
cfe/trunk/lib/CodeGen/CodeGenPGO.h
cfe/trunk/lib/CodeGen/EHScopeStack.h
cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp

Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=250418=250417=250418=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Thu Oct 15 10:29:40 2015
@@ -4106,15 +4106,6 @@ Value *CodeGenFunction::vectorWrapScalar
   return Op;
 }
 
-Value *CodeGenFunction::vectorWrapScalar8(Value *Op) {
-  llvm::Type *VTy = llvm::VectorType::get(Int8Ty, 8);
-  Op = Builder.CreateBitCast(Op, Int8Ty);
-  Value *V = UndefValue::get(VTy);
-  llvm::Constant *CI = ConstantInt::get(SizeTy, 0);
-  Op = Builder.CreateInsertElement(V, Op, CI);
-  return Op;
-}
-
 Value *CodeGenFunction::EmitAArch64BuiltinExpr(unsigned BuiltinID,
const CallExpr *E) {
   unsigned HintID = static_cast(-1);

Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=250418=250417=250418=diff
==
--- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCall.cpp Thu Oct 15 10:29:40 2015
@@ -3038,12 +3038,6 @@ CodeGenFunction::EmitRuntimeCallOrInvoke
   return callSite;
 }
 
-llvm::CallSite
-CodeGenFunction::EmitCallOrInvoke(llvm::Value *Callee,
-  const Twine ) {
-  return EmitCallOrInvoke(Callee, None, Name);
-}
-
 /// Emits a call or invoke instruction to the given function, depending
 /// on the current state of the EH stack.
 llvm::CallSite

Modified: cfe/trunk/lib/CodeGen/CGCleanup.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCleanup.cpp?rev=250418=250417=250418=diff
==
--- cfe/trunk/lib/CodeGen/CGCleanup.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCleanup.cpp Thu Oct 15 10:29:40 2015
@@ -167,23 +167,6 @@ EHScopeStack::getInnermostActiveNormalCl
   return stable_end();
 }
 
-EHScopeStack::stable_iterator EHScopeStack::getInnermostActiveEHScope() const {
-  for (stable_iterator si = getInnermostEHScope(), se = stable_end();
- si != se; ) {
-// Skip over inactive cleanups.
-EHCleanupScope *cleanup = dyn_cast(&*find(si));
-if (cleanup && !cleanup->isActive()) {
-  si = cleanup->getEnclosingEHScope();
-  continue;
-}
-
-// All other scopes are always active.
-return si;
-  }
-
-  return stable_end();
-}
-
 
 void *EHScopeStack::pushCleanup(CleanupKind Kind, size_t Size) {
   char *Buffer = allocate(EHCleanupScope::getSizeForCleanupSize(Size));

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=250418=250417=250418=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Thu Oct 15 10:29:40 2015
@@ -2159,30 +2159,6 @@ llvm::DIType *CGDebugInfo::getOrCreateTy
   return Res;
 }
 
-unsigned CGDebugInfo::Checksum(const ObjCInterfaceDecl *ID) {
-  // The assumption is that the number of ivars can only increase
-  // monotonically, so it is safe to just use their current number as
-  // a checksum.
-  unsigned Sum = 0;
-  for (const ObjCIvarDecl *Ivar = ID->all_declared_ivar_begin();
-   Ivar != nullptr; Ivar = Ivar->getNextIvar())
-++Sum;
-
-  return Sum;
-}
-
-ObjCInterfaceDecl *CGDebugInfo::getObjCInterfaceDecl(QualType Ty) {
-  switch (Ty->getTypeClass()) {
-  case Type::ObjCObjectPointer:
-return getObjCInterfaceDecl(
-cast(Ty)->getPointeeType());
-  case Type::ObjCInterface:
-return cast(Ty)->getDecl();
-  default:
-return nullptr;
-  }
-}
-
 llvm::DIModule *CGDebugInfo::getParentModuleOrNull(const Decl *D) {
   // A forward declaration inside a module header does not belong to the 
module.
   if (isa(D) && !cast(D)->getDefinition())

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.h?rev=250418=250417=250418=diff

Re: r250418 - [CodeGen] Remove dead code. NFC.

[Adrian Prantl via cfe-commits]

> On Oct 15, 2015, at 8:29 AM, Benjamin Kramer via cfe-commits 
>  wrote:
> 
> Author: d0k
> Date: Thu Oct 15 10:29:40 2015
> New Revision: 250418
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=250418=rev
> Log:
> [CodeGen] Remove dead code. NFC.
> 
> Modified:
>cfe/trunk/lib/CodeGen/CGBuiltin.cpp
>cfe/trunk/lib/CodeGen/CGCall.cpp
>cfe/trunk/lib/CodeGen/CGCleanup.cpp
>cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
>cfe/trunk/lib/CodeGen/CGDebugInfo.h
>cfe/trunk/lib/CodeGen/CGObjC.cpp
>cfe/trunk/lib/CodeGen/CGObjCMac.cpp
>cfe/trunk/lib/CodeGen/CGVTables.h
>cfe/trunk/lib/CodeGen/CodeGenABITypes.cpp
>cfe/trunk/lib/CodeGen/CodeGenFunction.h
>cfe/trunk/lib/CodeGen/CodeGenModule.cpp
>cfe/trunk/lib/CodeGen/CodeGenModule.h
>cfe/trunk/lib/CodeGen/CodeGenPGO.h
>cfe/trunk/lib/CodeGen/EHScopeStack.h
>cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
> 
> Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=250418=250417=250418=diff
> ==
> --- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Thu Oct 15 10:29:40 2015
> @@ -4106,15 +4106,6 @@ Value *CodeGenFunction::vectorWrapScalar
>   return Op;
> }
> 
> -Value *CodeGenFunction::vectorWrapScalar8(Value *Op) {
> -  llvm::Type *VTy = llvm::VectorType::get(Int8Ty, 8);
> -  Op = Builder.CreateBitCast(Op, Int8Ty);
> -  Value *V = UndefValue::get(VTy);
> -  llvm::Constant *CI = ConstantInt::get(SizeTy, 0);
> -  Op = Builder.CreateInsertElement(V, Op, CI);
> -  return Op;
> -}
> -
> Value *CodeGenFunction::EmitAArch64BuiltinExpr(unsigned BuiltinID,
>const CallExpr *E) {
>   unsigned HintID = static_cast(-1);
> 
> Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=250418=250417=250418=diff
> ==
> --- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGCall.cpp Thu Oct 15 10:29:40 2015
> @@ -3038,12 +3038,6 @@ CodeGenFunction::EmitRuntimeCallOrInvoke
>   return callSite;
> }
> 
> -llvm::CallSite
> -CodeGenFunction::EmitCallOrInvoke(llvm::Value *Callee,
> -  const Twine ) {
> -  return EmitCallOrInvoke(Callee, None, Name);
> -}
> -
> /// Emits a call or invoke instruction to the given function, depending
> /// on the current state of the EH stack.
> llvm::CallSite
> 
> Modified: cfe/trunk/lib/CodeGen/CGCleanup.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCleanup.cpp?rev=250418=250417=250418=diff
> ==
> --- cfe/trunk/lib/CodeGen/CGCleanup.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGCleanup.cpp Thu Oct 15 10:29:40 2015
> @@ -167,23 +167,6 @@ EHScopeStack::getInnermostActiveNormalCl
>   return stable_end();
> }
> 
> -EHScopeStack::stable_iterator EHScopeStack::getInnermostActiveEHScope() 
> const {
> -  for (stable_iterator si = getInnermostEHScope(), se = stable_end();
> - si != se; ) {
> -// Skip over inactive cleanups.
> -EHCleanupScope *cleanup = dyn_cast(&*find(si));
> -if (cleanup && !cleanup->isActive()) {
> -  si = cleanup->getEnclosingEHScope();
> -  continue;
> -}
> -
> -// All other scopes are always active.
> -return si;
> -  }
> -
> -  return stable_end();
> -}
> -
> 
> void *EHScopeStack::pushCleanup(CleanupKind Kind, size_t Size) {
>   char *Buffer = allocate(EHCleanupScope::getSizeForCleanupSize(Size));
> 
> Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=250418=250417=250418=diff
> ==
> --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Thu Oct 15 10:29:40 2015
> @@ -2159,30 +2159,6 @@ llvm::DIType *CGDebugInfo::getOrCreateTy
>   return Res;
> }
> 
> -unsigned CGDebugInfo::Checksum(const ObjCInterfaceDecl *ID) {
> -  // The assumption is that the number of ivars can only increase
> -  // monotonically, so it is safe to just use their current number as
> -  // a checksum.
> -  unsigned Sum = 0;
> -  for (const ObjCIvarDecl *Ivar = ID->all_declared_ivar_begin();
> -   Ivar != nullptr; Ivar = Ivar->getNextIvar())
> -++Sum;
> -
> -  return Sum;
> -}
> -
> -ObjCInterfaceDecl *CGDebugInfo::getObjCInterfaceDecl(QualType Ty) {
> -  switch (Ty->getTypeClass()) {
> -  case Type::ObjCObjectPointer:
> -return getObjCInterfaceDecl(
> -cast(Ty)->getPointeeType());
> -  case Type::ObjCInterface:
> -return cast(Ty)->getDecl();
> -  default:
> -return nullptr;
> -  }
> -}
> -
> 

Re: [PATCH] D11908: Clang support for -fthinlto.

[Teresa Johnson via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL250398: Clang support for -flto=thin. (authored by 
tejohnson).

Changed prior to commit:
  http://reviews.llvm.org/D11908?vs=36453=37478#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D11908

Files:
  cfe/trunk/include/clang/Driver/Driver.h
  cfe/trunk/include/clang/Driver/Options.td
  cfe/trunk/include/clang/Frontend/CodeGenOptions.def
  cfe/trunk/lib/CodeGen/BackendUtil.cpp
  cfe/trunk/lib/Driver/Driver.cpp
  cfe/trunk/lib/Driver/SanitizerArgs.cpp
  cfe/trunk/lib/Driver/Tools.cpp
  cfe/trunk/lib/Frontend/CompilerInvocation.cpp
  cfe/trunk/test/Driver/clang_f_opts.c
  cfe/trunk/test/Driver/lto.c
  cfe/trunk/test/Driver/thinlto.c
  cfe/trunk/test/Misc/thinlto.c

Index: cfe/trunk/include/clang/Driver/Options.td
===
--- cfe/trunk/include/clang/Driver/Options.td
+++ cfe/trunk/include/clang/Driver/Options.td
@@ -687,9 +687,12 @@
 def flat__namespace : Flag<["-"], "flat_namespace">;
 def flax_vector_conversions : Flag<["-"], "flax-vector-conversions">, Group;
 def flimited_precision_EQ : Joined<["-"], "flimited-precision=">, Group;
-def flto_EQ : Joined<["-"], "flto=">, Group;
-def flto : Flag<["-"], "flto">, Flags<[CC1Option]>, Group;
-def fno_lto : Flag<["-"], "fno-lto">, Group;
+def flto_EQ : Joined<["-"], "flto=">, Flags<[CC1Option]>, Group,
+  HelpText<"Set LTO mode to either 'full' or 'thin'">;
+def flto : Flag<["-"], "flto">, Flags<[CC1Option]>, Group,
+  HelpText<"Enable LTO in 'full' mode">;
+def fno_lto : Flag<["-"], "fno-lto">, Group,
+  HelpText<"Disable LTO mode (default)">;
 def fmacro_backtrace_limit_EQ : Joined<["-"], "fmacro-backtrace-limit=">,
 Group, Flags<[DriverOption, CoreOption]>;
 def fmerge_all_constants : Flag<["-"], "fmerge-all-constants">, Group;
Index: cfe/trunk/include/clang/Driver/Driver.h
===
--- cfe/trunk/include/clang/Driver/Driver.h
+++ cfe/trunk/include/clang/Driver/Driver.h
@@ -52,6 +52,14 @@
   class SanitizerArgs;
   class ToolChain;
 
+/// Describes the kind of LTO mode selected via -f(no-)?lto(=.*)? options.
+enum LTOKind {
+  LTOK_None,
+  LTOK_Full,
+  LTOK_Thin,
+  LTOK_Unknown
+};
+
 /// Driver - Encapsulate logic for constructing compilation processes
 /// from a set of gcc-driver-like command line arguments.
 class Driver {
@@ -74,6 +82,9 @@
 SaveTempsObj
   } SaveTemps;
 
+  /// LTO mode selected via -f(no-)?lto(=.*)? options.
+  LTOKind LTOMode;
+
 public:
   // Diag - Forwarding function for diagnostics.
   DiagnosticBuilder Diag(unsigned DiagID) const {
@@ -411,9 +422,17 @@
   /// handle this action.
   bool ShouldUseClangCompiler(const JobAction ) const;
 
-  bool IsUsingLTO(const llvm::opt::ArgList ) const;
+  /// Returns true if we are performing any kind of LTO.
+  bool isUsingLTO() const { return LTOMode != LTOK_None; }
+
+  /// Get the specific kind of LTO being performed.
+  LTOKind getLTOMode() const { return LTOMode; }
 
 private:
+  /// Parse the \p Args list for LTO options and record the type of LTO
+  /// compilation based on which -f(no-)?lto(=.*)? option occurs last.
+  void setLTOMode(const llvm::opt::ArgList );
+
   /// \brief Retrieves a ToolChain for a particular \p Target triple.
   ///
   /// Will cache ToolChains for the life of the driver object, and create them
Index: cfe/trunk/include/clang/Frontend/CodeGenOptions.def
===
--- cfe/trunk/include/clang/Frontend/CodeGenOptions.def
+++ cfe/trunk/include/clang/Frontend/CodeGenOptions.def
@@ -73,6 +73,8 @@
  ///< be generated.
 CODEGENOPT(PrepareForLTO , 1, 0) ///< Set when -flto is enabled on the
  ///< compile step.
+CODEGENOPT(EmitFunctionSummary, 1, 0) ///< Set when -flto=thin is enabled on the
+  ///< compile step.
 CODEGENOPT(MergeAllConstants , 1, 1) ///< Merge identical constants.
 CODEGENOPT(MergeFunctions, 1, 0) ///< Set when -fmerge-functions is enabled.
 CODEGENOPT(MSVolatile, 1, 0) ///< Set when /volatile:ms is enabled.
Index: cfe/trunk/test/Misc/thinlto.c
===
--- cfe/trunk/test/Misc/thinlto.c
+++ cfe/trunk/test/Misc/thinlto.c
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -flto=thin -emit-llvm-bc < %s | llvm-bcanalyzer -dump | FileCheck %s
+// CHECK:  %t.log
-// RUN: grep '2: compiler, {1}, ir' %t.log
-// RUN: grep '3: backend, {2}, lto-bc' %t.log
-
-// RUN: %clang -ccc-print-phases %s -flto 2> %t.log
-// RUN: grep '0: input, ".*lto.c", c' %t.log
-// RUN: grep '1: preprocessor, {0}, cpp-output' %t.log
-// RUN: grep '2: compiler, {1}, ir' %t.log
-// RUN: grep '3: backend, {2}, lto-bc' %t.log
-// RUN: grep '4: linker, {3}, image' %t.log
+// RUN: %clang -ccc-print-phases -c %s -flto 2> 

Re: [PATCH] D13516: Fix overlapping replacements in clang-tidy.

[Angel Garcia via cfe-commits]

angelgarcia added a comment.

I cannot find a way to make Daniel's idea work with equal intervals:

In this case, fix A can be applied because B is completely contained inside
it.
A: [a, b)[c, d)
B: [a, b)

This time, we should not apply anyone:
A: [a, b)
B: [a, b)

And here they both have to be discarded again, but for a different reason:
A:[a, b)[c, d)
B: [e, f)[a, b)

The problem is that we have three completely different situations that are
the same from the point of view of interval "[a, b)". The local situation
of individual intervals doesn't provide enough information.


http://reviews.llvm.org/D13516



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

r250402 - Revert "Clang support for -flto=thin." (bot failures)

[Teresa Johnson via cfe-commits]

Author: tejohnson
Date: Thu Oct 15 08:41:51 2015
New Revision: 250402

URL: http://llvm.org/viewvc/llvm-project?rev=250402=rev
Log:
Revert "Clang support for -flto=thin." (bot failures)

Rolling this back for now since there are a couple of bot failures on
the new tests I added, and I won't have a chance to look at them in detail
until later this afternoon. I think the new tests need some restrictions on
having the gold plugin available.

This reverts commit r250398.

Removed:
cfe/trunk/test/Driver/thinlto.c
cfe/trunk/test/Misc/thinlto.c
Modified:
cfe/trunk/include/clang/Driver/Driver.h
cfe/trunk/include/clang/Driver/Options.td
cfe/trunk/include/clang/Frontend/CodeGenOptions.def
cfe/trunk/lib/CodeGen/BackendUtil.cpp
cfe/trunk/lib/Driver/Driver.cpp
cfe/trunk/lib/Driver/SanitizerArgs.cpp
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/test/Driver/clang_f_opts.c
cfe/trunk/test/Driver/lto.c

Modified: cfe/trunk/include/clang/Driver/Driver.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Driver.h?rev=250402=250401=250402=diff
==
--- cfe/trunk/include/clang/Driver/Driver.h (original)
+++ cfe/trunk/include/clang/Driver/Driver.h Thu Oct 15 08:41:51 2015
@@ -52,14 +52,6 @@ namespace driver {
   class SanitizerArgs;
   class ToolChain;
 
-/// Describes the kind of LTO mode selected via -f(no-)?lto(=.*)? options.
-enum LTOKind {
-  LTOK_None,
-  LTOK_Full,
-  LTOK_Thin,
-  LTOK_Unknown
-};
-
 /// Driver - Encapsulate logic for constructing compilation processes
 /// from a set of gcc-driver-like command line arguments.
 class Driver {
@@ -82,9 +74,6 @@ class Driver {
 SaveTempsObj
   } SaveTemps;
 
-  /// LTO mode selected via -f(no-)?lto(=.*)? options.
-  LTOKind LTOMode;
-
 public:
   // Diag - Forwarding function for diagnostics.
   DiagnosticBuilder Diag(unsigned DiagID) const {
@@ -422,17 +411,9 @@ public:
   /// handle this action.
   bool ShouldUseClangCompiler(const JobAction ) const;
 
-  /// Returns true if we are performing any kind of LTO.
-  bool isUsingLTO() const { return LTOMode != LTOK_None; }
-
-  /// Get the specific kind of LTO being performed.
-  LTOKind getLTOMode() const { return LTOMode; }
+  bool IsUsingLTO(const llvm::opt::ArgList ) const;
 
 private:
-  /// Parse the \p Args list for LTO options and record the type of LTO
-  /// compilation based on which -f(no-)?lto(=.*)? option occurs last.
-  void setLTOMode(const llvm::opt::ArgList );
-
   /// \brief Retrieves a ToolChain for a particular \p Target triple.
   ///
   /// Will cache ToolChains for the life of the driver object, and create them

Modified: cfe/trunk/include/clang/Driver/Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=250402=250401=250402=diff
==
--- cfe/trunk/include/clang/Driver/Options.td (original)
+++ cfe/trunk/include/clang/Driver/Options.td Thu Oct 15 08:41:51 2015
@@ -687,12 +687,9 @@ def finstrument_functions : Flag<["-"],
 def flat__namespace : Flag<["-"], "flat_namespace">;
 def flax_vector_conversions : Flag<["-"], "flax-vector-conversions">, 
Group;
 def flimited_precision_EQ : Joined<["-"], "flimited-precision=">, 
Group;
-def flto_EQ : Joined<["-"], "flto=">, Flags<[CC1Option]>, Group,
-  HelpText<"Set LTO mode to either 'full' or 'thin'">;
-def flto : Flag<["-"], "flto">, Flags<[CC1Option]>, Group,
-  HelpText<"Enable LTO in 'full' mode">;
-def fno_lto : Flag<["-"], "fno-lto">, Group,
-  HelpText<"Disable LTO mode (default)">;
+def flto_EQ : Joined<["-"], "flto=">, 
Group;
+def flto : Flag<["-"], "flto">, Flags<[CC1Option]>, Group;
+def fno_lto : Flag<["-"], "fno-lto">, Group;
 def fmacro_backtrace_limit_EQ : Joined<["-"], "fmacro-backtrace-limit=">,
 Group, Flags<[DriverOption, 
CoreOption]>;
 def fmerge_all_constants : Flag<["-"], "fmerge-all-constants">, Group;

Modified: cfe/trunk/include/clang/Frontend/CodeGenOptions.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CodeGenOptions.def?rev=250402=250401=250402=diff
==
--- cfe/trunk/include/clang/Frontend/CodeGenOptions.def (original)
+++ cfe/trunk/include/clang/Frontend/CodeGenOptions.def Thu Oct 15 08:41:51 2015
@@ -73,8 +73,6 @@ CODEGENOPT(LessPreciseFPMAD  , 1, 0) ///
  ///< be generated.
 CODEGENOPT(PrepareForLTO , 1, 0) ///< Set when -flto is enabled on the
  ///< compile step.
-CODEGENOPT(EmitFunctionSummary, 1, 0) ///< Set when -flto=thin is enabled on 
the
-  ///< compile step.
 CODEGENOPT(MergeAllConstants , 1, 1) ///< Merge identical constants.
 CODEGENOPT(MergeFunctions, 1, 0) ///< 

Re: [PATCH] D13516: Fix overlapping replacements in clang-tidy.

[Angel Garcia via cfe-commits]

angelgarcia added a comment.

I implemented this, with the following addition: if several errors share
the same interval, I can still apply the biggest one that was not discarded
during the sweep. This way, the first example would work and in the two
other examples it would just apply a random one, as you suggested. But I
found a different case that also fails:
A: [a, b)[c,d)
B: [e, f) such that e < a, b < f < c.

In this case it just discards A. This is not incorrect (as long as we don't
apply both, everything is OK), but it gets away from the idea of "if two
fixes overlap, discard both", which is what Manuel said when I started
this. I don't think that changing that idea is a problem, but right now the
behavior of the tool is so diffuse that maintaining and testing it would be
a bit painful. Also, if we want to allow applying one of the fixes when
they overlap, we have a different problem, it might be better just to start
from scratch and think about how to solve that problem.


http://reviews.llvm.org/D13516



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

Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain

[Filipe Cabecinhas via cfe-commits]

Hi Katya,

On Thu, Oct 15, 2015 at 2:01 AM, Romanova, Katya <
katya_roman...@playstation.sony.com> wrote:

> Filipe,
>
> I have one question regarding the change in debug-option.c that you made
> to get the builds green again… (r250294).
>
>
>
> Basically you changed the generic run line that used to test the drivers
> for every single platform
>
> // RUN: %clang -### -g %s 2>&1 | FileCheck -check-prefix=CI %s
>
>
>
> into the run line that tests x86_64 drivers only.
>
> // RUN: %clang -### -g -target x86_64-unknown-unknown %s 2>&1 \
>
> // | FileCheck -check-prefix=CI %s
>
>
>
> By making this change, we reduced driver coverage for the other platforms,
> e.g. AMD.  This run line will continue to pass for AMD irrespective of
> whether the AMD driver enabled or disabled emitting column information by
> default. I suspect that **non**-x86_64 developers won't be happy that we
> reduced their drivers’ test coverage without letting them know.
>

>
> Is there a better way to address this issue?
>

As far as I can tell, only the PS4 differs from the default in column info:
  // PS4 defaults to no column info
  if (Args.hasFlag(options::OPT_gcolumn_info, options::OPT_gno_column_info,
   /*Default=*/ !IsPS4CPU))
CmdArgs.push_back("-dwarf-column-info");

There are practically no other mentions of "column.?info" (case-insensitive
regex) in the clang driver. And almost no other mentions in clang, except
for actually emitting if the setting is on.

I think the platform that deviates from the default should add their tests,
but also make the tests that assumed everyone had the same default still
pass. This will force us to hard-code a triple, since we can't test every
other triple we can use in clang. I ended up using x86_64, because it was
already used in the file anyway. And I tend to use "unknown-unknown" for
vendor and OS, since those should get us to the "default" handling,
whatever that is.

>From what I understand, it’s impossible now to execute a specific RUN line
> for all the platforms, except platform . However, it’s easy to do it
> for the whole file (XFAIL: ). Does anyone know how hard it would be to
> expand lit functionality to do XFAIL:  for a block of RUN lines in a
> file (e.g. XFAIL : begin:  …. XFAIL : end : ? Or, even a simpler
> approach: force XFAIL to take effect only for the RUN lines that follow
> XFAIL line. It will definitely add much more power/flexibility to FAIL
> functionality in lit. It might also reduce test code duplication. What do
> you think?
>
Most tests are very generic and have to do with what clang supports
"everywhere". The driver has some special cases, especially due to the
default triple, but I'm not sure it's a problem big enough to warrant doing
all that work. I would be ok with it, but don't see a huge benefit coming
out of there.

But for now (for our specific problem)  maybe it’s better to remove the run
> lines that work differently for PS4 and for the rest of the world from
> debug_options.c  file and place them into a ps4 specific file (e.g.
> ps4-Gcolumn-info.c) and into non-ps4 generic file (e.g gcolumn-info.c) and
> make gcolumn-info.c to XFAIL for PS4. We could do this extraction for
> gcolumn_info, debug_aranges, and anything else that is different for PS4
> and everyone else,
>
Splitting the file and adding complementary XFAILs would bring up
additional problems and maintenance burden.

We would have to copy over all of the tests from debug_options.c that we
still want to do on the PS4 (at the very least all the generic ones).
Whenever something changed, people would have to change both files in the
same way.

And since we're the only ones that diverge from the "default" and we're
testing the default and our special case, I don't think there is a problem
with the test.

 Filipe

Katya.
>
>
>
>
>
> *From:* fil...@gmail.com [mailto:fil...@gmail.com] *On Behalf Of *Filipe
> Cabecinhas
> *Sent:* Wednesday, October 14, 2015 6:11 AM
> *To:* Romanova, Katya
> *Cc:* Sean Silva; Eric Christopher;
> reviews+d13482+public+a1a9627af638c...@reviews.llvm.org; Alex Rosenberg;
> Robinson, Paul; Jonathan Roelofs; Bedwell, Greg;
> pierregoussea...@gmail.com; Anton Korobeynikov; Takumi NAKAMURA;
> cfe-commits
>
> *Subject:* Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain
>
>
>
> Hi all,
>
>
>
> I have harnessed the powers of time zones and did the last tweak we needed
> to get it comitted.
>
> It's still going through some bots, but I don't foresee big problems. The
> fast bots liked it.
>
>
>
> Thanks to everyone that reviewed it and worked on it!
>
>
>
>   Filipe
>
>
>
> On Wed, Oct 14, 2015 at 8:54 AM, Romanova, Katya <
> katya_roman...@playstation.sony.com> wrote:
>
> Hi Sean,
>
>
>
> I don’t think that the whole patch should have been reverted. There were
> much easier way to make the PS4 bot green. A single test could have been
> marked as “XFAIL: ps4” for a few hours until a better solution is
> implemented. Reverting this huge 

r250403 - Tweak to make clang/test/Driver/ps4-linker-win.c less sinsitive of DLL path.

[NAKAMURA Takumi via cfe-commits]

Author: chapuni
Date: Thu Oct 15 08:51:13 2015
New Revision: 250403

URL: http://llvm.org/viewvc/llvm-project?rev=250403=rev
Log:
Tweak to make clang/test/Driver/ps4-linker-win.c less sinsitive of DLL path.

  - On mingw-w64, libstdc++-6.dll is used for clang.exe. The DLL might not be 
in Windows' system directory.
  - With --enable-shared, DLLs might be in ${CMAKE_BINARY_DIR}/bin.

I understand this test confirms that appropriate name of executable can be 
found on %PATH%.
Therefore I added "Output\\" before each expression.

FIXME: The output directory %T is hardcoded like "Output\\ps4-ld.exe".

Modified:
cfe/trunk/test/Driver/ps4-linker-win.c
cfe/trunk/test/lit.cfg

Modified: cfe/trunk/test/Driver/ps4-linker-win.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/ps4-linker-win.c?rev=250403=250402=250403=diff
==
--- cfe/trunk/test/Driver/ps4-linker-win.c (original)
+++ cfe/trunk/test/Driver/ps4-linker-win.c Thu Oct 15 08:51:13 2015
@@ -10,17 +10,18 @@
 // RUN: touch %T/ps4-ld.exe
 // RUN: touch %T/ps4-ld.gold.exe
 
-// RUN: env "PATH=%T" %clang -target x86_64-scei-ps4  %s -fuse-ld=gold -### 
2>&1 \
+// RUN: env "PATH=%T;%PATH%" %clang -target x86_64-scei-ps4  %s -fuse-ld=gold 
-### 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-PS4-GOLD %s
-// RUN: env "PATH=%T" %clang -target x86_64-scei-ps4  %s -shared -### 2>&1 \
+// RUN: env "PATH=%T;%PATH%" %clang -target x86_64-scei-ps4  %s -shared -### 
2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-PS4-GOLD %s
 
-// RUN: env "PATH=%T" %clang -target x86_64-scei-ps4  %s -### 2>&1 \
+// RUN: env "PATH=%T;%PATH%" %clang -target x86_64-scei-ps4  %s -### 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-PS4-LINKER %s
-// RUN: env "PATH=%T" %clang -target x86_64-scei-ps4  %s -fuse-ld=ps4 -### 
2>&1 \
+// RUN: env "PATH=%T;%PATH%" %clang -target x86_64-scei-ps4  %s -fuse-ld=ps4 
-### 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-PS4-LINKER %s
-// RUN: env "PATH=%T" %clang -target x86_64-scei-ps4  %s -shared \
+// RUN: env "PATH=%T;%PATH%" %clang -target x86_64-scei-ps4  %s -shared \
 // RUN: -fuse-ld=ps4 -### 2>&1 | FileCheck --check-prefix=CHECK-PS4-LINKER 
%s
 
-// CHECK-PS4-GOLD: ps4-ld.gold.exe
-// CHECK-PS4-LINKER: ps4-ld.exe
+// FIXME: "Output\\" is hardcoded part of %T.
+// CHECK-PS4-GOLD: Output\\ps4-ld.gold.exe"
+// CHECK-PS4-LINKER: Output\\ps4-ld.exe"

Modified: cfe/trunk/test/lit.cfg
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/lit.cfg?rev=250403=250402=250403=diff
==
--- cfe/trunk/test/lit.cfg (original)
+++ cfe/trunk/test/lit.cfg Thu Oct 15 08:51:13 2015
@@ -206,6 +206,7 @@ if has_plugins and config.llvm_plugin_ex
 
 config.substitutions.append( ('%llvmshlibdir', config.llvm_shlib_dir) )
 config.substitutions.append( ('%pluginext', config.llvm_plugin_ext) )
+config.substitutions.append( ('%PATH%', config.environment['PATH']) )
 
 if config.clang_examples:
 config.available_features.add('examples')


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

Re: [PATCH] D13731: [RFC][Analyzer] Supporting function attributes in .model files.

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

xazax.hun added reviewers: krememek, zaks.anna, dcoughlin.
xazax.hun added a comment.

Hi!

I have some high level questions and notes about this patch.

I implemented the function modelling as a Google Summer of Code project and Ted 
Kremenek was my mentor. I am happy that you found an useful application of the 
function modeling system, and I think, in general, it is a good idea to be able 
to store attributes for the modelled functions. However I am a bit surprised, 
when I saw this patch. The main reason is that, models lack a lot of 
functionality right now.

Main missing features:

- Ability to specify multiple model paths similar to how header include paths 
are specified.
- Support for methods, namespaces, overloaded functions.

Did you find the feature useful despite those limitations? I am interested to 
improve the situation in the future, unfortunately I find very little time to 
work on this area recently, but I do welcome every changes.

I have two comments before I start to review the patch itself. Right now this 
patch contains two modifications. One for the .model files and one for a 
checker. I think it would be better to separate these two changes into two 
separate patches. If the motivation behind the merge of those patches is that, 
you want to test a feature you implemented in .model files, than I think there 
are other checker that are using attributes, so I think you should be able to 
provide a test case with the two changes separated. (For example using the 
nonnull parameter checker.)

The other comment is that, the .model files are intended to work in a way, that 
checkers should not be able utilize the information whether some data is coming 
from a model file or the analyzed translation unit. In fact, this is an 
abstraction, that makes it possible to develop the checkers and the modelling 
mechanism independently. With you patch, the checker should observe the model 
declaration explicitly. I think, a better design would somehow merge the 
attributes that are coming from the original translation unit with the 
attributes coming from the model files, and expore that set of attributes. This 
way the checker could not tell what the source of the information is. 
Unfortunately I do not know what would be the best way to enfore this, since 
the checkers can just observe the AST of the original translation unit and 
bypassing the models.


http://reviews.llvm.org/D13731



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

Re: [libcxx] r250256 - Workaround -pedantic flag added by LLVM

[Evgenii Stepanov via cfe-commits]

Guess what this does to the -Wno-pedantic flag added by MSan? :)

On Tue, Oct 13, 2015 at 4:56 PM, Eric Fiselier via cfe-commits
 wrote:
> Author: ericwf
> Date: Tue Oct 13 18:56:33 2015
> New Revision: 250256
>
> URL: http://llvm.org/viewvc/llvm-project?rev=250256=rev
> Log:
> Workaround -pedantic flag added by LLVM
>
> Modified:
> libcxx/trunk/CMakeLists.txt
>
> Modified: libcxx/trunk/CMakeLists.txt
> URL: 
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=250256=250255=250256=diff
> ==
> --- libcxx/trunk/CMakeLists.txt (original)
> +++ libcxx/trunk/CMakeLists.txt Tue Oct 13 18:56:33 2015
> @@ -198,6 +198,10 @@ include(HandleLibcxxFlags)
>  remove_flags(-DNDEBUG -UNDEBUG -D_DEBUG
>   -stdlib=libc++ -stdlib=libstdc++ -lc++abi -m32)
>
> +# FIXME(EricWF): See the FIXME on LIBCXX_ENABLE_PEDANTIC.
> +# Remove the -pedantic flag provided by LLVM.
> +remove_flags(-pedantic)
> +
>  # Required flags 
> ==
>  add_compile_flags_if_supported(-std=c++11)
>  if (NOT MSVC AND NOT LIBCXX_SUPPORTS_STD_EQ_CXX11_FLAG)
>
>
> ___
> 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

r250448 - Add the minimum target features that these tests depend upon.

[Eric Christopher via cfe-commits]

Author: echristo
Date: Thu Oct 15 15:04:40 2015
New Revision: 250448

URL: http://llvm.org/viewvc/llvm-project?rev=250448=rev
Log:
Add the minimum target features that these tests depend upon.

Modified:
cfe/trunk/test/CodeGen/adc-builtins.c
cfe/trunk/test/CodeGen/builtins-x86.c

Modified: cfe/trunk/test/CodeGen/adc-builtins.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/adc-builtins.c?rev=250448=250447=250448=diff
==
--- cfe/trunk/test/CodeGen/adc-builtins.c (original)
+++ cfe/trunk/test/CodeGen/adc-builtins.c Thu Oct 15 15:04:40 2015
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -triple x86_64-unknown-unknown -emit-llvm -o - %s | 
FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-feature +adx 
-emit-llvm -o - %s | FileCheck %s
 
 #define __MM_MALLOC_H
 

Modified: cfe/trunk/test/CodeGen/builtins-x86.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/builtins-x86.c?rev=250448=250447=250448=diff
==
--- cfe/trunk/test/CodeGen/builtins-x86.c (original)
+++ cfe/trunk/test/CodeGen/builtins-x86.c Thu Oct 15 15:04:40 2015
@@ -1,5 +1,5 @@
-// RUN: %clang_cc1 -DUSE_64 -triple x86_64-unknown-unknown -emit-llvm -o %t %s
-// RUN: %clang_cc1 -DUSE_ALL -triple x86_64-unknown-unknown -fsyntax-only -o 
%t %s
+// RUN: %clang_cc1 -DUSE_64 -triple x86_64-unknown-unknown -target-feature 
+avx -target-feature +xsaveopt -target-feature +xsaves -target-feature +xsavec 
-emit-llvm -o %t %s
+// RUN: %clang_cc1 -DUSE_ALL -triple x86_64-unknown-unknown -target-feature 
+avx -target-feature +xsaveopt -target-feature +xsaves -target-feature +xsavec 
-fsyntax-only -o %t %s
 
 #ifdef USE_ALL
 #define USE_3DNOW


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

r250449 - The target-feature command line option doesn't take a comma delimited

[Eric Christopher via cfe-commits]

Author: echristo
Date: Thu Oct 15 15:04:42 2015
New Revision: 250449

URL: http://llvm.org/viewvc/llvm-project?rev=250449=rev
Log:
The target-feature command line option doesn't take a comma delimited
string, so split them into multiple options.

Modified:
cfe/trunk/test/CodeGen/x86_32-xsave.c
cfe/trunk/test/CodeGen/x86_64-xsave.c

Modified: cfe/trunk/test/CodeGen/x86_32-xsave.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/x86_32-xsave.c?rev=250449=250448=250449=diff
==
--- cfe/trunk/test/CodeGen/x86_32-xsave.c (original)
+++ cfe/trunk/test/CodeGen/x86_32-xsave.c Thu Oct 15 15:04:42 2015
@@ -1,14 +1,14 @@
 // RUN: %clang_cc1 %s -DTEST_XSAVE -O0 -triple=i686-unknown-unknown 
-target-feature +xsave -emit-llvm -o - -Werror | FileCheck %s 
--check-prefix=XSAVE
 // RUN: %clang_cc1 %s -DTEST_XSAVE -O0 -triple=i686-unknown-unknown 
-target-feature +xsave -fno-signed-char -emit-llvm -o - -Werror | FileCheck %s 
--check-prefix=XSAVE
 
-// RUN: %clang_cc1 %s -DTEST_XSAVEOPT -O0 -triple=i686-unknown-unknown 
-target-feature +xsave,+xsaveopt -emit-llvm -o - -Werror | FileCheck %s 
--check-prefix=XSAVEOPT
-// RUN: %clang_cc1 %s -DTEST_XSAVEOPT -O0 -triple=i686-unknown-unknown 
-target-feature +xsave,+xsaveopt -fno-signed-char -emit-llvm -o - -Werror | 
FileCheck %s --check-prefix=XSAVEOPT
+// RUN: %clang_cc1 %s -DTEST_XSAVEOPT -O0 -triple=i686-unknown-unknown 
-target-feature +xsave -target-feature +xsaveopt -emit-llvm -o - -Werror | 
FileCheck %s --check-prefix=XSAVEOPT
+// RUN: %clang_cc1 %s -DTEST_XSAVEOPT -O0 -triple=i686-unknown-unknown 
-target-feature +xsave -target-feature +xsaveopt -fno-signed-char -emit-llvm -o 
- -Werror | FileCheck %s --check-prefix=XSAVEOPT
 
-// RUN: %clang_cc1 %s -DTEST_XSAVEC -O0 -triple=i686-unknown-unknown 
-target-feature +xsave,+xsavec -emit-llvm -o - -Werror | FileCheck %s 
--check-prefix=XSAVEC
-// RUN: %clang_cc1 %s -DTEST_XSAVEC -O0 -triple=i686-unknown-unknown 
-target-feature +xsave,+xsavec -fno-signed-char -emit-llvm -o - -Werror | 
FileCheck %s --check-prefix=XSAVEC
+// RUN: %clang_cc1 %s -DTEST_XSAVEC -O0 -triple=i686-unknown-unknown 
-target-feature +xsave -target-feature +xsavec -emit-llvm -o - -Werror | 
FileCheck %s --check-prefix=XSAVEC
+// RUN: %clang_cc1 %s -DTEST_XSAVEC -O0 -triple=i686-unknown-unknown 
-target-feature +xsave -target-feature +xsavec -fno-signed-char -emit-llvm -o - 
-Werror | FileCheck %s --check-prefix=XSAVEC
 
-// RUN: %clang_cc1 %s -DTEST_XSAVES -O0 -triple=i686-unknown-unknown 
-target-feature +xsave,+xsaves -emit-llvm -o - -Werror | FileCheck %s 
--check-prefix=XSAVES
-// RUN: %clang_cc1 %s -DTEST_XSAVES -O0 -triple=i686-unknown-unknown 
-target-feature +xsave,+xsaves -fno-signed-char -emit-llvm -o - -Werror | 
FileCheck %s --check-prefix=XSAVES
+// RUN: %clang_cc1 %s -DTEST_XSAVES -O0 -triple=i686-unknown-unknown 
-target-feature +xsave -target-feature +xsaves -emit-llvm -o - -Werror | 
FileCheck %s --check-prefix=XSAVES
+// RUN: %clang_cc1 %s -DTEST_XSAVES -O0 -triple=i686-unknown-unknown 
-target-feature +xsave -target-feature +xsaves -fno-signed-char -emit-llvm -o - 
-Werror | FileCheck %s --check-prefix=XSAVES
 
 void test() {
   unsigned long long tmp_ULLi;

Modified: cfe/trunk/test/CodeGen/x86_64-xsave.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/x86_64-xsave.c?rev=250449=250448=250449=diff
==
--- cfe/trunk/test/CodeGen/x86_64-xsave.c (original)
+++ cfe/trunk/test/CodeGen/x86_64-xsave.c Thu Oct 15 15:04:42 2015
@@ -1,14 +1,14 @@
 // RUN: %clang_cc1 %s -DTEST_XSAVE -O0 -triple=x86_64-unknown-unknown 
-target-feature +xsave -emit-llvm -o - -Werror | FileCheck %s 
--check-prefix=XSAVE
 // RUN: %clang_cc1 %s -DTEST_XSAVE -O0 -triple=x86_64-unknown-unknown 
-target-feature +xsave -fno-signed-char -emit-llvm -o - -Werror | FileCheck %s 
--check-prefix=XSAVE
 
-// RUN: %clang_cc1 %s -DTEST_XSAVEOPT -O0 -triple=x86_64-unknown-unknown 
-target-feature +xsave,+xsaveopt -emit-llvm -o - -Werror | FileCheck %s 
--check-prefix=XSAVEOPT
-// RUN: %clang_cc1 %s -DTEST_XSAVEOPT -O0 -triple=x86_64-unknown-unknown 
-target-feature +xsave,+xsaveopt -fno-signed-char -emit-llvm -o - -Werror | 
FileCheck %s --check-prefix=XSAVEOPT
+// RUN: %clang_cc1 %s -DTEST_XSAVEOPT -O0 -triple=x86_64-unknown-unknown 
-target-feature +xsave -target-feature +xsaveopt -emit-llvm -o - -Werror | 
FileCheck %s --check-prefix=XSAVEOPT
+// RUN: %clang_cc1 %s -DTEST_XSAVEOPT -O0 -triple=x86_64-unknown-unknown 
-target-feature +xsave -target-feature +xsaveopt -fno-signed-char -emit-llvm -o 
- -Werror | FileCheck %s --check-prefix=XSAVEOPT
 
-// RUN: %clang_cc1 %s -DTEST_XSAVEC -O0 -triple=x86_64-unknown-unknown 
-target-feature +xsave,+xsavec -emit-llvm -o - -Werror | FileCheck %s 
--check-prefix=XSAVEC
-// RUN: %clang_cc1 %s -DTEST_XSAVEC -O0 -triple=x86_64-unknown-unknown 

[PATCH] D13784: [clang-tidy] add check cppcoreguidelines-pro-type-union-access

[Matthias Gehre via cfe-commits]

mgehre created this revision.
mgehre added reviewers: alexfh, sbenza, bkramer, aaron.ballman.
mgehre added a subscriber: cfe-commits.

This check flags all access to members of unions. Passing unions as a
whole is not flagged.

Reading from a union member assumes that member was the last one
written, and writing to a union member assumes another member with a
nontrivial destructor had its destructor called. This is fragile because
it cannot generally be enforced to be safe in the language and so relies
on programmer discipline to get it right.

This rule is part of the "Type safety" profile of the C++ Core
Guidelines, see
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#-type7-avoid-accessing-members-of-raw-unions-prefer-variant-instead

http://reviews.llvm.org/D13784

Files:
  clang-tidy/cppcoreguidelines/CMakeLists.txt
  clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
  clang-tidy/cppcoreguidelines/ProTypeUnionAccessCheck.cpp
  clang-tidy/cppcoreguidelines/ProTypeUnionAccessCheck.h
  docs/clang-tidy/checks/cppcoreguidelines-pro-type-union-access.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/cppcoreguidelines-pro-type-union-access.cpp

Index: test/clang-tidy/cppcoreguidelines-pro-type-union-access.cpp
===
--- /dev/null
+++ test/clang-tidy/cppcoreguidelines-pro-type-union-access.cpp
@@ -0,0 +1,41 @@
+// RUN: %python %S/check_clang_tidy.py %s cppcoreguidelines-pro-type-union-access %t
+
+union U {
+  bool union_member1;
+  char union_member2;
+} u;
+
+struct S {
+  int non_union_member;
+  union {
+bool union_member;
+  };
+  union {
+char union_member2;
+  } u;
+} s;
+
+
+void f(char);
+void f2(U);
+void f3(U&);
+void f4(U*);
+
+void check()
+{
+  u.union_member1 = true;
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: do not access members of unions; use (boost::)variant instead [cppcoreguidelines-pro-type-union-access]
+  auto b = u.union_member2;
+  // CHECK-MESSAGES: :[[@LINE-1]]:14: warning: do not access members of unions; use (boost::)variant instead
+  auto a = _member;
+  // CHECK-MESSAGES: :[[@LINE-1]]:15: warning: do not access members of unions; use (boost::)variant instead
+  f(s.u.union_member2);
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: do not access members of unions; use (boost::)variant instead
+
+  s.non_union_member = 2; // OK
+
+  U u2 = u; // OK
+  f2(u); // OK
+  f3(u); // OK
+  f4(); // OK
+}
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -8,6 +8,7 @@
cppcoreguidelines-pro-type-const-cast
cppcoreguidelines-pro-type-reinterpret-cast
cppcoreguidelines-pro-type-static-cast-downcast
+   cppcoreguidelines-pro-type-union-access
google-build-explicit-make-pair
google-build-namespaces
google-build-using-namespace
Index: docs/clang-tidy/checks/cppcoreguidelines-pro-type-union-access.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/cppcoreguidelines-pro-type-union-access.rst
@@ -0,0 +1,9 @@
+cppcoreguidelines-pro-type-union-access
+===
+
+This check flags all access to members of unions. Passing unions as a whole is not flagged.
+
+Reading from a union member assumes that member was the last one written, and writing to a union member assumes another member with a nontrivial destructor had its destructor called. This is fragile because it cannot generally be enforced to be safe in the language and so relies on programmer discipline to get it right.
+
+This rule is part of the "Type safety" profile of the C++ Core Guidelines, see
+https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#-type7-avoid-accessing-members-of-raw-unions-prefer-variant-instead
Index: clang-tidy/cppcoreguidelines/ProTypeUnionAccessCheck.h
===
--- /dev/null
+++ clang-tidy/cppcoreguidelines/ProTypeUnionAccessCheck.h
@@ -0,0 +1,35 @@
+//===--- ProTypeUnionAccessCheck.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_CPPCOREGUIDELINES_PRO_TYPE_UNION_ACCESS_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_CPPCOREGUIDELINES_PRO_TYPE_UNION_ACCESS_H
+
+#include "../ClangTidy.h"
+
+namespace clang {
+namespace tidy {
+
+/// This check flags all access to members of unions.
+/// Access to a union as a whole (e.g. passing to a function) is not flagged.
+///
+/// For the user-facing documentation see:
+/// 

[PATCH] D13785: [clang-tidy] add cert's VariadicFunctionDefCheck as cppcoreguidelines-pro-type-vararg-def

[Matthias Gehre via cfe-commits]

mgehre created this revision.
mgehre added reviewers: alexfh, sbenza, bkramer, aaron.ballman.
mgehre added a subscriber: cfe-commits.

Import the cert check for variadic function definitions into
cppcoreguidelines module to check part of
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#-type8-avoid-reading-from-varargs-or-passing-vararg-arguments-prefer-variadic-template-parameters-instead

http://reviews.llvm.org/D13785

Files:
  clang-tidy/cppcoreguidelines/CMakeLists.txt
  clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp

Index: clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
===
--- clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
+++ clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
@@ -10,6 +10,7 @@
 #include "../ClangTidy.h"
 #include "../ClangTidyModule.h"
 #include "../ClangTidyModuleRegistry.h"
+#include "../cert/VariadicFunctionDefCheck.h"
 #include "../misc/AssignOperatorSignatureCheck.h"
 #include "ProBoundsPointerArithmeticCheck.h"
 #include "ProTypeConstCastCheck.h"
@@ -28,6 +29,8 @@
 "cppcoreguidelines-pro-bounds-pointer-arithmetic");
 CheckFactories.registerCheck(
 "cppcoreguidelines-pro-type-const-cast");
+CheckFactories.registerCheck(
+"cppcoreguidelines-pro-type-vararg-def");
 CheckFactories.registerCheck(
 "cppcoreguidelines-pro-type-reinterpret-cast");
 CheckFactories.registerCheck(
Index: clang-tidy/cppcoreguidelines/CMakeLists.txt
===
--- clang-tidy/cppcoreguidelines/CMakeLists.txt
+++ clang-tidy/cppcoreguidelines/CMakeLists.txt
@@ -13,6 +13,7 @@
   clangBasic
   clangLex
   clangTidy
+  clangTidyCERTModule
   clangTidyMiscModule
   clangTidyUtils
   clangTooling


Index: clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
===
--- clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
+++ clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
@@ -10,6 +10,7 @@
 #include "../ClangTidy.h"
 #include "../ClangTidyModule.h"
 #include "../ClangTidyModuleRegistry.h"
+#include "../cert/VariadicFunctionDefCheck.h"
 #include "../misc/AssignOperatorSignatureCheck.h"
 #include "ProBoundsPointerArithmeticCheck.h"
 #include "ProTypeConstCastCheck.h"
@@ -28,6 +29,8 @@
 "cppcoreguidelines-pro-bounds-pointer-arithmetic");
 CheckFactories.registerCheck(
 "cppcoreguidelines-pro-type-const-cast");
+CheckFactories.registerCheck(
+"cppcoreguidelines-pro-type-vararg-def");
 CheckFactories.registerCheck(
 "cppcoreguidelines-pro-type-reinterpret-cast");
 CheckFactories.registerCheck(
Index: clang-tidy/cppcoreguidelines/CMakeLists.txt
===
--- clang-tidy/cppcoreguidelines/CMakeLists.txt
+++ clang-tidy/cppcoreguidelines/CMakeLists.txt
@@ -13,6 +13,7 @@
   clangBasic
   clangLex
   clangTidy
+  clangTidyCERTModule
   clangTidyMiscModule
   clangTidyUtils
   clangTooling
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Adrian Prantl via cfe-commits]

> On Oct 15, 2015, at 1:42 PM, Richard Smith  wrote:
> 
> On Thu, Oct 15, 2015 at 11:14 AM, Adrian Prantl  > wrote:
> 
>> On Oct 14, 2015, at 5:07 PM, Richard Smith > > wrote:
>> 
>> Ack, there are non-modular headers in the Darwin module. =( I seem to recall 
>> that they're not version-locked to your compiler, so we've got to support 
>> them as-is?
>> 
>> If we can't turn on local submodule visibility, then we need a module map 
>> for libc++ that covers all of its headers. I'll look into pruning the 
>> include path when building a module from an implicitly-loaded module map.
> 
> The attached patch implements this in the most hacky way; with it I can 
> successfully compile the first few hundred files of LLVM.
> 
> Great, it looks like this plan should work then. What failure do you 
> eventually hit? Does it look related to these  changes?

So far I fixed 250446  and 250459 which were both just missing include files. 
I’m puzzled by 250459 though, as there is nothing Darwin-specific about the 
change. I’ll keep iterating and will let you know if there are any 
libc++-related problems.

> 
> I'm working on a more refined version of the approach I described earlier; 
> I'll mail you a patch to test when I have it finished.

That sounds great.

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

r250460 - Add llvm-bcanalyzer to list of clang test dependences

[Teresa Johnson via cfe-commits]

Author: tejohnson
Date: Thu Oct 15 16:06:53 2015
New Revision: 250460

URL: http://llvm.org/viewvc/llvm-project?rev=250460=rev
Log:
Add llvm-bcanalyzer to list of clang test dependences

This addresses a bot failure from r250455, since new Misc/thinlto.c
test uses it.

Modified:
cfe/trunk/test/CMakeLists.txt

Modified: cfe/trunk/test/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CMakeLists.txt?rev=250460=250459=250460=diff
==
--- cfe/trunk/test/CMakeLists.txt (original)
+++ cfe/trunk/test/CMakeLists.txt Thu Oct 15 16:06:53 2015
@@ -59,7 +59,7 @@ if( NOT CLANG_BUILT_STANDALONE )
   list(APPEND CLANG_TEST_DEPS
 llvm-config
 FileCheck count not
-llc opt llvm-symbolizer llvm-profdata llvm-objdump llvm-readobj
+llc opt llvm-symbolizer llvm-profdata llvm-objdump llvm-readobj 
llvm-bcanalyzer
 )
 endif()
 


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

Re: [libcxx] r249738 - Split out of .

[Richard Smith via cfe-commits]

On Thu, Oct 15, 2015 at 2:57 PM, Adrian Prantl via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Oct 15, 2015, at 2:51 PM, Alex Rosenberg  wrote:
>
> On Oct 15, 2015, at 2:20 PM, Adrian Prantl via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>
> On Oct 15, 2015, at 2:09 PM, Adrian Prantl via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>
> On Oct 15, 2015, at 1:42 PM, Richard Smith  wrote:
>
> On Thu, Oct 15, 2015 at 11:14 AM, Adrian Prantl  wrote:
>
>>
>> On Oct 14, 2015, at 5:07 PM, Richard Smith  wrote:
>>
>> Ack, there are non-modular headers in the Darwin module. =( I seem to
>> recall that they're not version-locked to your compiler, so we've got to
>> support them as-is?
>>
>> If we can't turn on local submodule visibility, then we need a module map
>> for libc++ that covers all of its headers. I'll look into pruning the
>> include path when building a module from an implicitly-loaded module map.
>>
>>
>> The attached patch implements this in the most hacky way; with it I can
>> successfully compile the first few hundred files of LLVM.
>>
>
> Great, it looks like this plan should work then. What failure do you
> eventually hit? Does it look related to these  changes?
>
>
> So far I fixed 250446  and 250459 which were both just missing include
> files. I’m puzzled by 250459 though, as there is nothing Darwin-specific
> about the change. I’ll keep iterating and will let you know if there are
> any libc++-related problems.
>
>
> I'm working on a more refined version of the approach I described earlier;
> I'll mail you a patch to test when I have it finished.
>
>
> That sounds great.
>
> thanks,
> adrian
>
>
> Here’s a weird one:
>
> *../lib/Transforms/Scalar/ScalarReplAggregates.cpp:1031:6: **error: **'SROA'
> is not a class, namespace, or enumeration*
> bool SROA::runOnFunction(Function ) {
> * ^*
> *../lib/Transforms/Scalar/ScalarReplAggregates.cpp:1031:6: **error: 
> **reference
> to 'SROA' is ambiguous*
> *../include/llvm/Transforms/Scalar/SROA.h:54:7: note: *candidate found by
> name lookup is 'llvm::SROA'
> class SROA {
> *  ^*
> *../lib/Transforms/Scalar/ScalarReplAggregates.cpp:63:10: note: *candidate
> found by name lookup is '(anonymous namespace)::SROA'
>   struct SROA : public FunctionPass {
> * ^*
>
> this doesn’t look Darwin-specific at all. Assuming that the Linux module
> build works, why am I seeing this?
>
>
> The Linux bot has the same problem:
> http://lab.llvm.org:8011/builders/clang-x86_64-linux-selfhost-modules/builds/7331/steps/compile.llvm.stage2/logs/stdio
>
>
> Oh :-) That bot does not look very happy:
>
> http://lab.llvm.org:8011/builders/clang-x86_64-linux-selfhost-modules?numbuilds=1000
>

Investigating that is ~third on my todo list at the moment. I suspect this
is a Clang bug; I don't know why we have two different SROA passes, but
ScalarReplAggregates.cpp doesn't make SROA.h visible, so the two names
should not conflict.


> What’s the appropriate solution, renaming the struct ::SROA in the
> anonymous namespace to something else?
>
> — adrian
>
> ___
> 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

r250475 - Mark this test as requiring and x86 registered target.

[Eric Christopher via cfe-commits]

Author: echristo
Date: Thu Oct 15 19:14:36 2015
New Revision: 250475

URL: http://llvm.org/viewvc/llvm-project?rev=250475=rev
Log:
Mark this test as requiring and x86 registered target.

Modified:
cfe/trunk/test/CodeGen/target-builtin-noerror.c

Modified: cfe/trunk/test/CodeGen/target-builtin-noerror.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/target-builtin-noerror.c?rev=250475=250474=250475=diff
==
--- cfe/trunk/test/CodeGen/target-builtin-noerror.c (original)
+++ cfe/trunk/test/CodeGen/target-builtin-noerror.c Thu Oct 15 19:14:36 2015
@@ -1,3 +1,4 @@
+// REQUIRES: x86-registered-target
 // RUN: %clang_cc1 %s -triple=x86_64-linux-gnu -S -o -
 #define __MM_MALLOC_H
 


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

Re: [PATCH] D13357: [Concepts] Diagnose when 'concept' is specified on a specialization

[Faisal Vali via cfe-commits]

faisalv added inline comments.


Comment at: include/clang/AST/Decl.h:1577
@@ -1576,2 +1576,3 @@
   bool IsConstexpr : 1;
+  bool IsConcept : 1;
 

My inclination would have been to add this bit to FunctionTemplateDecl, instead 
of to every FunctionDecl - since not every kind of FunctionDecl can be a 
concept ...  My first instinct would have been to add an enum to TemplateKind, 
and then forward isConcept() to check if we are a template and if so, through 
it, if concept is specified?  

But I suppose that adds more complexity, and you trade space for speed - For my 
own edification, could I ask you or Richard to comment on the cons of that 
approach - and why the current approach is preferred? (i.e. simplicity over 
complexity or space over time etc.)


http://reviews.llvm.org/D13357



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

Re: [libcxx] r250469 - [libcxx] Make libc++.so a linker script by default on most platforms.

[Saleem Abdulrasool via cfe-commits]

On Thu, Oct 15, 2015 at 3:41 PM, Eric Fiselier via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: ericwf
> Date: Thu Oct 15 17:41:51 2015
> New Revision: 250469
>
> URL: http://llvm.org/viewvc/llvm-project?rev=250469=rev
> Log:
> [libcxx] Make libc++.so a linker script by default on most platforms.
>

I think that this probably is release-note-worthy.


> Summary:
> This patch turns on `LIBCXX_ENABLE_ABI_LINKER_SCRIPT` by default whenever
> `LLVM_HAVE_LINK_VERSION_SCRIPT` is ON. This turns out to be whenever:
>
> 1. WIN32 is not defined.
> 2 UNIX is defined.
> 3. APPLE is not defined.
>
> While `LLVM_HAVE_LINK_VERSION_SCRIPT` is meant to reflect exactly what we
> are asking I think it's close enough.
>
> After committing this patch Linux users will no longer have to use
> "-lc++abi" explicitly!
>
>
>
>
> Reviewers: mclow.lists, danalbert, compnerd, jroelofs
>
> Subscribers: emaste, rengolin, cbergstrom, cfe-commits
>
> Differential Revision: http://reviews.llvm.org/D13739
>
> Modified:
> libcxx/trunk/CMakeLists.txt
> libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake
> libcxx/trunk/docs/BuildingLibcxx.rst
> libcxx/trunk/docs/UsingLibcxx.rst
>
> Modified: libcxx/trunk/CMakeLists.txt
> URL:
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=250469=250468=250469=diff
>
> ==
> --- libcxx/trunk/CMakeLists.txt (original)
> +++ libcxx/trunk/CMakeLists.txt Thu Oct 15 17:41:51 2015
> @@ -67,12 +67,22 @@ set(LIBCXX_CXX_ABI "${LIBCXX_CXX_ABI}" C
>  set(CXXABIS none libcxxabi libcxxrt libstdc++ libsupc++)
>  set_property(CACHE LIBCXX_CXX_ABI PROPERTY STRINGS ;${CXXABIS})
>
> +# Use a static copy of the ABI library when linking libc++. This option
> +# cannot be used with LIBCXX_ENABLE_ABI_LINKER_SCRIPT.
>  option(LIBCXX_ENABLE_STATIC_ABI_LIBRARY "Statically link the ABI library"
> OFF)
>
>  # Generate and install a linker script inplace of libc++.so. The linker
> script
> -# will link libc++ to the correct ABI library.
> +# will link libc++ to the correct ABI library. This option is on by
> default
> +# On UNIX platforms other than Apple unless
> 'LIBCXX_ENABLE_STATIC_ABI_LIBRARY'
> +# is on.
> +set(ENABLE_LINKER_SCRIPT_DEFAULT_VALUE OFF)
> +if (LLVM_HAVE_LINK_VERSION_SCRIPT AND NOT
> LIBCXX_ENABLE_STATIC_ABI_LIBRARY)
> +set(ENABLE_LINKER_SCRIPT_DEFAULT_VALUE ON)
> +endif()
> +
>  option(LIBCXX_ENABLE_ABI_LINKER_SCRIPT
> -  "Use and install a linker script for the given ABI library" OFF)
> +  "Use and install a linker script for the given ABI library"
> +  ${ENABLE_LINKER_SCRIPT_DEFAULT_VALUE})
>
>  # Build libc++abi with libunwind. We need this option to determine
> whether to
>  # link with libunwind or libgcc_s while running the test cases.
>
> Modified: libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake
> URL:
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake?rev=250469=250468=250469=diff
>
> ==
> --- libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake (original)
> +++ libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake Thu Oct 15
> 17:41:51 2015
> @@ -109,6 +109,30 @@ if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURR
>  message(STATUS "Sphinx disabled.")
>endif()
>
> +  # FIXME - This is cribbed from HandleLLVMOptions.cmake.
> +  if(WIN32)
> +set(LLVM_HAVE_LINK_VERSION_SCRIPT 0)
> +if(CYGWIN)
> +  set(LLVM_ON_WIN32 0)
> +  set(LLVM_ON_UNIX 1)
> +else(CYGWIN)
> +  set(LLVM_ON_WIN32 1)
> +  set(LLVM_ON_UNIX 0)
> +endif(CYGWIN)
> +  else(WIN32)
> +if(UNIX)
> +  set(LLVM_ON_WIN32 0)
> +  set(LLVM_ON_UNIX 1)
> +  if(APPLE)
> +set(LLVM_HAVE_LINK_VERSION_SCRIPT 0)
> +  else(APPLE)
> +set(LLVM_HAVE_LINK_VERSION_SCRIPT 1)
> +  endif(APPLE)
> +else(UNIX)
> +  MESSAGE(SEND_ERROR "Unable to determine platform")
> +endif(UNIX)
> +  endif(WIN32)
> +
># Add LLVM Functions
> 
>include(AddLLVM OPTIONAL)
>  endif()
>
> Modified: libcxx/trunk/docs/BuildingLibcxx.rst
> URL:
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/docs/BuildingLibcxx.rst?rev=250469=250468=250469=diff
>
> ==
> --- libcxx/trunk/docs/BuildingLibcxx.rst (original)
> +++ libcxx/trunk/docs/BuildingLibcxx.rst Thu Oct 15 17:41:51 2015
> @@ -170,6 +170,14 @@ ABI Library Specific Options
>If this option is enabled, libc++ will try and link the selected ABI
> library
>statically.
>
> +.. option:: LIBCXX_ENABLE_ABI_LINKER_SCRIPT:BOOL
> +
> +  **Default**: ``ON`` by default on UNIX platforms other than Apple unless
> +  'LIBCXX_ENABLE_STATIC_ABI_LIBRARY' is ON. Otherwise the default value
> is ``OFF``.
> +
> +  This option generate and installs a linker script as ``libc++.so`` which

r250473 - Add an error when calling a builtin that requires features that don't

[Eric Christopher via cfe-commits]

Author: echristo
Date: Thu Oct 15 18:47:11 2015
New Revision: 250473

URL: http://llvm.org/viewvc/llvm-project?rev=250473=rev
Log:
Add an error when calling a builtin that requires features that don't
match the feature set of the function that they're being called from.

This ensures that we can effectively diagnose some[1] code that would
instead ICE in the backend with a failure to select message.

Example:

__m128d foo(__m128d a, __m128d b) {
  return __builtin_ia32_addsubps(b, a);
}

compiled for normal x86_64 via:

clang -target x86_64-linux-gnu -c

would fail to compile in the back end because the normal subtarget
features for x86_64 only include sse2 and the builtin requires sse3.

[1] We're still not erroring on:

__m128i bar(__m128i const *p) { return _mm_lddqu_si128(p); }

where we should fail and error on an always_inline function being
inlined into a function that doesn't support the subtarget features
required.

Added:
cfe/trunk/test/CodeGen/target-builtin-error-2.c
cfe/trunk/test/CodeGen/target-builtin-error.c
cfe/trunk/test/CodeGen/target-builtin-noerror.c
Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.h

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=250473=250472=250473=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Thu Oct 15 18:47:11 
2015
@@ -430,6 +430,7 @@ def warn_redecl_library_builtin : Warnin
 def err_builtin_definition : Error<"definition of builtin function %0">;
 def err_arm_invalid_specialreg : Error<"invalid special register for builtin">;
 def err_invalid_cpu_supports : Error<"invalid cpu feature string for builtin">;
+def err_builtin_needs_feature : Error<"%0 needs target feature %1">;
 def warn_builtin_unknown : Warning<"use of unknown builtin %0">,
   InGroup, DefaultError;
 def warn_dyn_class_memaccess : Warning<

Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=250473=250472=250473=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Thu Oct 15 18:47:11 2015
@@ -21,6 +21,7 @@
 #include "clang/Basic/TargetBuiltins.h"
 #include "clang/Basic/TargetInfo.h"
 #include "clang/CodeGen/CGFunctionInfo.h"
+#include "clang/Sema/SemaDiagnostic.h"
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/IR/CallSite.h"
 #include "llvm/IR/DataLayout.h"
@@ -288,6 +289,62 @@ Value *CodeGenFunction::EmitVAStartEnd(V
   return Builder.CreateCall(CGM.getIntrinsic(inst), ArgValue);
 }
 
+// Returns true if we have a valid set of target features.
+bool CodeGenFunction::checkBuiltinTargetFeatures(
+const FunctionDecl *TargetDecl) {
+  // Early exit if this is an indirect call.
+  if (!TargetDecl)
+return true;
+
+  // Get the current enclosing function if it exists.
+  if (const FunctionDecl *FD = dyn_cast_or_null(CurFuncDecl)) {
+unsigned BuiltinID = TargetDecl->getBuiltinID();
+const char *FeatureList =
+CGM.getContext().BuiltinInfo.getRequiredFeatures(BuiltinID);
+if (FeatureList && StringRef(FeatureList) != "") {
+  StringRef TargetCPU = Target.getTargetOpts().CPU;
+  llvm::StringMap FeatureMap;
+
+  if (const auto *TD = FD->getAttr()) {
+// If we have a TargetAttr build up the feature map based on that.
+TargetAttr::ParsedTargetAttr ParsedAttr = TD->parse();
+
+// Make a copy of the features as passed on the command line into the
+// beginning of the additional features from the function to override.
+ParsedAttr.first.insert(
+ParsedAttr.first.begin(),
+Target.getTargetOpts().FeaturesAsWritten.begin(),
+Target.getTargetOpts().FeaturesAsWritten.end());
+
+if (ParsedAttr.second != "")
+  TargetCPU = ParsedAttr.second;
+
+// Now populate the feature map, first with the TargetCPU which is
+// either
+// the default or a new one from the target attribute string. Then 
we'll
+// use the passed in features (FeaturesAsWritten) along with the new
+// ones
+// from the attribute.
+Target.initFeatureMap(FeatureMap, CGM.getDiags(), TargetCPU,
+  ParsedAttr.first);
+  } else {
+Target.initFeatureMap(FeatureMap, CGM.getDiags(), TargetCPU,
+  Target.getTargetOpts().Features);
+  }
+
+  // If we have at least one of the features in the feature list return
+  // true, otherwise return false.
+  SmallVector 

r250477 - Add "-Wc++11-inline-namespace" so that libc++ can use -pedantic in C++03.

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Thu Oct 15 19:31:36 2015
New Revision: 250477

URL: http://llvm.org/viewvc/llvm-project?rev=250477=rev
Log:
Add "-Wc++11-inline-namespace" so that libc++ can use -pedantic in C++03.

Summary: The title says it all.

Reviewers: rsmith

Subscribers: cfe-commits

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

Modified:
cfe/trunk/include/clang/Basic/DiagnosticGroups.td
cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td

Modified: cfe/trunk/include/clang/Basic/DiagnosticGroups.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticGroups.td?rev=250477=250476=250477=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticGroups.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticGroups.td Thu Oct 15 19:31:36 2015
@@ -217,6 +217,7 @@ def NonModularIncludeInModule : DiagGrou
 def IncompleteModule : DiagGroup<"incomplete-module",
 [IncompleteUmbrella, NonModularIncludeInModule]>;
 
+def CXX11InlineNamespace : DiagGroup<"c++11-inline-namespace">;
 def InvalidNoreturn : DiagGroup<"invalid-noreturn">;
 def InvalidSourceEncoding : DiagGroup<"invalid-source-encoding">;
 def KNRPromotedParameter : DiagGroup<"knr-promoted-parameter">;
@@ -679,7 +680,8 @@ def NonGCC : DiagGroup<"non-gcc",
 
 // A warning group for warnings about using C++11 features as extensions in
 // earlier C++ versions.
-def CXX11 : DiagGroup<"c++11-extensions", [CXX11ExtraSemi, CXX11LongLong]>;
+def CXX11 : DiagGroup<"c++11-extensions", [CXX11ExtraSemi, 
CXX11InlineNamespace,
+   CXX11LongLong]>;
 
 // A warning group for warnings about using C++14 features as extensions in
 // earlier C++ versions.

Modified: cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td?rev=250477=250476=250477=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td Thu Oct 15 19:31:36 
2015
@@ -271,7 +271,7 @@ def warn_cxx98_compat_ref_qualifier : Wa
   "reference qualifiers on functions are incompatible with C++98">,
   InGroup, DefaultIgnore;
 def ext_inline_namespace : ExtWarn<
-  "inline namespaces are a C++11 feature">, InGroup;
+  "inline namespaces are a C++11 feature">, InGroup;
 def warn_cxx98_compat_inline_namespace : Warning<
   "inline namespaces are incompatible with C++98">,
   InGroup, DefaultIgnore;


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

Re: [PATCH] D13795: Prefer functions with true enable_if conditions when attempting to resolve the address of an overload

[Richard Smith via cfe-commits]

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

Looks great, thanks!



Comment at: lib/Sema/SemaOverload.cpp:8413-8414
@@ +8412,4 @@
+// Cand1's first N enable_if attributes have precisely the same conditions as
+// Cand2's first N enable_if attributes (where N = the number of enable_if
+// attributes on Cand2)
+static bool hasBetterEnableIfAttrs(Sema , const FunctionDecl *Cand1,

... and Cand1 has more than N enable_if attributes.


http://reviews.llvm.org/D13795



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

[PATCH] D13795: Prefer functions with true enable_if conditions when attempting to resolve the address of an overload

[George Burgess IV via cfe-commits]

george.burgess.iv created this revision.
george.burgess.iv added a reviewer: rsmith.
george.burgess.iv added a subscriber: cfe-commits.

Our overload resolution logic considers some candidate A better than some 
candidate B if the set of A's enable_if conditions is a strict superset of the 
set of B's enable_if conditions.

Our address-of overload resolution logic does not.

This is suboptimal.

This patch updates the address-of overload resolution logic to behave more like 
the regular overload resolution logic.

http://reviews.llvm.org/D13795

Files:
  lib/Sema/SemaOverload.cpp
  test/CodeGen/enable_if.c
  test/CodeGenCXX/enable_if.cpp
  test/Sema/enable_if.c
  test/SemaCXX/enable_if.cpp

Index: test/SemaCXX/enable_if.cpp
===
--- test/SemaCXX/enable_if.cpp
+++ test/SemaCXX/enable_if.cpp
@@ -189,7 +189,7 @@
   }
 
   int ovlConflict(int m) __attribute__((enable_if(true, "")));
-  int ovlConflict(int m);
+  int ovlConflict(int m) __attribute__((enable_if(1, "")));
   void test3() {
 int (*p)(int) = ovlConflict; // expected-error{{address of overloaded function 'ovlConflict' is ambiguous}} expected-note@191{{candidate function}} expected-note@192{{candidate function}}
 int (*p2)(int) =  // expected-error{{address of overloaded function 'ovlConflict' is ambiguous}} expected-note@191{{candidate function}} expected-note@192{{candidate function}}
@@ -225,7 +225,7 @@
   template 
   T templatedConflict(T m) __attribute__((enable_if(true, ""))) { return T(); }
   template 
-  T templatedConflict(T m) { return T(); }
+  T templatedConflict(T m) __attribute__((enable_if(1, ""))) { return T(); }
   void test6() {
 int (*p)(int) = templatedConflict; // expected-error{{address of overloaded function 'templatedConflict' is ambiguous}} expected-note@224{{candidate function made ineligible by enable_if}} expected-note@226{{candidate function}} expected-note@228{{candidate function}}
 int (*p0)(int) = ; // expected-error{{address of overloaded function 'templatedConflict' is ambiguous}} expected-note@224{{candidate function made ineligible by enable_if}} expected-note@226{{candidate function}} expected-note@228{{candidate function}}
Index: test/Sema/enable_if.c
===
--- test/Sema/enable_if.c
+++ test/Sema/enable_if.c
@@ -5,6 +5,8 @@
 typedef int mode_t;
 typedef unsigned long size_t;
 
+const int TRUE = 1;
+
 int open(const char *pathname, int flags) __attribute__((enable_if(!(flags & O_CREAT), "must specify mode when using O_CREAT"))) __attribute__((overloadable));  // expected-note{{candidate disabled: must specify mode when using O_CREAT}}
 int open(const char *pathname, int flags, mode_t mode) __attribute__((overloadable));  // expected-note{{candidate function not viable: requires 3 arguments, but 2 were provided}}
 
@@ -118,20 +120,20 @@
 
 void f2(void) __attribute__((overloadable)) __attribute__((enable_if(1, "always chosen")));
 void f2(void) __attribute__((overloadable)) __attribute__((enable_if(0, "never chosen")));
-void f2(void) __attribute__((overloadable));
+void f2(void) __attribute__((overloadable)) __attribute__((enable_if(TRUE, "always chosen #2")));
 void test6() {
-  void (*p1)(void) =  // expected-error{{initializing 'void (*)(void)' with an expression of incompatible type ''}} expected-note@119{{candidate function}} expected-note@120{{candidate function made ineligible by enable_if}} expected-note@121{{candidate function}}
-  void (*p2)(void) = f2; // expected-error{{initializing 'void (*)(void)' with an expression of incompatible type ''}} expected-note@119{{candidate function}} expected-note@120{{candidate function made ineligible by enable_if}} expected-note@121{{candidate function}}
-  void *p3 = (void*) // expected-error{{address of overloaded function 'f2' is ambiguous}} expected-note@119{{candidate function}} expected-note@120{{candidate function made ineligible by enable_if}} expected-note@121{{candidate function}}
-  void *p4 = (void*)f2; // expected-error{{address of overloaded function 'f2' is ambiguous}} expected-note@119{{candidate function}} expected-note@120{{candidate function made ineligible by enable_if}} expected-note@121{{candidate function}}
+  void (*p1)(void) =  // expected-error{{initializing 'void (*)(void)' with an expression of incompatible type ''}} expected-note@121{{candidate function}} expected-note@122{{candidate function made ineligible by enable_if}} expected-note@123{{candidate function}}
+  void (*p2)(void) = f2; // expected-error{{initializing 'void (*)(void)' with an expression of incompatible type ''}} expected-note@121{{candidate function}} expected-note@122{{candidate function made ineligible by enable_if}} expected-note@123{{candidate function}}
+  void *p3 = (void*) // expected-error{{address of overloaded function 'f2' is ambiguous}} expected-note@121{{candidate function}} expected-note@122{{candidate function made 

[PATCH] D13796: [libcxx] Use "-stdlib=libc++" when possible instead of '-nodefaultlibs' in the test suite.

[Eric Fiselier via cfe-commits]

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

Currently we use '-nodefaultlibs' when building and running the libc++ tests. 
However we should prefer using '-stdlib=libc++'.
This patch automatically detects when the test suite can use "-stdlib=libc++" 
and prefers it when possible.

We use `-stdlib=libc++` when the following are true:

1. `CXX` is clang or apple clang.
2. 'cxx_abi' is set to 'none'. This means that libc++ handles the ABI library 
dependency on its own.
3. We are using the default unwinder (ie not libunwind).


http://reviews.llvm.org/D13796

Files:
  test/libcxx/compiler.py
  test/libcxx/test/config.py

Index: test/libcxx/test/config.py
===
--- test/libcxx/test/config.py
+++ test/libcxx/test/config.py
@@ -71,6 +71,7 @@
 self.abi_library_root = None
 self.env = {}
 self.use_target = False
+self.use_stdlib_eq_libcxx = False
 self.use_system_cxx_lib = False
 self.use_clang_verify = False
 self.long_tests = None
@@ -107,6 +108,7 @@
 self.configure_use_clang_verify()
 self.configure_execute_external()
 self.configure_ccache()
+self.configure_use_stdlib_eq_libcxx()
 self.configure_compile_flags()
 self.configure_link_flags()
 self.configure_env()
@@ -355,6 +357,19 @@
 if self.cxx.hasCompileFlag('-fsized-deallocation'):
 self.config.available_features.add('fsized-deallocation')
 
+def configure_use_stdlib_eq_libcxx(self):
+cxx_abi = self.get_lit_conf('cxx_abi', 'libcxxabi')
+use_llvm_unwinder = self.get_lit_bool('llvm_unwinder', False)
+deduced_use_stdlib_eq_libcxx = (self.cxx.isClang() and
+cxx_abi == 'none' and
+not use_llvm_unwinder)
+self.use_stdlib_eq_libcxx = self.get_lit_bool(
+'use_stdlib_eq_libcxx', deduced_use_stdlib_eq_libcxx)
+if self.use_stdlib_eq_libcxx and not deduced_use_stdlib_eq_libcxx:
+self.lit_config.fatal('--param=use_stdlib_eq_libcxx=true cannot be '
+'specified in this configuration.')
+
+
 def configure_compile_flags(self):
 no_default_flags = self.get_lit_bool('no_default_flags', False)
 if not no_default_flags:
@@ -496,16 +511,23 @@
 def configure_link_flags(self):
 no_default_flags = self.get_lit_bool('no_default_flags', False)
 if not no_default_flags:
-self.cxx.link_flags += ['-nodefaultlibs']
+if not self.use_stdlib_eq_libcxx:
+self.cxx.link_flags += ['-nodefaultlibs']
 
 # Configure library path
 self.configure_link_flags_cxx_library_path()
 self.configure_link_flags_abi_library_path()
 
-# Configure libraries
 self.configure_link_flags_cxx_library()
 self.configure_link_flags_abi_library()
-self.configure_extra_library_flags()
+
+enable_threads = ('libcpp-has-no-threads' not in
+   self.config.available_features)
+
+if not self.use_stdlib_eq_libcxx:
+self.configure_builtin_libraries(enable_threads)
+elif enable_threads:
+self.cxx.link_flags += ['-lpthread']
 
 link_flags_str = self.get_lit_conf('link_flags', '')
 self.cxx.link_flags += shlex.split(link_flags_str)
@@ -538,12 +560,15 @@
 
 def configure_link_flags_cxx_library(self):
 libcxx_library = self.get_lit_conf('libcxx_library')
-if libcxx_library:
+if self.use_stdlib_eq_libcxx:
+self.cxx.link_flags += ['-stdlib=libc++']
+elif libcxx_library:
 self.cxx.link_flags += [libcxx_library]
 else:
 self.cxx.link_flags += ['-lc++']
 
 def configure_link_flags_abi_library(self):
+
 cxx_abi = self.get_lit_conf('cxx_abi', 'libcxxabi')
 if cxx_abi == 'libstdc++':
 self.cxx.link_flags += ['-lstdc++']
@@ -562,9 +587,8 @@
 self.lit_config.fatal(
 'C++ ABI setting %s unsupported for tests' % cxx_abi)
 
-def configure_extra_library_flags(self):
-enable_threads = ('libcpp-has-no-threads' not in
-  self.config.available_features)
+def configure_builtin_libraries(self, enable_threads):
+assert not self.use_stdlib_eq_libcxx
 llvm_unwinder = self.get_lit_bool('llvm_unwinder', False)
 target_platform = self.target_info.platform()
 if target_platform == 'darwin':
@@ -648,7 +672,8 @@
  symbolizer_search_paths)
 # Setup the sanitizer compile flags
 self.cxx.flags += ['-g', '-fno-omit-frame-pointer']
-if self.target_info.platform() == 'linux':

Re: [PATCH] D13795: Prefer functions with true enable_if conditions when attempting to resolve the address of an overload

[George Burgess IV via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL250486: [Sema] Fix address-of + enable_if overloading logic 
(authored by gbiv).

Changed prior to commit:
  http://reviews.llvm.org/D13795?vs=37545=37552#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D13795

Files:
  cfe/trunk/lib/Sema/SemaOverload.cpp
  cfe/trunk/test/CodeGen/enable_if.c
  cfe/trunk/test/CodeGenCXX/enable_if.cpp
  cfe/trunk/test/Sema/enable_if.c
  cfe/trunk/test/SemaCXX/enable_if.cpp

Index: cfe/trunk/test/SemaCXX/enable_if.cpp
===
--- cfe/trunk/test/SemaCXX/enable_if.cpp
+++ cfe/trunk/test/SemaCXX/enable_if.cpp
@@ -189,7 +189,7 @@
   }
 
   int ovlConflict(int m) __attribute__((enable_if(true, "")));
-  int ovlConflict(int m);
+  int ovlConflict(int m) __attribute__((enable_if(1, "")));
   void test3() {
 int (*p)(int) = ovlConflict; // expected-error{{address of overloaded function 'ovlConflict' is ambiguous}} expected-note@191{{candidate function}} expected-note@192{{candidate function}}
 int (*p2)(int) =  // expected-error{{address of overloaded function 'ovlConflict' is ambiguous}} expected-note@191{{candidate function}} expected-note@192{{candidate function}}
@@ -225,7 +225,7 @@
   template 
   T templatedConflict(T m) __attribute__((enable_if(true, ""))) { return T(); }
   template 
-  T templatedConflict(T m) { return T(); }
+  T templatedConflict(T m) __attribute__((enable_if(1, ""))) { return T(); }
   void test6() {
 int (*p)(int) = templatedConflict; // expected-error{{address of overloaded function 'templatedConflict' is ambiguous}} expected-note@224{{candidate function made ineligible by enable_if}} expected-note@226{{candidate function}} expected-note@228{{candidate function}}
 int (*p0)(int) = ; // expected-error{{address of overloaded function 'templatedConflict' is ambiguous}} expected-note@224{{candidate function made ineligible by enable_if}} expected-note@226{{candidate function}} expected-note@228{{candidate function}}
Index: cfe/trunk/test/CodeGen/enable_if.c
===
--- cfe/trunk/test/CodeGen/enable_if.c
+++ cfe/trunk/test/CodeGen/enable_if.c
@@ -49,3 +49,34 @@
   // CHECK: store i8* bitcast (void (i32)* @_Z3barUa9enable_ifIXLi1EEEi to i8*)
   vp1 = (void*)bar;
 }
+
+void baz(int m) __attribute__((overloadable, enable_if(1, "")));
+void baz(int m) __attribute__((overloadable));
+// CHECK-LABEL: define void @test3
+void test3() {
+  // CHECK: store void (i32)* @_Z3bazUa9enable_ifIXLi1EEEi
+  void (*p)(int) = baz;
+  // CHECK: store void (i32)* @_Z3bazUa9enable_ifIXLi1EEEi
+  void (*p2)(int) = 
+  // CHECK: store void (i32)* @_Z3bazUa9enable_ifIXLi1EEEi
+  p = baz;
+  // CHECK: store void (i32)* @_Z3bazUa9enable_ifIXLi1EEEi
+  p = 
+}
+
+
+const int TRUEFACTS = 1;
+void qux(int m) __attribute__((overloadable, enable_if(1, ""),
+   enable_if(TRUEFACTS, "")));
+void qux(int m) __attribute__((overloadable, enable_if(1, "")));
+// CHECK-LABEL: define void @test4
+void test4() {
+  // CHECK: store void (i32)* @_Z3quxUa9enable_ifIXLi1EEXL_Z9TRUEFACTSEEEi
+  void (*p)(int) = qux;
+  // CHECK: store void (i32)* @_Z3quxUa9enable_ifIXLi1EEXL_Z9TRUEFACTSEEEi
+  void (*p2)(int) = 
+  // CHECK: store void (i32)* @_Z3quxUa9enable_ifIXLi1EEXL_Z9TRUEFACTSEEEi
+  p = qux;
+  // CHECK: store void (i32)* @_Z3quxUa9enable_ifIXLi1EEXL_Z9TRUEFACTSEEEi
+  p = 
+}
Index: cfe/trunk/test/CodeGenCXX/enable_if.cpp
===
--- cfe/trunk/test/CodeGenCXX/enable_if.cpp
+++ cfe/trunk/test/CodeGenCXX/enable_if.cpp
@@ -1,4 +1,13 @@
 // RUN: %clang_cc1 -emit-llvm %s -o - -triple=x86_64-pc-linux-gnu| FileCheck %s
+
+// Test address-of overloading logic
+int test5(int);
+template 
+T test5(T) __attribute__((enable_if(1, "better than non-template")));
+
+// CHECK: @_Z5test5IiEUa9enable_ifIXLi1EEET_S0_
+int (*Ptr)(int) = 
+
 // Test itanium mangling for attribute enable_if
 
 // CHECK: _Z5test1Ua9enable_ifIXeqfL0p_Li1EEEi
Index: cfe/trunk/test/Sema/enable_if.c
===
--- cfe/trunk/test/Sema/enable_if.c
+++ cfe/trunk/test/Sema/enable_if.c
@@ -5,6 +5,8 @@
 typedef int mode_t;
 typedef unsigned long size_t;
 
+const int TRUE = 1;
+
 int open(const char *pathname, int flags) __attribute__((enable_if(!(flags & O_CREAT), "must specify mode when using O_CREAT"))) __attribute__((overloadable));  // expected-note{{candidate disabled: must specify mode when using O_CREAT}}
 int open(const char *pathname, int flags, mode_t mode) __attribute__((overloadable));  // expected-note{{candidate function not viable: requires 3 arguments, but 2 were provided}}
 
@@ -118,20 +120,20 @@
 
 void f2(void) __attribute__((overloadable)) __attribute__((enable_if(1, "always chosen")));
 void f2(void) __attribute__((overloadable)) 

Re: [PATCH] D13786: [Sema] Implement __make_integer_seq

[Eric Fiselier via cfe-commits]

EricWF added a subscriber: EricWF.
EricWF added a comment.

Cool! I imagine that a lot of parts of libc++ could benefit from this. Having 
something like this that slices parameter packs would probably help libc++ 
compile times for tuple. Is that something your considering as well?


http://reviews.llvm.org/D13786



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

Re: [PATCH] D12821: Allow for C's "writing off the end" idiom in __builtin_object_size

[Richard Smith via cfe-commits]

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

Some minor typographical comments.

Please add some tests for the union case, then this LGTM.



Comment at: lib/AST/ExprConstant.cpp:6333-6336
@@ +6332,6 @@
+if (BaseType->isArrayType()) {
+  // Because __builtin_object_size treats arrays as objects, we can ignore
+  // the index iff this is the last array in the Designator.
+  if (I + 1 == E)
+return true;
+  auto *CAT = cast(Ctx.getAsArrayType(BaseType));

OK, but please reflect that this is specific to `__builtin_object_size` in the 
name or at least doc comment for this function.


Comment at: lib/AST/ExprConstant.cpp:6361
@@ +6360,3 @@
+
+/// Tests to see if the has a designator (that isn't necessarily valid).
+static bool hasDesignator(const LValue ) {

This is missing a noun.


Comment at: lib/AST/ExprConstant.cpp:6362
@@ +6361,3 @@
+/// Tests to see if the has a designator (that isn't necessarily valid).
+static bool hasDesignator(const LValue ) {
+  if (LVal.Designator.Invalid || !LVal.Designator.Entries.empty())

I think this would be clearer if it were named `hasNonemptyDesignator`... or 
perhaps reverse the sense of it and name it `refersToCompleteObject` or similar?


http://reviews.llvm.org/D12821



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

Re: [PATCH] D13786: [Sema] Implement __make_integer_seq

[Richard Smith via cfe-commits]

rsmith added inline comments.


Comment at: include/clang/AST/TemplateName.h:93-100
@@ +92,10 @@
+
+/// \brief A structure for storing the information associated with an
+/// builtin template name.
+class BuiltinTemplateStorage : public UncommonTemplateNameStorage {
+  friend class ASTContext;
+
+public:
+  BuiltinTemplateStorage() : UncommonTemplateNameStorage(Builtin, 0) {}
+};
+

Please add an enum for builtin template names (and pass it around when creating 
`TemplateName`s and `BuiltinTemplateDecl`s as appropriate), even though it will 
only have one value for now.


Comment at: lib/Parse/ParseDecl.cpp:2937-2939
@@ +2936,5 @@
+  if (Type.isInvalid()) {
+// If we failed to parse the template ID but skipped ahead to a >, 
we're
+// not
+// going to be able to form a token annotation.  Eat the '>' if 
present.
+TryConsumeToken(tok::greater);

Reflow this comment.


Comment at: lib/Sema/SemaTemplate.cpp:2060-2102
@@ -2055,1 +2059,45 @@
 
+  // Instantiations involving __make_integer_seq are treated like
+  // S.
+  TemplateArgumentListInfo SyntheticTemplateArgs;
+  TemplateName UnderlyingName = Name;
+  bool UseSyntheticTemplateArgs = false;
+  if (IsBuiltinTemplate) {
+assert(Converted.size() == 3 && "Unexpected BuiltinTemplate!");
+
+// Switch our template from __make_integer_seq to S.
+Name = Converted[0].getAsTemplate();
+Template = Name.getAsTemplateDecl();
+TemplateArgument NumArgsArg = Converted[2];
+if (!NumArgsArg.isDependent()) {
+  // The first template argument will be reused as the template decl that
+  // our synthetic template arguments will be applied to while the last
+  // template argument will be replaced with a pack.
+  TemplateArgument SequenceType = Converted[1];
+  Converted.clear();
+  Converted.push_back(SequenceType);
+  UseSyntheticTemplateArgs = true;
+
+  // Diagnose attempts to create integer sequences with a negative length.
+  llvm::APSInt NumArgs = NumArgsArg.getAsIntegral();
+  if (NumArgs < 0)
+Diag(UnderlyingTemplateArgs[2].getLocation(),
+ diag::err_integer_sequence_negative_length);
+
+  QualType Ty = NumArgsArg.getIntegralType();
+  SmallVector ArgumentPack;
+  for (llvm::APSInt I(NumArgs.getBitWidth(), NumArgs.isUnsigned());
+   I < NumArgs; ++I) {
+TemplateArgument TA(Context, I, Ty);
+Expr *E =
+BuildExpressionFromIntegralTemplateArgument(TA, SourceLocation())
+.getAs();
+ArgumentPack.push_back(TA);
+SyntheticTemplateArgs.addArgument(
+TemplateArgumentLoc(TemplateArgument(E), E));
+  }
+  Converted.push_back(
+  TemplateArgument::CreatePackCopy(Context, ArgumentPack));
+}
+  }
+

Please factor this out into a separate function, `CheckBuiltinTemplateIdType` 
or similar.


Comment at: lib/Sema/SemaTemplate.cpp:2069-2071
@@ +2068,5 @@
+// Switch our template from __make_integer_seq to S.
+Name = Converted[0].getAsTemplate();
+Template = Name.getAsTemplateDecl();
+TemplateArgument NumArgsArg = Converted[2];
+if (!NumArgsArg.isDependent()) {

I would prefer to see this structured as follows:

In the `if` chain below where we're dispatching on the type of the template, if 
the template is a `BuiltinTemplateDecl`, then do some special-case handling to 
compute the `CanonType` (which is really poorly / misleadingly named; it's just 
the underlying type, not the canonical type). In the `__make_integer_sequence` 
case, this would involve recursively calling back into `CheckTemplateIdType` to 
build the template-id for the expanded form.

This means you'll retain an intermediate TST between the `__make_integer_seq` 
and the ultimate type.


Comment at: lib/Sema/SemaTemplate.cpp:2083-2085
@@ +2082,5 @@
+  llvm::APSInt NumArgs = NumArgsArg.getAsIntegral();
+  if (NumArgs < 0)
+Diag(UnderlyingTemplateArgs[2].getLocation(),
+ diag::err_integer_sequence_negative_length);
+

Is it worth putting some kind of upper bound on what we'll accept here?


http://reviews.llvm.org/D13786



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

[libcxx] r250472 - Re-enable linker scripts after fixing bad CMake

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Thu Oct 15 18:04:54 2015
New Revision: 250472

URL: http://llvm.org/viewvc/llvm-project?rev=250472=rev
Log:
Re-enable linker scripts after fixing bad CMake

Modified:
libcxx/trunk/CMakeLists.txt
libcxx/trunk/lib/CMakeLists.txt

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=250472=250471=250472=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Thu Oct 15 18:04:54 2015
@@ -76,14 +76,14 @@ option(LIBCXX_ENABLE_STATIC_ABI_LIBRARY
 # On UNIX platforms other than Apple unless 'LIBCXX_ENABLE_STATIC_ABI_LIBRARY'
 # is on.
 set(ENABLE_LINKER_SCRIPT_DEFAULT_VALUE OFF)
-if (LLVM_HAVE_LINK_VERSION_SCRIPT AND NOT LIBCXX_ENABLE_STATIC_ABI_LIBRARY)
+if (LLVM_HAVE_LINK_VERSION_SCRIPT AND NOT LIBCXX_ENABLE_STATIC_ABI_LIBRARY
+  AND PYTHONINTERP_FOUND)
 set(ENABLE_LINKER_SCRIPT_DEFAULT_VALUE ON)
 endif()
 
-#FIXME(EricWF)
 option(LIBCXX_ENABLE_ABI_LINKER_SCRIPT
   "Use and install a linker script for the given ABI library"
-  OFF) #${ENABLE_LINKER_SCRIPT_DEFAULT_VALUE})
+  ${ENABLE_LINKER_SCRIPT_DEFAULT_VALUE})
 
 # Build libc++abi with libunwind. We need this option to determine whether to
 # link with libunwind or libgcc_s while running the test cases.

Modified: libcxx/trunk/lib/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/lib/CMakeLists.txt?rev=250472=250471=250472=diff
==
--- libcxx/trunk/lib/CMakeLists.txt (original)
+++ libcxx/trunk/lib/CMakeLists.txt Thu Oct 15 18:04:54 2015
@@ -140,7 +140,7 @@ if (LIBCXX_ENABLE_ABI_LINKER_SCRIPT)
   # is a target name and not a library. Ex cxxabi_shared.
   set(SCRIPT_ABI_LIBNAME "${LIBCXX_CXX_ABI_LIBRARY}")
   if (SCRIPT_ABI_LIBNAME STREQUAL "cxxabi_shared")
-set("${SCRIPT_ABI_LIBNAME}" "c++abi")
+set(SCRIPT_ABI_LIBNAME "c++abi")
   endif()
   # Generate a linker script inplace of a libc++.so symlink. Rerun this command
   # after cxx builds.


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

Re: [libcxx] r249738 - Split out of .

[Richard Smith via cfe-commits]

On Thu, Oct 15, 2015 at 2:57 PM, Adrian Prantl via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Oct 15, 2015, at 2:51 PM, Alex Rosenberg  wrote:
>
> On Oct 15, 2015, at 2:20 PM, Adrian Prantl via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>
> On Oct 15, 2015, at 2:09 PM, Adrian Prantl via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>
> On Oct 15, 2015, at 1:42 PM, Richard Smith  wrote:
>
> On Thu, Oct 15, 2015 at 11:14 AM, Adrian Prantl  wrote:
>
>>
>> On Oct 14, 2015, at 5:07 PM, Richard Smith  wrote:
>>
>> Ack, there are non-modular headers in the Darwin module. =( I seem to
>> recall that they're not version-locked to your compiler, so we've got to
>> support them as-is?
>>
>> If we can't turn on local submodule visibility, then we need a module map
>> for libc++ that covers all of its headers. I'll look into pruning the
>> include path when building a module from an implicitly-loaded module map.
>>
>>
>> The attached patch implements this in the most hacky way; with it I can
>> successfully compile the first few hundred files of LLVM.
>>
>
> Great, it looks like this plan should work then. What failure do you
> eventually hit? Does it look related to these  changes?
>
>
> So far I fixed 250446  and 250459 which were both just missing include
> files. I’m puzzled by 250459 though, as there is nothing Darwin-specific
> about the change. I’ll keep iterating and will let you know if there are
> any libc++-related problems.
>
>
> I'm working on a more refined version of the approach I described earlier;
> I'll mail you a patch to test when I have it finished.
>
>
> That sounds great.
>
> thanks,
> adrian
>
>
> Here’s a weird one:
>
> *../lib/Transforms/Scalar/ScalarReplAggregates.cpp:1031:6: **error: **'SROA'
> is not a class, namespace, or enumeration*
> bool SROA::runOnFunction(Function ) {
> * ^*
> *../lib/Transforms/Scalar/ScalarReplAggregates.cpp:1031:6: **error: 
> **reference
> to 'SROA' is ambiguous*
> *../include/llvm/Transforms/Scalar/SROA.h:54:7: note: *candidate found by
> name lookup is 'llvm::SROA'
> class SROA {
> *  ^*
> *../lib/Transforms/Scalar/ScalarReplAggregates.cpp:63:10: note: *candidate
> found by name lookup is '(anonymous namespace)::SROA'
>   struct SROA : public FunctionPass {
> * ^*
>
> this doesn’t look Darwin-specific at all. Assuming that the Linux module
> build works, why am I seeing this?
>
>
> The Linux bot has the same problem:
> http://lab.llvm.org:8011/builders/clang-x86_64-linux-selfhost-modules/builds/7331/steps/compile.llvm.stage2/logs/stdio
>
>
> Oh :-) That bot does not look very happy:
>
> http://lab.llvm.org:8011/builders/clang-x86_64-linux-selfhost-modules?numbuilds=1000
>
> What’s the appropriate solution, renaming the struct ::SROA in the
> anonymous namespace to something else?
>

Oh, and please don't do that: the point of the modules selfhost bot is to
find bugs in Clang's modules implementation. We shouldn't make changes to
the LLVM code to make the build pass unless the problem is known to be a
bug in the code being compiled rather than a bug in the compiler.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r250488 - Make __builtin_object_size more conservative

[George Burgess IV via cfe-commits]

Author: gbiv
Date: Thu Oct 15 20:49:01 2015
New Revision: 250488

URL: http://llvm.org/viewvc/llvm-project?rev=250488=rev
Log:
Make __builtin_object_size more conservative

r246877 made __builtin_object_size substantially more aggressive with
unknown bases if Type=1 or Type=3, which causes issues when we encounter
code like this:

struct Foo {
  int a;
  char str[1];
};

const char str[] = "Hello, World!";
struct Foo *f = (struct Foo *)malloc(sizeof(*f) + strlen(str));
strcpy(>str, str);

__builtin_object_size(>str, 1) would hand back 1, which is
technically correct given the type of Foo, but the type of Foo lies to
us about how many bytes are available in this case.

This patch adds support for this "writing off the end" idiom -- we now
answer conservatively when we're given the address of the very last
member in a struct.

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

Modified:
cfe/trunk/lib/AST/ExprConstant.cpp
cfe/trunk/test/CodeGen/object-size.c
cfe/trunk/test/CodeGen/object-size.cpp

Modified: cfe/trunk/lib/AST/ExprConstant.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ExprConstant.cpp?rev=250488=250487=250488=diff
==
--- cfe/trunk/lib/AST/ExprConstant.cpp (original)
+++ cfe/trunk/lib/AST/ExprConstant.cpp Thu Oct 15 20:49:01 2015
@@ -114,7 +114,8 @@ namespace {
   static
   unsigned findMostDerivedSubobject(ASTContext , QualType Base,
 ArrayRef Path,
-uint64_t , QualType ) {
+uint64_t , QualType ,
+bool ) {
 unsigned MostDerivedLength = 0;
 Type = Base;
 for (unsigned I = 0, N = Path.size(); I != N; ++I) {
@@ -124,18 +125,22 @@ namespace {
 Type = CAT->getElementType();
 ArraySize = CAT->getSize().getZExtValue();
 MostDerivedLength = I + 1;
+IsArray = true;
   } else if (Type->isAnyComplexType()) {
 const ComplexType *CT = Type->castAs();
 Type = CT->getElementType();
 ArraySize = 2;
 MostDerivedLength = I + 1;
+IsArray = true;
   } else if (const FieldDecl *FD = getAsField(Path[I])) {
 Type = FD->getType();
 ArraySize = 0;
 MostDerivedLength = I + 1;
+IsArray = false;
   } else {
 // Path[I] describes a base class.
 ArraySize = 0;
+IsArray = false;
   }
 }
 return MostDerivedLength;
@@ -157,12 +162,17 @@ namespace {
 /// Is this a pointer one past the end of an object?
 bool IsOnePastTheEnd : 1;
 
+/// Indicator of whether the most-derived object is an array element.
+bool MostDerivedIsArrayElement : 1;
+
 /// The length of the path to the most-derived object of which this is a
 /// subobject.
-unsigned MostDerivedPathLength : 30;
+unsigned MostDerivedPathLength : 29;
 
-/// The size of the array of which the most-derived object is an element, 
or
-/// 0 if the most-derived object is not an array element.
+/// The size of the array of which the most-derived object is an element.
+/// This will always be 0 if the most-derived object is not an array
+/// element. 0 is not an indicator of whether or not the most-derived 
object
+/// is an array, however, because 0-length arrays are allowed.
 uint64_t MostDerivedArraySize;
 
 /// The type of the most derived object referred to by this address.
@@ -176,21 +186,26 @@ namespace {
 SubobjectDesignator() : Invalid(true) {}
 
 explicit SubobjectDesignator(QualType T)
-  : Invalid(false), IsOnePastTheEnd(false), MostDerivedPathLength(0),
-MostDerivedArraySize(0), MostDerivedType(T) {}
+: Invalid(false), IsOnePastTheEnd(false),
+  MostDerivedIsArrayElement(false), MostDerivedPathLength(0),
+  MostDerivedArraySize(0), MostDerivedType(T) {}
 
 SubobjectDesignator(ASTContext , const APValue )
-  : Invalid(!V.isLValue() || !V.hasLValuePath()), IsOnePastTheEnd(false),
-MostDerivedPathLength(0), MostDerivedArraySize(0) {
+: Invalid(!V.isLValue() || !V.hasLValuePath()), IsOnePastTheEnd(false),
+  MostDerivedIsArrayElement(false), MostDerivedPathLength(0),
+  MostDerivedArraySize(0) {
   if (!Invalid) {
 IsOnePastTheEnd = V.isLValueOnePastTheEnd();
 ArrayRef VEntries = V.getLValuePath();
 Entries.insert(Entries.end(), VEntries.begin(), VEntries.end());
-if (V.getLValueBase())
+if (V.getLValueBase()) {
+  bool IsArray = false;
   MostDerivedPathLength =
   findMostDerivedSubobject(Ctx, getType(V.getLValueBase()),
V.getLValuePath(), MostDerivedArraySize,
-   MostDerivedType);
+   MostDerivedType, IsArray);
+  

Re: [libcxx] r250256 - Workaround -pedantic flag added by LLVM

[Eric Fiselier via cfe-commits]

> It would probably make sense for libc++ to remove -Wno-pedantic before
removing -pedantic.

Good localized fix. Committed as r250452. `remove_flags` hack needs to die
soon :(

On Thu, Oct 15, 2015 at 2:00 PM, Evgenii Stepanov  wrote:

> It looks like, since libc++ removes -pedantic, we don't need to add
> -Wno-pedantic, so I can just fix it in MSan. It would probably make
> sense for libc++ to remove -Wno-pedantic before removing -pedantic.
>
> On Thu, Oct 15, 2015 at 12:57 PM, Evgenii Stepanov
>  wrote:
> > Transforms it to -Wno.
> >
> > On Thu, Oct 15, 2015 at 12:56 PM, Eric Fiselier  wrote:
> >> Removes it because "-Wno-pedantic" incorrectly matches -pedantic? If my
> >> guess is correct, whoops :-(
> >>
> >> On Thu, Oct 15, 2015 at 1:51 PM, Evgenii Stepanov
> >>  wrote:
> >>>
> >>> Guess what this does to the -Wno-pedantic flag added by MSan? :)
> >>>
> >>> On Tue, Oct 13, 2015 at 4:56 PM, Eric Fiselier via cfe-commits
> >>>  wrote:
> >>> > Author: ericwf
> >>> > Date: Tue Oct 13 18:56:33 2015
> >>> > New Revision: 250256
> >>> >
> >>> > URL: http://llvm.org/viewvc/llvm-project?rev=250256=rev
> >>> > Log:
> >>> > Workaround -pedantic flag added by LLVM
> >>> >
> >>> > Modified:
> >>> > libcxx/trunk/CMakeLists.txt
> >>> >
> >>> > Modified: libcxx/trunk/CMakeLists.txt
> >>> > URL:
> >>> >
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=250256=250255=250256=diff
> >>> >
> >>> >
> ==
> >>> > --- libcxx/trunk/CMakeLists.txt (original)
> >>> > +++ libcxx/trunk/CMakeLists.txt Tue Oct 13 18:56:33 2015
> >>> > @@ -198,6 +198,10 @@ include(HandleLibcxxFlags)
> >>> >  remove_flags(-DNDEBUG -UNDEBUG -D_DEBUG
> >>> >   -stdlib=libc++ -stdlib=libstdc++ -lc++abi -m32)
> >>> >
> >>> > +# FIXME(EricWF): See the FIXME on LIBCXX_ENABLE_PEDANTIC.
> >>> > +# Remove the -pedantic flag provided by LLVM.
> >>> > +remove_flags(-pedantic)
> >>> > +
> >>> >  # Required flags
> >>> > ==
> >>> >  add_compile_flags_if_supported(-std=c++11)
> >>> >  if (NOT MSVC AND NOT LIBCXX_SUPPORTS_STD_EQ_CXX11_FLAG)
> >>> >
> >>> >
> >>> > ___
> >>> > 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] D13786: [Sema] Implement __make_integer_seq

[David Majnemer via cfe-commits]

majnemer updated this revision to Diff 37518.
majnemer added a comment.

- Add an llvm_unreachable to ASTDeclReader::VisitBuiltinTemplateDecl


http://reviews.llvm.org/D13786

Files:
  include/clang/AST/ASTContext.h
  include/clang/AST/DataRecursiveASTVisitor.h
  include/clang/AST/DeclTemplate.h
  include/clang/AST/RecursiveASTVisitor.h
  include/clang/AST/TemplateName.h
  include/clang/Basic/DeclNodes.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/TokenKinds.def
  include/clang/Sema/Sema.h
  lib/AST/ASTContext.cpp
  lib/AST/ASTDumper.cpp
  lib/AST/ASTImporter.cpp
  lib/AST/DeclBase.cpp
  lib/AST/DeclTemplate.cpp
  lib/AST/ItaniumMangle.cpp
  lib/AST/TemplateName.cpp
  lib/AST/Type.cpp
  lib/CodeGen/CGDecl.cpp
  lib/Parse/ParseDecl.cpp
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaTemplate.cpp
  lib/Sema/SemaTemplateInstantiateDecl.cpp
  lib/Sema/TreeTransform.h
  lib/Serialization/ASTCommon.cpp
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTReaderDecl.cpp
  lib/Serialization/ASTWriter.cpp
  tools/libclang/CIndex.cpp

Index: tools/libclang/CIndex.cpp
===
--- tools/libclang/CIndex.cpp
+++ tools/libclang/CIndex.cpp
@@ -1392,6 +1392,9 @@
 return Visit(MakeCursorTemplateRef(
   Name.getAsSubstTemplateTemplateParmPack()->getParameterPack(),
Loc, TU));
+
+  case TemplateName::BuiltinTemplate:
+return false;
   }
 
   llvm_unreachable("Invalid TemplateName::Kind!");
@@ -5110,6 +5113,7 @@
   case Decl::Import:
   case Decl::OMPThreadPrivate:
   case Decl::ObjCTypeParam:
+  case Decl::BuiltinTemplate:
 return C;
 
   // Declaration kinds that don't make any sense here, but are
Index: lib/Serialization/ASTWriter.cpp
===
--- lib/Serialization/ASTWriter.cpp
+++ lib/Serialization/ASTWriter.cpp
@@ -5246,6 +5246,9 @@
 AddTemplateArgument(SubstPack->getArgumentPack(), Record);
 break;
   }
+  case TemplateName::BuiltinTemplate: {
+break;
+  }
   }
 }
 
Index: lib/Serialization/ASTReaderDecl.cpp
===
--- lib/Serialization/ASTReaderDecl.cpp
+++ lib/Serialization/ASTReaderDecl.cpp
@@ -293,6 +293,7 @@
 DeclID VisitTemplateDecl(TemplateDecl *D);
 RedeclarableResult VisitRedeclarableTemplateDecl(RedeclarableTemplateDecl *D);
 void VisitClassTemplateDecl(ClassTemplateDecl *D);
+void VisitBuiltinTemplateDecl(BuiltinTemplateDecl *D);
 void VisitVarTemplateDecl(VarTemplateDecl *D);
 void VisitFunctionTemplateDecl(FunctionTemplateDecl *D);
 void VisitTemplateTemplateParmDecl(TemplateTemplateParmDecl *D);
@@ -1856,6 +1857,10 @@
   }
 }
 
+void ASTDeclReader::VisitBuiltinTemplateDecl(BuiltinTemplateDecl *D) {
+  llvm_unreachable("BuiltinTemplates are not serialized");
+}
+
 /// TODO: Unify with ClassTemplateDecl version?
 ///   May require unifying ClassTemplateDecl and
 ///VarTemplateDecl beyond TemplateDecl...
Index: lib/Serialization/ASTReader.cpp
===
--- lib/Serialization/ASTReader.cpp
+++ lib/Serialization/ASTReader.cpp
@@ -7619,6 +7619,9 @@
 
 return Context.getSubstTemplateTemplateParmPack(Param, ArgPack);
   }
+  case TemplateName::BuiltinTemplate: {
+return Context.getBuiltinTemplateName();
+  }
   }
 
   llvm_unreachable("Unhandled template name kind!");
Index: lib/Serialization/ASTCommon.cpp
===
--- lib/Serialization/ASTCommon.cpp
+++ lib/Serialization/ASTCommon.cpp
@@ -329,6 +329,7 @@
   case Decl::ClassScopeFunctionSpecialization:
   case Decl::Import:
   case Decl::OMPThreadPrivate:
+  case Decl::BuiltinTemplate:
 return false;
 
   // These indirectly derive from Redeclarable but are not actually
Index: lib/Sema/TreeTransform.h
===
--- lib/Sema/TreeTransform.h
+++ lib/Sema/TreeTransform.h
@@ -3454,6 +3454,9 @@
 SubstPack->getArgumentPack());
   }
 
+  if (Name.getKind() == TemplateName::BuiltinTemplate)
+return Name;
+
   // These should be getting filtered out before they reach the AST.
   llvm_unreachable("overloaded function decl survived to here");
 }
Index: lib/Sema/SemaTemplateInstantiateDecl.cpp
===
--- lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -922,6 +922,11 @@
   llvm_unreachable("EnumConstantDecls can only occur within EnumDecls.");
 }
 
+Decl *
+TemplateDeclInstantiator::VisitBuiltinTemplateDecl(BuiltinTemplateDecl *D) {
+  llvm_unreachable("BuiltinTemplateDecls cannot be instantiated.");
+}
+
 Decl *TemplateDeclInstantiator::VisitClassTemplateDecl(ClassTemplateDecl *D) {
   bool isFriend = (D->getFriendObjectKind() 

Re: [libcxx] r249738 - Split out of .

[Richard Smith via cfe-commits]

On Thu, Oct 15, 2015 at 11:14 AM, Adrian Prantl  wrote:

>
> On Oct 14, 2015, at 5:07 PM, Richard Smith  wrote:
>
> Ack, there are non-modular headers in the Darwin module. =( I seem to
> recall that they're not version-locked to your compiler, so we've got to
> support them as-is?
>
> If we can't turn on local submodule visibility, then we need a module map
> for libc++ that covers all of its headers. I'll look into pruning the
> include path when building a module from an implicitly-loaded module map.
>
>
> The attached patch implements this in the most hacky way; with it I can
> successfully compile the first few hundred files of LLVM.
>

Great, it looks like this plan should work then. What failure do you
eventually hit? Does it look related to these  changes?

I'm working on a more refined version of the approach I described earlier;
I'll mail you a patch to test when I have it finished.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r250470 - Fix the subtarget features required by some x86 builtins.

[Eric Christopher via cfe-commits]

Author: echristo
Date: Thu Oct 15 17:46:02 2015
New Revision: 250470

URL: http://llvm.org/viewvc/llvm-project?rev=250470=rev
Log:
Fix the subtarget features required by some x86 builtins.

Update the fma builtins to be fma/fma4 until some we can find some
documentation either way.

Update a couple of the avx intrinsics because they were in the wrong
category.

Modified:
cfe/trunk/include/clang/Basic/BuiltinsX86.def

Modified: cfe/trunk/include/clang/Basic/BuiltinsX86.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsX86.def?rev=250470=250469=250470=diff
==
--- cfe/trunk/include/clang/Basic/BuiltinsX86.def (original)
+++ cfe/trunk/include/clang/Basic/BuiltinsX86.def Thu Oct 15 17:46:02 2015
@@ -718,38 +718,38 @@ TARGET_BUILTIN(__builtin_ia32_sha256msg1
 TARGET_BUILTIN(__builtin_ia32_sha256msg2, "V4iV4iV4i", "", "sha")
 
 // FMA
-TARGET_BUILTIN(__builtin_ia32_vfmaddps, "V4fV4fV4fV4f", "", "fma")
-TARGET_BUILTIN(__builtin_ia32_vfmaddpd, "V2dV2dV2dV2d", "", "fma")
-TARGET_BUILTIN(__builtin_ia32_vfmaddss, "V4fV4fV4fV4f", "", "fma")
-TARGET_BUILTIN(__builtin_ia32_vfmaddsd, "V2dV2dV2dV2d", "", "fma")
-TARGET_BUILTIN(__builtin_ia32_vfmsubps, "V4fV4fV4fV4f", "", "fma")
-TARGET_BUILTIN(__builtin_ia32_vfmsubpd, "V2dV2dV2dV2d", "", "fma")
-TARGET_BUILTIN(__builtin_ia32_vfmsubss, "V4fV4fV4fV4f", "", "fma")
-TARGET_BUILTIN(__builtin_ia32_vfmsubsd, "V2dV2dV2dV2d", "", "fma")
-TARGET_BUILTIN(__builtin_ia32_vfnmaddps, "V4fV4fV4fV4f", "", "fma")
-TARGET_BUILTIN(__builtin_ia32_vfnmaddpd, "V2dV2dV2dV2d", "", "fma")
-TARGET_BUILTIN(__builtin_ia32_vfnmaddss, "V4fV4fV4fV4f", "", "fma")
-TARGET_BUILTIN(__builtin_ia32_vfnmaddsd, "V2dV2dV2dV2d", "", "fma")
-TARGET_BUILTIN(__builtin_ia32_vfnmsubps, "V4fV4fV4fV4f", "", "fma")
-TARGET_BUILTIN(__builtin_ia32_vfnmsubpd, "V2dV2dV2dV2d", "", "fma")
-TARGET_BUILTIN(__builtin_ia32_vfnmsubss, "V4fV4fV4fV4f", "", "fma")
-TARGET_BUILTIN(__builtin_ia32_vfnmsubsd, "V2dV2dV2dV2d", "", "fma")
-TARGET_BUILTIN(__builtin_ia32_vfmaddsubps, "V4fV4fV4fV4f", "", "fma")
-TARGET_BUILTIN(__builtin_ia32_vfmaddsubpd, "V2dV2dV2dV2d", "", "fma")
-TARGET_BUILTIN(__builtin_ia32_vfmsubaddps, "V4fV4fV4fV4f", "", "fma")
-TARGET_BUILTIN(__builtin_ia32_vfmsubaddpd, "V2dV2dV2dV2d", "", "fma")
-TARGET_BUILTIN(__builtin_ia32_vfmaddps256, "V8fV8fV8fV8f", "", "fma")
-TARGET_BUILTIN(__builtin_ia32_vfmaddpd256, "V4dV4dV4dV4d", "", "fma")
-TARGET_BUILTIN(__builtin_ia32_vfmsubps256, "V8fV8fV8fV8f", "", "fma")
-TARGET_BUILTIN(__builtin_ia32_vfmsubpd256, "V4dV4dV4dV4d", "", "fma")
-TARGET_BUILTIN(__builtin_ia32_vfnmaddps256, "V8fV8fV8fV8f", "", "fma")
-TARGET_BUILTIN(__builtin_ia32_vfnmaddpd256, "V4dV4dV4dV4d", "", "fma")
-TARGET_BUILTIN(__builtin_ia32_vfnmsubps256, "V8fV8fV8fV8f", "", "fma")
-TARGET_BUILTIN(__builtin_ia32_vfnmsubpd256, "V4dV4dV4dV4d", "", "fma")
-TARGET_BUILTIN(__builtin_ia32_vfmaddsubps256, "V8fV8fV8fV8f", "", "fma")
-TARGET_BUILTIN(__builtin_ia32_vfmaddsubpd256, "V4dV4dV4dV4d", "", "fma")
-TARGET_BUILTIN(__builtin_ia32_vfmsubaddps256, "V8fV8fV8fV8f", "", "fma")
-TARGET_BUILTIN(__builtin_ia32_vfmsubaddpd256, "V4dV4dV4dV4d", "", "fma")
+TARGET_BUILTIN(__builtin_ia32_vfmaddps, "V4fV4fV4fV4f", "", "fma,fma4")
+TARGET_BUILTIN(__builtin_ia32_vfmaddpd, "V2dV2dV2dV2d", "", "fma,fma4")
+TARGET_BUILTIN(__builtin_ia32_vfmaddss, "V4fV4fV4fV4f", "", "fma,fma4")
+TARGET_BUILTIN(__builtin_ia32_vfmaddsd, "V2dV2dV2dV2d", "", "fma,fma4")
+TARGET_BUILTIN(__builtin_ia32_vfmsubps, "V4fV4fV4fV4f", "", "fma,fma4")
+TARGET_BUILTIN(__builtin_ia32_vfmsubpd, "V2dV2dV2dV2d", "", "fma,fma4")
+TARGET_BUILTIN(__builtin_ia32_vfmsubss, "V4fV4fV4fV4f", "", "fma,fma4")
+TARGET_BUILTIN(__builtin_ia32_vfmsubsd, "V2dV2dV2dV2d", "", "fma,fma4")
+TARGET_BUILTIN(__builtin_ia32_vfnmaddps, "V4fV4fV4fV4f", "", "fma,fma4")
+TARGET_BUILTIN(__builtin_ia32_vfnmaddpd, "V2dV2dV2dV2d", "", "fma,fma4")
+TARGET_BUILTIN(__builtin_ia32_vfnmaddss, "V4fV4fV4fV4f", "", "fma,fma4")
+TARGET_BUILTIN(__builtin_ia32_vfnmaddsd, "V2dV2dV2dV2d", "", "fma,fma4")
+TARGET_BUILTIN(__builtin_ia32_vfnmsubps, "V4fV4fV4fV4f", "", "fma,fma4")
+TARGET_BUILTIN(__builtin_ia32_vfnmsubpd, "V2dV2dV2dV2d", "", "fma,fma4")
+TARGET_BUILTIN(__builtin_ia32_vfnmsubss, "V4fV4fV4fV4f", "", "fma,fma4")
+TARGET_BUILTIN(__builtin_ia32_vfnmsubsd, "V2dV2dV2dV2d", "", "fma,fma4")
+TARGET_BUILTIN(__builtin_ia32_vfmaddsubps, "V4fV4fV4fV4f", "", "fma,fma4")
+TARGET_BUILTIN(__builtin_ia32_vfmaddsubpd, "V2dV2dV2dV2d", "", "fma,fma4")
+TARGET_BUILTIN(__builtin_ia32_vfmsubaddps, "V4fV4fV4fV4f", "", "fma,fma4")
+TARGET_BUILTIN(__builtin_ia32_vfmsubaddpd, "V2dV2dV2dV2d", "", "fma,fma4")
+TARGET_BUILTIN(__builtin_ia32_vfmaddps256, "V8fV8fV8fV8f", "", "fma,fma4")
+TARGET_BUILTIN(__builtin_ia32_vfmaddpd256, "V4dV4dV4dV4d", "", "fma,fma4")
+TARGET_BUILTIN(__builtin_ia32_vfmsubps256, "V8fV8fV8fV8f", "", "fma,fma4")
+TARGET_BUILTIN(__builtin_ia32_vfmsubpd256, "V4dV4dV4dV4d", "", "fma,fma4")

Re: [PATCH] D12761: MPI-Checker patch for Clang Static Analyzer

[Alexander Droste via cfe-commits]

Alexander_Droste added a comment.

Sorry about the delay.



Comment at: tools/clang/lib/StaticAnalyzer/Checkers/MPI-Checker/MPITypes.h:67
@@ +66,3 @@
+  // Every time a request is 'set' a new 'RequestId' gets created.
+  // Therefore, the 'UserKind' does not need to be profiled.
+  const int RequestId{RequestIdCount++};

zaks.anna wrote:
> Alexander_Droste wrote:
> > zaks.anna wrote:
> > > Still it looks like you have several pieces of information in the state 
> > > that are redundant.. Looks like you've added more now.
> > > 
> > > For example, why do we need RequestId? Each report will only talk about a 
> > > single request, is this not the case?
> > > 
> > > Do you absolutely need to store LastUser and VariableName?
> > > 
> > > Note that storing in the state is very expensive; on the other hand, we 
> > > can afford to perform costly analysis on post-processing of an error 
> > > report. This is why all other checkers store minimal information in the 
> > > state, usually just a single enum and determine all the other information 
> > > during the walk over the error path in BugReporterVisitor. The visitor 
> > > will visit all nodes that you visited while reporting this bug, so it 
> > > should have access to all the information you need.
> > > 
> > I need the RequestID to distinct function calls of the same type 
> > and location using the request multiple times along the path.
> > Like in a loop:
> > ```
> > for int i ...
> >nonblocking(.., request) // double nonblocking
> > ```
> > 
> > > Do you absolutely need to store LastUser and VariableName?
> > Absolutely not. :D I will remove the string member.
> > The variable name retrieval can be delayed to the point where the report is 
> > created.
> > 
> > I can also remove the enum, as the state of the request can be derived from 
> > the LastUser.
> > The reason why I added the enum member, is that I was concerned about that 
> > the CallEventRef
> > can be invalid to reference again if the call is inlined from an 
> > implementation defined in a header. 
> > As this seems not to be the case, I can remove the redundancy.
> > 
> > > This is why all other checkers store minimal information in the state, 
> > > usually just a single enum and determine all the other information during 
> > > the walk over the error path in BugReporterVisitor.
> > 
> > Ah, I get it. Until now that seemed a bit overly complicated to me.
> I suspect the only thing you need in Request is the enum; everything else can 
> be determined while visiting the path. 
> 
> This should be in ento namespace not in the clang namespace.
I think you're right that the enum is sufficient.
Thus for better diagnostics the source range
of the CallEventRef (LastUser)
should be obtained by the BugReportVisitor.
Is it possible to obtain a CallEventRef based on
a memory region? So conceptually this would mean
to find the last function call (before the error node) using 
a specific region.
 


http://reviews.llvm.org/D12761



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

[PATCH] D13786: [Sema] Implement __make_integer_seq

[David Majnemer via cfe-commits]

majnemer created this revision.
majnemer added a reviewer: rsmith.
majnemer added a subscriber: cfe-commits.

This new builtin template allows for incredibly fast instantiations of
templates like std::integer_sequence.

Performance numbers follow:
My work station has 64 GB of ram + 20 Xeon Cores at 2.8 GHz.

__make_integer_seq takes 0.25
seconds.

std::make_integer_sequence takes unbound time, it is still
running.  Clang is consuming gigabytes of memory.

http://reviews.llvm.org/D13786

Files:
  include/clang/AST/ASTContext.h
  include/clang/AST/DataRecursiveASTVisitor.h
  include/clang/AST/DeclTemplate.h
  include/clang/AST/RecursiveASTVisitor.h
  include/clang/AST/TemplateName.h
  include/clang/Basic/DeclNodes.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/TokenKinds.def
  include/clang/Sema/Sema.h
  lib/AST/ASTContext.cpp
  lib/AST/ASTDumper.cpp
  lib/AST/ASTImporter.cpp
  lib/AST/DeclBase.cpp
  lib/AST/DeclTemplate.cpp
  lib/AST/ItaniumMangle.cpp
  lib/AST/TemplateName.cpp
  lib/AST/Type.cpp
  lib/CodeGen/CGDecl.cpp
  lib/Parse/ParseDecl.cpp
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaTemplate.cpp
  lib/Sema/SemaTemplateInstantiateDecl.cpp
  lib/Sema/TreeTransform.h
  lib/Serialization/ASTCommon.cpp
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTReaderDecl.cpp
  lib/Serialization/ASTWriter.cpp
  tools/libclang/CIndex.cpp

Index: tools/libclang/CIndex.cpp
===
--- tools/libclang/CIndex.cpp
+++ tools/libclang/CIndex.cpp
@@ -1392,6 +1392,9 @@
 return Visit(MakeCursorTemplateRef(
   Name.getAsSubstTemplateTemplateParmPack()->getParameterPack(),
Loc, TU));
+
+  case TemplateName::BuiltinTemplate:
+return false;
   }
 
   llvm_unreachable("Invalid TemplateName::Kind!");
@@ -5110,6 +5113,7 @@
   case Decl::Import:
   case Decl::OMPThreadPrivate:
   case Decl::ObjCTypeParam:
+  case Decl::BuiltinTemplate:
 return C;
 
   // Declaration kinds that don't make any sense here, but are
Index: lib/Serialization/ASTWriter.cpp
===
--- lib/Serialization/ASTWriter.cpp
+++ lib/Serialization/ASTWriter.cpp
@@ -5246,6 +5246,9 @@
 AddTemplateArgument(SubstPack->getArgumentPack(), Record);
 break;
   }
+  case TemplateName::BuiltinTemplate: {
+break;
+  }
   }
 }
 
Index: lib/Serialization/ASTReaderDecl.cpp
===
--- lib/Serialization/ASTReaderDecl.cpp
+++ lib/Serialization/ASTReaderDecl.cpp
@@ -293,6 +293,7 @@
 DeclID VisitTemplateDecl(TemplateDecl *D);
 RedeclarableResult VisitRedeclarableTemplateDecl(RedeclarableTemplateDecl *D);
 void VisitClassTemplateDecl(ClassTemplateDecl *D);
+void VisitBuiltinTemplateDecl(BuiltinTemplateDecl *D);
 void VisitVarTemplateDecl(VarTemplateDecl *D);
 void VisitFunctionTemplateDecl(FunctionTemplateDecl *D);
 void VisitTemplateTemplateParmDecl(TemplateTemplateParmDecl *D);
@@ -1856,6 +1857,10 @@
   }
 }
 
+void ASTDeclReader::VisitBuiltinTemplateDecl(BuiltinTemplateDecl *D) {
+  //
+}
+
 /// TODO: Unify with ClassTemplateDecl version?
 ///   May require unifying ClassTemplateDecl and
 ///VarTemplateDecl beyond TemplateDecl...
Index: lib/Serialization/ASTReader.cpp
===
--- lib/Serialization/ASTReader.cpp
+++ lib/Serialization/ASTReader.cpp
@@ -7619,6 +7619,9 @@
 
 return Context.getSubstTemplateTemplateParmPack(Param, ArgPack);
   }
+  case TemplateName::BuiltinTemplate: {
+return Context.getBuiltinTemplateName();
+  }
   }
 
   llvm_unreachable("Unhandled template name kind!");
Index: lib/Serialization/ASTCommon.cpp
===
--- lib/Serialization/ASTCommon.cpp
+++ lib/Serialization/ASTCommon.cpp
@@ -329,6 +329,7 @@
   case Decl::ClassScopeFunctionSpecialization:
   case Decl::Import:
   case Decl::OMPThreadPrivate:
+  case Decl::BuiltinTemplate:
 return false;
 
   // These indirectly derive from Redeclarable but are not actually
Index: lib/Sema/TreeTransform.h
===
--- lib/Sema/TreeTransform.h
+++ lib/Sema/TreeTransform.h
@@ -3454,6 +3454,9 @@
 SubstPack->getArgumentPack());
   }
 
+  if (Name.getKind() == TemplateName::BuiltinTemplate)
+return Name;
+
   // These should be getting filtered out before they reach the AST.
   llvm_unreachable("overloaded function decl survived to here");
 }
Index: lib/Sema/SemaTemplateInstantiateDecl.cpp
===
--- lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -922,6 +922,11 @@
   llvm_unreachable("EnumConstantDecls can only occur 

Re: [libcxx] r249738 - Split out of .

[Adrian Prantl via cfe-commits]

> On Oct 15, 2015, at 2:09 PM, Adrian Prantl via cfe-commits 
>  wrote:
> 
>> 
>> On Oct 15, 2015, at 1:42 PM, Richard Smith > > wrote:
>> 
>> On Thu, Oct 15, 2015 at 11:14 AM, Adrian Prantl > > wrote:
>> 
>>> On Oct 14, 2015, at 5:07 PM, Richard Smith >> > wrote:
>>> 
>>> Ack, there are non-modular headers in the Darwin module. =( I seem to 
>>> recall that they're not version-locked to your compiler, so we've got to 
>>> support them as-is?
>>> 
>>> If we can't turn on local submodule visibility, then we need a module map 
>>> for libc++ that covers all of its headers. I'll look into pruning the 
>>> include path when building a module from an implicitly-loaded module map.
>> 
>> The attached patch implements this in the most hacky way; with it I can 
>> successfully compile the first few hundred files of LLVM.
>> 
>> Great, it looks like this plan should work then. What failure do you 
>> eventually hit? Does it look related to these  changes?
> 
> So far I fixed 250446  and 250459 which were both just missing include files. 
> I’m puzzled by 250459 though, as there is nothing Darwin-specific about the 
> change. I’ll keep iterating and will let you know if there are any 
> libc++-related problems.
> 
>> 
>> I'm working on a more refined version of the approach I described earlier; 
>> I'll mail you a patch to test when I have it finished.
> 
> That sounds great.
> 
> thanks,
> adrian

Here’s a weird one:

../lib/Transforms/Scalar/ScalarReplAggregates.cpp:1031:6: error: 'SROA' is not 
a class, namespace, or enumeration
bool SROA::runOnFunction(Function ) {
 ^
../lib/Transforms/Scalar/ScalarReplAggregates.cpp:1031:6: error: reference to 
'SROA' is ambiguous
../include/llvm/Transforms/Scalar/SROA.h:54:7: note: candidate found by name 
lookup is 'llvm::SROA'
class SROA {
  ^
../lib/Transforms/Scalar/ScalarReplAggregates.cpp:63:10: note: candidate found 
by name lookup is '(anonymous namespace)::SROA'
  struct SROA : public FunctionPass {
 ^

this doesn’t look Darwin-specific at all. Assuming that the Linux module build 
works, why am I seeing this?

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

Re: [libcxx] r250256 - Workaround -pedantic flag added by LLVM

[Eric Fiselier via cfe-commits]

Removes it because "-Wno-pedantic" incorrectly matches -pedantic? If my
guess is correct, whoops :-(

On Thu, Oct 15, 2015 at 1:51 PM, Evgenii Stepanov  wrote:

> Guess what this does to the -Wno-pedantic flag added by MSan? :)
>
> On Tue, Oct 13, 2015 at 4:56 PM, Eric Fiselier via cfe-commits
>  wrote:
> > Author: ericwf
> > Date: Tue Oct 13 18:56:33 2015
> > New Revision: 250256
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=250256=rev
> > Log:
> > Workaround -pedantic flag added by LLVM
> >
> > Modified:
> > libcxx/trunk/CMakeLists.txt
> >
> > Modified: libcxx/trunk/CMakeLists.txt
> > URL:
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=250256=250255=250256=diff
> >
> ==
> > --- libcxx/trunk/CMakeLists.txt (original)
> > +++ libcxx/trunk/CMakeLists.txt Tue Oct 13 18:56:33 2015
> > @@ -198,6 +198,10 @@ include(HandleLibcxxFlags)
> >  remove_flags(-DNDEBUG -UNDEBUG -D_DEBUG
> >   -stdlib=libc++ -stdlib=libstdc++ -lc++abi -m32)
> >
> > +# FIXME(EricWF): See the FIXME on LIBCXX_ENABLE_PEDANTIC.
> > +# Remove the -pedantic flag provided by LLVM.
> > +remove_flags(-pedantic)
> > +
> >  # Required flags
> ==
> >  add_compile_flags_if_supported(-std=c++11)
> >  if (NOT MSVC AND NOT LIBCXX_SUPPORTS_STD_EQ_CXX11_FLAG)
> >
> >
> > ___
> > 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: [libcxx] r250256 - Workaround -pedantic flag added by LLVM

[Evgenii Stepanov via cfe-commits]

It looks like, since libc++ removes -pedantic, we don't need to add
-Wno-pedantic, so I can just fix it in MSan. It would probably make
sense for libc++ to remove -Wno-pedantic before removing -pedantic.

On Thu, Oct 15, 2015 at 12:57 PM, Evgenii Stepanov
 wrote:
> Transforms it to -Wno.
>
> On Thu, Oct 15, 2015 at 12:56 PM, Eric Fiselier  wrote:
>> Removes it because "-Wno-pedantic" incorrectly matches -pedantic? If my
>> guess is correct, whoops :-(
>>
>> On Thu, Oct 15, 2015 at 1:51 PM, Evgenii Stepanov
>>  wrote:
>>>
>>> Guess what this does to the -Wno-pedantic flag added by MSan? :)
>>>
>>> On Tue, Oct 13, 2015 at 4:56 PM, Eric Fiselier via cfe-commits
>>>  wrote:
>>> > Author: ericwf
>>> > Date: Tue Oct 13 18:56:33 2015
>>> > New Revision: 250256
>>> >
>>> > URL: http://llvm.org/viewvc/llvm-project?rev=250256=rev
>>> > Log:
>>> > Workaround -pedantic flag added by LLVM
>>> >
>>> > Modified:
>>> > libcxx/trunk/CMakeLists.txt
>>> >
>>> > Modified: libcxx/trunk/CMakeLists.txt
>>> > URL:
>>> > http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=250256=250255=250256=diff
>>> >
>>> > ==
>>> > --- libcxx/trunk/CMakeLists.txt (original)
>>> > +++ libcxx/trunk/CMakeLists.txt Tue Oct 13 18:56:33 2015
>>> > @@ -198,6 +198,10 @@ include(HandleLibcxxFlags)
>>> >  remove_flags(-DNDEBUG -UNDEBUG -D_DEBUG
>>> >   -stdlib=libc++ -stdlib=libstdc++ -lc++abi -m32)
>>> >
>>> > +# FIXME(EricWF): See the FIXME on LIBCXX_ENABLE_PEDANTIC.
>>> > +# Remove the -pedantic flag provided by LLVM.
>>> > +remove_flags(-pedantic)
>>> > +
>>> >  # Required flags
>>> > ==
>>> >  add_compile_flags_if_supported(-std=c++11)
>>> >  if (NOT MSVC AND NOT LIBCXX_SUPPORTS_STD_EQ_CXX11_FLAG)
>>> >
>>> >
>>> > ___
>>> > 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] D13549: Added new options to ClangFormat VSIX package.

[Zachary Turner via cfe-commits]

zturner added a comment.

No obvious problems, mostly just style issues.  Feel free to consider them 
optional.



Comment at: tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs:38
@@ +37,3 @@
+private bool sortIncludes = false;
+private string style = "file";
+

How about an enum instead?  

private enum Style {
File,
Chromium,
Google,
LLVM,
Mozilla,
Webkit
}
private Style style;


Then change the `StyleConverter` to just convert the enum value to its 
corresponding string representation?


Comment at: tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs:42-47
@@ +41,8 @@
+{
+protected ArrayList values;
+public StyleConverter()
+{
+// Initializes the standard values list with defaults.
+values = new ArrayList(new string[] { "file", "Chromium", 
"Google", "LLVM", "Mozilla", "WebKit" });
+}
+

This would all go away


Comment at: tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs:56
@@ +55,3 @@
+{
+return new StandardValuesCollection(values);
+}

This becomes `return new 
StandardValuesCollection(Enum.GetValues(typeof(Style)))`


Comment at: tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs:61-64
@@ +60,6 @@
+{
+if (sourceType == typeof(string))
+return true;
+
+return base.CanConvertFrom(context, sourceType);
+}

This becomes `sourceType == typeof(Style) || base.CanConvertFrom(context, 
sourceType)`


Comment at: tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs:69-73
@@ +68,7 @@
+{
+string s = value as string;
+if (s == null)
+return base.ConvertFrom(context, culture, value);
+
+return value;
+}

This becomes

Style s = value as Style;
if (value == null)
return base.ConvertFrom(context, culture, value);
return value.ToString();

(I think, I can't tell what the source and destination type are supposed to be 
here)


Comment at: tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs:92
@@ -51,2 +91,3 @@
+[TypeConverter(typeof(StyleConverter))]
 public string Style
 {

Now you can return an enum here instead of a string


Comment at: tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs:115
@@ +114,3 @@
+// Check if string contains quotes. On Windows, file names 
cannot contain quotes.
+// We do not accept them however to avoid hard-to-debug 
problems.
+// A quote in user input would end the parameter quote and so 
break the command invocation.

Wouldn't it be better to just return `false` from `CanConvertFrom` if the 
filename contains quotes?  Then you can assert in this function that it does 
not contain quotes?


Comment at: tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs:136-143
@@ +135,10 @@
+
+public sealed class FallbackStyleConverter : StyleConverter
+{
+public FallbackStyleConverter()
+{
+// Add "none" to the list of styles.
+values.Insert(0, "none");
+}
+}
+

Same comment as before, but use the enum.s  I guess you would need to make 
`None` one of the actual style enum values, but remove it before returning the 
list in the other StyleConverter.  


Comment at: tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs:331-347
@@ -213,1 +330,19 @@
 
+private string GetAssumeFilename()
+{
+var page = (OptionPageGrid)GetDialogPage(typeof(OptionPageGrid));
+return page.AssumeFilename;
+}
+
+private string GetFallbackStyle()
+{
+var page = (OptionPageGrid)GetDialogPage(typeof(OptionPageGrid));
+return page.FallbackStyle;
+}
+
+private bool GetSortIncludes()
+{
+var page = (OptionPageGrid)GetDialogPage(typeof(OptionPageGrid));
+return page.SortIncludes;
+}
+

Maybe you could use properties instead of functions.


http://reviews.llvm.org/D13549



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

Re: [libcxx] r249738 - Split out of .

[Alex Rosenberg via cfe-commits]

On Oct 15, 2015, at 2:20 PM, Adrian Prantl via cfe-commits 
 wrote:

>> 
>> On Oct 15, 2015, at 2:09 PM, Adrian Prantl via cfe-commits 
>>  wrote:
>> 
>>> 
>>> On Oct 15, 2015, at 1:42 PM, Richard Smith  wrote:
>>> 
>>> On Thu, Oct 15, 2015 at 11:14 AM, Adrian Prantl  wrote:
>>> 
 On Oct 14, 2015, at 5:07 PM, Richard Smith  wrote:
 
 Ack, there are non-modular headers in the Darwin module. =( I seem to 
 recall that they're not version-locked to your compiler, so we've got to 
 support them as-is?
 
 If we can't turn on local submodule visibility, then we need a module map 
 for libc++ that covers all of its headers. I'll look into pruning the 
 include path when building a module from an implicitly-loaded module map.
>>> 
>>> The attached patch implements this in the most hacky way; with it I can 
>>> successfully compile the first few hundred files of LLVM.
>>> 
>>> Great, it looks like this plan should work then. What failure do you 
>>> eventually hit? Does it look related to these  changes?
>> 
>> So far I fixed 250446  and 250459 which were both just missing include 
>> files. I’m puzzled by 250459 though, as there is nothing Darwin-specific 
>> about the change. I’ll keep iterating and will let you know if there are any 
>> libc++-related problems.
>> 
>>> 
>>> I'm working on a more refined version of the approach I described earlier; 
>>> I'll mail you a patch to test when I have it finished.
>> 
>> That sounds great.
>> 
>> thanks,
>> adrian
> 
> Here’s a weird one:
> 
> ../lib/Transforms/Scalar/ScalarReplAggregates.cpp:1031:6: error: 'SROA' is 
> not a class, namespace, or enumeration
> bool SROA::runOnFunction(Function ) {
>  ^
> ../lib/Transforms/Scalar/ScalarReplAggregates.cpp:1031:6: error: reference to 
> 'SROA' is ambiguous
> ../include/llvm/Transforms/Scalar/SROA.h:54:7: note: candidate found by name 
> lookup is 'llvm::SROA'
> class SROA {
>   ^
> ../lib/Transforms/Scalar/ScalarReplAggregates.cpp:63:10: note: candidate 
> found by name lookup is '(anonymous namespace)::SROA'
>   struct SROA : public FunctionPass {
>  ^
> 
> this doesn’t look Darwin-specific at all. Assuming that the Linux module 
> build works, why am I seeing this?

The Linux bot has the same problem: 
http://lab.llvm.org:8011/builders/clang-x86_64-linux-selfhost-modules/builds/7331/steps/compile.llvm.stage2/logs/stdio

++
| Alexander M. Rosenberg |
| Nobody cares what I say, so no disclaimer appears here.|

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

Re: [PATCH] D13785: [clang-tidy] add cert's VariadicFunctionDefCheck as cppcoreguidelines-pro-type-vararg-def

[Aaron Ballman via cfe-commits]

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

LGTM! (If you haven't already gotten commit privileges, now would be a good 
time to get them -- I will be out of town for two weeks starting Saturday, and 
alexfh is also currently out of town.)

~Aaron


http://reviews.llvm.org/D13785



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

Re: [PATCH] D13785: [clang-tidy] add cert's VariadicFunctionDefCheck as cppcoreguidelines-pro-type-vararg-def

[Matthias Gehre via cfe-commits]

mgehre added a comment.

I have commit privileges :-)


http://reviews.llvm.org/D13785



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

[libcxx] r250452 - Fix handling of -Wno-pedantic

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Thu Oct 15 15:27:15 2015
New Revision: 250452

URL: http://llvm.org/viewvc/llvm-project?rev=250452=rev
Log:
Fix handling of -Wno-pedantic

Modified:
libcxx/trunk/CMakeLists.txt

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=250452=250451=250452=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Thu Oct 15 15:27:15 2015
@@ -219,8 +219,9 @@ remove_flags(-DNDEBUG -UNDEBUG -D_DEBUG
  -stdlib=libc++ -stdlib=libstdc++ -lc++abi -m32)
 
 # FIXME(EricWF): See the FIXME on LIBCXX_ENABLE_PEDANTIC.
-# Remove the -pedantic flag provided by LLVM.
-remove_flags(-pedantic)
+# Remove the -pedantic flag and -Wno-pedantic and -pedantic-errors
+# so they don't get transformed into -Wno and -errors respectivly.
+remove_flags(-Wno-pedantic -pedantic-errors -pedantic)
 
 # Required flags ==
 add_compile_flags_if_supported(-std=c++11)


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

Re: [PATCH] D13357: [Concepts] Diagnose when 'concept' is specified on a specialization

[Nathan Wilson via cfe-commits]

nwilson updated this revision to Diff 37529.
nwilson added a comment.

Addressing Richard's other comment regarding the FunctionDecl being declared a 
concept check. Also, remove setting the FunctionDecl being Invalid in the 
Specialization check since the downstream parts of Clang should look at the 
primary template.


http://reviews.llvm.org/D13357

Files:
  include/clang/AST/Decl.h
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaTemplate.cpp
  test/CXX/concepts-ts/dcl.dcl/dcl.spec/dcl.spec.concept/p1.cpp

Index: test/CXX/concepts-ts/dcl.dcl/dcl.spec/dcl.spec.concept/p1.cpp
===
--- test/CXX/concepts-ts/dcl.dcl/dcl.spec/dcl.spec.concept/p1.cpp
+++ test/CXX/concepts-ts/dcl.dcl/dcl.spec/dcl.spec.concept/p1.cpp
@@ -39,3 +39,20 @@
 template  concept union TCU1 {}; // expected-error {{'concept' can only appear on the definition of a function template or variable template}}
 
 concept bool; // expected-error {{'concept' can only appear on the definition of a function template or variable template}}
+
+template concept bool VCEI { true };
+template concept bool VCEI; // expected-error {{'concept' cannot be applied on an explicit instantiation}}
+extern template concept bool VCEI; // expected-error {{'concept' cannot be applied on an explicit instantiation}}
+
+template concept bool VCPS { true };
+template concept bool VCPS { true }; // expected-error {{'concept' cannot be applied on an partial specialization}}
+
+template concept bool VCES { true };
+template<> concept bool VCES { true }; // expected-error {{'concept' cannot be applied on an explicit specialization}}
+
+template concept bool FCEI() { return true; }
+template concept bool FCEI(); // expected-error {{'concept' cannot be applied on an explicit instantiation}}
+extern template concept bool FCEI(); // expected-error {{'concept' cannot be applied on an explicit instantiation}}
+
+template concept bool FCES() { return true; }
+template<> concept bool FCES() { return true; } // expected-error {{'concept' cannot be applied on an explicit specialization}}
Index: lib/Sema/SemaTemplate.cpp
===
--- lib/Sema/SemaTemplate.cpp
+++ lib/Sema/SemaTemplate.cpp
@@ -7597,6 +7597,17 @@
 Diag(D.getDeclSpec().getConstexprSpecLoc(),
  diag::err_explicit_instantiation_constexpr);
 
+  // C++ Concepts TS [dcl.spec.concept]p1: The concept specifier shall be
+  // applied only to the definition of a function template or variable template,
+  // declared in namespace scope. A concept definition refers to either a
+  // function concept and its definition or a variable concept and its
+  // initializer.
+  if (D.getDeclSpec().isConceptSpecified()) {
+Diag(D.getDeclSpec().getConceptSpecLoc(),
+ diag:: err_concept_specified_specialization) << 0;
+return true;
+  }
+
   // C++0x [temp.explicit]p2:
   //   There are two forms of explicit instantiation: an explicit instantiation
   //   definition and an explicit instantiation declaration. An explicit
Index: lib/Sema/SemaDecl.cpp
===
--- lib/Sema/SemaDecl.cpp
+++ lib/Sema/SemaDecl.cpp
@@ -5898,6 +5898,17 @@
 << 0 << 3;
 NewVD->setInvalidDecl(true);
   }
+
+  // C++ Concepts TS [dcl.spec.concept]p1: The concept specifier shall be
+  // applied only to the definition of a [...] variable template, declared
+  // in namespace scope. [...] A concept definition refers to [...] a
+  // variable concept and its initializer.
+  if (IsVariableTemplateSpecialization) {
+Diag(D.getDeclSpec().getConceptSpecLoc(),
+ diag::err_concept_specified_specialization)
+  << (IsPartialSpecialization ? 2 : 1);
+NewVD->setInvalidDecl(true);
+  }
 }
   }
 
@@ -7544,6 +7555,9 @@
 }
 
 if (isConcept) {
+  // This is a function concept.
+  NewFD->setConcept(true);
+
   // C++ Concepts TS [dcl.spec.concept]p1: The concept specifier shall be
   // applied only to the definition of a function template [...]
   if (!D.isFunctionDefinition()) {
@@ -7595,6 +7609,15 @@
 << 1 << 3;
 NewFD->setInvalidDecl(true);
   }
+
+  // C++ Concepts TS [dcl.spec.concept]p1: The concept specifier shall be
+  // applied only to the definition of a function template [...], declared
+  // in namespace scope. [...] A concept definition refers to either a
+  // function concept and its definition [...].
+  if (isFunctionTemplateSpecialization) {
+Diag(D.getDeclSpec().getConceptSpecLoc(),
+ diag::err_concept_specified_specialization) << 1;
+  }
 }
 
 // If __module_private__ was specified, mark the function accordingly.
@@ -7858,7 +7881,7 @@
  TemplateArgs);
 
   HasExplicitTemplateArgs = true;
-
+
 

Re: [libcxx] r249738 - Split out of .

[Adrian Prantl via cfe-commits]

> On Oct 15, 2015, at 2:51 PM, Alex Rosenberg  wrote:
> 
> On Oct 15, 2015, at 2:20 PM, Adrian Prantl via cfe-commits 
> > wrote:
> 
>>> 
>>> On Oct 15, 2015, at 2:09 PM, Adrian Prantl via cfe-commits 
>>> > wrote:
>>> 
 
 On Oct 15, 2015, at 1:42 PM, Richard Smith > wrote:
 
 On Thu, Oct 15, 2015 at 11:14 AM, Adrian Prantl > wrote:
 
> On Oct 14, 2015, at 5:07 PM, Richard Smith  > wrote:
> 
> Ack, there are non-modular headers in the Darwin module. =( I seem to 
> recall that they're not version-locked to your compiler, so we've got to 
> support them as-is?
> 
> If we can't turn on local submodule visibility, then we need a module map 
> for libc++ that covers all of its headers. I'll look into pruning the 
> include path when building a module from an implicitly-loaded module map.
 
 The attached patch implements this in the most hacky way; with it I can 
 successfully compile the first few hundred files of LLVM.
 
 Great, it looks like this plan should work then. What failure do you 
 eventually hit? Does it look related to these  changes?
>>> 
>>> So far I fixed 250446  and 250459 which were both just missing include 
>>> files. I’m puzzled by 250459 though, as there is nothing Darwin-specific 
>>> about the change. I’ll keep iterating and will let you know if there are 
>>> any libc++-related problems.
>>> 
 
 I'm working on a more refined version of the approach I described earlier; 
 I'll mail you a patch to test when I have it finished.
>>> 
>>> That sounds great.
>>> 
>>> thanks,
>>> adrian
>> 
>> Here’s a weird one:
>> 
>> ../lib/Transforms/Scalar/ScalarReplAggregates.cpp:1031:6: error: 'SROA' is 
>> not a class, namespace, or enumeration
>> bool SROA::runOnFunction(Function ) {
>>  ^
>> ../lib/Transforms/Scalar/ScalarReplAggregates.cpp:1031:6: error: reference 
>> to 'SROA' is ambiguous
>> ../include/llvm/Transforms/Scalar/SROA.h:54:7: note: candidate found by name 
>> lookup is 'llvm::SROA'
>> class SROA {
>>   ^
>> ../lib/Transforms/Scalar/ScalarReplAggregates.cpp:63:10: note: candidate 
>> found by name lookup is '(anonymous namespace)::SROA'
>>   struct SROA : public FunctionPass {
>>  ^
>> 
>> this doesn’t look Darwin-specific at all. Assuming that the Linux module 
>> build works, why am I seeing this?
> 
> The Linux bot has the same problem: 
> http://lab.llvm.org:8011/builders/clang-x86_64-linux-selfhost-modules/builds/7331/steps/compile.llvm.stage2/logs/stdio
>  
> 
Oh :-) That bot does not look very happy:
http://lab.llvm.org:8011/builders/clang-x86_64-linux-selfhost-modules?numbuilds=1000

What’s the appropriate solution, renaming the struct ::SROA in the anonymous 
namespace to something else?

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

[PATCH] D13790: Add "-Wc++11-inline-namespace" so that libc++ can use -pedantic in C++03.

[Eric Fiselier via cfe-commits]

EricWF created this revision.
EricWF added a reviewer: rsmith.
EricWF added a subscriber: cfe-commits.

The title says it all.

http://reviews.llvm.org/D13790

Files:
  include/clang/Basic/DiagnosticGroups.td
  include/clang/Basic/DiagnosticParseKinds.td

Index: include/clang/Basic/DiagnosticParseKinds.td
===
--- include/clang/Basic/DiagnosticParseKinds.td
+++ include/clang/Basic/DiagnosticParseKinds.td
@@ -271,7 +271,7 @@
   "reference qualifiers on functions are incompatible with C++98">,
   InGroup, DefaultIgnore;
 def ext_inline_namespace : ExtWarn<
-  "inline namespaces are a C++11 feature">, InGroup;
+  "inline namespaces are a C++11 feature">, InGroup;
 def warn_cxx98_compat_inline_namespace : Warning<
   "inline namespaces are incompatible with C++98">,
   InGroup, DefaultIgnore;
Index: include/clang/Basic/DiagnosticGroups.td
===
--- include/clang/Basic/DiagnosticGroups.td
+++ include/clang/Basic/DiagnosticGroups.td
@@ -217,6 +217,7 @@
 def IncompleteModule : DiagGroup<"incomplete-module",
 [IncompleteUmbrella, NonModularIncludeInModule]>;
 
+def CXX11InlineNamespace : DiagGroup<"c++11-inline-namespace">;
 def InvalidNoreturn : DiagGroup<"invalid-noreturn">;
 def InvalidSourceEncoding : DiagGroup<"invalid-source-encoding">;
 def KNRPromotedParameter : DiagGroup<"knr-promoted-parameter">;
@@ -679,7 +680,8 @@
 
 // A warning group for warnings about using C++11 features as extensions in
 // earlier C++ versions.
-def CXX11 : DiagGroup<"c++11-extensions", [CXX11ExtraSemi, CXX11LongLong]>;
+def CXX11 : DiagGroup<"c++11-extensions", [CXX11ExtraSemi, 
CXX11InlineNamespace,
+   CXX11LongLong]>;
 
 // A warning group for warnings about using C++14 features as extensions in
 // earlier C++ versions.


Index: include/clang/Basic/DiagnosticParseKinds.td
===
--- include/clang/Basic/DiagnosticParseKinds.td
+++ include/clang/Basic/DiagnosticParseKinds.td
@@ -271,7 +271,7 @@
   "reference qualifiers on functions are incompatible with C++98">,
   InGroup, DefaultIgnore;
 def ext_inline_namespace : ExtWarn<
-  "inline namespaces are a C++11 feature">, InGroup;
+  "inline namespaces are a C++11 feature">, InGroup;
 def warn_cxx98_compat_inline_namespace : Warning<
   "inline namespaces are incompatible with C++98">,
   InGroup, DefaultIgnore;
Index: include/clang/Basic/DiagnosticGroups.td
===
--- include/clang/Basic/DiagnosticGroups.td
+++ include/clang/Basic/DiagnosticGroups.td
@@ -217,6 +217,7 @@
 def IncompleteModule : DiagGroup<"incomplete-module",
 [IncompleteUmbrella, NonModularIncludeInModule]>;
 
+def CXX11InlineNamespace : DiagGroup<"c++11-inline-namespace">;
 def InvalidNoreturn : DiagGroup<"invalid-noreturn">;
 def InvalidSourceEncoding : DiagGroup<"invalid-source-encoding">;
 def KNRPromotedParameter : DiagGroup<"knr-promoted-parameter">;
@@ -679,7 +680,8 @@
 
 // A warning group for warnings about using C++11 features as extensions in
 // earlier C++ versions.
-def CXX11 : DiagGroup<"c++11-extensions", [CXX11ExtraSemi, CXX11LongLong]>;
+def CXX11 : DiagGroup<"c++11-extensions", [CXX11ExtraSemi, CXX11InlineNamespace,
+   CXX11LongLong]>;
 
 // A warning group for warnings about using C++14 features as extensions in
 // earlier C++ versions.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249929 - Split out of .

[Richard Smith via cfe-commits]

On Thu, Oct 15, 2015 at 12:03 PM, Manman Ren via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
> On Oct 15, 2015, at 11:25 AM, Richard Smith  wrote:
>
> I assume the code in question has a "using namespace std;"?
>
> Yes
>
> I don't see any way around this other than giving up on trying to fix the
> function signatures here (or maybe adding a Clang feature to let us fix the
> bad signature).
>
> Can you elaborate on how to fix the bad signature by adding a Clang
> feature? I want to see how hard it is before giving up on trying to fix the
> signatures.
>

I thought about this a bit more, and we already have a feature that can be
used for this.

Please let me know if the attached patch resolves the issue for you. This
should also fix the wrong overload sets for these functions being provided
by  on Darwin.


Eric, Marshall: the attached patch adds a macro _LIBCPP_PREFERRED_OVERLOAD
that can be applied to a function to (a) mark it as a separate overload
from any other function with the same signature without the overload, and
(b) instruct the compiler that it's preferred over another function with
the same signature without the attribute. This allows us to replace the
libc function

  char *strchr(const char *, int);

with the C++ overload set:

  const char *strchr(const char *, int);
  char *strchr(char *, int);

It only works with Clang, though; for other compilers, we leave the C
library's signature alone (as we used to before my patches landed).

Thanks,
> Manman
>
>
> On Oct 15, 2015 11:07 AM, "Manman Ren via cfe-commits" <
> cfe-commits@lists.llvm.org> wrote:
>
>> Hi Richard,
>>
>> This is causing a failure when building povray on iOS.
>>
>> Compilation error:
>> /Users/buildslave/tmp/test-suite-externals/speccpu2006/benchspec/CPU2006/453.povray/src/fileinputoutput.cpp:364:20:
>> error: call to 'strrchr' is ambiguous
>>  const char *p=strrchr(name, '.’);
>>
>> iOS.sdk/usr/include/string.h:87:7: note: candidate function
>> char*strrchr(const char *, int);
>>  ^
>> /Users/buildslave/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cstring:109:46:
>> note: candidate function
>> inline _LIBCPP_INLINE_VISIBILITY const char* strrchr(const char* __s, int
>> __c) {return ::strrchr(__s, __c);}
>>
>> It is a little strange to have "char*strrchr(const char *, int);” in
>> iOS. But it is already in our SDK.
>>
>> Do you have any suggestion on how to fix this?
>>
>> Thanks,
>> Manman
>>
>> > On Oct 9, 2015, at 6:25 PM, Richard Smith via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>> >
>> > Author: rsmith
>> > Date: Fri Oct  9 20:25:31 2015
>> > New Revision: 249929
>> >
>> > URL: http://llvm.org/viewvc/llvm-project?rev=249929=rev
>> > Log:
>> > Split  out of .
>> >
>> > Also fix the overload set for the five functions whose signatures
>> change in the
>> > case where we can fix it. This is already covered by existing tests for
>> the
>> > affected systems.
>> >
>> > Added:
>> >libcxx/trunk/include/string.h
>> >  - copied, changed from r249736, libcxx/trunk/include/cstring
>> > Modified:
>> >libcxx/trunk/include/cstring
>> >
>> > Modified: libcxx/trunk/include/cstring
>> > URL:
>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/cstring?rev=249929=249928=249929=diff
>> >
>> ==
>> > --- libcxx/trunk/include/cstring (original)
>> > +++ libcxx/trunk/include/cstring Fri Oct  9 20:25:31 2015
>> > @@ -78,37 +78,42 @@ using ::strcmp;
>> > using ::strncmp;
>> > using ::strcoll;
>> > using ::strxfrm;
>> > +using ::strcspn;
>> > +using ::strspn;
>> > +#ifndef _LIBCPP_HAS_NO_THREAD_UNSAFE_C_FUNCTIONS
>> > +using ::strtok;
>> > +#endif
>> > +using ::memset;
>> > +using ::strerror;
>> > +using ::strlen;
>> >
>> > -using ::memchr;
>> > +// MSVCRT, GNU libc and its derivates already have the correct
>> prototype in
>> > +//  if __cplusplus is defined. This macro can be defined by
>> users if
>> > +// their C library provides the right signature.
>> > +#if defined(__GLIBC__) || defined(_LIBCPP_MSVCRT) || defined(__sun__)
>> || \
>> > +defined(_STRING_H_CPLUSPLUS_98_CONFORMANCE_)
>> > +#define _LIBCPP_STRING_H_HAS_CONST_OVERLOADS
>> > +#endif
>> >
>> > +#ifdef _LIBCPP_STRING_H_HAS_CONST_OVERLOADS
>> > using ::strchr;
>> > -
>> > -using ::strcspn;
>> > -
>> > using ::strpbrk;
>> > -
>> > using ::strrchr;
>> > -
>> > -using ::strspn;
>> > -
>> > +using ::memchr;
>> > using ::strstr;
>> > -
>> > -// MSVCRT, GNU libc and its derivates already have the correct
>> prototype in  #ifdef __cplusplus
>> > -#if !defined(__GLIBC__) && !defined(_LIBCPP_MSVCRT) &&
>> !defined(__sun__) && !defined(_STRING_H_CPLUSPLUS_98_CONFORMANCE_)
>> > +#else
>> > +inline _LIBCPP_INLINE_VISIBILITY const char* strchr(const char* __s,
>> int __c) {return ::strchr(__s, __c);}
>> > inline _LIBCPP_INLINE_VISIBILITY   char* strchr(  char* __s,
>> 

Re: [PATCH] D13549: Added new options to ClangFormat VSIX package.

[Reid Kleckner via cfe-commits]

rnk added a comment.

In http://reviews.llvm.org/D13549#267790, @klimek wrote:

> We're waiting for Reid to find somebody who is good at reviewing this in 
> detail.
>  Sorry it takes a while, so far we don't have enough trusted Windows experts 
> in the community :(


Oops, I didn't know that. Zach knows C#, but I don't think any of us are VSIX 
experts.


http://reviews.llvm.org/D13549



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

[clang-tools-extra] r250468 - [clang-tidy] add cert's VariadicFunctionDefCheck as cppcoreguidelines-pro-type-vararg-def

[Matthias Gehre via cfe-commits]

Author: mgehre
Date: Thu Oct 15 17:40:45 2015
New Revision: 250468

URL: http://llvm.org/viewvc/llvm-project?rev=250468=rev
Log:
[clang-tidy] add cert's VariadicFunctionDefCheck as 
cppcoreguidelines-pro-type-vararg-def

Summary:
Import the cert check for variadic function definitions into
cppcoreguidelines module to check part of
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#-type8-avoid-reading-from-varargs-or-passing-vararg-arguments-prefer-variadic-template-parameters-instead

Reviewers: alexfh, sbenza, bkramer, aaron.ballman

Subscribers: cfe-commits

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

Modified:
clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CMakeLists.txt

clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp

Modified: clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CMakeLists.txt?rev=250468=250467=250468=diff
==
--- clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CMakeLists.txt 
(original)
+++ clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CMakeLists.txt Thu Oct 
15 17:40:45 2015
@@ -13,6 +13,7 @@ add_clang_library(clangTidyCppCoreGuidel
   clangBasic
   clangLex
   clangTidy
+  clangTidyCERTModule
   clangTidyMiscModule
   clangTidyUtils
   clangTooling

Modified: 
clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp?rev=250468=250467=250468=diff
==
--- 
clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
 (original)
+++ 
clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
 Thu Oct 15 17:40:45 2015
@@ -10,6 +10,7 @@
 #include "../ClangTidy.h"
 #include "../ClangTidyModule.h"
 #include "../ClangTidyModuleRegistry.h"
+#include "../cert/VariadicFunctionDefCheck.h"
 #include "../misc/AssignOperatorSignatureCheck.h"
 #include "ProBoundsPointerArithmeticCheck.h"
 #include "ProTypeConstCastCheck.h"
@@ -28,6 +29,8 @@ public:
 "cppcoreguidelines-pro-bounds-pointer-arithmetic");
 CheckFactories.registerCheck(
 "cppcoreguidelines-pro-type-const-cast");
+CheckFactories.registerCheck(
+"cppcoreguidelines-pro-type-vararg-def");
 CheckFactories.registerCheck(
 "cppcoreguidelines-pro-type-reinterpret-cast");
 CheckFactories.registerCheck(


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

Re: [PATCH] D13785: [clang-tidy] add cert's VariadicFunctionDefCheck as cppcoreguidelines-pro-type-vararg-def

[Matthias Gehre via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL250468: [clang-tidy] add cert's VariadicFunctionDefCheck as 
cppcoreguidelines-pro… (authored by mgehre).

Changed prior to commit:
  http://reviews.llvm.org/D13785?vs=37516=37532#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D13785

Files:
  clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CMakeLists.txt
  
clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp

Index: clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CMakeLists.txt
===
--- clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CMakeLists.txt
+++ clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CMakeLists.txt
@@ -13,6 +13,7 @@
   clangBasic
   clangLex
   clangTidy
+  clangTidyCERTModule
   clangTidyMiscModule
   clangTidyUtils
   clangTooling
Index: 
clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
===
--- 
clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
+++ 
clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
@@ -10,6 +10,7 @@
 #include "../ClangTidy.h"
 #include "../ClangTidyModule.h"
 #include "../ClangTidyModuleRegistry.h"
+#include "../cert/VariadicFunctionDefCheck.h"
 #include "../misc/AssignOperatorSignatureCheck.h"
 #include "ProBoundsPointerArithmeticCheck.h"
 #include "ProTypeConstCastCheck.h"
@@ -28,6 +29,8 @@
 "cppcoreguidelines-pro-bounds-pointer-arithmetic");
 CheckFactories.registerCheck(
 "cppcoreguidelines-pro-type-const-cast");
+CheckFactories.registerCheck(
+"cppcoreguidelines-pro-type-vararg-def");
 CheckFactories.registerCheck(
 "cppcoreguidelines-pro-type-reinterpret-cast");
 CheckFactories.registerCheck(


Index: clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CMakeLists.txt
===
--- clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CMakeLists.txt
+++ clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CMakeLists.txt
@@ -13,6 +13,7 @@
   clangBasic
   clangLex
   clangTidy
+  clangTidyCERTModule
   clangTidyMiscModule
   clangTidyUtils
   clangTooling
Index: clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
===
--- clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
+++ clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
@@ -10,6 +10,7 @@
 #include "../ClangTidy.h"
 #include "../ClangTidyModule.h"
 #include "../ClangTidyModuleRegistry.h"
+#include "../cert/VariadicFunctionDefCheck.h"
 #include "../misc/AssignOperatorSignatureCheck.h"
 #include "ProBoundsPointerArithmeticCheck.h"
 #include "ProTypeConstCastCheck.h"
@@ -28,6 +29,8 @@
 "cppcoreguidelines-pro-bounds-pointer-arithmetic");
 CheckFactories.registerCheck(
 "cppcoreguidelines-pro-type-const-cast");
+CheckFactories.registerCheck(
+"cppcoreguidelines-pro-type-vararg-def");
 CheckFactories.registerCheck(
 "cppcoreguidelines-pro-type-reinterpret-cast");
 CheckFactories.registerCheck(
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxx] r250469 - [libcxx] Make libc++.so a linker script by default on most platforms.

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Thu Oct 15 17:41:51 2015
New Revision: 250469

URL: http://llvm.org/viewvc/llvm-project?rev=250469=rev
Log:
[libcxx] Make libc++.so a linker script by default on most platforms.

Summary:
This patch turns on `LIBCXX_ENABLE_ABI_LINKER_SCRIPT` by default whenever 
`LLVM_HAVE_LINK_VERSION_SCRIPT` is ON. This turns out to be whenever:

1. WIN32 is not defined.
2 UNIX is defined.
3. APPLE is not defined.

While `LLVM_HAVE_LINK_VERSION_SCRIPT` is meant to reflect exactly what we are 
asking I think it's close enough.

After committing this patch Linux users will no longer have to use "-lc++abi" 
explicitly!




Reviewers: mclow.lists, danalbert, compnerd, jroelofs

Subscribers: emaste, rengolin, cbergstrom, cfe-commits

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

Modified:
libcxx/trunk/CMakeLists.txt
libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake
libcxx/trunk/docs/BuildingLibcxx.rst
libcxx/trunk/docs/UsingLibcxx.rst

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=250469=250468=250469=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Thu Oct 15 17:41:51 2015
@@ -67,12 +67,22 @@ set(LIBCXX_CXX_ABI "${LIBCXX_CXX_ABI}" C
 set(CXXABIS none libcxxabi libcxxrt libstdc++ libsupc++)
 set_property(CACHE LIBCXX_CXX_ABI PROPERTY STRINGS ;${CXXABIS})
 
+# Use a static copy of the ABI library when linking libc++. This option
+# cannot be used with LIBCXX_ENABLE_ABI_LINKER_SCRIPT.
 option(LIBCXX_ENABLE_STATIC_ABI_LIBRARY "Statically link the ABI library" OFF)
 
 # Generate and install a linker script inplace of libc++.so. The linker script
-# will link libc++ to the correct ABI library.
+# will link libc++ to the correct ABI library. This option is on by default
+# On UNIX platforms other than Apple unless 'LIBCXX_ENABLE_STATIC_ABI_LIBRARY'
+# is on.
+set(ENABLE_LINKER_SCRIPT_DEFAULT_VALUE OFF)
+if (LLVM_HAVE_LINK_VERSION_SCRIPT AND NOT LIBCXX_ENABLE_STATIC_ABI_LIBRARY)
+set(ENABLE_LINKER_SCRIPT_DEFAULT_VALUE ON)
+endif()
+
 option(LIBCXX_ENABLE_ABI_LINKER_SCRIPT
-  "Use and install a linker script for the given ABI library" OFF)
+  "Use and install a linker script for the given ABI library"
+  ${ENABLE_LINKER_SCRIPT_DEFAULT_VALUE})
 
 # Build libc++abi with libunwind. We need this option to determine whether to
 # link with libunwind or libgcc_s while running the test cases.

Modified: libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake?rev=250469=250468=250469=diff
==
--- libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake (original)
+++ libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake Thu Oct 15 17:41:51 
2015
@@ -109,6 +109,30 @@ if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURR
 message(STATUS "Sphinx disabled.")
   endif()
 
+  # FIXME - This is cribbed from HandleLLVMOptions.cmake.
+  if(WIN32)
+set(LLVM_HAVE_LINK_VERSION_SCRIPT 0)
+if(CYGWIN)
+  set(LLVM_ON_WIN32 0)
+  set(LLVM_ON_UNIX 1)
+else(CYGWIN)
+  set(LLVM_ON_WIN32 1)
+  set(LLVM_ON_UNIX 0)
+endif(CYGWIN)
+  else(WIN32)
+if(UNIX)
+  set(LLVM_ON_WIN32 0)
+  set(LLVM_ON_UNIX 1)
+  if(APPLE)
+set(LLVM_HAVE_LINK_VERSION_SCRIPT 0)
+  else(APPLE)
+set(LLVM_HAVE_LINK_VERSION_SCRIPT 1)
+  endif(APPLE)
+else(UNIX)
+  MESSAGE(SEND_ERROR "Unable to determine platform")
+endif(UNIX)
+  endif(WIN32)
+
   # Add LLVM Functions 
   include(AddLLVM OPTIONAL)
 endif()

Modified: libcxx/trunk/docs/BuildingLibcxx.rst
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/docs/BuildingLibcxx.rst?rev=250469=250468=250469=diff
==
--- libcxx/trunk/docs/BuildingLibcxx.rst (original)
+++ libcxx/trunk/docs/BuildingLibcxx.rst Thu Oct 15 17:41:51 2015
@@ -170,6 +170,14 @@ ABI Library Specific Options
   If this option is enabled, libc++ will try and link the selected ABI library
   statically.
 
+.. option:: LIBCXX_ENABLE_ABI_LINKER_SCRIPT:BOOL
+
+  **Default**: ``ON`` by default on UNIX platforms other than Apple unless
+  'LIBCXX_ENABLE_STATIC_ABI_LIBRARY' is ON. Otherwise the default value is 
``OFF``.
+
+  This option generate and installs a linker script as ``libc++.so`` which
+  links the correct ABI library.
+
 .. option:: LIBCXXABI_USE_LLVM_UNWINDER:BOOL
 
   **Default**: ``OFF``

Modified: libcxx/trunk/docs/UsingLibcxx.rst
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/docs/UsingLibcxx.rst?rev=250469=250468=250469=diff
==
--- libcxx/trunk/docs/UsingLibcxx.rst (original)
+++ 

[libcxx] r250471 - Quickly fix bad commit

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Thu Oct 15 17:51:50 2015
New Revision: 250471

URL: http://llvm.org/viewvc/llvm-project?rev=250471=rev
Log:
Quickly fix bad commit

Modified:
libcxx/trunk/CMakeLists.txt

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=250471=250470=250471=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Thu Oct 15 17:51:50 2015
@@ -80,9 +80,10 @@ if (LLVM_HAVE_LINK_VERSION_SCRIPT AND NO
 set(ENABLE_LINKER_SCRIPT_DEFAULT_VALUE ON)
 endif()
 
+#FIXME(EricWF)
 option(LIBCXX_ENABLE_ABI_LINKER_SCRIPT
   "Use and install a linker script for the given ABI library"
-  ${ENABLE_LINKER_SCRIPT_DEFAULT_VALUE})
+  OFF) #${ENABLE_LINKER_SCRIPT_DEFAULT_VALUE})
 
 # Build libc++abi with libunwind. We need this option to determine whether to
 # link with libunwind or libgcc_s while running the test cases.


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

r250495 - [X86] Add proper feature name to some avx512dq builtins.

[Craig Topper via cfe-commits]

Author: ctopper
Date: Fri Oct 16 00:25:04 2015
New Revision: 250495

URL: http://llvm.org/viewvc/llvm-project?rev=250495=rev
Log:
[X86] Add proper feature name to some avx512dq builtins.

Modified:
cfe/trunk/include/clang/Basic/BuiltinsX86.def

Modified: cfe/trunk/include/clang/Basic/BuiltinsX86.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsX86.def?rev=250495=250494=250495=diff
==
--- cfe/trunk/include/clang/Basic/BuiltinsX86.def (original)
+++ cfe/trunk/include/clang/Basic/BuiltinsX86.def Fri Oct 16 00:25:04 2015
@@ -1545,22 +1545,22 @@ TARGET_BUILTIN(__builtin_ia32_punpcklbw1
 TARGET_BUILTIN(__builtin_ia32_punpcklbw256_mask, "V32cV32cV32cV32cUi", "", 
"avx512vl,avx512bw")
 TARGET_BUILTIN(__builtin_ia32_punpcklwd128_mask, "V8sV8sV8sV8sUc", "", 
"avx512vl,avx512bw")
 TARGET_BUILTIN(__builtin_ia32_punpcklwd256_mask, "V16sV16sV16sV16sUs", "", 
"avx512vl,avx512bw")
-BUILTIN(__builtin_ia32_cvtpd2qq512_mask, "V8LLiV8dV8LLiUcIi", "")
-BUILTIN(__builtin_ia32_cvtpd2uqq512_mask, "V8LLiV8dV8LLiUcIi", "")
-BUILTIN(__builtin_ia32_cvtps2qq512_mask, "V8LLiV8fV8LLiUcIi", "")
-BUILTIN(__builtin_ia32_cvtps2uqq512_mask, "V8LLiV8fV8LLiUcIi", "")
-BUILTIN(__builtin_ia32_cvtqq2pd512_mask, "V8dV8LLiV8dUcIi", "")
-BUILTIN(__builtin_ia32_cvtqq2ps512_mask, "V8fV8LLiV8fUcIi", "")
-BUILTIN(__builtin_ia32_cvttpd2qq512_mask, "V8LLiV8dV8LLiUcIi", "")
-BUILTIN(__builtin_ia32_cvttpd2uqq512_mask, "V8LLiV8dV8LLiUcIi", "")
-BUILTIN(__builtin_ia32_cvttps2qq512_mask, "V8LLiV8fV8LLiUcIi", "")
-BUILTIN(__builtin_ia32_cvttps2uqq512_mask, "V8LLiV8fV8LLiUcIi", "")
-BUILTIN(__builtin_ia32_cvtuqq2pd512_mask, "V8dV8LLiV8dUcIi", "")
-BUILTIN(__builtin_ia32_cvtuqq2ps512_mask, "V8fV8LLiV8fUcIi", "")
-BUILTIN(__builtin_ia32_rangepd512_mask, "V8dV8dV8dIiV8dUcIi", "")
-BUILTIN(__builtin_ia32_rangeps512_mask, "V16fV16fV16fIiV16fUsIi", "")
-BUILTIN(__builtin_ia32_reducepd512_mask, "V8dV8dIiV8dUcIi", "")
-BUILTIN(__builtin_ia32_reduceps512_mask, "V16fV16fIiV16fUsIi", "")
+TARGET_BUILTIN(__builtin_ia32_cvtpd2qq512_mask, "V8LLiV8dV8LLiUcIi", "", 
"avx512dq")
+TARGET_BUILTIN(__builtin_ia32_cvtpd2uqq512_mask, "V8LLiV8dV8LLiUcIi", "", 
"avx512dq")
+TARGET_BUILTIN(__builtin_ia32_cvtps2qq512_mask, "V8LLiV8fV8LLiUcIi", "", 
"avx512dq")
+TARGET_BUILTIN(__builtin_ia32_cvtps2uqq512_mask, "V8LLiV8fV8LLiUcIi", "", 
"avx512dq")
+TARGET_BUILTIN(__builtin_ia32_cvtqq2pd512_mask, "V8dV8LLiV8dUcIi", "", 
"avx512dq")
+TARGET_BUILTIN(__builtin_ia32_cvtqq2ps512_mask, "V8fV8LLiV8fUcIi", "", 
"avx512dq")
+TARGET_BUILTIN(__builtin_ia32_cvttpd2qq512_mask, "V8LLiV8dV8LLiUcIi", "", 
"avx512dq")
+TARGET_BUILTIN(__builtin_ia32_cvttpd2uqq512_mask, "V8LLiV8dV8LLiUcIi", "", 
"avx512dq")
+TARGET_BUILTIN(__builtin_ia32_cvttps2qq512_mask, "V8LLiV8fV8LLiUcIi", "", 
"avx512dq")
+TARGET_BUILTIN(__builtin_ia32_cvttps2uqq512_mask, "V8LLiV8fV8LLiUcIi", "", 
"avx512dq")
+TARGET_BUILTIN(__builtin_ia32_cvtuqq2pd512_mask, "V8dV8LLiV8dUcIi", "", 
"avx512dq")
+TARGET_BUILTIN(__builtin_ia32_cvtuqq2ps512_mask, "V8fV8LLiV8fUcIi", "", 
"avx512dq")
+TARGET_BUILTIN(__builtin_ia32_rangepd512_mask, "V8dV8dV8dIiV8dUcIi", "", 
"avx512dq")
+TARGET_BUILTIN(__builtin_ia32_rangeps512_mask, "V16fV16fV16fIiV16fUsIi", "", 
"avx512dq")
+TARGET_BUILTIN(__builtin_ia32_reducepd512_mask, "V8dV8dIiV8dUcIi", "", 
"avx512dq")
+TARGET_BUILTIN(__builtin_ia32_reduceps512_mask, "V16fV16fIiV16fUsIi", "", 
"avx512dq")
 
 #undef BUILTIN
 #undef TARGET_BUILTIN


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

r250496 - [X86] Add sse4.2 feature name to CRC32 builtins.

[Craig Topper via cfe-commits]

Author: ctopper
Date: Fri Oct 16 00:25:15 2015
New Revision: 250496

URL: http://llvm.org/viewvc/llvm-project?rev=250496=rev
Log:
[X86] Add sse4.2 feature name to CRC32 builtins.

Modified:
cfe/trunk/include/clang/Basic/BuiltinsX86.def

Modified: cfe/trunk/include/clang/Basic/BuiltinsX86.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsX86.def?rev=250496=250495=250496=diff
==
--- cfe/trunk/include/clang/Basic/BuiltinsX86.def (original)
+++ cfe/trunk/include/clang/Basic/BuiltinsX86.def Fri Oct 16 00:25:15 2015
@@ -414,10 +414,10 @@ TARGET_BUILTIN(__builtin_ia32_pcmpestrio
 TARGET_BUILTIN(__builtin_ia32_pcmpestris128, "iV16ciV16ciIc","", "sse4.2")
 TARGET_BUILTIN(__builtin_ia32_pcmpestriz128, "iV16ciV16ciIc","", "sse4.2")
 
-BUILTIN(__builtin_ia32_crc32qi, "UiUiUc", "")
-BUILTIN(__builtin_ia32_crc32hi, "UiUiUs", "")
-BUILTIN(__builtin_ia32_crc32si, "UiUiUi", "")
-BUILTIN(__builtin_ia32_crc32di, "ULLiULLiULLi", "")
+TARGET_BUILTIN(__builtin_ia32_crc32qi, "UiUiUc", "", "sse4.2")
+TARGET_BUILTIN(__builtin_ia32_crc32hi, "UiUiUs", "", "sse4.2")
+TARGET_BUILTIN(__builtin_ia32_crc32si, "UiUiUi", "", "sse4.2")
+TARGET_BUILTIN(__builtin_ia32_crc32di, "ULLiULLiULLi", "", "sse4.2")
 
 // SSE4a
 TARGET_BUILTIN(__builtin_ia32_extrqi, "V2LLiV2LLiIcIc", "", "sse4a")


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

Re: [PATCH] D13330: Implement __attribute__((unique_instantiation))

[Keno Fischer via cfe-commits]

loladiro added inline comments.


Comment at: include/clang/Basic/AttrDocs.td:1638
@@ +1637,3 @@
+
+Note that to ensure correct execution the user MUST make certain that no
+other translation unit has an implicit instantiation of the same entity. In

aaron.ballman wrote:
> In the unlikely event the user gets this wrong (lol), is there a way to 
> diagnose this on the backend? The wording here makes it sound like it's 
> possible for this to cause silent miscompiles, which would be unfortunate.
I don't think there is anything that can be really done here. I believe the 
static linker will link this just fine (there'll be one weak and one strong 
symbol). The difficulty of course arises with dynamic linkers that won't bother 
looking for any weak symbols to merge with (at least the OS X one doesn't). I 
suppose it's not really that different from missing a `weak` attribute on some 
declarations but not others.


Comment at: lib/CodeGen/CGVTables.cpp:744
@@ +743,3 @@
+// UniqueInstantiationAttr), the VTable should too.
+keyFunction->dump();
+if (Context.containedInUniqueInstantiation(keyFunction))

aaron.ballman wrote:
> Looks like some debugging code accidentally made it in.
Thanks!


Comment at: lib/Sema/SemaDecl.cpp:2285
@@ +2284,3 @@
+  // here.
+  if (auto *CTSD = dyn_cast(New)) {
+TemplateSpecializationKind kind = CTSD->getSpecializationKind();

aaron.ballman wrote:
> Isn't this a bit broad? I do agree that we don't want to give incorrect 
> warnings, but it seems like this may inadvertently silence correct warnings 
> as well. If my gut feeling is wrong (which it might be), it would be good to 
> have some test cases confirming that this doesn't silence correct 
> diagnostics. 
As far as I know, this is only called from mergeDeclAttributes, which didn't 
use to be called on these before this patch. I also don't think any attributes 
but dllexport or unique_instantiation apply to these declarations and those two 
both need special processing.


http://reviews.llvm.org/D13330



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

Re: [PATCH] D13786: [Sema] Implement __make_integer_seq

[David Majnemer via cfe-commits]

majnemer updated this revision to Diff 37558.
majnemer marked 2 inline comments as done.
majnemer added a comment.

- Address Richard's review comments.


http://reviews.llvm.org/D13786

Files:
  include/clang/AST/ASTContext.h
  include/clang/AST/DataRecursiveASTVisitor.h
  include/clang/AST/DeclTemplate.h
  include/clang/AST/RecursiveASTVisitor.h
  include/clang/AST/TemplateName.h
  include/clang/Basic/Builtins.h
  include/clang/Basic/DeclNodes.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/TokenKinds.def
  include/clang/Sema/Sema.h
  lib/AST/ASTContext.cpp
  lib/AST/ASTDumper.cpp
  lib/AST/ASTImporter.cpp
  lib/AST/DeclBase.cpp
  lib/AST/DeclTemplate.cpp
  lib/AST/ItaniumMangle.cpp
  lib/AST/TemplateName.cpp
  lib/AST/Type.cpp
  lib/CodeGen/CGDecl.cpp
  lib/Parse/ParseDecl.cpp
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaTemplate.cpp
  lib/Sema/SemaTemplateInstantiateDecl.cpp
  lib/Sema/TreeTransform.h
  lib/Serialization/ASTCommon.cpp
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTReaderDecl.cpp
  lib/Serialization/ASTWriter.cpp
  tools/libclang/CIndex.cpp

Index: tools/libclang/CIndex.cpp
===
--- tools/libclang/CIndex.cpp
+++ tools/libclang/CIndex.cpp
@@ -1392,6 +1392,9 @@
 return Visit(MakeCursorTemplateRef(
   Name.getAsSubstTemplateTemplateParmPack()->getParameterPack(),
Loc, TU));
+
+  case TemplateName::BuiltinTemplate:
+return false;
   }
 
   llvm_unreachable("Invalid TemplateName::Kind!");
@@ -5110,6 +5113,7 @@
   case Decl::Import:
   case Decl::OMPThreadPrivate:
   case Decl::ObjCTypeParam:
+  case Decl::BuiltinTemplate:
 return C;
 
   // Declaration kinds that don't make any sense here, but are
Index: lib/Serialization/ASTWriter.cpp
===
--- lib/Serialization/ASTWriter.cpp
+++ lib/Serialization/ASTWriter.cpp
@@ -5246,6 +5246,12 @@
 AddTemplateArgument(SubstPack->getArgumentPack(), Record);
 break;
   }
+  case TemplateName::BuiltinTemplate: {
+BuiltinTemplateStorage *BTS = Name.getAsBuiltinTemplate();
+BuiltinTemplateNameKind BTNK = BTS->getKind();
+Record.push_back(BTNK);
+break;
+  }
   }
 }
 
Index: lib/Serialization/ASTReaderDecl.cpp
===
--- lib/Serialization/ASTReaderDecl.cpp
+++ lib/Serialization/ASTReaderDecl.cpp
@@ -293,6 +293,7 @@
 DeclID VisitTemplateDecl(TemplateDecl *D);
 RedeclarableResult VisitRedeclarableTemplateDecl(RedeclarableTemplateDecl *D);
 void VisitClassTemplateDecl(ClassTemplateDecl *D);
+void VisitBuiltinTemplateDecl(BuiltinTemplateDecl *D);
 void VisitVarTemplateDecl(VarTemplateDecl *D);
 void VisitFunctionTemplateDecl(FunctionTemplateDecl *D);
 void VisitTemplateTemplateParmDecl(TemplateTemplateParmDecl *D);
@@ -1856,6 +1857,10 @@
   }
 }
 
+void ASTDeclReader::VisitBuiltinTemplateDecl(BuiltinTemplateDecl *D) {
+  llvm_unreachable("BuiltinTemplates are not serialized");
+}
+
 /// TODO: Unify with ClassTemplateDecl version?
 ///   May require unifying ClassTemplateDecl and
 ///VarTemplateDecl beyond TemplateDecl...
Index: lib/Serialization/ASTReader.cpp
===
--- lib/Serialization/ASTReader.cpp
+++ lib/Serialization/ASTReader.cpp
@@ -7619,6 +7619,10 @@
 
 return Context.getSubstTemplateTemplateParmPack(Param, ArgPack);
   }
+  case TemplateName::BuiltinTemplate: {
+BuiltinTemplateNameKind BTNK = (BuiltinTemplateNameKind)Record[Idx++];
+return Context.getBuiltinTemplateName(BTNK);
+  }
   }
 
   llvm_unreachable("Unhandled template name kind!");
Index: lib/Serialization/ASTCommon.cpp
===
--- lib/Serialization/ASTCommon.cpp
+++ lib/Serialization/ASTCommon.cpp
@@ -329,6 +329,7 @@
   case Decl::ClassScopeFunctionSpecialization:
   case Decl::Import:
   case Decl::OMPThreadPrivate:
+  case Decl::BuiltinTemplate:
 return false;
 
   // These indirectly derive from Redeclarable but are not actually
Index: lib/Sema/TreeTransform.h
===
--- lib/Sema/TreeTransform.h
+++ lib/Sema/TreeTransform.h
@@ -3454,6 +3454,9 @@
 SubstPack->getArgumentPack());
   }
 
+  if (Name.getKind() == TemplateName::BuiltinTemplate)
+return Name;
+
   // These should be getting filtered out before they reach the AST.
   llvm_unreachable("overloaded function decl survived to here");
 }
Index: lib/Sema/SemaTemplateInstantiateDecl.cpp
===
--- lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -922,6 +922,11 @@
   llvm_unreachable("EnumConstantDecls can only occur within EnumDecls.");
 }
 
+Decl *

Re: [PATCH] D13330: Implement __attribute__((unique_instantiation))

[Keno Fischer via cfe-commits]

loladiro updated this revision to Diff 37555.
loladiro added a comment.

Address review comments and clang-format.


http://reviews.llvm.org/D13330

Files:
  include/clang/AST/ASTContext.h
  include/clang/Basic/Attr.td
  include/clang/Basic/AttrDocs.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Sema/AttributeList.h
  lib/AST/ASTContext.cpp
  lib/CodeGen/CGVTables.cpp
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaDeclAttr.cpp
  lib/Sema/SemaTemplate.cpp
  test/CodeGenCXX/unique-instantiation.cpp
  test/SemaCXX/unique-instantiations.cpp
  utils/TableGen/ClangAttrEmitter.cpp

Index: utils/TableGen/ClangAttrEmitter.cpp
===
--- utils/TableGen/ClangAttrEmitter.cpp
+++ utils/TableGen/ClangAttrEmitter.cpp
@@ -2339,6 +2339,8 @@
 case Func | ObjCMethod | Param: return "ExpectedFunctionMethodOrParameter";
 case Func | ObjCMethod: return "ExpectedFunctionOrMethod";
 case Func | Var: return "ExpectedVariableOrFunction";
+case Func | Class:
+  return "ExpectedFunctionOrClass";
 
 // If not compiling for C++, the class portion does not apply.
 case Func | Var | Class:
Index: test/SemaCXX/unique-instantiations.cpp
===
--- /dev/null
+++ test/SemaCXX/unique-instantiations.cpp
@@ -0,0 +1,23 @@
+// RUN: %clang -cc1 -std=c++11 -fsyntax-only -verify %s
+
+template 
+struct foo1 {};
+template struct __attribute__((unique_instantiation)) foo1; // expected-error{{requires a previous declaration}}
+
+template 
+struct foo2 {};
+extern template struct foo2;// expected-note{{previous explicit instantiation is here}}
+template struct __attribute__((unique_instantiation)) foo2; // expected-error{{must be specified on all declarations}}
+
+template 
+struct foo3 {};
+extern template struct __attribute__((unique_instantiation)) foo3; // expected-note{{previous explicit instantiation is here}}
+extern template struct foo3;   // expected-error{{must be specified on all declarations}}
+
+template 
+struct __attribute__((unique_instantiation)) foo4 {}; // expected-error{{only applies to explicit template declarations or definitions}}
+
+template 
+struct foo5 {};
+extern template struct __attribute__((unique_instantiation)) foo5; // expected-note{{previous explicit instantiation is here}}
+template struct foo5;  // expected-error{{must be specified on all declarations}}
Index: test/CodeGenCXX/unique-instantiation.cpp
===
--- /dev/null
+++ test/CodeGenCXX/unique-instantiation.cpp
@@ -0,0 +1,38 @@
+// RUN: %clang -std=c++11 -emit-llvm -O0 -c -S -o - %s | FileCheck %s
+
+template 
+struct foo {
+  T x;
+  T getX() { return x; }
+  struct bar {
+T y;
+bar(T y) : y(y) {}
+  };
+};
+template 
+T bar();
+
+// CHECK: define i32 @_ZN3fooIiE4getXEv
+// CHECK: define void @_ZN3fooIiE3barC2Ei
+// CHECK-NOT: define weak_odr i32 @_ZN3fooIiE4getXEv
+// CHECK-NOT: define weak_odr void @_ZN3fooIiE3barC2Ei
+extern template struct __attribute__((unique_instantiation)) foo;
+template struct __attribute__((unique_instantiation)) foo;
+
+extern template __attribute__((unique_instantiation)) int bar();
+
+template 
+T bar() {
+  return (T)0;
+}
+
+// CHECK: define i32 @_Z3barIiET_v()
+// CHECK-NOT: define weak_odr i32 @_Z3barIiET_v()
+template __attribute__((unique_instantiation)) int bar();
+
+int footest() {
+  auto var = foo{5};
+  auto var2 = foo::bar{5};
+  auto x = bar();
+  return var.getX();
+}
Index: lib/Sema/SemaTemplate.cpp
===
--- lib/Sema/SemaTemplate.cpp
+++ lib/Sema/SemaTemplate.cpp
@@ -7330,20 +7330,22 @@
   Specialization->setExternLoc(ExternLoc);
   Specialization->setTemplateKeywordLoc(TemplateLoc);
   Specialization->setRBraceLoc(SourceLocation());
+  Specialization->setTemplateSpecializationKind(TSK);
 
   if (Attr)
 ProcessDeclAttributeList(S, Specialization, Attr);
 
+  if (PrevDecl)
+mergeDeclAttributes(Specialization, PrevDecl);
+
   // Add the explicit instantiation into its lexical context. However,
   // since explicit instantiations are never found by name lookup, we
   // just put it into the declaration context directly.
   Specialization->setLexicalDeclContext(CurContext);
   CurContext->addDecl(Specialization);
 
   // Syntax is now OK, so return if it has no other effect on semantics.
   if (HasNoEffect) {
-// Set the template specialization kind.
-Specialization->setTemplateSpecializationKind(TSK);
 return Specialization;
   }
 
@@ -7397,14 +7399,7 @@
   }
 }
 
-// Set the template specialization kind. Make sure it is set before
-// instantiating the members which will trigger ASTConsumer callbacks.
-Specialization->setTemplateSpecializationKind(TSK);
 

r250428 - Put back doxygen comment accidentally dropped in r250418.

[Benjamin Kramer via cfe-commits]

Author: d0k
Date: Thu Oct 15 11:46:25 2015
New Revision: 250428

URL: http://llvm.org/viewvc/llvm-project?rev=250428=rev
Log:
Put back doxygen comment accidentally dropped in r250418.

Modified:
cfe/trunk/lib/CodeGen/CGDebugInfo.h

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.h?rev=250428=250427=250428=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.h (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.h Thu Oct 15 11:46:25 2015
@@ -135,6 +135,11 @@ class CGDebugInfo {
   NamespaceAliasCache;
   llvm::DenseMap>
   StaticDataMemberCache;
+
+  /// Helper functions for getOrCreateType.
+  /// @{
+  /// Currently the checksum of an interface includes the number of
+  /// ivars and property accessors.
   llvm::DIType *CreateType(const BuiltinType *Ty);
   llvm::DIType *CreateType(const ComplexType *Ty);
   llvm::DIType *CreateQualifiedType(QualType Ty, llvm::DIFile *Fg);


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

Re: r250418 - [CodeGen] Remove dead code. NFC.

[Benjamin Kramer via cfe-commits]

On Thu, Oct 15, 2015 at 6:12 PM, Adrian Prantl  wrote:
>
>> On Oct 15, 2015, at 8:29 AM, Benjamin Kramer via cfe-commits 
>>  wrote:
>>
>> Author: d0k
>> Date: Thu Oct 15 10:29:40 2015
>> New Revision: 250418
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=250418=rev
>> Log:
>> [CodeGen] Remove dead code. NFC.
>>
>> Modified:
>>cfe/trunk/lib/CodeGen/CGBuiltin.cpp
>>cfe/trunk/lib/CodeGen/CGCall.cpp
>>cfe/trunk/lib/CodeGen/CGCleanup.cpp
>>cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
>>cfe/trunk/lib/CodeGen/CGDebugInfo.h
>>cfe/trunk/lib/CodeGen/CGObjC.cpp
>>cfe/trunk/lib/CodeGen/CGObjCMac.cpp
>>cfe/trunk/lib/CodeGen/CGVTables.h
>>cfe/trunk/lib/CodeGen/CodeGenABITypes.cpp
>>cfe/trunk/lib/CodeGen/CodeGenFunction.h
>>cfe/trunk/lib/CodeGen/CodeGenModule.cpp
>>cfe/trunk/lib/CodeGen/CodeGenModule.h
>>cfe/trunk/lib/CodeGen/CodeGenPGO.h
>>cfe/trunk/lib/CodeGen/EHScopeStack.h
>>cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
>>
>> Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=250418=250417=250418=diff
>> ==
>> --- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
>> +++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Thu Oct 15 10:29:40 2015
>> @@ -4106,15 +4106,6 @@ Value *CodeGenFunction::vectorWrapScalar
>>   return Op;
>> }
>>
>> -Value *CodeGenFunction::vectorWrapScalar8(Value *Op) {
>> -  llvm::Type *VTy = llvm::VectorType::get(Int8Ty, 8);
>> -  Op = Builder.CreateBitCast(Op, Int8Ty);
>> -  Value *V = UndefValue::get(VTy);
>> -  llvm::Constant *CI = ConstantInt::get(SizeTy, 0);
>> -  Op = Builder.CreateInsertElement(V, Op, CI);
>> -  return Op;
>> -}
>> -
>> Value *CodeGenFunction::EmitAArch64BuiltinExpr(unsigned BuiltinID,
>>const CallExpr *E) {
>>   unsigned HintID = static_cast(-1);
>>
>> Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=250418=250417=250418=diff
>> ==
>> --- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
>> +++ cfe/trunk/lib/CodeGen/CGCall.cpp Thu Oct 15 10:29:40 2015
>> @@ -3038,12 +3038,6 @@ CodeGenFunction::EmitRuntimeCallOrInvoke
>>   return callSite;
>> }
>>
>> -llvm::CallSite
>> -CodeGenFunction::EmitCallOrInvoke(llvm::Value *Callee,
>> -  const Twine ) {
>> -  return EmitCallOrInvoke(Callee, None, Name);
>> -}
>> -
>> /// Emits a call or invoke instruction to the given function, depending
>> /// on the current state of the EH stack.
>> llvm::CallSite
>>
>> Modified: cfe/trunk/lib/CodeGen/CGCleanup.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCleanup.cpp?rev=250418=250417=250418=diff
>> ==
>> --- cfe/trunk/lib/CodeGen/CGCleanup.cpp (original)
>> +++ cfe/trunk/lib/CodeGen/CGCleanup.cpp Thu Oct 15 10:29:40 2015
>> @@ -167,23 +167,6 @@ EHScopeStack::getInnermostActiveNormalCl
>>   return stable_end();
>> }
>>
>> -EHScopeStack::stable_iterator EHScopeStack::getInnermostActiveEHScope() 
>> const {
>> -  for (stable_iterator si = getInnermostEHScope(), se = stable_end();
>> - si != se; ) {
>> -// Skip over inactive cleanups.
>> -EHCleanupScope *cleanup = dyn_cast(&*find(si));
>> -if (cleanup && !cleanup->isActive()) {
>> -  si = cleanup->getEnclosingEHScope();
>> -  continue;
>> -}
>> -
>> -// All other scopes are always active.
>> -return si;
>> -  }
>> -
>> -  return stable_end();
>> -}
>> -
>>
>> void *EHScopeStack::pushCleanup(CleanupKind Kind, size_t Size) {
>>   char *Buffer = allocate(EHCleanupScope::getSizeForCleanupSize(Size));
>>
>> Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=250418=250417=250418=diff
>> ==
>> --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
>> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Thu Oct 15 10:29:40 2015
>> @@ -2159,30 +2159,6 @@ llvm::DIType *CGDebugInfo::getOrCreateTy
>>   return Res;
>> }
>>
>> -unsigned CGDebugInfo::Checksum(const ObjCInterfaceDecl *ID) {
>> -  // The assumption is that the number of ivars can only increase
>> -  // monotonically, so it is safe to just use their current number as
>> -  // a checksum.
>> -  unsigned Sum = 0;
>> -  for (const ObjCIvarDecl *Ivar = ID->all_declared_ivar_begin();
>> -   Ivar != nullptr; Ivar = Ivar->getNextIvar())
>> -++Sum;
>> -
>> -  return Sum;
>> -}
>> -
>> -ObjCInterfaceDecl *CGDebugInfo::getObjCInterfaceDecl(QualType Ty) {
>> -  switch (Ty->getTypeClass()) {
>> -  case Type::ObjCObjectPointer:
>> -return 

Re: [libcxx] r249738 - Split out of .

[Adrian Prantl via cfe-commits]

On Oct 14, 2015, at 5:07 PM, Richard Smith  wrote:Ack, there are non-modular headers in the Darwin module. =( I seem to recall that they're not version-locked to your compiler, so we've got to support them as-is?If we can't turn on local submodule visibility, then we need a module map for libc++ that covers all of its headers. I'll look into pruning the include path when building a module from an implicitly-loaded module map.The attached patch implements this in the most hacky way; with it I can successfully compile the first few hundred files of LLVM.— adrian

ignorelibc++.diff
Description: Binary data
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249929 - Split out of .

[Richard Smith via cfe-commits]

I assume the code in question has a "using namespace std;"?

I don't see any way around this other than giving up on trying to fix the
function signatures here (or maybe adding a Clang feature to let us fix the
bad signature).
On Oct 15, 2015 11:07 AM, "Manman Ren via cfe-commits" <
cfe-commits@lists.llvm.org> wrote:

> Hi Richard,
>
> This is causing a failure when building povray on iOS.
>
> Compilation error:
> /Users/buildslave/tmp/test-suite-externals/speccpu2006/benchspec/CPU2006/453.povray/src/fileinputoutput.cpp:364:20:
> error: call to 'strrchr' is ambiguous
>  const char *p=strrchr(name, '.’);
>
> iOS.sdk/usr/include/string.h:87:7: note: candidate function
> char*strrchr(const char *, int);
>  ^
> /Users/buildslave/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cstring:109:46:
> note: candidate function
> inline _LIBCPP_INLINE_VISIBILITY const char* strrchr(const char* __s, int
> __c) {return ::strrchr(__s, __c);}
>
> It is a little strange to have "char*strrchr(const char *, int);” in
> iOS. But it is already in our SDK.
>
> Do you have any suggestion on how to fix this?
>
> Thanks,
> Manman
>
> > On Oct 9, 2015, at 6:25 PM, Richard Smith via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
> >
> > Author: rsmith
> > Date: Fri Oct  9 20:25:31 2015
> > New Revision: 249929
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=249929=rev
> > Log:
> > Split  out of .
> >
> > Also fix the overload set for the five functions whose signatures change
> in the
> > case where we can fix it. This is already covered by existing tests for
> the
> > affected systems.
> >
> > Added:
> >libcxx/trunk/include/string.h
> >  - copied, changed from r249736, libcxx/trunk/include/cstring
> > Modified:
> >libcxx/trunk/include/cstring
> >
> > Modified: libcxx/trunk/include/cstring
> > URL:
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/cstring?rev=249929=249928=249929=diff
> >
> ==
> > --- libcxx/trunk/include/cstring (original)
> > +++ libcxx/trunk/include/cstring Fri Oct  9 20:25:31 2015
> > @@ -78,37 +78,42 @@ using ::strcmp;
> > using ::strncmp;
> > using ::strcoll;
> > using ::strxfrm;
> > +using ::strcspn;
> > +using ::strspn;
> > +#ifndef _LIBCPP_HAS_NO_THREAD_UNSAFE_C_FUNCTIONS
> > +using ::strtok;
> > +#endif
> > +using ::memset;
> > +using ::strerror;
> > +using ::strlen;
> >
> > -using ::memchr;
> > +// MSVCRT, GNU libc and its derivates already have the correct
> prototype in
> > +//  if __cplusplus is defined. This macro can be defined by
> users if
> > +// their C library provides the right signature.
> > +#if defined(__GLIBC__) || defined(_LIBCPP_MSVCRT) || defined(__sun__)
> || \
> > +defined(_STRING_H_CPLUSPLUS_98_CONFORMANCE_)
> > +#define _LIBCPP_STRING_H_HAS_CONST_OVERLOADS
> > +#endif
> >
> > +#ifdef _LIBCPP_STRING_H_HAS_CONST_OVERLOADS
> > using ::strchr;
> > -
> > -using ::strcspn;
> > -
> > using ::strpbrk;
> > -
> > using ::strrchr;
> > -
> > -using ::strspn;
> > -
> > +using ::memchr;
> > using ::strstr;
> > -
> > -// MSVCRT, GNU libc and its derivates already have the correct
> prototype in  #ifdef __cplusplus
> > -#if !defined(__GLIBC__) && !defined(_LIBCPP_MSVCRT) &&
> !defined(__sun__) && !defined(_STRING_H_CPLUSPLUS_98_CONFORMANCE_)
> > +#else
> > +inline _LIBCPP_INLINE_VISIBILITY const char* strchr(const char* __s,
> int __c) {return ::strchr(__s, __c);}
> > inline _LIBCPP_INLINE_VISIBILITY   char* strchr(  char* __s, int
> __c) {return ::strchr(__s, __c);}
> > +inline _LIBCPP_INLINE_VISIBILITY const char* strpbrk(const char* __s1,
> const char* __s2) {return ::strpbrk(__s1, __s2);}
> > inline _LIBCPP_INLINE_VISIBILITY   char* strpbrk(  char* __s1,
> const char* __s2) {return ::strpbrk(__s1, __s2);}
> > +inline _LIBCPP_INLINE_VISIBILITY const char* strrchr(const char* __s,
> int __c) {return ::strrchr(__s, __c);}
> > inline _LIBCPP_INLINE_VISIBILITY   char* strrchr(  char* __s,
> int __c) {return ::strrchr(__s, __c);}
> > +inline _LIBCPP_INLINE_VISIBILITY const void* memchr(const void* __s,
> int __c, size_t __n) {return ::memchr(__s, __c, __n);}
> > inline _LIBCPP_INLINE_VISIBILITY   void* memchr(  void* __s, int
> __c, size_t __n) {return ::memchr(__s, __c, __n);}
> > +inline _LIBCPP_INLINE_VISIBILITY const char* strstr(const char* __s1,
> const char* __s2) {return ::strstr(__s1, __s2);}
> > inline _LIBCPP_INLINE_VISIBILITY   char* strstr(  char* __s1,
> const char* __s2) {return ::strstr(__s1, __s2);}
> > #endif
> >
> > -#ifndef _LIBCPP_HAS_NO_THREAD_UNSAFE_C_FUNCTIONS
> > -using ::strtok;
> > -#endif
> > -using ::memset;
> > -using ::strerror;
> > -using ::strlen;
> > -
> > _LIBCPP_END_NAMESPACE_STD
> >
> > #endif  // _LIBCPP_CSTRING
> >
> > Copied: libcxx/trunk/include/string.h (from r249736,
> libcxx/trunk/include/cstring)
> > URL:
> 

Re: [libcxx] r249929 - Split out of .

[Manman Ren via cfe-commits]

> On Oct 15, 2015, at 11:25 AM, Richard Smith  wrote:
> 
> I assume the code in question has a "using namespace std;"?
> 
> 
Yes

> I don't see any way around this other than giving up on trying to fix the 
> function signatures here (or maybe adding a Clang feature to let us fix the 
> bad signature).
> 
> 
Can you elaborate on how to fix the bad signature by adding a Clang feature? I 
want to see how hard it is before giving up on trying to fix the signatures.

Thanks,
Manman


> On Oct 15, 2015 11:07 AM, "Manman Ren via cfe-commits" 
> > wrote:
> Hi Richard,
> 
> This is causing a failure when building povray on iOS.
> 
> Compilation error:
> /Users/buildslave/tmp/test-suite-externals/speccpu2006/benchspec/CPU2006/453.povray/src/fileinputoutput.cpp:364:20:
>  error: call to 'strrchr' is ambiguous
>  const char *p=strrchr(name, '.’);
> 
> iOS.sdk/usr/include/string.h:87:7: note: candidate function
> char*strrchr(const char *, int);
>  ^
> /Users/buildslave/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cstring:109:46:
>  note: candidate function
> inline _LIBCPP_INLINE_VISIBILITY const char* strrchr(const char* __s, int 
> __c) {return ::strrchr(__s, __c);}
> 
> It is a little strange to have "char*strrchr(const char *, int);” in iOS. 
> But it is already in our SDK.
> 
> Do you have any suggestion on how to fix this?
> 
> Thanks,
> Manman
> 
> > On Oct 9, 2015, at 6:25 PM, Richard Smith via cfe-commits 
> > > wrote:
> >
> > Author: rsmith
> > Date: Fri Oct  9 20:25:31 2015
> > New Revision: 249929
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=249929=rev 
> > 
> > Log:
> > Split  out of .
> >
> > Also fix the overload set for the five functions whose signatures change in 
> > the
> > case where we can fix it. This is already covered by existing tests for the
> > affected systems.
> >
> > Added:
> >libcxx/trunk/include/string.h
> >  - copied, changed from r249736, libcxx/trunk/include/cstring
> > Modified:
> >libcxx/trunk/include/cstring
> >
> > Modified: libcxx/trunk/include/cstring
> > URL: 
> > http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/cstring?rev=249929=249928=249929=diff
> >  
> > 
> > ==
> > --- libcxx/trunk/include/cstring (original)
> > +++ libcxx/trunk/include/cstring Fri Oct  9 20:25:31 2015
> > @@ -78,37 +78,42 @@ using ::strcmp;
> > using ::strncmp;
> > using ::strcoll;
> > using ::strxfrm;
> > +using ::strcspn;
> > +using ::strspn;
> > +#ifndef _LIBCPP_HAS_NO_THREAD_UNSAFE_C_FUNCTIONS
> > +using ::strtok;
> > +#endif
> > +using ::memset;
> > +using ::strerror;
> > +using ::strlen;
> >
> > -using ::memchr;
> > +// MSVCRT, GNU libc and its derivates already have the correct prototype in
> > +//  if __cplusplus is defined. This macro can be defined by 
> > users if
> > +// their C library provides the right signature.
> > +#if defined(__GLIBC__) || defined(_LIBCPP_MSVCRT) || defined(__sun__) || \
> > +defined(_STRING_H_CPLUSPLUS_98_CONFORMANCE_)
> > +#define _LIBCPP_STRING_H_HAS_CONST_OVERLOADS
> > +#endif
> >
> > +#ifdef _LIBCPP_STRING_H_HAS_CONST_OVERLOADS
> > using ::strchr;
> > -
> > -using ::strcspn;
> > -
> > using ::strpbrk;
> > -
> > using ::strrchr;
> > -
> > -using ::strspn;
> > -
> > +using ::memchr;
> > using ::strstr;
> > -
> > -// MSVCRT, GNU libc and its derivates already have the correct prototype 
> > in  #ifdef __cplusplus
> > -#if !defined(__GLIBC__) && !defined(_LIBCPP_MSVCRT) && !defined(__sun__) 
> > && !defined(_STRING_H_CPLUSPLUS_98_CONFORMANCE_)
> > +#else
> > +inline _LIBCPP_INLINE_VISIBILITY const char* strchr(const char* __s, int 
> > __c) {return ::strchr(__s, __c);}
> > inline _LIBCPP_INLINE_VISIBILITY   char* strchr(  char* __s, int 
> > __c) {return ::strchr(__s, __c);}
> > +inline _LIBCPP_INLINE_VISIBILITY const char* strpbrk(const char* __s1, 
> > const char* __s2) {return ::strpbrk(__s1, __s2);}
> > inline _LIBCPP_INLINE_VISIBILITY   char* strpbrk(  char* __s1, 
> > const char* __s2) {return ::strpbrk(__s1, __s2);}
> > +inline _LIBCPP_INLINE_VISIBILITY const char* strrchr(const char* __s, int 
> > __c) {return ::strrchr(__s, __c);}
> > inline _LIBCPP_INLINE_VISIBILITY   char* strrchr(  char* __s, int 
> > __c) {return ::strrchr(__s, __c);}
> > +inline _LIBCPP_INLINE_VISIBILITY const void* memchr(const void* __s, int 
> > __c, size_t __n) {return ::memchr(__s, __c, __n);}
> > inline _LIBCPP_INLINE_VISIBILITY   void* memchr(  void* __s, int 
> > __c, size_t __n) {return ::memchr(__s, __c, __n);}
> > +inline _LIBCPP_INLINE_VISIBILITY const char* 

Re: [PATCH] D13549: Added new options to ClangFormat VSIX package.

[Daniel Jasper via cfe-commits]

djasper added a comment.

While we are waiting, submitted the changes to ClangFormat.cpp in r250440. 
Thank you!


http://reviews.llvm.org/D13549



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

Re: r250440 - clang-format: Basic escaping when outputting XML.

[Nico Weber via cfe-commits]

test?

On Thu, Oct 15, 2015 at 11:39 AM, Daniel Jasper via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: djasper
> Date: Thu Oct 15 13:39:31 2015
> New Revision: 250440
>
> URL: http://llvm.org/viewvc/llvm-project?rev=250440=rev
> Log:
> clang-format: Basic escaping when outputting XML.
>
> Modified:
> cfe/trunk/tools/clang-format/ClangFormat.cpp
>
> Modified: cfe/trunk/tools/clang-format/ClangFormat.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-format/ClangFormat.cpp?rev=250440=250439=250440=diff
>
> ==
> --- cfe/trunk/tools/clang-format/ClangFormat.cpp (original)
> +++ cfe/trunk/tools/clang-format/ClangFormat.cpp Thu Oct 15 13:39:31 2015
> @@ -199,9 +199,11 @@ static bool fillRanges(MemoryBuffer *Cod
>  }
>
>  static void outputReplacementXML(StringRef Text) {
> +  // FIXME: When we sort includes, we need to make sure the stream is
> correct
> +  // utf-8.
>size_t From = 0;
>size_t Index;
> -  while ((Index = Text.find_first_of("\n\r", From)) != StringRef::npos) {
> +  while ((Index = Text.find_first_of("\n\r<&", From)) != StringRef::npos)
> {
>  llvm::outs() << Text.substr(From, Index - From);
>  switch (Text[Index]) {
>  case '\n':
> @@ -210,6 +212,12 @@ static void outputReplacementXML(StringR
>  case '\r':
>llvm::outs() << "";
>break;
> +case '<':
> +  llvm::outs() << "";
> +  break;
> +case '&':
> +  llvm::outs() << "";
> +  break;
>  default:
>llvm_unreachable("Unexpected character encountered!");
>  }
>
>
> ___
> 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: [libcxx] r249929 - Split out of .

[Manman Ren via cfe-commits]

Hi Richard,

This is causing a failure when building povray on iOS.

Compilation error:
/Users/buildslave/tmp/test-suite-externals/speccpu2006/benchspec/CPU2006/453.povray/src/fileinputoutput.cpp:364:20:
 error: call to 'strrchr' is ambiguous
 const char *p=strrchr(name, '.’);

iOS.sdk/usr/include/string.h:87:7: note: candidate function
char*strrchr(const char *, int);
 ^
/Users/buildslave/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cstring:109:46:
 note: candidate function
inline _LIBCPP_INLINE_VISIBILITY const char* strrchr(const char* __s, int __c) 
{return ::strrchr(__s, __c);}

It is a little strange to have "char*strrchr(const char *, int);” in iOS. 
But it is already in our SDK.

Do you have any suggestion on how to fix this?

Thanks,
Manman

> On Oct 9, 2015, at 6:25 PM, Richard Smith via cfe-commits 
>  wrote:
> 
> Author: rsmith
> Date: Fri Oct  9 20:25:31 2015
> New Revision: 249929
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=249929=rev
> Log:
> Split  out of .
> 
> Also fix the overload set for the five functions whose signatures change in 
> the
> case where we can fix it. This is already covered by existing tests for the
> affected systems.
> 
> Added:
>libcxx/trunk/include/string.h
>  - copied, changed from r249736, libcxx/trunk/include/cstring
> Modified:
>libcxx/trunk/include/cstring
> 
> Modified: libcxx/trunk/include/cstring
> URL: 
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/cstring?rev=249929=249928=249929=diff
> ==
> --- libcxx/trunk/include/cstring (original)
> +++ libcxx/trunk/include/cstring Fri Oct  9 20:25:31 2015
> @@ -78,37 +78,42 @@ using ::strcmp;
> using ::strncmp;
> using ::strcoll;
> using ::strxfrm;
> +using ::strcspn;
> +using ::strspn;
> +#ifndef _LIBCPP_HAS_NO_THREAD_UNSAFE_C_FUNCTIONS
> +using ::strtok;
> +#endif
> +using ::memset;
> +using ::strerror;
> +using ::strlen;
> 
> -using ::memchr;
> +// MSVCRT, GNU libc and its derivates already have the correct prototype in
> +//  if __cplusplus is defined. This macro can be defined by users 
> if
> +// their C library provides the right signature.
> +#if defined(__GLIBC__) || defined(_LIBCPP_MSVCRT) || defined(__sun__) || \
> +defined(_STRING_H_CPLUSPLUS_98_CONFORMANCE_)
> +#define _LIBCPP_STRING_H_HAS_CONST_OVERLOADS
> +#endif
> 
> +#ifdef _LIBCPP_STRING_H_HAS_CONST_OVERLOADS
> using ::strchr;
> -
> -using ::strcspn;
> -
> using ::strpbrk;
> -
> using ::strrchr;
> -
> -using ::strspn;
> -
> +using ::memchr;
> using ::strstr;
> -
> -// MSVCRT, GNU libc and its derivates already have the correct prototype in 
>  #ifdef __cplusplus
> -#if !defined(__GLIBC__) && !defined(_LIBCPP_MSVCRT) && !defined(__sun__) && 
> !defined(_STRING_H_CPLUSPLUS_98_CONFORMANCE_)
> +#else
> +inline _LIBCPP_INLINE_VISIBILITY const char* strchr(const char* __s, int 
> __c) {return ::strchr(__s, __c);}
> inline _LIBCPP_INLINE_VISIBILITY   char* strchr(  char* __s, int __c) 
> {return ::strchr(__s, __c);}
> +inline _LIBCPP_INLINE_VISIBILITY const char* strpbrk(const char* __s1, const 
> char* __s2) {return ::strpbrk(__s1, __s2);}
> inline _LIBCPP_INLINE_VISIBILITY   char* strpbrk(  char* __s1, const 
> char* __s2) {return ::strpbrk(__s1, __s2);}
> +inline _LIBCPP_INLINE_VISIBILITY const char* strrchr(const char* __s, int 
> __c) {return ::strrchr(__s, __c);}
> inline _LIBCPP_INLINE_VISIBILITY   char* strrchr(  char* __s, int 
> __c) {return ::strrchr(__s, __c);}
> +inline _LIBCPP_INLINE_VISIBILITY const void* memchr(const void* __s, int 
> __c, size_t __n) {return ::memchr(__s, __c, __n);}
> inline _LIBCPP_INLINE_VISIBILITY   void* memchr(  void* __s, int __c, 
> size_t __n) {return ::memchr(__s, __c, __n);}
> +inline _LIBCPP_INLINE_VISIBILITY const char* strstr(const char* __s1, const 
> char* __s2) {return ::strstr(__s1, __s2);}
> inline _LIBCPP_INLINE_VISIBILITY   char* strstr(  char* __s1, const 
> char* __s2) {return ::strstr(__s1, __s2);}
> #endif
> 
> -#ifndef _LIBCPP_HAS_NO_THREAD_UNSAFE_C_FUNCTIONS
> -using ::strtok;
> -#endif
> -using ::memset;
> -using ::strerror;
> -using ::strlen;
> -
> _LIBCPP_END_NAMESPACE_STD
> 
> #endif  // _LIBCPP_CSTRING
> 
> Copied: libcxx/trunk/include/string.h (from r249736, 
> libcxx/trunk/include/cstring)
> URL: 
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/string.h?p2=libcxx/trunk/include/string.h=libcxx/trunk/include/cstring=249736=249929=249929=diff
> ==
> --- libcxx/trunk/include/cstring (original)
> +++ libcxx/trunk/include/string.h Fri Oct  9 20:25:31 2015
> @@ -1,5 +1,5 @@
> // -*- C++ -*-
> -//===--- cstring 
> --===//
> +//===--- string.h 
>