[PATCH] D31007: [Objective-C] Miscellaneous -fobjc-weak Fixes

2017-03-20 Thread John McCall via Phabricator via cfe-commits
rjmccall added inline comments.



Comment at: lib/AST/Type.cpp:3773
+/// lifetime semantics.
+bool Type::isNonTrivialObjCLifetimeType() const {
+  return CanonicalType.hasNonTrivialObjCLifetime();

Is this method not identical in behavior to hasNonTrivialObjCLifetime()?


https://reviews.llvm.org/D31007



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


[PATCH] D31006: [Objective-C] Fix "weak-unavailable" warning with -fobjc-weak

2017-03-20 Thread John McCall via Phabricator via cfe-commits
rjmccall accepted this revision.
rjmccall added a comment.
This revision is now accepted and ready to land.

LGTM.




Comment at: lib/Sema/SemaCast.cpp:125
+  assert(Self.getLangOpts().ObjCAutoRefCount ||
+ Self.getLangOpts().ObjCWeak);
 

bkelley wrote:
> rjmccall wrote:
> > Unlike the other patches, we do clearly need to be checking the language 
> > options in places like this.  Still, it's a shame to repeat the same 
> > condition in a million places.
> > 
> > I think the right thing to do here is to add a helper method to LangOpts:
> > 
> >   /// Returns true if any types in the program might have non-trivial 
> > lifetime qualifiers.
> >   bool allowsNonTrivialObjCLifetimeQualifiers() const {
> > return ObjCAutoRefCount || ObjCWeak;
> >   }
> Thanks for the suggestion. I was hesitant to add a method to LangOpts since 
> it has so few derived state functions, but it certainly makes everything else 
> cleaner.
There's probably two main reasons for that:

  - Often, when there's a feature that cuts across different language 
configurations, there's also a specific language option for it.
  - People are too reticent about adding derived state functions to LangOpts. :)


https://reviews.llvm.org/D31006



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


[PATCH] D31004: [Objective-C] Fix __weak type traits with -fobjc-weak

2017-03-20 Thread John McCall via Phabricator via cfe-commits
rjmccall added inline comments.



Comment at: lib/AST/Type.cpp:2026
 
-  if (Context.getLangOpts().ObjCAutoRefCount) {
-switch (getObjCLifetime()) {
-case Qualifiers::OCL_ExplicitNone:
-  return true;
-  
-case Qualifiers::OCL_Strong:
-case Qualifiers::OCL_Weak:
-case Qualifiers::OCL_Autoreleasing:
-  return false;
-
-case Qualifiers::OCL_None:
-  break;
-}
-  }
+  if (getQualifiers().hasObjCLifetime() && hasNonTrivialObjCLifetime())
+return false;

Is the first condition not implied by the second?


https://reviews.llvm.org/D31004



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


[PATCH] D31003: [Objective-C] C++ Classes with __weak Members non-POD Types when using -fobjc-weak

2017-03-20 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

Thanks, LGTM.


https://reviews.llvm.org/D31003



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


[PATCH] D30415: Fix -mno-altivec cannot overwrite -maltivec option

2017-03-20 Thread Eric Christopher via Phabricator via cfe-commits
echristo added a comment.

In https://reviews.llvm.org/D30415#705889, @echristo wrote:

> In https://reviews.llvm.org/D30415#705196, @uweigand wrote:
>
> > In https://reviews.llvm.org/D30415#704761, @echristo wrote:
> >
> > > In https://reviews.llvm.org/D30415#703652, @uweigand wrote:
> > >
> > > > I'm a bit confused by this discussion.  -faltivec and -maltivec are 
> > > > simply aliases, they do exactly the same thing; the clang-internal 
> > > > variable OPT_faltivec indicates the use of either -faltivec or 
> > > > -maltivec.
> > >
> > >
> > > They didn't used to, I arranged it so that they did (technically breaking 
> > > gcc compatibility) a while ago.
> >
> >
> > Well, mainline GCC doesn't have -faltivec at all and never had, I think 
> > this was only an Apple GCC extension ...  Not sure what exactly the 
> > semantics of that was.
>
>
> Sure it does and has for years. Check out rs6000/darwin.h :)
>
> FWIW: It turns on maltivec and adds a -include of altivec.h
>
> >>> Or is the suggestion to simply remove the alias -faltivec, and leave 
> >>> -maltivec as-is?  I'd be less opposed to this since it probably breaks 
> >>> fewer users ... but I'm still not quite sure what it actually buys us.   
> >>> And in any case the patch currently under discussion here would still be 
> >>> necessary then, to fix -maltivec -mno-altivec ...
> >> 
> >> No, remove faltivec and move forward with -maltivec/-mno-altivec but you 
> >> should be able to remove a lot of the special handling at that point.
> > 
> > I'm still confused as to what exactly you're refering to here.  As far as I 
> > can see, every single thing triggered by -faltivec / -maltivec in the 
> > compiler frontend would still be needed exactly the same if we only 
> > supported the -maltivec option name.  So the only thing we'd save is 
> > literally the two lines in include/clang/Driver/Options.td that set up the 
> > alias.
> > 
> > Do you have an example of the "special handling" to remove you're thinking 
> > of?
>
> Nearly all of the code in lib/Driver/ToolChains/Clang.cpp and 
> lib/Driver/ToolChains/Arch/PPC.cpp that deal with altivec. Simplifying the 
> interface by getting rid of needing to check multiple options.


I have a patch to do this now. I'll plan on committing it in a bit.

-eric


https://reviews.llvm.org/D30415



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


[PATCH] D31168: Set FMF for -ffp-contract=fast rather than a TargetConfig

2017-03-20 Thread Adam Nemet via Phabricator via cfe-commits
anemet created this revision.

This is toward moving fp-contraction=fast from an LLVM TargetOption to a
FastMathFlag in order to fix PR25721.


https://reviews.llvm.org/D31168

Files:
  lib/CodeGen/CGExprScalar.cpp


Index: lib/CodeGen/CGExprScalar.cpp
===
--- lib/CodeGen/CGExprScalar.cpp
+++ lib/CodeGen/CGExprScalar.cpp
@@ -256,8 +256,22 @@
   //Visitor Methods
   
//======//
 
+  /// A RAII to apply the FP features from the expression to the IRBuilder.
+  struct ApplyFPFeatures : public CGBuilderTy::FastMathFlagGuard {
+ApplyFPFeatures(llvm::IRBuilderBase &Builder, Expr *E)
+: CGBuilderTy::FastMathFlagGuard(Builder) {
+  if (const auto *BO = dyn_cast(E)) {
+llvm::FastMathFlags FMF = Builder.getFastMathFlags();
+FMF.setAllowContract(
+BO->getFPFeatures().allowFPContractAcrossStatement());
+Builder.setFastMathFlags(FMF);
+  }
+}
+  };
+
   Value *Visit(Expr *E) {
 ApplyDebugLocation DL(CGF, E);
+ApplyFPFeatures FPF(Builder, E);
 return StmtVisitor::Visit(E);
   }
 


Index: lib/CodeGen/CGExprScalar.cpp
===
--- lib/CodeGen/CGExprScalar.cpp
+++ lib/CodeGen/CGExprScalar.cpp
@@ -256,8 +256,22 @@
   //Visitor Methods
   //======//
 
+  /// A RAII to apply the FP features from the expression to the IRBuilder.
+  struct ApplyFPFeatures : public CGBuilderTy::FastMathFlagGuard {
+ApplyFPFeatures(llvm::IRBuilderBase &Builder, Expr *E)
+: CGBuilderTy::FastMathFlagGuard(Builder) {
+  if (const auto *BO = dyn_cast(E)) {
+llvm::FastMathFlags FMF = Builder.getFastMathFlags();
+FMF.setAllowContract(
+BO->getFPFeatures().allowFPContractAcrossStatement());
+Builder.setFastMathFlags(FMF);
+  }
+}
+  };
+
   Value *Visit(Expr *E) {
 ApplyDebugLocation DL(CGF, E);
+ApplyFPFeatures FPF(Builder, E);
 return StmtVisitor::Visit(E);
   }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D31167: Use FPContractModeKind universally

2017-03-20 Thread Adam Nemet via Phabricator via cfe-commits
anemet created this revision.

FPContractModeKind is the codegen option flag which is already ternary (off,
on, fast).  This makes it universally the type for the contractable info
across the front-end:

- In FPOptions (i.e. in the Sema + in the expression nodes).
- In LangOpts::DefaultFPContractMode which is the option that initializes

FPOptions in the Sema.

Another way to look at this change is that before fp-contractable on/off were
the only states handled to the front-end:

- For "on", FMA folding was performed by  the front-end
- For "fast", we simply forwarded the flag to TargetOptions to handle it in LLVM

Now off/on/fast are all exposed because for fast we will generate
fast-math-flags during CodeGen.

This is toward moving fp-contraction=fast from an LLVM TargetOption to a
FastMathFlag in order to fix PR25721.


https://reviews.llvm.org/D31167

Files:
  include/clang/AST/Expr.h
  include/clang/AST/ExprCXX.h
  include/clang/Basic/LangOptions.def
  include/clang/Basic/LangOptions.h
  include/clang/Frontend/CodeGenOptions.def
  include/clang/Frontend/CodeGenOptions.h
  lib/CodeGen/BackendUtil.cpp
  lib/CodeGen/CGExprScalar.cpp
  lib/Frontend/CompilerInvocation.cpp
  lib/Sema/SemaAttr.cpp

Index: lib/Sema/SemaAttr.cpp
===
--- lib/Sema/SemaAttr.cpp
+++ lib/Sema/SemaAttr.cpp
@@ -450,13 +450,16 @@
 void Sema::ActOnPragmaFPContract(tok::OnOffSwitch OOS) {
   switch (OOS) {
   case tok::OOS_ON:
-FPFeatures.setFPContractable(true);
+FPFeatures.setAllowFPContractWithinStatement();
 break;
   case tok::OOS_OFF:
-FPFeatures.setFPContractable(false);
+FPFeatures.setDisallowFPContract();
 break;
   case tok::OOS_DEFAULT:
-FPFeatures.setFPContractable(getLangOpts().DefaultFPContract);
+if (getLangOpts().getDefaultFPContractMode() == LangOptions::FPC_On)
+  FPFeatures.setAllowFPContractWithinStatement();
+else
+  FPFeatures.setDisallowFPContract();
 break;
   }
 }
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -811,18 +811,6 @@
 }
   }
 
-  if (Arg *A = Args.getLastArg(OPT_ffp_contract)) {
-StringRef Val = A->getValue();
-if (Val == "fast")
-  Opts.setFPContractMode(CodeGenOptions::FPC_Fast);
-else if (Val == "on")
-  Opts.setFPContractMode(CodeGenOptions::FPC_On);
-else if (Val == "off")
-  Opts.setFPContractMode(CodeGenOptions::FPC_Off);
-else
-  Diags.Report(diag::err_drv_invalid_value) << A->getAsString(Args) << Val;
-  }
-
   if (Arg *A = Args.getLastArg(OPT_fdenormal_fp_math_EQ)) {
 StringRef Val = A->getValue();
 if (Val == "ieee")
@@ -1625,7 +1613,7 @@
 Opts.ZVector = 0;
 Opts.CXXOperatorNames = 1;
 Opts.LaxVectorConversions = 0;
-Opts.DefaultFPContract = 1;
+Opts.setDefaultFPContractMode(LangOptions::FPC_On);
 Opts.NativeHalfType = 1;
 Opts.NativeHalfArgsAndReturns = 1;
 // Include default header file for OpenCL.
@@ -1636,6 +1624,9 @@
 
   Opts.CUDA = IK == IK_CUDA || IK == IK_PreprocessedCuda ||
   LangStd == LangStandard::lang_cuda;
+  if (Opts.CUDA)
+// Set default FP_CONTRACT to FAST.
+Opts.setDefaultFPContractMode(LangOptions::FPC_Fast);
 
   Opts.RenderScript = IK == IK_RenderScript;
   if (Opts.RenderScript) {
@@ -2263,6 +2254,18 @@
   Args.hasArg(OPT_cl_unsafe_math_optimizations) ||
   Args.hasArg(OPT_cl_fast_relaxed_math);
 
+  if (Arg *A = Args.getLastArg(OPT_ffp_contract)) {
+StringRef Val = A->getValue();
+if (Val == "fast")
+  Opts.setDefaultFPContractMode(LangOptions::FPC_Fast);
+else if (Val == "on")
+  Opts.setDefaultFPContractMode(LangOptions::FPC_On);
+else if (Val == "off")
+  Opts.setDefaultFPContractMode(LangOptions::FPC_Off);
+else
+  Diags.Report(diag::err_drv_invalid_value) << A->getAsString(Args) << Val;
+  }
+
   Opts.RetainCommentsFromSystemHeaders =
   Args.hasArg(OPT_fretain_comments_from_system_headers);
 
@@ -2516,10 +2519,6 @@
 // triple used for host compilation.
 if (LangOpts.CUDAIsDevice)
   Res.getTargetOpts().HostTriple = Res.getFrontendOpts().AuxTriple;
-
-// Set default FP_CONTRACT to FAST.
-if (!Args.hasArg(OPT_ffp_contract))
-  Res.getCodeGenOpts().setFPContractMode(CodeGenOptions::FPC_Fast);
   }
 
   // FIXME: Override value name discarding when asan or msan is used because the
Index: lib/CodeGen/CGExprScalar.cpp
===
--- lib/CodeGen/CGExprScalar.cpp
+++ lib/CodeGen/CGExprScalar.cpp
@@ -2663,12 +2663,7 @@
  "Only fadd/fsub can be the root of an fmuladd.");
 
   // Check whether this op is marked as fusable.
-  if (!op.FPFeatures.isFPContractable())
-return nullptr;
-
-  // Check whether -ffp-contract=on. (If -ffp-contract=off/fast, f

[PATCH] D31166: Encapsulate FPOptions and use it consistently

2017-03-20 Thread Adam Nemet via Phabricator via cfe-commits
anemet created this revision.

Sema holds the current FPOptions which is adjusted by 'pragma STDC
FP_CONTRACT'.  This then gets propagated into expression nodes as they are
built.

This encapsulates FPOptions so that this propagation happens opaquely rather
than directly with the fp_contractable on/off bit.  This allows controlled
transitioning of fp_contractable to a ternary value (off, on, fast).  It will
also allow adding more fast-math flags later.

This is toward moving fp-contraction=fast from an LLVM TargetOption to a
FastMathFlag in order to fix PR25721.


https://reviews.llvm.org/D31166

Files:
  include/clang/AST/Expr.h
  include/clang/AST/ExprCXX.h
  include/clang/Basic/LangOptions.h
  include/clang/Sema/Sema.h
  lib/AST/ASTImporter.cpp
  lib/Analysis/BodyFarm.cpp
  lib/CodeGen/CGExprScalar.cpp
  lib/CodeGen/CGObjC.cpp
  lib/CodeGen/CGStmtOpenMP.cpp
  lib/Frontend/Rewrite/RewriteModernObjC.cpp
  lib/Frontend/Rewrite/RewriteObjC.cpp
  lib/Sema/SemaAttr.cpp
  lib/Sema/SemaDeclCXX.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaExprCXX.cpp
  lib/Sema/SemaOverload.cpp
  lib/Sema/SemaPseudoObject.cpp
  lib/Sema/TreeTransform.h
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTReaderStmt.cpp
  lib/Serialization/ASTWriter.cpp
  lib/Serialization/ASTWriterStmt.cpp

Index: lib/Serialization/ASTWriterStmt.cpp
===
--- lib/Serialization/ASTWriterStmt.cpp
+++ lib/Serialization/ASTWriterStmt.cpp
@@ -650,7 +650,7 @@
   Record.AddStmt(E->getRHS());
   Record.push_back(E->getOpcode()); // FIXME: stable encoding
   Record.AddSourceLocation(E->getOperatorLoc());
-  Record.push_back(E->isFPContractable());
+  Record.push_back(E->getFPFeatures().getInt());
   Code = serialization::EXPR_BINARY_OPERATOR;
 }
 
@@ -1218,7 +1218,7 @@
   VisitCallExpr(E);
   Record.push_back(E->getOperator());
   Record.AddSourceRange(E->Range);
-  Record.push_back(E->isFPContractable());
+  Record.push_back(E->getFPFeatures().getInt());
   Code = serialization::EXPR_CXX_OPERATOR_CALL;
 }
 
Index: lib/Serialization/ASTWriter.cpp
===
--- lib/Serialization/ASTWriter.cpp
+++ lib/Serialization/ASTWriter.cpp
@@ -3975,7 +3975,7 @@
 
 /// \brief Write an FP_PRAGMA_OPTIONS block for the given FPOptions.
 void ASTWriter::WriteFPPragmaOptions(const FPOptions &Opts) {
-  RecordData::value_type Record[] = {Opts.fp_contract};
+  RecordData::value_type Record[] = {Opts.getInt()};
   Stream.EmitRecord(FP_PRAGMA_OPTIONS, Record);
 }
 
Index: lib/Serialization/ASTReaderStmt.cpp
===
--- lib/Serialization/ASTReaderStmt.cpp
+++ lib/Serialization/ASTReaderStmt.cpp
@@ -670,7 +670,7 @@
   E->setRHS(Record.readSubExpr());
   E->setOpcode((BinaryOperator::Opcode)Record.readInt());
   E->setOperatorLoc(ReadSourceLocation());
-  E->setFPContractable((bool)Record.readInt());
+  E->setFPFeatures(FPOptions(Record.readInt()));
 }
 
 void ASTStmtReader::VisitCompoundAssignOperator(CompoundAssignOperator *E) {
@@ -1225,7 +1225,7 @@
   VisitCallExpr(E);
   E->Operator = (OverloadedOperatorKind)Record.readInt();
   E->Range = Record.readSourceRange();
-  E->setFPContractable((bool)Record.readInt());
+  E->setFPFeatures(FPOptions(Record.readInt()));
 }
 
 void ASTStmtReader::VisitCXXConstructExpr(CXXConstructExpr *E) {
Index: lib/Serialization/ASTReader.cpp
===
--- lib/Serialization/ASTReader.cpp
+++ lib/Serialization/ASTReader.cpp
@@ -7215,7 +7215,7 @@
   // FIXME: What happens if these are changed by a module import?
   if (!FPPragmaOptions.empty()) {
 assert(FPPragmaOptions.size() == 1 && "Wrong number of FP_PRAGMA_OPTIONS");
-SemaObj->FPFeatures.fp_contract = FPPragmaOptions[0];
+SemaObj->FPFeatures = FPOptions(FPPragmaOptions[0]);
   }
 
   SemaObj->OpenCLFeatures.copy(OpenCLExtensions);
Index: lib/Sema/TreeTransform.h
===
--- lib/Sema/TreeTransform.h
+++ lib/Sema/TreeTransform.h
@@ -9146,7 +9146,7 @@
 return E;
 
   Sema::FPContractStateRAII FPContractState(getSema());
-  getSema().FPFeatures.fp_contract = E->isFPContractable();
+  getSema().FPFeatures = E->getFPFeatures();
 
   return getDerived().RebuildBinaryOperator(E->getOperatorLoc(), E->getOpcode(),
 LHS.get(), RHS.get());
@@ -9626,7 +9626,7 @@
 return SemaRef.MaybeBindToTemporary(E);
 
   Sema::FPContractStateRAII FPContractState(getSema());
-  getSema().FPFeatures.fp_contract = E->isFPContractable();
+  getSema().FPFeatures = E->getFPFeatures();
 
   return getDerived().RebuildCXXOperatorCallExpr(E->getOperator(),
  E->getOperatorLoc(),
Index: lib/Sema/SemaPseudoObject.cpp
===
--- lib/Sema/SemaPseudoObject.cpp
+++ lib/Se

[PATCH] D31130: B32239 clang-tidy should not warn about array to pointer decay on system macros

2017-03-20 Thread Breno Rodrigues Guimaraes via Phabricator via cfe-commits
brenoguim updated this revision to Diff 92419.
brenoguim added a comment.

- Using the ImplicitCastExpr type on the AST_MATCHER directly to avoid explicit 
cast.
- Using isa<> instead of dyn_cast<> to just check for type
- Move variable declaration into "if"  condition


https://reviews.llvm.org/D31130

Files:
  clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.cpp
  test/clang-tidy/cppcoreguidelines-pro-bounds-array-to-pointer-decay.cpp


Index: test/clang-tidy/cppcoreguidelines-pro-bounds-array-to-pointer-decay.cpp
===
--- test/clang-tidy/cppcoreguidelines-pro-bounds-array-to-pointer-decay.cpp
+++ test/clang-tidy/cppcoreguidelines-pro-bounds-array-to-pointer-decay.cpp
@@ -1,4 +1,5 @@
 // RUN: %check_clang_tidy %s 
cppcoreguidelines-pro-bounds-array-to-pointer-decay %t
+#include 
 #include 
 
 namespace gsl {
@@ -34,6 +35,11 @@
 
   for (auto &e : a) // OK, iteration internally decays array to pointer
 e = 1;
+
+  assert(false); // OK, array decay inside system header macro
+
+  assert(a);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: do not implicitly decay an array 
into a pointer; consider using gsl::array_view or an explicit cast instead 
[cppcoreguidelines-pro-bounds-array-to-pointer-decay]
 }
 
 const char *g() {
Index: clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.cpp
===
--- clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.cpp
+++ clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.cpp
@@ -47,6 +47,25 @@
   return InnerMatcher.matches(*E, Finder, Builder);
 }
 
+AST_MATCHER(ImplicitCastExpr, isArrayToPointerDecay) {
+  return Node.getCastKind() == CK_ArrayToPointerDecay;
+}
+
+AST_MATCHER(ImplicitCastExpr, sysSymbolDecayInSysHeader) {
+  auto &SM = Finder->getASTContext().getSourceManager();
+  if (SM.isInSystemMacro(Node.getLocStart())) {
+if (isa(Node.getSubExpr()))
+  return true;
+
+if (const auto *SymbolDeclRef = dyn_cast(Node.getSubExpr())) {
+  const ValueDecl *SymbolDecl = SymbolDeclRef->getDecl();
+  if (SymbolDecl && SM.isInSystemHeader(SymbolDecl->getLocation()))
+return true;
+}
+  }
+  return false;
+}
+
 void ProBoundsArrayToPointerDecayCheck::registerMatchers(MatchFinder *Finder) {
   if (!getLangOpts().CPlusPlus)
 return;
@@ -56,19 +75,19 @@
   // 2) inside a range-for over an array
   // 3) if it converts a string literal to a pointer
   Finder->addMatcher(
-  implicitCastExpr(unless(hasParent(arraySubscriptExpr())),
+  implicitCastExpr(isArrayToPointerDecay(),
+   unless(hasParent(arraySubscriptExpr())),
unless(hasParentIgnoringImpCasts(explicitCastExpr())),
unless(isInsideOfRangeBeginEndStmt()),
-   unless(hasSourceExpression(stringLiteral(
+   unless(hasSourceExpression(stringLiteral())),
+   unless(sysSymbolDecayInSysHeader()))
   .bind("cast"),
   this);
 }
 
 void ProBoundsArrayToPointerDecayCheck::check(
 const MatchFinder::MatchResult &Result) {
   const auto *MatchedCast = Result.Nodes.getNodeAs("cast");
-  if (MatchedCast->getCastKind() != CK_ArrayToPointerDecay)
-return;
 
   diag(MatchedCast->getExprLoc(), "do not implicitly decay an array into a "
   "pointer; consider using gsl::array_view or "


Index: test/clang-tidy/cppcoreguidelines-pro-bounds-array-to-pointer-decay.cpp
===
--- test/clang-tidy/cppcoreguidelines-pro-bounds-array-to-pointer-decay.cpp
+++ test/clang-tidy/cppcoreguidelines-pro-bounds-array-to-pointer-decay.cpp
@@ -1,4 +1,5 @@
 // RUN: %check_clang_tidy %s cppcoreguidelines-pro-bounds-array-to-pointer-decay %t
+#include 
 #include 
 
 namespace gsl {
@@ -34,6 +35,11 @@
 
   for (auto &e : a) // OK, iteration internally decays array to pointer
 e = 1;
+
+  assert(false); // OK, array decay inside system header macro
+
+  assert(a);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: do not implicitly decay an array into a pointer; consider using gsl::array_view or an explicit cast instead [cppcoreguidelines-pro-bounds-array-to-pointer-decay]
 }
 
 const char *g() {
Index: clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.cpp
===
--- clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.cpp
+++ clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.cpp
@@ -47,6 +47,25 @@
   return InnerMatcher.matches(*E, Finder, Builder);
 }
 
+AST_MATCHER(ImplicitCastExpr, isArrayToPointerDecay) {
+  return Node.getCastKind() == CK_ArrayToPointerDecay;
+}
+
+AST_MATCHER(ImplicitCastExpr, sysSymbolDecayInSysHeader) {
+  auto &SM = Finder->getASTContext().getSourceManager();
+  if (SM.isInSystemMacro(Node.ge

[PATCH] D30760: Record command lines in objects built by clang

2017-03-20 Thread George Burgess IV via Phabricator via cfe-commits
george.burgess.iv added a comment.

This is looking pretty good! Aside from a few nits, I'm happy with this after 
we add tests.




Comment at: lib/Driver/ToolChains/Clang.cpp:2725
+  if (Args.hasArg(options::OPT_grecord_gcc_switches)) {
+std::string CmdLineOpts = "";
+for (const auto *Arg : Args) CmdLineOpts += Arg->getAsString(Args) + " ";

Nit: can we use a `SmallString<256>` that we initialize to "-record-cmd-opts=" 
instead?



Comment at: lib/Driver/ToolChains/Clang.cpp:2726
+std::string CmdLineOpts = "";
+for (const auto *Arg : Args) CmdLineOpts += Arg->getAsString(Args) + " ";
+CmdLineOpts.pop_back();

Style nit: Loop bodies should go on a new line. If you use clang-format, it 
should handle all of these issues for you. :)



Comment at: lib/Driver/ToolChains/Clang.cpp:2728
+CmdLineOpts.pop_back();
+CmdArgs.push_back(Args.MakeArgString("-record-cmd-opts=" +
+ CmdLineOpts));

Nit: since we're using a thing directly convertible to StringRef, can we call 
`MakeArgStringRef` here instead?


https://reviews.llvm.org/D30760



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


[PATCH] D30766: Add support for attribute "enum_extensibility"

2017-03-20 Thread Akira Hatanaka via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
ahatanak marked an inline comment as done.
Closed by commit rL298332: Add support for attribute enum_extensibility. 
(authored by ahatanak).

Changed prior to commit:
  https://reviews.llvm.org/D30766?vs=91782&id=92418#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D30766

Files:
  cfe/trunk/include/clang/AST/Decl.h
  cfe/trunk/include/clang/Basic/Attr.td
  cfe/trunk/include/clang/Basic/AttrDocs.td
  cfe/trunk/lib/AST/Decl.cpp
  cfe/trunk/lib/Sema/SemaDecl.cpp
  cfe/trunk/lib/Sema/SemaDeclAttr.cpp
  cfe/trunk/lib/Sema/SemaStmt.cpp
  cfe/trunk/test/Sema/enum-attr.c
  cfe/trunk/test/SemaCXX/attr-flag-enum-reject.cpp
  cfe/trunk/test/SemaCXX/enum-attr.cpp

Index: cfe/trunk/test/SemaCXX/enum-attr.cpp
===
--- cfe/trunk/test/SemaCXX/enum-attr.cpp
+++ cfe/trunk/test/SemaCXX/enum-attr.cpp
@@ -0,0 +1,108 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -Wassign-enum -Wswitch-enum -Wcovered-switch-default -std=c++11 %s
+
+enum Enum {
+  A0 = 1, A1 = 10
+};
+
+enum __attribute__((enum_extensibility(closed))) EnumClosed {
+  B0 = 1, B1 = 10
+};
+
+enum [[clang::enum_extensibility(open)]] EnumOpen {
+  C0 = 1, C1 = 10
+};
+
+enum __attribute__((flag_enum)) EnumFlag {
+  D0 = 1, D1 = 8
+};
+
+enum __attribute__((flag_enum,enum_extensibility(closed))) EnumFlagClosed {
+  E0 = 1, E1 = 8
+};
+
+enum __attribute__((flag_enum,enum_extensibility(open))) EnumFlagOpen {
+  F0 = 1, F1 = 8
+};
+
+void test() {
+  enum Enum t0;
+
+  switch (t0) { // expected-warning{{enumeration value 'A1' not handled in switch}}
+  case A0: break;
+  case 16: break; // expected-warning{{case value not in enumerated type}}
+  }
+
+  switch (t0) {
+  case A0: break;
+  case A1: break;
+  default: break; // expected-warning{{default label in switch which covers all enumeration}}
+  }
+
+  enum EnumClosed t1;
+
+  switch (t1) { // expected-warning{{enumeration value 'B1' not handled in switch}}
+  case B0: break;
+  case 16: break; // expected-warning{{case value not in enumerated type}}
+  }
+
+  switch (t1) {
+  case B0: break;
+  case B1: break;
+  default: break; // expected-warning{{default label in switch which covers all enumeration}}
+  }
+
+  enum EnumOpen t2;
+
+  switch (t2) { // expected-warning{{enumeration value 'C1' not handled in switch}}
+  case C0: break;
+  case 16: break;
+  }
+
+  switch (t2) {
+  case C0: break;
+  case C1: break;
+  default: break;
+  }
+
+  enum EnumFlag t3;
+
+  switch (t3) { // expected-warning{{enumeration value 'D1' not handled in switch}}
+  case D0: break;
+  case 9: break;
+  case 16: break; // expected-warning{{case value not in enumerated type}}
+  }
+
+  switch (t3) {
+  case D0: break;
+  case D1: break;
+  default: break;
+  }
+
+  enum EnumFlagClosed t4;
+
+  switch (t4) { // expected-warning{{enumeration value 'E1' not handled in switch}}
+  case E0: break;
+  case 9: break;
+  case 16: break; // expected-warning{{case value not in enumerated type}}
+  }
+
+  switch (t4) {
+  case E0: break;
+  case E1: break;
+  default: break;
+  }
+
+  enum EnumFlagOpen t5;
+
+  switch (t5) { // expected-warning{{enumeration value 'F1' not handled in switch}}
+  case F0: break;
+  case 9: break;
+  case 16: break;
+  }
+
+  switch (t5) {
+  case F0: break;
+  case F1: break;
+  default: break;
+  }
+}
Index: cfe/trunk/test/SemaCXX/attr-flag-enum-reject.cpp
===
--- cfe/trunk/test/SemaCXX/attr-flag-enum-reject.cpp
+++ cfe/trunk/test/SemaCXX/attr-flag-enum-reject.cpp
@@ -1,4 +0,0 @@
-// RUN: %clang_cc1 -verify -fsyntax-only -x c++ -Wassign-enum %s
-
-enum __attribute__((flag_enum)) flag { // expected-warning {{ignored}}
-};
Index: cfe/trunk/test/Sema/enum-attr.c
===
--- cfe/trunk/test/Sema/enum-attr.c
+++ cfe/trunk/test/Sema/enum-attr.c
@@ -0,0 +1,130 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -Wassign-enum -Wswitch-enum -Wcovered-switch-default %s
+
+enum Enum {
+  A0 = 1, A1 = 10
+};
+
+enum __attribute__((enum_extensibility(closed))) EnumClosed {
+  B0 = 1, B1 = 10
+};
+
+enum __attribute__((enum_extensibility(open))) EnumOpen {
+  C0 = 1, C1 = 10
+};
+
+enum __attribute__((flag_enum)) EnumFlag {
+  D0 = 1, D1 = 8
+};
+
+enum __attribute__((flag_enum,enum_extensibility(closed))) EnumFlagClosed {
+  E0 = 1, E1 = 8
+};
+
+enum __attribute__((flag_enum,enum_extensibility(open))) EnumFlagOpen {
+  F0 = 1, F1 = 8
+};
+
+enum __attribute__((enum_extensibility(arg1))) EnumInvalidArg { // expected-warning{{'enum_extensibility' attribute argument not supported: 'arg1'}}
+  X0
+};
+
+// FIXME: The warning should mention that enum_extensibility takes only one argument.
+enum __attribute__((enum_extensibility(closed,open))) EnumTooManyArgs { // expected-error{{use of undeclared identifier 'open'}}
+  X1
+};
+
+enum __attribute__((enum_extensibility())) Enum

r298332 - Add support for attribute enum_extensibility.

2017-03-20 Thread Akira Hatanaka via cfe-commits
Author: ahatanak
Date: Mon Mar 20 21:23:00 2017
New Revision: 298332

URL: http://llvm.org/viewvc/llvm-project?rev=298332&view=rev
Log:
Add support for attribute enum_extensibility.

This commit adds support for a new attribute that will be used to
distinguish between extensible and inextensible enums. There are three
main purposes of this attribute:

1. Give better control over when enum-related warnings are issued.
For example, in the code below, clang will not issue a -Wassign-enum
warning if the enum is marked "open":

enum __attribute__((enum_extensibility(closed))) EnumClosed {
  B0 = 1, B1 = 10
};

enum __attribute__((enum_extensibility(open))) EnumOpen {
  C0 = 1, C1 = 10
};

enum EnumClosed ec = 100; // warning issued
enum EnumOpen eo = 100; // no warning

2. Enable code-completion and debugging tools to offer better
suggestions.

3. Make it easier for swift's clang importer to determine which swift
type an enum should be mapped to.

For more details, see the discussion I started on cfe-dev:
http://lists.llvm.org/pipermail/cfe-dev/2017-February/052748.html

rdar://problem/12764379
rdar://problem/23145650

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

Added:
cfe/trunk/test/Sema/enum-attr.c
cfe/trunk/test/SemaCXX/enum-attr.cpp
Removed:
cfe/trunk/test/SemaCXX/attr-flag-enum-reject.cpp
Modified:
cfe/trunk/include/clang/AST/Decl.h
cfe/trunk/include/clang/Basic/Attr.td
cfe/trunk/include/clang/Basic/AttrDocs.td
cfe/trunk/lib/AST/Decl.cpp
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/lib/Sema/SemaDeclAttr.cpp
cfe/trunk/lib/Sema/SemaStmt.cpp

Modified: cfe/trunk/include/clang/AST/Decl.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Decl.h?rev=298332&r1=298331&r2=298332&view=diff
==
--- cfe/trunk/include/clang/AST/Decl.h (original)
+++ cfe/trunk/include/clang/AST/Decl.h Mon Mar 20 21:23:00 2017
@@ -3235,6 +3235,18 @@ public:
 return isCompleteDefinition() || isFixed();
   }
 
+  /// Returns true if this enum is either annotated with
+  /// enum_extensibility(closed) or isn't annotated with enum_extensibility.
+  bool isClosed() const;
+
+  /// Returns true if this enum is annotated with flag_enum and isn't annotated
+  /// with enum_extensibility(open).
+  bool isClosedFlag() const;
+
+  /// Returns true if this enum is annotated with neither flag_enum nor
+  /// enum_extensibility(open).
+  bool isClosedNonFlag() const;
+
   /// \brief Retrieve the enum definition from which this enumeration could
   /// be instantiated, if it is an instantiation (rather than a non-template).
   EnumDecl *getTemplateInstantiationPattern() const;

Modified: cfe/trunk/include/clang/Basic/Attr.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=298332&r1=298331&r2=298332&view=diff
==
--- cfe/trunk/include/clang/Basic/Attr.td (original)
+++ cfe/trunk/include/clang/Basic/Attr.td Mon Mar 20 21:23:00 2017
@@ -881,7 +881,15 @@ def FlagEnum : InheritableAttr {
   let Spellings = [GNU<"flag_enum">];
   let Subjects = SubjectList<[Enum]>;
   let Documentation = [FlagEnumDocs];
-  let LangOpts = [COnly];
+}
+
+def EnumExtensibility : InheritableAttr {
+  let Spellings = [GNU<"enum_extensibility">,
+   CXX11<"clang", "enum_extensibility">];
+  let Subjects = SubjectList<[Enum]>;
+  let Args = [EnumArgument<"Extensibility", "Kind",
+  ["closed", "open"], ["Closed", "Open"]>];
+  let Documentation = [EnumExtensibilityDocs];
 }
 
 def Flatten : InheritableAttr {

Modified: cfe/trunk/include/clang/Basic/AttrDocs.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/AttrDocs.td?rev=298332&r1=298331&r2=298332&view=diff
==
--- cfe/trunk/include/clang/Basic/AttrDocs.td (original)
+++ cfe/trunk/include/clang/Basic/AttrDocs.td Mon Mar 20 21:23:00 2017
@@ -1963,6 +1963,55 @@ manipulating bits of the enumerator when
   }];
 }
 
+def EnumExtensibilityDocs : Documentation {
+  let Category = DocCatType;
+  let Content = [{
+Attribute ``enum_extensibility`` is used to distinguish between enum 
definitions
+that are extensible and those that are not. The attribute can take either
+``closed`` or ``open`` as an argument. ``closed`` indicates a variable of the
+enum type takes a value that corresponds to one of the enumerators listed in 
the
+enum definition or, when the enum is annotated with ``flag_enum``, a value that
+can be constructed using values corresponding to the enumerators. ``open``
+indicates a variable of the enum type can take any values allowed by the
+standard and instructs clang to be more lenient when issuing warnings.
+
+.. code-block:: c
+
+  enum __attribute__((enum_extensibility(closed))) ClosedEnum {
+A0, A1
+  };
+
+  enum __attribute__((enum_ext

[PATCH] D31162: IRGen: Do not set dllexport on declarations.

2017-03-20 Thread Peter Collingbourne via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL298330: IRGen: Do not set dllexport on declarations. 
(authored by pcc).

Changed prior to commit:
  https://reviews.llvm.org/D31162?vs=92412&id=92416#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D31162

Files:
  cfe/trunk/lib/CodeGen/CodeGenModule.cpp
  cfe/trunk/test/CodeGenCXX/dllexport.cpp


Index: cfe/trunk/test/CodeGenCXX/dllexport.cpp
===
--- cfe/trunk/test/CodeGenCXX/dllexport.cpp
+++ cfe/trunk/test/CodeGenCXX/dllexport.cpp
@@ -108,8 +108,8 @@
 template __declspec(dllexport) int VarTmplDef;
 INSTVAR(VarTmplDef)
 
-// MSC-DAG: @"\01??$VarTmplImplicitDef@UImplicitInst_Exported3HA" = 
external dllexport global
-// GNU-DAG: @_Z18VarTmplImplicitDefI21ImplicitInst_ExportedE  = 
external dllexport global
+// MSC-DAG: @"\01??$VarTmplImplicitDef@UImplicitInst_Exported3HA" = 
external global
+// GNU-DAG: @_Z18VarTmplImplicitDefI21ImplicitInst_ExportedE  = 
external global
 template __declspec(dllexport) int VarTmplImplicitDef;
 USEVAR(VarTmplImplicitDef)
 
@@ -528,7 +528,7 @@
   // M32-DAG: define weak_odr dllexport x86_thiscallcc void @"\01?a@T@@QAEXXZ"
 
   static int b;
-  // M32-DAG: @"\01?b@T@@2HA" = external dllexport global i32
+  // M32-DAG: @"\01?b@T@@2HA" = external global i32
 
   static int c;
   // M32-DAG: @"\01?c@T@@2HA" = dllexport global i32 0, align 4
Index: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
===
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp
@@ -1036,7 +1036,6 @@
   GV->setDLLStorageClass(llvm::GlobalValue::DLLImportStorageClass);
 } else if (ND->hasAttr()) {
   GV->setLinkage(llvm::GlobalValue::ExternalLinkage);
-  GV->setDLLStorageClass(llvm::GlobalValue::DLLExportStorageClass);
 } else if (ND->hasAttr() || ND->isWeakImported()) {
   // "extern_weak" is overloaded in LLVM; we probably should have
   // separate linkage types for this.


Index: cfe/trunk/test/CodeGenCXX/dllexport.cpp
===
--- cfe/trunk/test/CodeGenCXX/dllexport.cpp
+++ cfe/trunk/test/CodeGenCXX/dllexport.cpp
@@ -108,8 +108,8 @@
 template __declspec(dllexport) int VarTmplDef;
 INSTVAR(VarTmplDef)
 
-// MSC-DAG: @"\01??$VarTmplImplicitDef@UImplicitInst_Exported3HA" = external dllexport global
-// GNU-DAG: @_Z18VarTmplImplicitDefI21ImplicitInst_ExportedE  = external dllexport global
+// MSC-DAG: @"\01??$VarTmplImplicitDef@UImplicitInst_Exported3HA" = external global
+// GNU-DAG: @_Z18VarTmplImplicitDefI21ImplicitInst_ExportedE  = external global
 template __declspec(dllexport) int VarTmplImplicitDef;
 USEVAR(VarTmplImplicitDef)
 
@@ -528,7 +528,7 @@
   // M32-DAG: define weak_odr dllexport x86_thiscallcc void @"\01?a@T@@QAEXXZ"
 
   static int b;
-  // M32-DAG: @"\01?b@T@@2HA" = external dllexport global i32
+  // M32-DAG: @"\01?b@T@@2HA" = external global i32
 
   static int c;
   // M32-DAG: @"\01?c@T@@2HA" = dllexport global i32 0, align 4
Index: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
===
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp
@@ -1036,7 +1036,6 @@
   GV->setDLLStorageClass(llvm::GlobalValue::DLLImportStorageClass);
 } else if (ND->hasAttr()) {
   GV->setLinkage(llvm::GlobalValue::ExternalLinkage);
-  GV->setDLLStorageClass(llvm::GlobalValue::DLLExportStorageClass);
 } else if (ND->hasAttr() || ND->isWeakImported()) {
   // "extern_weak" is overloaded in LLVM; we probably should have
   // separate linkage types for this.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r298330 - IRGen: Do not set dllexport on declarations.

2017-03-20 Thread Peter Collingbourne via cfe-commits
Author: pcc
Date: Mon Mar 20 21:02:41 2017
New Revision: 298330

URL: http://llvm.org/viewvc/llvm-project?rev=298330&view=rev
Log:
IRGen: Do not set dllexport on declarations.

Setting dllexport on a declaration has no effect, as we do not emit export
directives for declarations.

Part of the fix for PR32334.

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

Modified:
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/test/CodeGenCXX/dllexport.cpp

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=298330&r1=298329&r2=298330&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Mon Mar 20 21:02:41 2017
@@ -1036,7 +1036,6 @@ static void setLinkageAndVisibilityForGV
   GV->setDLLStorageClass(llvm::GlobalValue::DLLImportStorageClass);
 } else if (ND->hasAttr()) {
   GV->setLinkage(llvm::GlobalValue::ExternalLinkage);
-  GV->setDLLStorageClass(llvm::GlobalValue::DLLExportStorageClass);
 } else if (ND->hasAttr() || ND->isWeakImported()) {
   // "extern_weak" is overloaded in LLVM; we probably should have
   // separate linkage types for this.

Modified: cfe/trunk/test/CodeGenCXX/dllexport.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/dllexport.cpp?rev=298330&r1=298329&r2=298330&view=diff
==
--- cfe/trunk/test/CodeGenCXX/dllexport.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/dllexport.cpp Mon Mar 20 21:02:41 2017
@@ -108,8 +108,8 @@ inline int __declspec(dllexport) inlineS
 template __declspec(dllexport) int VarTmplDef;
 INSTVAR(VarTmplDef)
 
-// MSC-DAG: @"\01??$VarTmplImplicitDef@UImplicitInst_Exported3HA" = 
external dllexport global
-// GNU-DAG: @_Z18VarTmplImplicitDefI21ImplicitInst_ExportedE  = 
external dllexport global
+// MSC-DAG: @"\01??$VarTmplImplicitDef@UImplicitInst_Exported3HA" = 
external global
+// GNU-DAG: @_Z18VarTmplImplicitDefI21ImplicitInst_ExportedE  = 
external global
 template __declspec(dllexport) int VarTmplImplicitDef;
 USEVAR(VarTmplImplicitDef)
 
@@ -528,7 +528,7 @@ struct __declspec(dllexport) T {
   // M32-DAG: define weak_odr dllexport x86_thiscallcc void @"\01?a@T@@QAEXXZ"
 
   static int b;
-  // M32-DAG: @"\01?b@T@@2HA" = external dllexport global i32
+  // M32-DAG: @"\01?b@T@@2HA" = external global i32
 
   static int c;
   // M32-DAG: @"\01?c@T@@2HA" = dllexport global i32 0, align 4


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


[PATCH] D31163: Implement Pp0156r2 "Variadic Lock Guard, version 5"

2017-03-20 Thread Marshall Clow via Phabricator via cfe-commits
mclow.lists created this revision.

WG21 has decided that the ABI-breaking `lock_guard` proposal that we (@EricWF) 
implemented (and hid behind an ABI-break macro) is not the way to go. Instead, 
we're introducing a new class, `scoped_lock`, which is variadic, and leaving 
`lock_guard` as non-variadic.

So, delete Eric's work, nuke the ABI macro, and implement the non-ABI breaking 
stuff.

While I'm in the neighborhood, implement the mutex-ey parts of P0433: 
"Deduction guides for the standard library". This bit has the guides for 
`lock_guard`, `scoped_lock`, `unique_lock`, and `shared_lock`.

Note: If you're using the variadic version of `lock_guard`, then this is a 
breaking change.  Good news is that you just switch to using `scoped_lock`, and 
everything works the same.


https://reviews.llvm.org/D31163

Files:
  include/__config
  include/__mutex_base
  include/mutex
  include/shared_mutex
  
test/libcxx/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_mutex_mangling.pass.cpp
  test/std/thread/thread.mutex/thread.lock/thread.lock.guard/mutex.pass.cpp
  
test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_adopt_lock.pass.cpp
  
test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_assign.fail.cpp
  
test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_copy.fail.cpp
  
test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_mutex.fail.cpp
  
test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_mutex.pass.cpp
  
test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_mutex_cxx03.pass.cpp
  
test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_types.pass.cpp
  
test/std/thread/thread.mutex/thread.lock/thread.lock.scoped/adopt_lock.pass.cpp
  test/std/thread/thread.mutex/thread.lock/thread.lock.scoped/assign.fail.cpp
  test/std/thread/thread.mutex/thread.lock/thread.lock.scoped/copy.fail.cpp
  test/std/thread/thread.mutex/thread.lock/thread.lock.scoped/mutex.fail.cpp
  test/std/thread/thread.mutex/thread.lock/thread.lock.scoped/mutex.pass.cpp
  test/std/thread/thread.mutex/thread.lock/thread.lock.scoped/types.pass.cpp
  
test/std/thread/thread.mutex/thread.lock/thread.lock.shared/thread.lock.shared.cons/mutex.pass.cpp
  
test/std/thread/thread.mutex/thread.lock/thread.lock.unique/thread.lock.unique.cons/mutex.pass.cpp

Index: test/std/thread/thread.mutex/thread.lock/thread.lock.unique/thread.lock.unique.cons/mutex.pass.cpp
===
--- test/std/thread/thread.mutex/thread.lock/thread.lock.unique/thread.lock.unique.cons/mutex.pass.cpp
+++ test/std/thread/thread.mutex/thread.lock/thread.lock.unique/thread.lock.unique.cons/mutex.pass.cpp
@@ -15,11 +15,16 @@
 
 // explicit unique_lock(mutex_type& m);
 
+// template unique_lock(unique_lock<_Mutex>)
+// -> unique_lock<_Mutex>;  // C++17
+
 #include 
 #include 
 #include 
 #include 
 
+#include "test_macros.h"
+
 std::mutex m;
 
 typedef std::chrono::system_clock Clock;
@@ -47,4 +52,8 @@
 std::this_thread::sleep_for(ms(250));
 m.unlock();
 t.join();
+
+#if TEST_STD_VER > 14
+	std::unique_lock ul(m);	// deduction guide
+#endif
 }
Index: test/std/thread/thread.mutex/thread.lock/thread.lock.shared/thread.lock.shared.cons/mutex.pass.cpp
===
--- test/std/thread/thread.mutex/thread.lock/thread.lock.shared/thread.lock.shared.cons/mutex.pass.cpp
+++ test/std/thread/thread.mutex/thread.lock/thread.lock.shared/thread.lock.shared.cons/mutex.pass.cpp
@@ -18,6 +18,9 @@
 
 // explicit shared_lock(mutex_type& m);
 
+// template shared_lock(shared_lock<_Mutex>)
+// -> shared_lock<_Mutex>;  // C++17
+
 #include 
 #include 
 #include 
@@ -92,4 +95,8 @@
 t.join();
 q.join();
 }
+
+#if TEST_STD_VER > 14
+	std::shared_lock sl(m);	// deduction guide
+#endif
 }
Index: test/std/thread/thread.mutex/thread.lock/thread.lock.scoped/types.pass.cpp
===
--- test/std/thread/thread.mutex/thread.lock/thread.lock.scoped/types.pass.cpp
+++ test/std/thread/thread.mutex/thread.lock/thread.lock.scoped/types.pass.cpp
@@ -0,0 +1,78 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+//
+// UNSUPPORTED: libcpp-has-no-threads
+// UNSUPPORTED: c++98, c++03, c++11, c++14
+
+// 
+
+// template 
+// class scoped_lock
+// {
+// public:
+// typedef Mutex mutex_type;  // only if sizeof...(Mutex) == 1
+// ...
+// };
+
+#include 
+#include 
+#include "test_macros.h"
+
+struct NAT {};
+
+template 
+auto test_typedef(int) -> typename LG::mutex_type;
+
+template 
+a

[PATCH] D30766: Add support for attribute "enum_extensibility"

2017-03-20 Thread Akira Hatanaka via Phabricator via cfe-commits
ahatanak marked an inline comment as done.
ahatanak added inline comments.



Comment at: test/Sema/enum-attr.c:27
+
+enum __attribute__((enum_extensibility(arg1))) EnumInvalidArg { // 
expected-warning{{'enum_extensibility' attribute argument not supported: 
'arg1'}}
+  G

aaron.ballman wrote:
> ahatanak wrote:
> > aaron.ballman wrote:
> > > ahatanak wrote:
> > > > arphaman wrote:
> > > > > Should this be an error instead?
> > > > Yes, I agree.
> > > I'm not opposed to it, but we do treat it as a warning for every other 
> > > attribute (and just ignore the attribute), FWIW.
> > Do you know the reason we treat wrong attribute arguments as a warning in 
> > other cases rather than an error?
> > 
> > I'm guessing a warning is preferred because in most cases dropping an 
> > attribute doesn't affect correctness (it doesn't cause miscompiles).
> You are correct. The general rule is to use warnings when an incorrect 
> attribute still has no impact on the code generated for the user, and use an 
> error otherwise. We're not always perfect about this, which is why I'm not 
> opposed, but since this involves adding an entirely new diagnostic, I figured 
> it might be worth mentioning that there's really no reason for this to be an 
> error that prevents the user's source code from being translated either.
OK. I don't think we have a strong reason to error out here so I think it's 
better to follow convention and issue a warning.



Comment at: test/Sema/enum-attr.c:31
+
+enum __attribute__((enum_extensibility(closed,open))) EnumTooManyArgs { // 
expected-error{{use of undeclared identifier 'open'}}
+  X1

aaron.ballman wrote:
> That's a rather unfortunate diagnostic. I would have expected this to mention 
> that it only takes one argument as in the zero arg case. I'm not certain that 
> this is the fault of your patch, however. Can you at least add a FIXME to 
> this test that mentions this diagnostic could be improved?
It's possible to implement a parser function in ParseDecl.cpp specifically for 
enum_extensibility to improve the diagnostic, but I think 
ParseAttributeArgsCommon should be able to check the number of arguments and 
emit a proper diagnostic. I've added a FIXME to the test for now.

It looks like ParseAttributeArgsCommon currently assumes that the first 
argument can be an identifier but it tries to parse the remaining arguments as 
expressions. I think it's possible to make it check the number of arguments 
provided and parse each argument according to its type.


https://reviews.llvm.org/D30766



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


[PATCH] D31162: IRGen: Do not set dllexport on declarations.

2017-03-20 Thread Reid Kleckner via Phabricator via cfe-commits
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.

Lgtm


https://reviews.llvm.org/D31162



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


[PATCH] D30760: Record command lines in objects built by clang

2017-03-20 Thread Zhizhou Yang via Phabricator via cfe-commits
zhizhouy updated this revision to Diff 92410.
zhizhouy added a comment.

Re-implemented the the patch: reusing -grecord-gcc-switches from gcc instead of 
passing arguments to DiagnosticsEngine.

If user specify the -grecord-gcc-switches in command line, Clang will start to 
record it in Driver, and create a CC1Option of "-record-cmd-opts" and record it 
in CodeGenOptions.

Producer will be updated directly from the CodeGenOptions.


https://reviews.llvm.org/D30760

Files:
  include/clang/Driver/CC1Options.td
  include/clang/Frontend/CodeGenOptions.h
  lib/CodeGen/CGDebugInfo.cpp
  lib/Driver/ToolChains/Clang.cpp
  lib/Frontend/CompilerInvocation.cpp


Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -529,6 +529,7 @@
   Opts.RelaxedAliasing = Args.hasArg(OPT_relaxed_aliasing);
   Opts.StructPathTBAA = !Args.hasArg(OPT_no_struct_path_tbaa);
   Opts.DwarfDebugFlags = Args.getLastArgValue(OPT_dwarf_debug_flags);
+  Opts.RecordCmdOpts = Args.getLastArgValue(OPT_record_cmd_opts_EQ);
   Opts.MergeAllConstants = !Args.hasArg(OPT_fno_merge_all_constants);
   Opts.NoCommon = Args.hasArg(OPT_fno_common);
   Opts.NoImplicitFloat = Args.hasArg(OPT_no_implicit_float);
Index: lib/Driver/ToolChains/Clang.cpp
===
--- lib/Driver/ToolChains/Clang.cpp
+++ lib/Driver/ToolChains/Clang.cpp
@@ -2720,7 +2720,16 @@
 DwarfVersion = getToolChain().GetDefaultDwarfVersion();
   }
 
-  // We ignore flags -gstrict-dwarf and -grecord-gcc-switches for now.
+  // Use -grecord-gcc-switches to record command line options from Driver.
+  if (Args.hasArg(options::OPT_grecord_gcc_switches)) {
+std::string CmdLineOpts = "";
+for (const auto *Arg : Args) CmdLineOpts += Arg->getAsString(Args) + " ";
+CmdLineOpts.pop_back();
+CmdArgs.push_back(Args.MakeArgString("-record-cmd-opts=" +
+ CmdLineOpts));
+  }
+
+  // We ignore flags -gstrict-dwarf for now.
   Args.ClaimAllArgs(options::OPT_g_flags_Group);
 
   // Column info is included by default for everything except PS4 and CodeView.
Index: lib/CodeGen/CGDebugInfo.cpp
===
--- lib/CodeGen/CGDebugInfo.cpp
+++ lib/CodeGen/CGDebugInfo.cpp
@@ -503,7 +503,10 @@
 LangTag = llvm::dwarf::DW_LANG_C89;
   }
 
+  // Producer records current clang version and the command line options from
+  // Driver.
   std::string Producer = getClangFullVersion();
+  Producer += " " + CGM.getCodeGenOpts().RecordCmdOpts;
 
   // Figure out which version of the ObjC runtime we have.
   unsigned RuntimeVers = 0;
Index: include/clang/Frontend/CodeGenOptions.h
===
--- include/clang/Frontend/CodeGenOptions.h
+++ include/clang/Frontend/CodeGenOptions.h
@@ -119,6 +119,9 @@
   /// non-empty.
   std::string DwarfDebugFlags;
 
+  /// The string of command line options from Driver.
+  std::string RecordCmdOpts;
+
   std::map DebugPrefixMap;
 
   /// The ABI to use for passing floating point arguments.
Index: include/clang/Driver/CC1Options.td
===
--- include/clang/Driver/CC1Options.td
+++ include/clang/Driver/CC1Options.td
@@ -144,6 +144,7 @@
   HelpText<"The compilation directory to embed in the debug info.">;
 def dwarf_debug_flags : Separate<["-"], "dwarf-debug-flags">,
   HelpText<"The string to embed in the Dwarf debug flags record.">;
+def record_cmd_opts_EQ : Joined<["-"], "record-cmd-opts=">;
 def mno_exec_stack : Flag<["-"], "mnoexecstack">,
   HelpText<"Mark the file as not needing an executable stack">;
 def massembler_fatal_warnings : Flag<["-"], "massembler-fatal-warnings">,


Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -529,6 +529,7 @@
   Opts.RelaxedAliasing = Args.hasArg(OPT_relaxed_aliasing);
   Opts.StructPathTBAA = !Args.hasArg(OPT_no_struct_path_tbaa);
   Opts.DwarfDebugFlags = Args.getLastArgValue(OPT_dwarf_debug_flags);
+  Opts.RecordCmdOpts = Args.getLastArgValue(OPT_record_cmd_opts_EQ);
   Opts.MergeAllConstants = !Args.hasArg(OPT_fno_merge_all_constants);
   Opts.NoCommon = Args.hasArg(OPT_fno_common);
   Opts.NoImplicitFloat = Args.hasArg(OPT_no_implicit_float);
Index: lib/Driver/ToolChains/Clang.cpp
===
--- lib/Driver/ToolChains/Clang.cpp
+++ lib/Driver/ToolChains/Clang.cpp
@@ -2720,7 +2720,16 @@
 DwarfVersion = getToolChain().GetDefaultDwarfVersion();
   }
 
-  // We ignore flags -gstrict-dwarf and -grecord-gcc-switches for now.
+  // Use -grecord-gcc-switches to record command line options from Driver.
+  if (Args.hasArg(options::OPT_grecor

[PATCH] D31162: IRGen: Do not set dllexport on declarations.

2017-03-20 Thread Peter Collingbourne via Phabricator via cfe-commits
pcc created this revision.

Setting dllexport on a declaration has no effect, as we do not emit export
directives for declarations.

Part of the fix for PR32334.


https://reviews.llvm.org/D31162

Files:
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/test/CodeGenCXX/dllexport.cpp


Index: clang/test/CodeGenCXX/dllexport.cpp
===
--- clang/test/CodeGenCXX/dllexport.cpp
+++ clang/test/CodeGenCXX/dllexport.cpp
@@ -108,8 +108,8 @@
 template __declspec(dllexport) int VarTmplDef;
 INSTVAR(VarTmplDef)
 
-// MSC-DAG: @"\01??$VarTmplImplicitDef@UImplicitInst_Exported3HA" = 
external dllexport global
-// GNU-DAG: @_Z18VarTmplImplicitDefI21ImplicitInst_ExportedE  = 
external dllexport global
+// MSC-DAG: @"\01??$VarTmplImplicitDef@UImplicitInst_Exported3HA" = 
external global
+// GNU-DAG: @_Z18VarTmplImplicitDefI21ImplicitInst_ExportedE  = 
external global
 template __declspec(dllexport) int VarTmplImplicitDef;
 USEVAR(VarTmplImplicitDef)
 
@@ -528,7 +528,7 @@
   // M32-DAG: define weak_odr dllexport x86_thiscallcc void @"\01?a@T@@QAEXXZ"
 
   static int b;
-  // M32-DAG: @"\01?b@T@@2HA" = external dllexport global i32
+  // M32-DAG: @"\01?b@T@@2HA" = external global i32
 
   static int c;
   // M32-DAG: @"\01?c@T@@2HA" = dllexport global i32 0, align 4
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -1036,7 +1036,6 @@
   GV->setDLLStorageClass(llvm::GlobalValue::DLLImportStorageClass);
 } else if (ND->hasAttr()) {
   GV->setLinkage(llvm::GlobalValue::ExternalLinkage);
-  GV->setDLLStorageClass(llvm::GlobalValue::DLLExportStorageClass);
 } else if (ND->hasAttr() || ND->isWeakImported()) {
   // "extern_weak" is overloaded in LLVM; we probably should have
   // separate linkage types for this.


Index: clang/test/CodeGenCXX/dllexport.cpp
===
--- clang/test/CodeGenCXX/dllexport.cpp
+++ clang/test/CodeGenCXX/dllexport.cpp
@@ -108,8 +108,8 @@
 template __declspec(dllexport) int VarTmplDef;
 INSTVAR(VarTmplDef)
 
-// MSC-DAG: @"\01??$VarTmplImplicitDef@UImplicitInst_Exported3HA" = external dllexport global
-// GNU-DAG: @_Z18VarTmplImplicitDefI21ImplicitInst_ExportedE  = external dllexport global
+// MSC-DAG: @"\01??$VarTmplImplicitDef@UImplicitInst_Exported3HA" = external global
+// GNU-DAG: @_Z18VarTmplImplicitDefI21ImplicitInst_ExportedE  = external global
 template __declspec(dllexport) int VarTmplImplicitDef;
 USEVAR(VarTmplImplicitDef)
 
@@ -528,7 +528,7 @@
   // M32-DAG: define weak_odr dllexport x86_thiscallcc void @"\01?a@T@@QAEXXZ"
 
   static int b;
-  // M32-DAG: @"\01?b@T@@2HA" = external dllexport global i32
+  // M32-DAG: @"\01?b@T@@2HA" = external global i32
 
   static int c;
   // M32-DAG: @"\01?c@T@@2HA" = dllexport global i32 0, align 4
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -1036,7 +1036,6 @@
   GV->setDLLStorageClass(llvm::GlobalValue::DLLImportStorageClass);
 } else if (ND->hasAttr()) {
   GV->setLinkage(llvm::GlobalValue::ExternalLinkage);
-  GV->setDLLStorageClass(llvm::GlobalValue::DLLExportStorageClass);
 } else if (ND->hasAttr() || ND->isWeakImported()) {
   // "extern_weak" is overloaded in LLVM; we probably should have
   // separate linkage types for this.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D30415: Fix -mno-altivec cannot overwrite -maltivec option

2017-03-20 Thread Eric Christopher via Phabricator via cfe-commits
echristo added a comment.

In https://reviews.llvm.org/D30415#705196, @uweigand wrote:

> In https://reviews.llvm.org/D30415#704761, @echristo wrote:
>
> > In https://reviews.llvm.org/D30415#703652, @uweigand wrote:
> >
> > > I'm a bit confused by this discussion.  -faltivec and -maltivec are 
> > > simply aliases, they do exactly the same thing; the clang-internal 
> > > variable OPT_faltivec indicates the use of either -faltivec or -maltivec.
> >
> >
> > They didn't used to, I arranged it so that they did (technically breaking 
> > gcc compatibility) a while ago.
>
>
> Well, mainline GCC doesn't have -faltivec at all and never had, I think this 
> was only an Apple GCC extension ...  Not sure what exactly the semantics of 
> that was.


Sure it does and has for years. Check out rs6000/darwin.h :)

FWIW: It turns on maltivec and adds a -include of altivec.h

>>> Or is the suggestion to simply remove the alias -faltivec, and leave 
>>> -maltivec as-is?  I'd be less opposed to this since it probably breaks 
>>> fewer users ... but I'm still not quite sure what it actually buys us.   
>>> And in any case the patch currently under discussion here would still be 
>>> necessary then, to fix -maltivec -mno-altivec ...
>> 
>> No, remove faltivec and move forward with -maltivec/-mno-altivec but you 
>> should be able to remove a lot of the special handling at that point.
> 
> I'm still confused as to what exactly you're refering to here.  As far as I 
> can see, every single thing triggered by -faltivec / -maltivec in the 
> compiler frontend would still be needed exactly the same if we only supported 
> the -maltivec option name.  So the only thing we'd save is literally the two 
> lines in include/clang/Driver/Options.td that set up the alias.
> 
> Do you have an example of the "special handling" to remove you're thinking of?

Nearly all of the code in lib/Driver/ToolChains/Clang.cpp and 
lib/Driver/ToolChains/Arch/PPC.cpp that deal with altivec. Simplifying the 
interface by getting rid of needing to check multiple options.

-eric


https://reviews.llvm.org/D30415



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


r298322 - Add a function to MD5 a file's contents.

2017-03-20 Thread Zachary Turner via cfe-commits
Author: zturner
Date: Mon Mar 20 18:33:18 2017
New Revision: 298322

URL: http://llvm.org/viewvc/llvm-project?rev=298322&view=rev
Log:
Add a function to MD5 a file's contents.

In doing so, clean up the MD5 interface a little.  Most
existing users only care about the lower 8 bytes of an MD5,
but for some users that care about the upper and lower,
there wasn't a good interface.  Furthermore, consumers
of the MD5 checksum were required to handle endianness
details on their own, so it seems reasonable to abstract
this into a nicer interface that just gives you the right
value.

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

Modified:
cfe/trunk/lib/CodeGen/CodeGenPGO.cpp
cfe/trunk/lib/Frontend/ASTUnit.cpp

Modified: cfe/trunk/lib/CodeGen/CodeGenPGO.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenPGO.cpp?rev=298322&r1=298321&r2=298322&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenPGO.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenPGO.cpp Mon Mar 20 18:33:18 2017
@@ -612,7 +612,7 @@ uint64_t PGOHash::finalize() {
   llvm::MD5::MD5Result Result;
   MD5.final(Result);
   using namespace llvm::support;
-  return endian::read(Result);
+  return Result.low();
 }
 
 void CodeGenPGO::assignRegionCounters(GlobalDecl GD, llvm::Function *Fn) {

Modified: cfe/trunk/lib/Frontend/ASTUnit.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/ASTUnit.cpp?rev=298322&r1=298321&r2=298322&view=diff
==
--- cfe/trunk/lib/Frontend/ASTUnit.cpp (original)
+++ cfe/trunk/lib/Frontend/ASTUnit.cpp Mon Mar 20 18:33:18 2017
@@ -1252,7 +1252,7 @@ ASTUnit::PreambleFileHash::createForFile
   PreambleFileHash Result;
   Result.Size = Size;
   Result.ModTime = ModTime;
-  memset(Result.MD5, 0, sizeof(Result.MD5));
+  Result.MD5 = {};
   return Result;
 }
 
@@ -1273,7 +1273,7 @@ namespace clang {
 bool operator==(const ASTUnit::PreambleFileHash &LHS,
 const ASTUnit::PreambleFileHash &RHS) {
   return LHS.Size == RHS.Size && LHS.ModTime == RHS.ModTime &&
- memcmp(LHS.MD5, RHS.MD5, sizeof(LHS.MD5)) == 0;
+ LHS.MD5 == RHS.MD5;
 }
 } // namespace clang
 


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


[PATCH] D31160: [clang-tidy] Fix misc-move-const-arg for move-only types.

2017-03-20 Thread Alexander Kornienko via Phabricator via cfe-commits
alexfh created this revision.

Fix misc-move-const-arg false positives on move-only types.


https://reviews.llvm.org/D31160

Files:
  clang-tidy/misc/MoveConstantArgumentCheck.cpp
  test/clang-tidy/misc-move-const-arg.cpp


Index: test/clang-tidy/misc-move-const-arg.cpp
===
--- test/clang-tidy/misc-move-const-arg.cpp
+++ test/clang-tidy/misc-move-const-arg.cpp
@@ -158,3 +158,16 @@
   // a lambda that is, in turn, an argument to a macro.
   CALL([no_move_semantics] { M3(NoMoveSemantics, no_move_semantics); });
 }
+
+class MoveOnly {
+public:
+  MoveOnly(const MoveOnly &other) = delete;
+  MoveOnly &operator=(const MoveOnly &other) = delete;
+  MoveOnly(MoveOnly &&other) = default;
+  MoveOnly &operator=(MoveOnly &&other) = default;
+};
+template 
+void Q(T);
+void moveOnlyNegatives(MoveOnly val) {
+  Q(std::move(val));
+}
Index: clang-tidy/misc/MoveConstantArgumentCheck.cpp
===
--- clang-tidy/misc/MoveConstantArgumentCheck.cpp
+++ clang-tidy/misc/MoveConstantArgumentCheck.cpp
@@ -73,6 +73,12 @@
   Arg->getType().isTriviallyCopyableType(*Result.Context);
 
   if (IsConstArg || IsTriviallyCopyable) {
+if (const CXXRecordDecl *R = Arg->getType()->getAsCXXRecordDecl()) {
+  for (const auto *Ctor : R->ctors()) {
+if (Ctor->isCopyConstructor() && Ctor->isDeleted())
+  return;
+  }
+}
 bool IsVariable = isa(Arg);
 const auto *Var =
 IsVariable ? dyn_cast(Arg)->getDecl() : nullptr;


Index: test/clang-tidy/misc-move-const-arg.cpp
===
--- test/clang-tidy/misc-move-const-arg.cpp
+++ test/clang-tidy/misc-move-const-arg.cpp
@@ -158,3 +158,16 @@
   // a lambda that is, in turn, an argument to a macro.
   CALL([no_move_semantics] { M3(NoMoveSemantics, no_move_semantics); });
 }
+
+class MoveOnly {
+public:
+  MoveOnly(const MoveOnly &other) = delete;
+  MoveOnly &operator=(const MoveOnly &other) = delete;
+  MoveOnly(MoveOnly &&other) = default;
+  MoveOnly &operator=(MoveOnly &&other) = default;
+};
+template 
+void Q(T);
+void moveOnlyNegatives(MoveOnly val) {
+  Q(std::move(val));
+}
Index: clang-tidy/misc/MoveConstantArgumentCheck.cpp
===
--- clang-tidy/misc/MoveConstantArgumentCheck.cpp
+++ clang-tidy/misc/MoveConstantArgumentCheck.cpp
@@ -73,6 +73,12 @@
   Arg->getType().isTriviallyCopyableType(*Result.Context);
 
   if (IsConstArg || IsTriviallyCopyable) {
+if (const CXXRecordDecl *R = Arg->getType()->getAsCXXRecordDecl()) {
+  for (const auto *Ctor : R->ctors()) {
+if (Ctor->isCopyConstructor() && Ctor->isDeleted())
+  return;
+  }
+}
 bool IsVariable = isa(Arg);
 const auto *Var =
 IsVariable ? dyn_cast(Arg)->getDecl() : nullptr;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D31155: [X86][AVX512] Add _mm512_cvtsd_f64 and _mm512_cvtss_f32 intrinsics (PR32305)

2017-03-20 Thread Craig Topper via Phabricator via cfe-commits
craig.topper accepted this revision.
craig.topper added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rL LLVM

https://reviews.llvm.org/D31155



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


[PATCH] D31155: [X86][AVX512] Add _mm512_cvtsd_f64 and _mm512_cvtss_f32 intrinsics (PR32305)

2017-03-20 Thread Simon Pilgrim via Phabricator via cfe-commits
RKSimon created this revision.

Repository:
  rL LLVM

https://reviews.llvm.org/D31155

Files:
  lib/Headers/avx512fintrin.h
  test/CodeGen/avx512f-builtins.c


Index: test/CodeGen/avx512f-builtins.c
===
--- test/CodeGen/avx512f-builtins.c
+++ test/CodeGen/avx512f-builtins.c
@@ -7259,6 +7259,18 @@
   return _mm512_maskz_cvtps_epu32( __U, __A);
 }
 
+double test_mm512_cvtsd_f64(__m512d A) {
+  // CHECK-LABEL: test_mm512_cvtsd_f64
+  // CHECK: extractelement <8 x double> %{{.*}}, i32 0
+  return _mm512_cvtsd_f64(A);
+}
+
+float test_mm512_cvtss_f32(__m512 A) {
+  // CHECK-LABEL: test_mm512_cvtss_f32
+  // CHECK: extractelement <16 x float> %{{.*}}, i32 0
+  return _mm512_cvtss_f32(A);
+}
+
 __m512d test_mm512_mask_max_pd (__m512d __W, __mmask8 __U, __m512d __A, 
__m512d __B)
 {
   // CHECK-LABEL: @test_mm512_mask_max_pd 
Index: lib/Headers/avx512fintrin.h
===
--- lib/Headers/avx512fintrin.h
+++ lib/Headers/avx512fintrin.h
@@ -4229,6 +4229,18 @@
   _MM_FROUND_CUR_DIRECTION);
 }
 
+static __inline__ double __DEFAULT_FN_ATTRS
+_mm512_cvtsd_f64(__m512d __a)
+{
+  return __a[0];
+}
+
+static __inline__ float __DEFAULT_FN_ATTRS
+_mm512_cvtss_f32(__m512 __a)
+{
+  return __a[0];
+}
+
 /* Unpack and Interleave */
 
 static __inline __m512d __DEFAULT_FN_ATTRS


Index: test/CodeGen/avx512f-builtins.c
===
--- test/CodeGen/avx512f-builtins.c
+++ test/CodeGen/avx512f-builtins.c
@@ -7259,6 +7259,18 @@
   return _mm512_maskz_cvtps_epu32( __U, __A);
 }
 
+double test_mm512_cvtsd_f64(__m512d A) {
+  // CHECK-LABEL: test_mm512_cvtsd_f64
+  // CHECK: extractelement <8 x double> %{{.*}}, i32 0
+  return _mm512_cvtsd_f64(A);
+}
+
+float test_mm512_cvtss_f32(__m512 A) {
+  // CHECK-LABEL: test_mm512_cvtss_f32
+  // CHECK: extractelement <16 x float> %{{.*}}, i32 0
+  return _mm512_cvtss_f32(A);
+}
+
 __m512d test_mm512_mask_max_pd (__m512d __W, __mmask8 __U, __m512d __A, __m512d __B)
 {
   // CHECK-LABEL: @test_mm512_mask_max_pd 
Index: lib/Headers/avx512fintrin.h
===
--- lib/Headers/avx512fintrin.h
+++ lib/Headers/avx512fintrin.h
@@ -4229,6 +4229,18 @@
   _MM_FROUND_CUR_DIRECTION);
 }
 
+static __inline__ double __DEFAULT_FN_ATTRS
+_mm512_cvtsd_f64(__m512d __a)
+{
+  return __a[0];
+}
+
+static __inline__ float __DEFAULT_FN_ATTRS
+_mm512_cvtss_f32(__m512 __a)
+{
+  return __a[0];
+}
+
 /* Unpack and Interleave */
 
 static __inline __m512d __DEFAULT_FN_ATTRS
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r298318 - Fix parsing of htmxlintrin.h in C++ mode

2017-03-20 Thread Eric Christopher via cfe-commits
Author: echristo
Date: Mon Mar 20 17:31:33 2017
New Revision: 298318

URL: http://llvm.org/viewvc/llvm-project?rev=298318&view=rev
Log:
Fix parsing of htmxlintrin.h in C++ mode
 - Fix a variable naming mismatch
 - Fix gcc extension pointer arithmetic on void to cast to char *.
 - Test that the header (and htmintrin.h) parse.

Added:
cfe/trunk/test/Headers/htm-header.c
Modified:
cfe/trunk/lib/Headers/htmxlintrin.h

Modified: cfe/trunk/lib/Headers/htmxlintrin.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/htmxlintrin.h?rev=298318&r1=298317&r2=298318&view=diff
==
--- cfe/trunk/lib/Headers/htmxlintrin.h (original)
+++ cfe/trunk/lib/Headers/htmxlintrin.h Mon Mar 20 17:31:33 2017
@@ -35,14 +35,10 @@
 extern "C" {
 #endif
 
-#define _TEXASR_PTR(TM_BUF) \
-  ((texasr_t *)((TM_BUF)+0))
-#define _TEXASRU_PTR(TM_BUF) \
-  ((texasru_t *)((TM_BUF)+0))
-#define _TEXASRL_PTR(TM_BUF) \
-  ((texasrl_t *)((TM_BUF)+4))
-#define _TFIAR_PTR(TM_BUF) \
-  ((tfiar_t *)((TM_BUF)+8))
+#define _TEXASR_PTR(TM_BUF) ((texasr_t *)((char *)(TM_BUF) + 0))
+#define _TEXASRU_PTR(TM_BUF) ((texasru_t *)((char *)(TM_BUF) + 0))
+#define _TEXASRL_PTR(TM_BUF) ((texasrl_t *)((char *)(TM_BUF) + 4))
+#define _TFIAR_PTR(TM_BUF) ((tfiar_t *)((char *)(TM_BUF) + 8))
 
 typedef char TM_buff_type[16];
 
@@ -178,7 +174,7 @@ extern __inline long
 __attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
 __TM_is_conflict(void* const __TM_buff)
 {
-  texasru_t texasru = *_TEXASRU_PTR (TM_buff);
+  texasru_t texasru = *_TEXASRU_PTR (__TM_buff);
   /* Return TEXASR bits 11 (Self-Induced Conflict) through
  14 (Translation Invalidation Conflict).  */
   return (_TEXASRU_EXTRACT_BITS (texasru, 14, 4)) ? 1 : 0;

Added: cfe/trunk/test/Headers/htm-header.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Headers/htm-header.c?rev=298318&view=auto
==
--- cfe/trunk/test/Headers/htm-header.c (added)
+++ cfe/trunk/test/Headers/htm-header.c Mon Mar 20 17:31:33 2017
@@ -0,0 +1,19 @@
+// RUN: %clang_cc1 -triple powerpc64le-unknown-unknown -target-feature +htm 
-DHTM_HEADER -ffreestanding -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64le-unknown-unknown -target-feature +htm 
-DHTM_HEADER -ffreestanding -emit-llvm -x c++ -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64le-unknown-unknown -target-feature +htm 
-DHTMXL_HEADER -ffreestanding -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64le-unknown-unknown -target-feature +htm 
-DHTMXL_HEADER -ffreestanding -emit-llvm -x c++ -o - %s | FileCheck %s
+
+#ifdef HTM_HEADER
+#include 
+#endif
+
+#ifdef HTMXL_HEADER
+#include 
+#endif
+
+// Verify that simply including the headers does not generate any code
+// (i.e. all inline routines in the header are marked "static")
+
+// CHECK: target triple = "powerpc64
+// CHECK-NEXT: {{^$}}
+// CHECK-NEXT: {{llvm\..*}}


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


[PATCH] D31153: Add the ability to use the children() range API in a const-correct manner

2017-03-20 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman created this revision.

We already have children() but not children() const, which is causing some 
problems for me on an out of tree project. Most of the changes here are 
mechanical, except for the work done to `ConstStmtIterator`, which cheats and 
uses a `const_cast`. Since none of these are *actually* const, this should not 
trigger UB.


https://reviews.llvm.org/D31153

Files:
  include/clang/AST/Expr.h
  include/clang/AST/StmtIterator.h

Index: include/clang/AST/StmtIterator.h
===
--- include/clang/AST/StmtIterator.h
+++ include/clang/AST/StmtIterator.h
@@ -137,6 +137,10 @@
 
   ConstStmtIterator(const StmtIterator& RHS) :
 StmtIteratorImpl(RHS) {}
+
+  ConstStmtIterator(Stmt * const *S)
+  : StmtIteratorImpl(
+const_cast(S)) {}
 };
 
 } // end namespace clang
Index: include/clang/AST/Expr.h
===
--- include/clang/AST/Expr.h
+++ include/clang/AST/Expr.h
@@ -907,6 +907,10 @@
 return child_range(child_iterator(), child_iterator());
   }
 
+  const_child_range children() const {
+return const_child_range(const_child_iterator(), const_child_iterator());
+  }
+
   /// The source expression of an opaque value expression is the
   /// expression which originally generated the value.  This is
   /// provided as a convenience for analyses that don't wish to
@@ -1167,6 +1171,10 @@
 return child_range(child_iterator(), child_iterator());
   }
 
+  const_child_range children() const {
+return const_child_range(const_child_iterator(), const_child_iterator());
+  }
+
   friend TrailingObjects;
   friend class ASTStmtReader;
   friend class ASTStmtWriter;
@@ -1222,6 +1230,9 @@
 
   // Iterators
   child_range children() { return child_range(&FnName, &FnName + 1); }
+  const_child_range children() const {
+return const_child_range(&FnName, &FnName + 1);
+  }
 
   friend class ASTStmtReader;
 };
@@ -1315,6 +1326,9 @@
   child_range children() {
 return child_range(child_iterator(), child_iterator());
   }
+  const_child_range children() const {
+return const_child_range(const_child_iterator(), const_child_iterator());
+  }
 };
 
 class CharacterLiteral : public Expr {
@@ -1365,6 +1379,9 @@
   child_range children() {
 return child_range(child_iterator(), child_iterator());
   }
+  const_child_range children() const {
+return const_child_range(const_child_iterator(), const_child_iterator());
+  }
 };
 
 class FloatingLiteral : public Expr, private APFloatStorage {
@@ -1429,6 +1446,9 @@
   child_range children() {
 return child_range(child_iterator(), child_iterator());
   }
+  const_child_range children() const {
+return const_child_range(const_child_iterator(), const_child_iterator());
+  }
 };
 
 /// ImaginaryLiteral - We support imaginary integer and floating point literals,
@@ -1461,6 +1481,9 @@
 
   // Iterators
   child_range children() { return child_range(&Val, &Val+1); }
+  const_child_range children() const {
+return const_child_range(&Val, &Val + 1);
+  }
 };
 
 /// StringLiteral - This represents a string literal expression, e.g. "foo"
@@ -1628,6 +1651,9 @@
   child_range children() {
 return child_range(child_iterator(), child_iterator());
   }
+  const_child_range children() const {
+return const_child_range(const_child_iterator(), const_child_iterator());
+  }
 };
 
 /// ParenExpr - This represents a parethesized expression, e.g. "(1)".  This
@@ -1669,6 +1695,9 @@
 
   // Iterators
   child_range children() { return child_range(&Val, &Val+1); }
+  const_child_range children() const {
+return const_child_range(&Val, &Val + 1);
+  }
 };
 
 /// UnaryOperator - This represents the unary-expression's (except sizeof and
@@ -1778,6 +1807,9 @@
 
   // Iterators
   child_range children() { return child_range(&Val, &Val+1); }
+  const_child_range children() const {
+return const_child_range(&Val, &Val + 1);
+  }
 };
 
 /// Helper class for OffsetOfExpr.
@@ -1981,6 +2013,11 @@
 Stmt **begin = reinterpret_cast(getTrailingObjects());
 return child_range(begin, begin + NumExprs);
   }
+  const_child_range children() const {
+Stmt *const *begin =
+reinterpret_cast(getTrailingObjects());
+return const_child_range(begin, begin + NumExprs);
+  }
   friend TrailingObjects;
 };
 
@@ -2153,6 +2190,9 @@
   child_range children() {
 return child_range(&SubExprs[0], &SubExprs[0]+END_EXPR);
   }
+  const_child_range children() const {
+return const_child_range(&SubExprs[0], &SubExprs[0] + END_EXPR);
+  }
 };
 
 /// CallExpr - Represents a function call (C99 6.5.2.2, C++ [expr.call]).
@@ -2313,6 +2353,11 @@
 return child_range(&SubExprs[0],
&SubExprs[0]+NumArgs+getNumPreArgs()+PREARGS_START);
   }
+
+  const_child_range children() const {
+return const_child_range(&SubExprs[0], &SubExprs[0] + NumArgs +
+ 

[clang-tools-extra] r298316 - [clang-tidy] readability-container-size-empty fix for (*x).size()

2017-03-20 Thread Alexander Kornienko via cfe-commits
Author: alexfh
Date: Mon Mar 20 17:15:27 2017
New Revision: 298316

URL: http://llvm.org/viewvc/llvm-project?rev=298316&view=rev
Log:
[clang-tidy] readability-container-size-empty fix for (*x).size()

Modified:
clang-tools-extra/trunk/clang-tidy/readability/ContainerSizeEmptyCheck.cpp
clang-tools-extra/trunk/test/clang-tidy/readability-container-size-empty.cpp

Modified: 
clang-tools-extra/trunk/clang-tidy/readability/ContainerSizeEmptyCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/readability/ContainerSizeEmptyCheck.cpp?rev=298316&r1=298315&r2=298316&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/readability/ContainerSizeEmptyCheck.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/readability/ContainerSizeEmptyCheck.cpp 
Mon Mar 20 17:15:27 2017
@@ -56,8 +56,7 @@ void ContainerSizeEmptyCheck::registerMa
   Finder->addMatcher(
   cxxMemberCallExpr(on(expr(anyOf(hasType(ValidContainer),
   hasType(pointsTo(ValidContainer)),
-  hasType(references(ValidContainer
-   .bind("STLObject")),
+  hasType(references(ValidContainer),
 callee(cxxMethodDecl(hasName("size"))), WrongUse,
 unless(hasAncestor(cxxMethodDecl(
 ofClass(equalsBoundNode("container"))
@@ -69,7 +68,7 @@ void ContainerSizeEmptyCheck::check(cons
   const auto *MemberCall =
   Result.Nodes.getNodeAs("SizeCallExpr");
   const auto *BinaryOp = 
Result.Nodes.getNodeAs("SizeBinaryOp");
-  const auto *E = Result.Nodes.getNodeAs("STLObject");
+  const auto *E = MemberCall->getImplicitObjectArgument();
   FixItHint Hint;
   std::string ReplacementText =
   Lexer::getSourceText(CharSourceRange::getTokenRange(E->getSourceRange()),

Modified: 
clang-tools-extra/trunk/test/clang-tidy/readability-container-size-empty.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/readability-container-size-empty.cpp?rev=298316&r1=298315&r2=298316&view=diff
==
--- 
clang-tools-extra/trunk/test/clang-tidy/readability-container-size-empty.cpp 
(original)
+++ 
clang-tools-extra/trunk/test/clang-tidy/readability-container-size-empty.cpp 
Mon Mar 20 17:15:27 2017
@@ -168,6 +168,10 @@ int main() {
 ;
   // CHECK-MESSAGES: :[[@LINE-2]]:7: warning: the 'empty' method should be used
   // CHECK-FIXES: {{^  }}if (vect3->empty()){{$}}
+  if ((*vect3).size() == 0)
+;
+  // CHECK-MESSAGES: :[[@LINE-2]]:7: warning: the 'empty' method should be used
+  // CHECK-FIXES: {{^  }}if ((*vect3).empty()){{$}}
 
   delete vect3;
 


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


[clang-tools-extra] r298315 - [clang-tidy] Small cleanup. NFC.

2017-03-20 Thread Alexander Kornienko via cfe-commits
Author: alexfh
Date: Mon Mar 20 17:15:19 2017
New Revision: 298315

URL: http://llvm.org/viewvc/llvm-project?rev=298315&view=rev
Log:
[clang-tidy] Small cleanup. NFC.

Modified:
clang-tools-extra/trunk/clang-tidy/readability/DeleteNullPointerCheck.cpp

Modified: 
clang-tools-extra/trunk/clang-tidy/readability/DeleteNullPointerCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/readability/DeleteNullPointerCheck.cpp?rev=298315&r1=298314&r2=298315&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/readability/DeleteNullPointerCheck.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/readability/DeleteNullPointerCheck.cpp 
Mon Mar 20 17:15:19 2017
@@ -67,16 +67,10 @@ void DeleteNullPointerCheck::check(const
  *Result.SourceManager,
  Result.Context->getLangOpts(;
   if (Compound) {
-Diag << FixItHint::CreateRemoval(CharSourceRange::getTokenRange(
-Compound->getLBracLoc(),
-Lexer::getLocForEndOfToken(Compound->getLBracLoc(), 0,
-   *Result.SourceManager,
-   Result.Context->getLangOpts(;
-Diag << FixItHint::CreateRemoval(CharSourceRange::getTokenRange(
-Compound->getRBracLoc(),
-Lexer::getLocForEndOfToken(Compound->getRBracLoc(), 0,
-   *Result.SourceManager,
-   Result.Context->getLangOpts(;
+Diag << FixItHint::CreateRemoval(
+CharSourceRange::getTokenRange(Compound->getLBracLoc()));
+Diag << FixItHint::CreateRemoval(
+CharSourceRange::getTokenRange(Compound->getRBracLoc()));
   }
 }
 


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


[PATCH] D31130: B32239 clang-tidy should not warn about array to pointer decay on system macros

2017-03-20 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: 
clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.cpp:50
 
+AST_MATCHER(Stmt, isArrayToPointerDecay) {
+  const auto *MatchedCast = cast(&Node);

Why not match on `ImplicitCastExpr` rather than `Stmt`? Then you can remove the 
explicit cast below.



Comment at: 
clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.cpp:55
+
+AST_MATCHER(Stmt, sysSymbolDecayInSysHeader) {
+  const auto *E = cast(&Node);

Likewise here.



Comment at: 
clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.cpp:59-60
+  if (SM.isInSystemMacro(E->getLocStart())) {
+const auto *PredefSymbol = dyn_cast(E->getSubExpr());
+if (PredefSymbol)
+  return true;

I think this is better-expressed with an isa check: `if 
(isa(E->getSubExpr())) return true;`



Comment at: 
clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.cpp:63-64
+
+const auto *SymbolDeclRef = dyn_cast(E->getSubExpr());
+if (SymbolDeclRef) {
+  const ValueDecl *SymbolDecl = SymbolDeclRef->getDecl();

You can combine these into `if (const auto *SDR = dyn_cast<>())`


https://reviews.llvm.org/D31130



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


[PATCH] D30009: Add support for '#pragma clang attribute'

2017-03-20 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In https://reviews.llvm.org/D30009#705649, @efriedma wrote:

> Looking over the most recent version, I'm happy with the general semantics of 
> push with apply_only_to.  I'm not sure I see the point of apply_to: it 
> doesn't allow the user to do anything that can't be done with apply_only_to.  
> Also, if the apply_to list for an attribute ever changes, it becomes 
> impossible to write code which supports both versions of the compiler.


You bring up a really good point about compiler versioning -- it would be 
pretty awful to force the user to use #ifs to deal with that.

I believe apply_to is somewhat useful so that the user knows what an attribute 
actually appertains to, and get a diagnostic if we ever extend the list of 
things their particular attribute can appertain to so they are forced to decide 
whether they want that new behavior or not.

@arphaman, what do you think about the idea of only having apply_to with the 
same semantics as you currently have for apply_only_to?


Repository:
  rL LLVM

https://reviews.llvm.org/D30009



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


[PATCH] D27651: [clang-format] Even with AlignConsecutiveDeclarations, PointerAlignment: Right should keep *s and &s to the right

2017-03-20 Thread Ken-Patrick Lehrmann via Phabricator via cfe-commits
KP added a comment.

ping


https://reviews.llvm.org/D27651



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


r298310 - [docs] Clarify sanitizer flag behavior

2017-03-20 Thread Vedant Kumar via cfe-commits
Author: vedantk
Date: Mon Mar 20 16:40:58 2017
New Revision: 298310

URL: http://llvm.org/viewvc/llvm-project?rev=298310&view=rev
Log:
[docs] Clarify sanitizer flag behavior

PR32346 suggests that UBSan's docs about the -fsanitize,
-fno-sanitize-recover, and -fsanitize-trap options are not explicit
enough. Try to improve the wording.

Modified:
cfe/trunk/docs/UndefinedBehaviorSanitizer.rst

Modified: cfe/trunk/docs/UndefinedBehaviorSanitizer.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UndefinedBehaviorSanitizer.rst?rev=298310&r1=298309&r2=298310&view=diff
==
--- cfe/trunk/docs/UndefinedBehaviorSanitizer.rst (original)
+++ cfe/trunk/docs/UndefinedBehaviorSanitizer.rst Mon Mar 20 16:40:58 2017
@@ -50,9 +50,9 @@ instead of ``clang++`` if you're compili
 You can enable only a subset of :ref:`checks ` offered by UBSan,
 and define the desired behavior for each kind of check:
 
-* print a verbose error report and continue execution (default);
-* print a verbose error report and exit the program;
-* execute a trap instruction (doesn't require UBSan run-time support).
+* ``-fsanitize=...``: print a verbose error report and continue execution 
(default);
+* ``-fno-sanitize-recover=...``: print a verbose error report and exit the 
program;
+* ``-fsanitize-trap=...``: execute a trap instruction (doesn't require UBSan 
run-time support).
 
 For example if you compile/link your program as:
 


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


r298307 - Turn on HTM on power8 and later (including powerpc64le) since it's

2017-03-20 Thread Eric Christopher via cfe-commits
Author: echristo
Date: Mon Mar 20 16:12:53 2017
New Revision: 298307

URL: http://llvm.org/viewvc/llvm-project?rev=298307&view=rev
Log:
Turn on HTM on power8 and later (including powerpc64le) since it's
available by default on those cpus and configurations.

Modified:
cfe/trunk/lib/Basic/Targets.cpp
cfe/trunk/test/Driver/ppc-features.cpp
cfe/trunk/test/Preprocessor/predefined-arch-macros.c

Modified: cfe/trunk/lib/Basic/Targets.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=298307&r1=298306&r2=298307&view=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Mon Mar 20 16:12:53 2017
@@ -1488,6 +1488,11 @@ bool PPCTargetInfo::initFeatureMap(
 .Case("pwr8", true)
 .Case("pwr7", true)
 .Default(false);
+  Features["htm"] = llvm::StringSwitch(CPU)
+.Case("ppc64le", true)
+.Case("pwr9", true)
+.Case("pwr8", true)
+.Default(false);
 
   if (!ppcUserFeaturesCheck(Diags, FeaturesVec))
 return false;

Modified: cfe/trunk/test/Driver/ppc-features.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/ppc-features.cpp?rev=298307&r1=298306&r2=298307&view=diff
==
--- cfe/trunk/test/Driver/ppc-features.cpp (original)
+++ cfe/trunk/test/Driver/ppc-features.cpp Mon Mar 20 16:12:53 2017
@@ -151,6 +151,12 @@
 // RUN: %clang -target powerpc64-unknown-linux-gnu %s -mno-vsx -mvsx -### -o 
%t.o 2>&1 | FileCheck -check-prefix=CHECK-VSX %s
 // CHECK-VSX: "-target-feature" "+vsx"
 
+// RUN: %clang -target powerpc64-unknown-linux-gnu %s -mno-htm -### -o %t.o 
2>&1 | FileCheck -check-prefix=CHECK-NOHTM %s
+// CHECK-NOHTM: "-target-feature" "-htm"
+
+// RUN: %clang -target powerpc64-unknown-linux-gnu %s -mno-htm -mhtm -### -o 
%t.o 2>&1 | FileCheck -check-prefix=CHECK-HTM %s
+// CHECK-HTM: "-target-feature" "+htm"
+
 // RUN: %clang -target powerpc64-unknown-linux-gnu %s -mno-power8-vector -### 
-o %t.o 2>&1 | FileCheck -check-prefix=CHECK-NOP8VECTOR %s
 // CHECK-NOP8VECTOR: "-target-feature" "-power8-vector"
 

Modified: cfe/trunk/test/Preprocessor/predefined-arch-macros.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Preprocessor/predefined-arch-macros.c?rev=298307&r1=298306&r2=298307&view=diff
==
--- cfe/trunk/test/Preprocessor/predefined-arch-macros.c (original)
+++ cfe/trunk/test/Preprocessor/predefined-arch-macros.c Mon Mar 20 16:12:53 
2017
@@ -1984,6 +1984,24 @@
 // RUN:   | FileCheck -match-full-lines %s -check-prefix=CHECK_PPC_CRYPTO_M64
 //
 // CHECK_PPC_CRYPTO_M64: #define __CRYPTO__ 1
+
+// HTM is available on power8 or later which includes all of powerpc64le as an
+// ABI choice. Test that, the cpus, and the option.
+// RUN: %clang -mhtm -E -dM %s -o - 2>&1 \
+// RUN: -target powerpc64-unknown-linux \
+// RUN:   | FileCheck -match-full-lines %s -check-prefix=CHECK_PPC_HTM
+// RUN: %clang -E -dM %s -o - 2>&1 \
+// RUN: -target powerpc64le-unknown-linux \
+// RUN:   | FileCheck -match-full-lines %s -check-prefix=CHECK_PPC_HTM
+// RUN: %clang -mcpu=pwr8 -E -dM %s -o - 2>&1 \
+// RUN: -target powerpc64-unknown-linux \
+// RUN:   | FileCheck -match-full-lines %s -check-prefix=CHECK_PPC_HTM
+// RUN: %clang -mcpu=pwr9 -E -dM %s -o - 2>&1 \
+// RUN: -target powerpc64-unknown-linux \
+// RUN:   | FileCheck -match-full-lines %s -check-prefix=CHECK_PPC_HTM
+//
+// CHECK_PPC_HTM: #define __HTM__ 1
+
 //
 // RUN: %clang -mcpu=ppc64 -E -dM %s -o - 2>&1 \
 // RUN: -target powerpc64-unknown-unknown \


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


[PATCH] D27387: [libc++] Add a key function for bad_function_call

2017-03-20 Thread Shoaib Meenai via Phabricator via cfe-commits
smeenai added a subscriber: dexonsmith.
smeenai added a comment.

@jyknight 
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20161205/178830.html 
has the reasoning for guarding behind an ABI macro (with @dexonsmith from Apple 
weighing in).


https://reviews.llvm.org/D27387



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


[PATCH] D30009: Add support for '#pragma clang attribute'

2017-03-20 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added a comment.

Looking over the most recent version, I'm happy with the general semantics of 
push with apply_only_to.  I'm not sure I see the point of apply_to: it doesn't 
allow the user to do anything that can't be done with apply_only_to.  Also, if 
the apply_to list for an attribute ever changes, it becomes impossible to write 
code which supports both versions of the compiler.


Repository:
  rL LLVM

https://reviews.llvm.org/D30009



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


r298303 - Proposal: Backward-edge CFI for return statements (RCFI)

2017-03-20 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Mon Mar 20 15:42:00 2017
New Revision: 298303

URL: http://llvm.org/viewvc/llvm-project?rev=298303&view=rev
Log:
Proposal: Backward-edge CFI for return statements (RCFI)

Summary: Proposal: Backward-edge CFI for return statements (RCFI)

Reviewers: pcc, eugenis, krasin

Reviewed By: eugenis

Subscribers: llvm-commits

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

Modified:
cfe/trunk/docs/ControlFlowIntegrityDesign.rst

Modified: cfe/trunk/docs/ControlFlowIntegrityDesign.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ControlFlowIntegrityDesign.rst?rev=298303&r1=298302&r2=298303&view=diff
==
--- cfe/trunk/docs/ControlFlowIntegrityDesign.rst (original)
+++ cfe/trunk/docs/ControlFlowIntegrityDesign.rst Mon Mar 20 15:42:00 2017
@@ -498,12 +498,100 @@ In non-PIE executables the address of an
 the main executable) is the address of that function’s PLT record in
 the main executable. This would break the CFI checks.
 
+Backward-edge CFI for return statements (RCFI)
+==
+
+This section is a proposal. As of March 2017 it is not implemented.
+
+Backward-edge control flow (`RET` instructions) can be hijacked
+via overwriting the return address (`RA`) on stack.
+Various mitigation techniques (e.g. `SafeStack`_, `RFG`_, `Intel CET`_)
+try to detect or prevent `RA` corruption on stack.
+
+RCFI enforces the expected control flow in several different ways described 
below.
+RCFI heavily relies on LTO.
+
+Leaf Functions
+--
+If `f()` is a leaf function (i.e. it has no calls
+except maybe no-return calls) it can be called using a special calling 
convention
+that stores `RA` in a dedicated register `R` before the `CALL` instruction.
+`f()` does not spill `R` and does not use the `RET` instruction,
+instead it uses the value in `R` to `JMP` to `RA`.
+
+This flavour of CFI is *precise*, i.e. the function is guaranteed to return
+to the point exactly following the call.
+
+An alternative approach is to
+copy `RA` from stack to `R` in the first instruction of `f()`,
+then `JMP` to `R`.
+This approach is simpler to implement (does not require changing the caller)
+but weaker (there is a small window when `RA` is actually stored on stack).
+
+
+Functions called once
+-
+Suppose `f()` is called in just one place in the program
+(assuming we can verify this in LTO mode).
+In this case we can replace the `RET` instruction with a `JMP` instruction
+with the immediate constant for `RA`.
+This will *precisely* enforce the return control flow no matter what is stored 
on stack.
+
+Another variant is to compare `RA` on stack with the known constant and abort
+if they don't match; then `JMP` to the known constant address.
+
+Functions called in a small number of call sites
+
+We may extend the above approach to cases where `f()`
+is called more than once (but still a small number of times).
+With LTO we know all possible values of `RA` and we check them
+one-by-one (or using binary search) against the value on stack.
+If the match is found, we `JMP` to the known constant address, otherwise abort.
+
+This protection is *near-precise*, i.e. it guarantees that the control flow 
will
+be transferred to one of the valid return addresses for this function,
+but not necessary to the point of the most recent `CALL`.
+
+General case
+
+For functions called multiple times a *return jump table* is constructed
+in the same manner as jump tables for indirect function calls (see above).
+The correct jump table entry (or it's index) is passed by `CALL` to `f()`
+(as an extra argument) and then spilled to stack.
+The `RET` instruction is replaced with a load of the jump table entry,
+jump table range check, and `JMP` to the jump table entry.
+
+This protection is also *near-precise*.
+
+Returns from functions called indirectly
+
+
+If a function is called indirectly, the return jump table is constructed for 
the
+equivalence class of functions instead of a single function.
+
+Cross-DSO calls
+---
+Consider two instrumented DSOs, `A` and `B`. `A` defines `f()` and `B` calls 
it.
+
+This case will be handled similarly to the cross-DSO scheme using the slow 
path callback.
+
+Non-goals
+-
+
+RCFI does not protect `RET` instructions:
+  * in non-instrumented DSOs,
+  * in instrumented DSOs for functions that are called from non-instrumented 
DSOs,
+  * embedded into other instructions (e.g. `0f4fc3 cmovg %ebx,%eax`).
+
+.. _SafeStack: https://clang.llvm.org/docs/SafeStack.html
+.. _RFG: http://xlab.tencent.com/en/2016/11/02/return-flow-guard
+.. _Intel CET: 
https://software.intel.com/en-us/blogs/2016/06/09/intel-release-new-technology-specifications-protect-rop-attacks
 
 Hardware support
 
 
 We believe that the above design ca

r298300 - Avoid these headers looking like the same file on a content-addressed file system.

2017-03-20 Thread Richard Smith via cfe-commits
Author: rsmith
Date: Mon Mar 20 15:14:03 2017
New Revision: 298300

URL: http://llvm.org/viewvc/llvm-project?rev=298300&view=rev
Log:
Avoid these headers looking like the same file on a content-addressed file 
system.

Modified:
cfe/trunk/test/Modules/Inputs/system-out-of-date/X.h
cfe/trunk/test/Modules/Inputs/system-out-of-date/Z.h

Modified: cfe/trunk/test/Modules/Inputs/system-out-of-date/X.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/system-out-of-date/X.h?rev=298300&r1=298299&r2=298300&view=diff
==
--- cfe/trunk/test/Modules/Inputs/system-out-of-date/X.h (original)
+++ cfe/trunk/test/Modules/Inputs/system-out-of-date/X.h Mon Mar 20 15:14:03 
2017
@@ -1 +1,2 @@
+// X.h
 #import 

Modified: cfe/trunk/test/Modules/Inputs/system-out-of-date/Z.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/system-out-of-date/Z.h?rev=298300&r1=298299&r2=298300&view=diff
==
--- cfe/trunk/test/Modules/Inputs/system-out-of-date/Z.h (original)
+++ cfe/trunk/test/Modules/Inputs/system-out-of-date/Z.h Mon Mar 20 15:14:03 
2017
@@ -1 +1,2 @@
+// Z.h
 #import 


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


r298299 - Bump __cplusplus for C++17 to 201703L per the C++17 DIS.

2017-03-20 Thread Richard Smith via cfe-commits
Author: rsmith
Date: Mon Mar 20 15:12:48 2017
New Revision: 298299

URL: http://llvm.org/viewvc/llvm-project?rev=298299&view=rev
Log:
Bump __cplusplus for C++17 to 201703L per the C++17 DIS.

Modified:
cfe/trunk/lib/Frontend/InitPreprocessor.cpp
cfe/trunk/test/Preprocessor/init.c

Modified: cfe/trunk/lib/Frontend/InitPreprocessor.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/InitPreprocessor.cpp?rev=298299&r1=298298&r2=298299&view=diff
==
--- cfe/trunk/lib/Frontend/InitPreprocessor.cpp (original)
+++ cfe/trunk/lib/Frontend/InitPreprocessor.cpp Mon Mar 20 15:12:48 2017
@@ -374,9 +374,11 @@ static void InitializeStandardPredefined
 else if (!LangOpts.GNUMode && LangOpts.Digraphs)
   Builder.defineMacro("__STDC_VERSION__", "199409L");
   } else {
-// FIXME: Use correct value for C++17.
+// C++17 [cpp.predefined]p1:
+//   The name __cplusplus is defined to the value 201703L when compiling a
+//   C++ translation unit.
 if (LangOpts.CPlusPlus1z)
-  Builder.defineMacro("__cplusplus", "201406L");
+  Builder.defineMacro("__cplusplus", "201703L");
 // C++1y [cpp.predefined]p1:
 //   The name __cplusplus is defined to the value 201402L when compiling a
 //   C++ translation unit.

Modified: cfe/trunk/test/Preprocessor/init.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Preprocessor/init.c?rev=298299&r1=298298&r2=298299&view=diff
==
--- cfe/trunk/test/Preprocessor/init.c (original)
+++ cfe/trunk/test/Preprocessor/init.c Mon Mar 20 15:12:48 2017
@@ -15,7 +15,7 @@
 // CXX1Z:#define __GXX_EXPERIMENTAL_CXX0X__ 1
 // CXX1Z:#define __GXX_RTTI 1
 // CXX1Z:#define __GXX_WEAK__ 1
-// CXX1Z:#define __cplusplus 201406L
+// CXX1Z:#define __cplusplus 201703L
 // CXX1Z:#define __private_extern__ extern
 //
 //
@@ -115,7 +115,7 @@
 //
 // GXX1Z:#define __GNUG__ {{.*}}
 // GXX1Z:#define __GXX_WEAK__ 1
-// GXX1Z:#define __cplusplus 201406L
+// GXX1Z:#define __cplusplus 201703L
 // GXX1Z:#define __private_extern__ extern
 //
 //


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


[PATCH] D31022: Implement P0298R3: `std::byte`

2017-03-20 Thread Marshall Clow via Phabricator via cfe-commits
mclow.lists updated this revision to Diff 92370.
mclow.lists added a comment.

Put the `std::byte` type in the unadorned namespace `std`, rather than the 
versioned one.  This matches the behavior of other types that the compiler 
"knows about", like `initializer_list`, `type_info`, `bad_alloc` and so on.

Thanks to @rsmith for the catch.


https://reviews.llvm.org/D31022

Files:
  include/cstddef
  include/type_traits
  test/std/language.support/support.types/byte.pass.cpp
  test/std/language.support/support.types/byteops/and.assign.pass.cpp
  test/std/language.support/support.types/byteops/and.pass.cpp
  test/std/language.support/support.types/byteops/lshift.assign.fail.cpp
  test/std/language.support/support.types/byteops/lshift.assign.pass.cpp
  test/std/language.support/support.types/byteops/lshift.fail.cpp
  test/std/language.support/support.types/byteops/lshift.pass.cpp
  test/std/language.support/support.types/byteops/not.pass.cpp
  test/std/language.support/support.types/byteops/or.assign.pass.cpp
  test/std/language.support/support.types/byteops/or.pass.cpp
  test/std/language.support/support.types/byteops/rshift.assign.fail.cpp
  test/std/language.support/support.types/byteops/rshift.assign.pass.cpp
  test/std/language.support/support.types/byteops/rshift.fail.cpp
  test/std/language.support/support.types/byteops/rshift.pass.cpp
  test/std/language.support/support.types/byteops/to_integer.fail.cpp
  test/std/language.support/support.types/byteops/to_integer.pass.cpp
  test/std/language.support/support.types/byteops/xor.assign.pass.cpp
  test/std/language.support/support.types/byteops/xor.pass.cpp
  www/cxx1z_status.html

Index: www/cxx1z_status.html
===
--- www/cxx1z_status.html
+++ www/cxx1z_status.html
@@ -144,7 +144,7 @@
   	
 	http://wg21.link/P0156R2";>P0156R2LWGVariadic Lock guardKona
 	http://wg21.link/P0270R3";>P0270R3CWGRemoving C dependencies from signal handler wordingKona
-	http://wg21.link/P0298R3";>P0298R3CWGA byte type definitionKona
+	http://wg21.link/P0298R3";>P0298R3CWGA byte type definitionKonaComplete5.0
 	http://wg21.link/P0317R1";>P0317R1LWGDirectory Entry Caching for FilesystemKona
 	http://wg21.link/P0430R2";>P0430R2LWGFile system library on non-POSIX-like operating systemsKona
 	http://wg21.link/P0433R2";>P0433R2LWGToward a resolution of US7 and US14: Integrating template deduction for class templates into the standard libraryKona
Index: test/std/language.support/support.types/byteops/xor.pass.cpp
===
--- test/std/language.support/support.types/byteops/xor.pass.cpp
+++ test/std/language.support/support.types/byteops/xor.pass.cpp
@@ -0,0 +1,31 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include 
+#include 
+
+// XFAIL: c++98, c++03, c++11, c++14
+
+// constexpr byte operator^(byte l, byte r) noexcept;
+
+int main () {
+	constexpr std::byte b1{1};
+	constexpr std::byte b8{8};
+	constexpr std::byte b9{9};
+
+	static_assert(noexcept(b1 ^ b8), "" );
+
+	static_assert(std::to_integer(b1 ^ b8) == 9, "");
+	static_assert(std::to_integer(b1 ^ b9) == 8, "");
+	static_assert(std::to_integer(b8 ^ b9) == 1, "");
+
+	static_assert(std::to_integer(b8 ^ b1) == 9, "");
+	static_assert(std::to_integer(b9 ^ b1) == 8, "");
+	static_assert(std::to_integer(b9 ^ b8) == 1, "");
+}
Index: test/std/language.support/support.types/byteops/xor.assign.pass.cpp
===
--- test/std/language.support/support.types/byteops/xor.assign.pass.cpp
+++ test/std/language.support/support.types/byteops/xor.assign.pass.cpp
@@ -0,0 +1,39 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include 
+#include 
+
+// XFAIL: c++98, c++03, c++11, c++14
+
+// constexpr byte& operator ^=(byte l, byte r) noexcept;
+
+
+constexpr std::byte test(std::byte b1, std::byte b2) {
+	std::byte bret = b1;
+	return bret ^= b2;
+	}
+
+
+int main () {
+	std::byte b;  // not constexpr, just used in noexcept check
+	constexpr std::byte b1{1};
+	constexpr std::byte b8{8};
+	constexpr std::byte b9{9};
+
+	static_assert(noexcept(b ^= b), "" );
+
+	static_assert(std::to_integer(test(b1, b8)) == 9, "");
+	static_assert(std::to_integer(test(b1, b9)) == 8, "");
+	static_assert(std::to_integer(test(b8, b9)) == 1, "");
+
+	stati

[PATCH] D31121: [clangd] Add support for vscode extension configuration

2017-03-20 Thread Stanislav Ionascu via Phabricator via cfe-commits
stanionascu added inline comments.



Comment at: clangd/clients/clangd-vscode/package.json:45
+"default": "clangd",
+"description": "The path to clangd executable"
+},

krasimir wrote:
> krasimir wrote:
> > Maybe prepend a `, for example: /usr/bin/clangd` to the "description".
> meh, it's OK like that.
I still extended the description with the example :)


https://reviews.llvm.org/D31121



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


[PATCH] D31121: [clangd] Add support for vscode extension configuration

2017-03-20 Thread Stanislav Ionascu via Phabricator via cfe-commits
stanionascu updated this revision to Diff 92367.
stanionascu edited the summary of this revision.
stanionascu added a comment.

- removed unrelated new line change
- extended the "clang.path" description a bit
- removed defaultValue for getConfig<>, as it's anyway "contributed" by 
extension package.json


https://reviews.llvm.org/D31121

Files:
  clangd/clients/clangd-vscode/package.json
  clangd/clients/clangd-vscode/src/extension.ts


Index: clangd/clients/clangd-vscode/src/extension.ts
===
--- clangd/clients/clangd-vscode/src/extension.ts
+++ clangd/clients/clangd-vscode/src/extension.ts
@@ -2,14 +2,24 @@
 import * as vscodelc from 'vscode-languageclient';
 
 /**
+ * Method to get workspace configuration option
+ * @param option name of the option (e.g. for clangd.path should be path)
+ * @param defaultValue default value to return if option is not set
+ */
+function getConfig(option: string, defaultValue?: any) : T {
+const config = vscode.workspace.getConfiguration('clangd');
+return config.get(option, defaultValue);
+}
+
+/**
  *  this method is called when your extension is activate
  *  your extension is activated the very first time the command is executed
  */
 export function activate(context: vscode.ExtensionContext) {
-// TODO: make this configurable
-const clangdPath = '/usr/bin/clangd';
+const clangdPath = getConfig('path');
+const clangdArgs = getConfig('arguments');
 
-const serverOptions: vscodelc.ServerOptions = { command: clangdPath };
+const serverOptions: vscodelc.ServerOptions = { command: clangdPath, args: 
clangdArgs };
 
 const clientOptions: vscodelc.LanguageClientOptions = {
 // Register the server for C/C++ files
@@ -39,4 +49,4 @@
 const disposable = clangdClient.start();
 
 context.subscriptions.push(disposable, 
vscode.commands.registerCommand('clangd.applyFix', applyTextEdits));
-}
\ No newline at end of file
+}
Index: clangd/clients/clangd-vscode/package.json
===
--- clangd/clients/clangd-vscode/package.json
+++ clangd/clients/clangd-vscode/package.json
@@ -33,5 +33,26 @@
 "mocha": "^2.3.3",
 "@types/node": "^6.0.40",
 "@types/mocha": "^2.2.32"
+},
+"contributes": {
+"configuration": {
+"type": "object",
+"title": "clangd configuration",
+"properties": {
+"clangd.path": {
+"type": "string",
+"default": "clangd",
+"description": "The path to clangd executable, e.g.: 
/usr/bin/clangd"
+},
+"clangd.arguments": {
+"type": "array",
+"default": [],
+"items": {
+"type": "string"
+},
+"description": "Arguments for clangd server"
+}
+}
+}
 }
-}
\ No newline at end of file
+}


Index: clangd/clients/clangd-vscode/src/extension.ts
===
--- clangd/clients/clangd-vscode/src/extension.ts
+++ clangd/clients/clangd-vscode/src/extension.ts
@@ -2,14 +2,24 @@
 import * as vscodelc from 'vscode-languageclient';
 
 /**
+ * Method to get workspace configuration option
+ * @param option name of the option (e.g. for clangd.path should be path)
+ * @param defaultValue default value to return if option is not set
+ */
+function getConfig(option: string, defaultValue?: any) : T {
+const config = vscode.workspace.getConfiguration('clangd');
+return config.get(option, defaultValue);
+}
+
+/**
  *  this method is called when your extension is activate
  *  your extension is activated the very first time the command is executed
  */
 export function activate(context: vscode.ExtensionContext) {
-// TODO: make this configurable
-const clangdPath = '/usr/bin/clangd';
+const clangdPath = getConfig('path');
+const clangdArgs = getConfig('arguments');
 
-const serverOptions: vscodelc.ServerOptions = { command: clangdPath };
+const serverOptions: vscodelc.ServerOptions = { command: clangdPath, args: clangdArgs };
 
 const clientOptions: vscodelc.LanguageClientOptions = {
 // Register the server for C/C++ files
@@ -39,4 +49,4 @@
 const disposable = clangdClient.start();
 
 context.subscriptions.push(disposable, vscode.commands.registerCommand('clangd.applyFix', applyTextEdits));
-}
\ No newline at end of file
+}
Index: clangd/clients/clangd-vscode/package.json
===
--- clangd/clients/clangd-vscode/package.json
+++ clangd/clients/clangd-vscode/package.json
@@ -33,5 +33,26 @@
 "mocha": "^2.3.3",
 "@types/node": "^6.0.40",
 "@types/mocha": "^2.2.32"
+},
+"contributes": {
+"configura

[libcxx] r298284 - Add two more papers from Kona, and sort them

2017-03-20 Thread Marshall Clow via cfe-commits
Author: marshall
Date: Mon Mar 20 13:18:09 2017
New Revision: 298284

URL: http://llvm.org/viewvc/llvm-project?rev=298284&view=rev
Log:
Add two more papers from Kona, and sort them

Modified:
libcxx/trunk/www/cxx1z_status.html

Modified: libcxx/trunk/www/cxx1z_status.html
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/cxx1z_status.html?rev=298284&r1=298283&r2=298284&view=diff
==
--- libcxx/trunk/www/cxx1z_status.html (original)
+++ libcxx/trunk/www/cxx1z_status.html Mon Mar 20 13:18:09 2017
@@ -142,23 +142,25 @@
http://wg21.link/P0517R0";>P0517R0LWGMake 
future_error 
ConstructibleIssaquahComplete4.0
http://wg21.link/P0521R0";>P0521R0LWGProposed 
Resolution for CA 14 (shared_ptr 
use_count/unique)IssaquahNothing to 
don/a

+   http://wg21.link/P0156R2";>P0156R2LWGVariadic Lock 
guardKona
+   http://wg21.link/P0270R3";>P0270R3CWGRemoving C 
dependencies from signal handler 
wordingKona
+   http://wg21.link/P0298R3";>P0298R3CWGA byte type 
definitionKona
http://wg21.link/P0317R1";>P0317R1LWGDirectory Entry 
Caching for FilesystemKona
-   http://wg21.link/P0492R2";>P0492R2LWGProposed 
Resolution of C++17 National Body Comments for 
FilesystemsKona
http://wg21.link/P0430R2";>P0430R2LWGFile system 
library on non-POSIX-like operating 
systemsKona
+   http://wg21.link/P0433R2";>P0433R2LWGToward a 
resolution of US7 and US14: Integrating template deduction for class templates 
into the standard libraryKona
http://wg21.link/P0452R1";>P0452R1LWGUnifying 
 Parallel AlgorithmsKona
+   http://wg21.link/P0467R2";>P0467R2LWGIterator 
Concerns for Parallel AlgorithmsKona
+   http://wg21.link/P0492R2";>P0492R2LWGProposed 
Resolution of C++17 National Body Comments for 
FilesystemsKona
http://wg21.link/P0518R1";>P0518R1LWGAllowing copies 
as arguments to function objects given to parallel algorithms in response to 
CH11Kona
http://wg21.link/P0523R1";>P0523R1LWGWording for CH 
10: Complexity of parallel algorithmsKona
+   http://wg21.link/P0548R1";>P0548R1LWGcommon_type and 
durationKona
+   http://wg21.link/P0558R1";>P0558R1LWGResolving 
atomic named base class 
inconsistenciesKona
http://wg21.link/P0574R1";>P0574R1LWGAlgorithm 
Complexity Constraints and Parallel 
OverloadsKona
-   http://wg21.link/P0467R2";>P0467R2LWGIterator 
Concerns for Parallel AlgorithmsKona
-   http://wg21.link/P0623R0";>P0623R0LWGFinal C++17 
Parallel Algorithms FixesKona
+   http://wg21.link/P0599R1";>P0599R1LWGnoexcept for 
hash functionsKona
http://wg21.link/P0604R0";>P0604R0LWGResolving GB 
55, US 84, US 85, US 86Kona
http://wg21.link/P0607R0";>P0607R0LWGInline 
Variables for the Standard LibraryKona
http://wg21.link/P0618R0";>P0618R0LWGDeprecating 
Kona
-   http://wg21.link/P0156R2";>P0156R2LWGVariadic Lock 
guardKona
-   http://wg21.link/P0599R1";>P0599R1LWGnoexcept for 
hash functionsKona
-   http://wg21.link/P0433R2";>P0433R2LWGToward a 
resolution of US7 and US14: Integrating template deduction for class templates 
into the standard libraryKona
-   http://wg21.link/P0558R1";>P0558R1LWGResolving 
atomic named base class 
inconsistenciesKona
-   http://wg21.link/P0548R1";>P0548R1LWGcommon_type and 
durationKona
+   http://wg21.link/P0623R0";>P0623R0LWGFinal C++17 
Parallel Algorithms FixesKona
 
 
   


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


[PATCH] D31101: [ThinLTO] Use clang's existing code gen handling for ThinLTO backends

2017-03-20 Thread Teresa Johnson via Phabricator via cfe-commits
tejohnson added inline comments.



Comment at: lib/CodeGen/BackendUtil.cpp:1007
   else
 AsmHelper.EmitAssembly(Action, std::move(OS));
 

I just noticed that EmitAssembly does a lot more than just emission - it is 
also setting up an optimization pipeline in CreatePasses, which we don't want 
to do in the ThinLTO backend case as we already do the opt in LTO. Which makes 
me think that the simplest and most consistent solution, especially if as in 
discussed in D31114 we'll be using the LTO API for emitting object and assembly 
code, is to use LTO for all file emission in the ThinLTO backend case. It would 
mean extending lto::Config to be able to flag when we want to emit-llvm or 
emit-llvm-bc, and invoke the appropriate module writer/printer instead of 
normal codegen. That way -emit-llvm* will always get output corresponding to 
the native object/assembly in the ThinLTO backend case. WDYT?


https://reviews.llvm.org/D31101



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


[PATCH] D29923: PPCallbacks::MacroUndefined, change signature and add test.

2017-03-20 Thread Frederich Munch via Phabricator via cfe-commits
marsupial added a comment.

ping


https://reviews.llvm.org/D29923



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


r298278 - Reapply "Modules: Cache PCMs in memory and avoid a use-after-free"

2017-03-20 Thread Duncan P. N. Exon Smith via cfe-commits
Author: dexonsmith
Date: Mon Mar 20 12:58:26 2017
New Revision: 298278

URL: http://llvm.org/viewvc/llvm-project?rev=298278&view=rev
Log:
Reapply "Modules: Cache PCMs in memory and avoid a use-after-free"

This reverts commit r298185, effectively reapplying r298165, after fixing the
new unit tests (PR32338).  The memory buffer generator doesn't null-terminate
the MemoryBuffer it creates; this version of the commit informs getMemBuffer
about that to avoid the assert.

Original commit message follows:



Clang's internal build system for implicit modules uses lock files to
ensure that after a process writes a PCM it will read the same one back
in (without contention from other -cc1 commands).  Since PCMs are read
from disk repeatedly while invalidating, building, and importing, the
lock is not released quickly.  Furthermore, the LockFileManager is not
robust in every environment.  Other -cc1 commands can stall until
timeout (after about eight minutes).

This commit changes the lock file from being necessary for correctness
to a (possibly dubious) performance hack.  The remaining benefit is to
reduce duplicate work in competing -cc1 commands which depend on the
same module.  Follow-up commits will change the internal build system to
continue after a timeout, and reduce the timeout.  Perhaps we should
reconsider blocking at all.

This also fixes a use-after-free, when one part of a compilation
validates a PCM and starts using it, and another tries to swap out the
PCM for something new.

The PCMCache is a new type called MemoryBufferCache, which saves memory
buffers based on their filename.  Its ownership is shared by the
CompilerInstance and ModuleManager.

- The ModuleManager stores PCMs there that it loads from disk, never
touching the disk if the cache is hot.

- When modules fail to validate, they're removed from the cache.

- When a CompilerInstance is spawned to build a new module, each
already-loaded PCM is assumed to be valid, and is frozen to avoid
the use-after-free.

- Any newly-built module is written directly to the cache to avoid the
round-trip to the filesystem, making lock files unnecessary for
correctness.

Original patch by Manman Ren; most testcases by Adrian Prantl!

Added:
cfe/trunk/include/clang/Basic/MemoryBufferCache.h
cfe/trunk/lib/Basic/MemoryBufferCache.cpp
cfe/trunk/test/Modules/Inputs/system-out-of-date/X.h
cfe/trunk/test/Modules/Inputs/system-out-of-date/Y.h
cfe/trunk/test/Modules/Inputs/system-out-of-date/Z.h
cfe/trunk/test/Modules/Inputs/system-out-of-date/module.map
cfe/trunk/test/Modules/Inputs/warning-mismatch/Mismatch.h
cfe/trunk/test/Modules/Inputs/warning-mismatch/System.h
cfe/trunk/test/Modules/Inputs/warning-mismatch/module.modulemap
cfe/trunk/test/Modules/outofdate-rebuild.m
cfe/trunk/test/Modules/system-out-of-date-test.m
cfe/trunk/test/Modules/warning-mismatch.m
cfe/trunk/unittests/Basic/MemoryBufferCacheTest.cpp
Modified:
cfe/trunk/include/clang/Basic/DiagnosticSerializationKinds.td
cfe/trunk/include/clang/Frontend/ASTUnit.h
cfe/trunk/include/clang/Frontend/CompilerInstance.h
cfe/trunk/include/clang/Lex/Preprocessor.h
cfe/trunk/include/clang/Serialization/ASTReader.h
cfe/trunk/include/clang/Serialization/ASTWriter.h
cfe/trunk/include/clang/Serialization/Module.h
cfe/trunk/include/clang/Serialization/ModuleManager.h
cfe/trunk/lib/Basic/CMakeLists.txt
cfe/trunk/lib/Frontend/ASTUnit.cpp
cfe/trunk/lib/Frontend/CompilerInstance.cpp
cfe/trunk/lib/Lex/Preprocessor.cpp
cfe/trunk/lib/Serialization/ASTReader.cpp
cfe/trunk/lib/Serialization/ASTWriter.cpp
cfe/trunk/lib/Serialization/GeneratePCH.cpp
cfe/trunk/lib/Serialization/ModuleManager.cpp
cfe/trunk/unittests/Basic/CMakeLists.txt
cfe/trunk/unittests/Basic/SourceManagerTest.cpp
cfe/trunk/unittests/Lex/LexerTest.cpp
cfe/trunk/unittests/Lex/PPCallbacksTest.cpp
cfe/trunk/unittests/Lex/PPConditionalDirectiveRecordTest.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticSerializationKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSerializationKinds.td?rev=298278&r1=298277&r2=298278&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSerializationKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSerializationKinds.td Mon Mar 20 
12:58:26 2017
@@ -176,6 +176,11 @@ def warn_duplicate_module_file_extension
   "duplicate module file extension block name '%0'">,
   InGroup;
 
+def warn_module_system_bit_conflict : Warning<
+  "module file '%0' was validated as a system module and is now being imported 
"
+  "as a non-system module; any difference in diagnostic options will be 
ignored">,
+  InGroup;
+
 } // let CategoryName
 } // let Component
 

Added: cfe/trunk/include/clang/Basic/MemoryBufferCache.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include

r298275 - Fix some sphinx -Werror's

2017-03-20 Thread Jonathan Roelofs via cfe-commits
Author: jroelofs
Date: Mon Mar 20 12:07:49 2017
New Revision: 298275

URL: http://llvm.org/viewvc/llvm-project?rev=298275&view=rev
Log:
Fix some sphinx -Werror's

... mostly having to do with code blocks which the syntax highlighter chokes on

Modified:
cfe/trunk/docs/ClangFormatStyleOptions.rst
cfe/trunk/docs/ReleaseNotes.rst

Modified: cfe/trunk/docs/ClangFormatStyleOptions.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ClangFormatStyleOptions.rst?rev=298275&r1=298274&r2=298275&view=diff
==
--- cfe/trunk/docs/ClangFormatStyleOptions.rst (original)
+++ cfe/trunk/docs/ClangFormatStyleOptions.rst Mon Mar 20 12:07:49 2017
@@ -302,7 +302,7 @@ the configuration (without a prefix: ``A
 
 .. code-block:: c++
 
-  class {
+  class Foo {
 void f() { foo(); }
   };
 
@@ -311,7 +311,7 @@ the configuration (without a prefix: ``A
 
 .. code-block:: c++
 
-  class {
+  class Foo {
 void f() { foo(); }
   };
   void f() { bar(); }
@@ -898,7 +898,7 @@ the configuration (without a prefix: ``A
 
   .. code-block:: c++
 
- CommentPragmas: '^ FOOBAR pragma:'
+ // CommentPragmas: '^ FOOBAR pragma:'
  // Will leave the following line unaffected
  #include  // FOOBAR pragma: keep
 

Modified: cfe/trunk/docs/ReleaseNotes.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ReleaseNotes.rst?rev=298275&r1=298274&r2=298275&view=diff
==
--- cfe/trunk/docs/ReleaseNotes.rst (original)
+++ cfe/trunk/docs/ReleaseNotes.rst Mon Mar 20 12:07:49 2017
@@ -135,32 +135,43 @@ clang-format
 * Option **BreakBeforeInheritanceComma** added to break before ``:`` and ``,`` 
 in case of
   multiple inheritance in a class declaration. Enabled by default in the 
Mozilla coding style.
 
-  .. code-block:: c++
-
- true:  false:
- class MyClass  vs. class MyClass : public X, public Y 
{
- : public X };
- , public Y {
- };
+  +-++
+  | true| false  |
+  +=++
+  | .. code-block:: c++ | .. code-block:: c++|
+  | ||
+  |   class MyClass |   class MyClass : public X, public Y { |
+  |   : public X|   };   |
+  |   , public Y {  ||
+  |   };||
+  +-++
 
 * Align block comment decorations.
 
-  .. code-block:: c++
-
- /* line 1  /* line 1
-   * line 2   becomes:   * line 2
-  */ */
+  +--+-+
+  | Before   | After   |
+  +==+=+
+  |  .. code-block:: c++ | .. code-block:: c++ |
+  |  | |
+  |/* line 1 |   /* line 1 |
+  |  * line 2|* line 2 |
+  | */   |*/   |
+  +--+-+
 
 * The :doc:`ClangFormatStyleOptions` documentation provides detailed examples 
for most options.
 
 * Namespace end comments are now added or updated automatically.
 
-  .. code-block:: c++
-
- namespace A {  namespace A {
- int i; int i;
- int j;   becomes:  int j;
- }  } // namespace A
+  +-+-+
+  | Before  | After   |
+  +=+=+
+  | .. code-block:: c++ | .. code-block:: c++ |
+  | | |
+  |   namespace A { |   namespace A { |
+  |   int i;|   int i;|
+  |   int j;|   int j;|
+  |   } |   } |
+  +-+-+
 
 * Comment reflow support added. Overly long comment lines will now be reflown 
with the rest of
   the paragraph instead of just broken. Option **ReflowComments** added and 
enabled by default.


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


[PATCH] D30824: -frewrite-includes: Fix support for __has_include_next

2017-03-20 Thread David Vest via Phabricator via cfe-commits
davve abandoned this revision.
davve added a comment.

Eugene Velesevich noted in the bug that the patch is broken for multiple levels 
of headers:

> Patch seems work only for first header with same name. I.e. code below finds 
> first header even clang parses second or third ones. Thus __has_include_next 
> is always true if there are two or more headers with same name.

Code below being the extra added LookupFile call.


https://reviews.llvm.org/D30824



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


[PATCH] D30170: Function definition may have uninstantiated body

2017-03-20 Thread Serge Pavlov via Phabricator via cfe-commits
sepavloff updated this revision to Diff 92340.
sepavloff added a comment.

Small simplicifation


https://reviews.llvm.org/D30170

Files:
  include/clang/AST/Decl.h
  lib/AST/Decl.cpp
  lib/Sema/SemaDecl.cpp
  test/SemaCXX/cxx0x-cursory-default-delete.cpp
  test/SemaCXX/friend2.cpp

Index: test/SemaCXX/friend2.cpp
===
--- test/SemaCXX/friend2.cpp
+++ test/SemaCXX/friend2.cpp
@@ -101,6 +101,34 @@
   friend void func_12(int x = 0);  // expected-error{{friend declaration specifying a default argument must be the only declaration}}
 };
 
+// Friend function with uninstantiated body is still a definition.
+
+template struct C20 {
+  friend void func_20() {} // expected-note{{previous definition is here}}
+};
+C20 c20i;
+void func_20() {} // expected-error{{redefinition of 'func_20'}}
+
+template struct C21a {
+  friend void func_21() {} // expected-note{{previous definition is here}}
+};
+template struct C21b {
+  friend void func_21() {} // expected-error{{redefinition of 'func_21'}}
+};
+C21a c21ai;
+C21b c21bi; // expected-note{{in instantiation of template class 'C21b' requested here}}
+
+template struct C22a {
+  friend void func_22() {} // expected-note{{previous definition is here}}
+};
+template struct C22b {
+  friend void func_22();
+};
+C22a c22ai;
+C22b c22bi;
+void func_22() {} // expected-error{{redefinition of 'func_22'}}
+
+
 
 namespace pr22307 {
 
Index: test/SemaCXX/cxx0x-cursory-default-delete.cpp
===
--- test/SemaCXX/cxx0x-cursory-default-delete.cpp
+++ test/SemaCXX/cxx0x-cursory-default-delete.cpp
@@ -136,13 +136,13 @@
 };
 
 struct DefaultDelete {
-  DefaultDelete() = default; // expected-note {{previous declaration is here}}
+  DefaultDelete() = default; // expected-note {{previous definition is here}}
   DefaultDelete() = delete; // expected-error {{constructor cannot be redeclared}}
 
-  ~DefaultDelete() = default; // expected-note {{previous declaration is here}}
+  ~DefaultDelete() = default; // expected-note {{previous definition is here}}
   ~DefaultDelete() = delete; // expected-error {{destructor cannot be redeclared}}
 
-  DefaultDelete &operator=(const DefaultDelete &) = default; // expected-note {{previous declaration is here}}
+  DefaultDelete &operator=(const DefaultDelete &) = default; // expected-note {{previous definition is here}}
   DefaultDelete &operator=(const DefaultDelete &) = delete; // expected-error {{class member cannot be redeclared}}
 };
 
Index: lib/Sema/SemaDecl.cpp
===
--- lib/Sema/SemaDecl.cpp
+++ lib/Sema/SemaDecl.cpp
@@ -11692,8 +11692,12 @@
SkipBodyInfo *SkipBody) {
   const FunctionDecl *Definition = EffectiveDefinition;
   if (!Definition)
-if (!FD->isDefined(Definition))
+if (!FD->isOdrDefined(Definition))
   return;
+  assert(Definition);
+
+  if (FD == Definition)
+return;
 
   if (canRedefineFunction(Definition, getLangOpts()))
 return;
Index: lib/AST/Decl.cpp
===
--- lib/AST/Decl.cpp
+++ lib/AST/Decl.cpp
@@ -2533,8 +2533,18 @@
 
 bool FunctionDecl::isDefined(const FunctionDecl *&Definition) const {
   for (auto I : redecls()) {
-if (I->IsDeleted || I->IsDefaulted || I->Body || I->IsLateTemplateParsed ||
-I->hasDefiningAttr()) {
+if (I->isThisDeclarationADefinition()) {
+  Definition = I->IsDeleted ? I->getCanonicalDecl() : I;
+  return true;
+}
+  }
+
+  return false;
+}
+
+bool FunctionDecl::isOdrDefined(const FunctionDecl *&Definition) const {
+  for (auto I : redecls()) {
+if (I->isThisDeclarationAnOdrDefinition()) {
   Definition = I->IsDeleted ? I->getCanonicalDecl() : I;
   return true;
 }
Index: include/clang/AST/Decl.h
===
--- include/clang/AST/Decl.h
+++ include/clang/AST/Decl.h
@@ -1781,32 +1781,98 @@
 
   SourceRange getSourceRange() const override LLVM_READONLY;
 
-  /// \brief Returns true if the function has a body (definition). The
-  /// function body might be in any of the (re-)declarations of this
-  /// function. The variant that accepts a FunctionDecl pointer will
-  /// set that function declaration to the actual declaration
-  /// containing the body (if there is one).
+  /// \name Definition and body checks
+  ///
+  /// A function declaration may be:
+  /// - a non defining declaration,
+  /// - a definition. A function may be defined because:
+  ///   - it has a body, or will have it in the case of late parsing.
+  ///   - it has an uninstantiated body. The body does not exist because the
+  /// function is not used yet, but the declaration is considered a
+  /// definition from viewpoint of ODR checks.
+  ///   - it does not have a user specified body, but it does not allow
+  /// redefinition, b

[PATCH] D30809: [coroutines] Add codegen for await and yield expressions

2017-03-20 Thread Gor Nishanov via Phabricator via cfe-commits
GorNishanov marked 2 inline comments as done.
GorNishanov added a comment.

Looks good now?


https://reviews.llvm.org/D30809



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


Re: r297975 - Use arg_begin() instead of getArgumentList().begin(), the argument list is an implementation detail

2017-03-20 Thread David Blaikie via cfe-commits
On Mon, Mar 20, 2017 at 8:59 AM Reid Kleckner  wrote:

> I came across llvm/docs/HistoricalNotes/2002-06-25-MegaPatchInfo.txt,
> which has this:
> """
> * The Function class now has helper functions for accessing the Arguments
> list.
>   Instead of having to go through getArgumentList for simple things like
>   iterator over the arguments, now the a*() methods can be used to access
> them.
> """
>
> So, it seems like there was a desire to move away from using
> getArgumentList() all the way back in 2002.
>
> I removed getArgumentList() in a follow-up change anyway, so it's not a
> public member anymore.
>

Ah, great - haven't got to my llvm-commits catch up yet, I'll keep an eye
out for it. Thanks!


>
> On Mon, Mar 20, 2017 at 8:54 AM, David Blaikie  wrote:
>
>
>
> On Thu, Mar 16, 2017 at 12:07 PM Reid Kleckner via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> Author: rnk
> Date: Thu Mar 16 13:55:46 2017
> New Revision: 297975
>
> URL: http://llvm.org/viewvc/llvm-project?rev=297975&view=rev
> Log:
> Use arg_begin() instead of getArgumentList().begin(), the argument list is
> an implementation detail
>
>
> Seems like a somewhat strange justification, given that getArgumentList
> looks like a public member and probably used pervasively before LLVM moved
> towards more iterator-centric interfaces, etc.
>
> What do you mean by 'an implementation detail' in this context/what
> motivated this change? (curious what I'm missing)
>
> - Dave
>
>
>
> Modified:
> cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
>
> Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp?rev=297975&r1=297974&r2=297975&view=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp Thu Mar 16 13:55:46 2017
> @@ -3780,9 +3780,7 @@ CGOpenMPRuntime::emitTaskInit(CodeGenFun
>// Emit initial values for private copies (if any).
>llvm::Value *TaskPrivatesMap = nullptr;
>auto *TaskPrivatesMapTy =
> -
> std::next(cast(TaskFunction)->getArgumentList().begin(),
> -3)
> -  ->getType();
> +  std::next(cast(TaskFunction)->arg_begin(),
> 3)->getType();
>if (!Privates.empty()) {
>  auto FI = std::next(KmpTaskTWithPrivatesQTyRD->field_begin());
>  TaskPrivatesMap = emitTaskPrivateMappingFunction(
>
>
> ___
> 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: r297975 - Use arg_begin() instead of getArgumentList().begin(), the argument list is an implementation detail

2017-03-20 Thread Reid Kleckner via cfe-commits
I came across llvm/docs/HistoricalNotes/2002-06-25-MegaPatchInfo.txt, which
has this:
"""
* The Function class now has helper functions for accessing the Arguments
list.
  Instead of having to go through getArgumentList for simple things like
  iterator over the arguments, now the a*() methods can be used to access
them.
"""

So, it seems like there was a desire to move away from using
getArgumentList() all the way back in 2002.

I removed getArgumentList() in a follow-up change anyway, so it's not a
public member anymore.

On Mon, Mar 20, 2017 at 8:54 AM, David Blaikie  wrote:

>
>
> On Thu, Mar 16, 2017 at 12:07 PM Reid Kleckner via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: rnk
>> Date: Thu Mar 16 13:55:46 2017
>> New Revision: 297975
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=297975&view=rev
>> Log:
>> Use arg_begin() instead of getArgumentList().begin(), the argument list
>> is an implementation detail
>>
>
> Seems like a somewhat strange justification, given that getArgumentList
> looks like a public member and probably used pervasively before LLVM moved
> towards more iterator-centric interfaces, etc.
>
> What do you mean by 'an implementation detail' in this context/what
> motivated this change? (curious what I'm missing)
>
> - Dave
>
>
>>
>> Modified:
>> cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
>>
>> Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/
>> CGOpenMPRuntime.cpp?rev=297975&r1=297974&r2=297975&view=diff
>> 
>> ==
>> --- cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp (original)
>> +++ cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp Thu Mar 16 13:55:46 2017
>> @@ -3780,9 +3780,7 @@ CGOpenMPRuntime::emitTaskInit(CodeGenFun
>>// Emit initial values for private copies (if any).
>>llvm::Value *TaskPrivatesMap = nullptr;
>>auto *TaskPrivatesMapTy =
>> -  std::next(cast(TaskFunction)->
>> getArgumentList().begin(),
>> -3)
>> -  ->getType();
>> +  std::next(cast(TaskFunction)->arg_begin(),
>> 3)->getType();
>>if (!Privates.empty()) {
>>  auto FI = std::next(KmpTaskTWithPrivatesQTyRD->field_begin());
>>  TaskPrivatesMap = emitTaskPrivateMappingFunction(
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D31134: [Serialization] Serialize DependentSizedExtVectorType

2017-03-20 Thread Alex Lorenz via Phabricator via cfe-commits
arphaman created this revision.

DependentSizedExtVectorType should be supported by the serialization library


Repository:
  rL LLVM

https://reviews.llvm.org/D31134

Files:
  include/clang/Serialization/ASTBitCodes.h
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTWriter.cpp
  test/PCH/cxx-dependent-sized-ext-vector.cpp


Index: test/PCH/cxx-dependent-sized-ext-vector.cpp
===
--- /dev/null
+++ test/PCH/cxx-dependent-sized-ext-vector.cpp
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -std=c++11 -emit-pch %s -o %t
+// RUN: %clang_cc1 -std=c++11 -include-pch %t -verify %s
+
+#ifndef HEADER_INCLUDED
+
+#define HEADER_INCLUDED
+
+template
+using vec = T __attribute__((ext_vector_type(N)));
+
+#else
+
+void test() {
+  vec a;  // expected-error@-5 {{zero vector size}}
+  vec a; // expected-note {{in instantiation of template type alias 
'vec' requested here}}
+}
+
+#endif
Index: lib/Serialization/ASTWriter.cpp
===
--- lib/Serialization/ASTWriter.cpp
+++ lib/Serialization/ASTWriter.cpp
@@ -424,8 +424,10 @@
 void
 ASTTypeWriter::VisitDependentSizedExtVectorType(
 const DependentSizedExtVectorType *T) {
-  // FIXME: Serialize this type (C++ only)
-  llvm_unreachable("Cannot serialize dependent sized extended vector types");
+  Record.AddTypeRef(T->getElementType());
+  Record.AddStmt(T->getSizeExpr());
+  Record.AddSourceLocation(T->getAttributeLoc());
+  Code = TYPE_DEPENDENT_SIZED_EXT_VECTOR;
 }
 
 void
Index: lib/Serialization/ASTReader.cpp
===
--- lib/Serialization/ASTReader.cpp
+++ lib/Serialization/ASTReader.cpp
@@ -5921,6 +5921,17 @@
 return Context.getPipeType(ElementType, ReadOnly);
   }
 
+  case TYPE_DEPENDENT_SIZED_EXT_VECTOR: {
+unsigned Idx = 0;
+
+// DependentSizedExtVectorType
+QualType ElementType = readType(*Loc.F, Record, Idx);
+Expr *SizeExpr = ReadExpr(*Loc.F);
+SourceLocation AttrLoc = ReadSourceLocation(*Loc.F, Record, Idx);
+
+return Context.getDependentSizedExtVectorType(ElementType, SizeExpr,
+  AttrLoc);
+  }
   }
   llvm_unreachable("Invalid TypeCode!");
 }
Index: include/clang/Serialization/ASTBitCodes.h
===
--- include/clang/Serialization/ASTBitCodes.h
+++ include/clang/Serialization/ASTBitCodes.h
@@ -916,7 +916,9 @@
   /// \brief An ObjCTypeParamType record.
   TYPE_OBJC_TYPE_PARAM   = 44,
   /// \brief A DeducedTemplateSpecializationType record.
-  TYPE_DEDUCED_TEMPLATE_SPECIALIZATION = 45
+  TYPE_DEDUCED_TEMPLATE_SPECIALIZATION = 45,
+  /// \brief A DependentSizedExtVectorType record.
+  TYPE_DEPENDENT_SIZED_EXT_VECTOR = 46
 };
 
 /// \brief The type IDs for special types constructed by semantic


Index: test/PCH/cxx-dependent-sized-ext-vector.cpp
===
--- /dev/null
+++ test/PCH/cxx-dependent-sized-ext-vector.cpp
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -std=c++11 -emit-pch %s -o %t
+// RUN: %clang_cc1 -std=c++11 -include-pch %t -verify %s
+
+#ifndef HEADER_INCLUDED
+
+#define HEADER_INCLUDED
+
+template
+using vec = T __attribute__((ext_vector_type(N)));
+
+#else
+
+void test() {
+  vec a;  // expected-error@-5 {{zero vector size}}
+  vec a; // expected-note {{in instantiation of template type alias 'vec' requested here}}
+}
+
+#endif
Index: lib/Serialization/ASTWriter.cpp
===
--- lib/Serialization/ASTWriter.cpp
+++ lib/Serialization/ASTWriter.cpp
@@ -424,8 +424,10 @@
 void
 ASTTypeWriter::VisitDependentSizedExtVectorType(
 const DependentSizedExtVectorType *T) {
-  // FIXME: Serialize this type (C++ only)
-  llvm_unreachable("Cannot serialize dependent sized extended vector types");
+  Record.AddTypeRef(T->getElementType());
+  Record.AddStmt(T->getSizeExpr());
+  Record.AddSourceLocation(T->getAttributeLoc());
+  Code = TYPE_DEPENDENT_SIZED_EXT_VECTOR;
 }
 
 void
Index: lib/Serialization/ASTReader.cpp
===
--- lib/Serialization/ASTReader.cpp
+++ lib/Serialization/ASTReader.cpp
@@ -5921,6 +5921,17 @@
 return Context.getPipeType(ElementType, ReadOnly);
   }
 
+  case TYPE_DEPENDENT_SIZED_EXT_VECTOR: {
+unsigned Idx = 0;
+
+// DependentSizedExtVectorType
+QualType ElementType = readType(*Loc.F, Record, Idx);
+Expr *SizeExpr = ReadExpr(*Loc.F);
+SourceLocation AttrLoc = ReadSourceLocation(*Loc.F, Record, Idx);
+
+return Context.getDependentSizedExtVectorType(ElementType, SizeExpr,
+  AttrLoc);
+  }
   }
   llvm_unreachable("Invalid TypeCode!");
 }
Index: include/clang/Serialization/

Re: r297975 - Use arg_begin() instead of getArgumentList().begin(), the argument list is an implementation detail

2017-03-20 Thread David Blaikie via cfe-commits
On Thu, Mar 16, 2017 at 12:07 PM Reid Kleckner via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rnk
> Date: Thu Mar 16 13:55:46 2017
> New Revision: 297975
>
> URL: http://llvm.org/viewvc/llvm-project?rev=297975&view=rev
> Log:
> Use arg_begin() instead of getArgumentList().begin(), the argument list is
> an implementation detail
>

Seems like a somewhat strange justification, given that getArgumentList
looks like a public member and probably used pervasively before LLVM moved
towards more iterator-centric interfaces, etc.

What do you mean by 'an implementation detail' in this context/what
motivated this change? (curious what I'm missing)

- Dave


>
> Modified:
> cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
>
> Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp?rev=297975&r1=297974&r2=297975&view=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp Thu Mar 16 13:55:46 2017
> @@ -3780,9 +3780,7 @@ CGOpenMPRuntime::emitTaskInit(CodeGenFun
>// Emit initial values for private copies (if any).
>llvm::Value *TaskPrivatesMap = nullptr;
>auto *TaskPrivatesMapTy =
> -
> std::next(cast(TaskFunction)->getArgumentList().begin(),
> -3)
> -  ->getType();
> +  std::next(cast(TaskFunction)->arg_begin(),
> 3)->getType();
>if (!Privates.empty()) {
>  auto FI = std::next(KmpTaskTWithPrivatesQTyRD->field_begin());
>  TaskPrivatesMap = emitTaskPrivateMappingFunction(
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D31133: Add LibreOffice Clang plugin to ExternalClangExamples.rst

2017-03-20 Thread Stephan Bergmann via Phabricator via cfe-commits
sberg created this revision.

https://reviews.llvm.org/D31133

Files:
  docs/ExternalClangExamples.rst


Index: docs/ExternalClangExamples.rst
===
--- docs/ExternalClangExamples.rst
+++ docs/ExternalClangExamples.rst
@@ -90,3 +90,11 @@
You get more than 50 Qt related compiler warnings, ranging from unneeded
memory allocations to misusage of API, including fix-its for automatic
refactoring."
+
+``_
+   "LibreOffice uses a Clang plugin infrastructure to check during the build
+   various things, some more, some less specific to the LibreOffice source 
code.
+   There are currently around 50 such checkers, from flagging C-style casts and
+   uses of reserved identifiers to ensuring that code adheres to lifecycle
+   protocols for certain LibreOffice-specific classes.  They may serve as
+   examples for writing RecursiveASTVisitor-based plugins."


Index: docs/ExternalClangExamples.rst
===
--- docs/ExternalClangExamples.rst
+++ docs/ExternalClangExamples.rst
@@ -90,3 +90,11 @@
You get more than 50 Qt related compiler warnings, ranging from unneeded
memory allocations to misusage of API, including fix-its for automatic
refactoring."
+
+``_
+   "LibreOffice uses a Clang plugin infrastructure to check during the build
+   various things, some more, some less specific to the LibreOffice source code.
+   There are currently around 50 such checkers, from flagging C-style casts and
+   uses of reserved identifiers to ensuring that code adheres to lifecycle
+   protocols for certain LibreOffice-specific classes.  They may serve as
+   examples for writing RecursiveASTVisitor-based plugins."
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D30816: [OpenCL] Added implicit conversion rank for overloading functions with vector data type in OpenCL

2017-03-20 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia accepted this revision.
Anastasia added a comment.
This revision is now accepted and ready to land.

LGTM! Thanks!


https://reviews.llvm.org/D30816



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


[PATCH] D30830: [OpenCL] Fix extension guards for atomic functions

2017-03-20 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia closed this revision.
Anastasia added a comment.

Sorry, I overlooked this indeed. Committed in r298256!


https://reviews.llvm.org/D30830



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


[PATCH] D30937: [OpenCL] Added diagnostic for checking length of vector

2017-03-20 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia accepted this revision.
Anastasia added a comment.
This revision is now accepted and ready to land.

LGTM! Thanks!


https://reviews.llvm.org/D30937



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


r298256 - [OpenCL] Fix extension guards for atomic functions

2017-03-20 Thread Anastasia Stulova via cfe-commits
Author: stulova
Date: Mon Mar 20 10:02:54 2017
New Revision: 298256

URL: http://llvm.org/viewvc/llvm-project?rev=298256&view=rev
Log:
[OpenCL] Fix extension guards for atomic functions

Review: D30830

Patch by James Price!


Modified:
cfe/trunk/lib/Headers/opencl-c.h

Modified: cfe/trunk/lib/Headers/opencl-c.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/opencl-c.h?rev=298256&r1=298255&r2=298256&view=diff
==
--- cfe/trunk/lib/Headers/opencl-c.h (original)
+++ cfe/trunk/lib/Headers/opencl-c.h Mon Mar 20 10:02:54 2017
@@ -13703,10 +13703,10 @@ float __ovld atomic_xchg(volatile __loca
 
 #if defined(cl_khr_global_int32_base_atomics)
 int __ovld atom_xchg(volatile __global int *p, int val);
-int __ovld atom_xchg(volatile __local int *p, int val);
+unsigned int __ovld atom_xchg(volatile __global unsigned int *p, unsigned int 
val);
 #endif
 #if defined(cl_khr_local_int32_base_atomics)
-unsigned int __ovld atom_xchg(volatile __global unsigned int *p, unsigned int 
val);
+int __ovld atom_xchg(volatile __local int *p, int val);
 unsigned int __ovld atom_xchg(volatile __local unsigned int *p, unsigned int 
val);
 #endif
 
@@ -13823,8 +13823,6 @@ unsigned int __ovld atom_min(volatile __
 #if defined(cl_khr_int64_extended_atomics)
 long __ovld atom_min(volatile __global long *p, long val);
 unsigned long __ovld atom_min(volatile __global unsigned long *p, unsigned 
long val);
-#endif
-#if defined(cl_khr_local_int32_extended_atomics)
 long __ovld atom_min(volatile __local long *p, long val);
 unsigned long __ovld atom_min(volatile __local unsigned long *p, unsigned long 
val);
 #endif


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


[PATCH] D31114: Refactor `initTargetOptions` out of `EmitAssemblyHelper::CreateTargetMachine` and use it to initialize TargetOptions for ThinLTO Backends

2017-03-20 Thread Teresa Johnson via Phabricator via cfe-commits
tejohnson added a comment.

In https://reviews.llvm.org/D31114#704749, @mehdi_amini wrote:

> In https://reviews.llvm.org/D31114#704748, @tejohnson wrote:
>
> > In https://reviews.llvm.org/D31114#704733, @mehdi_amini wrote:
> >
> > > In https://reviews.llvm.org/D31114#704728, @tejohnson wrote:
> > >
> > > > In https://reviews.llvm.org/D31114#704726, @mehdi_amini wrote:
> > > >
> > > > > In https://reviews.llvm.org/D31114#704649, @tejohnson wrote:
> > > > >
> > > > > > I think you won't get the correct handling of -emit-llvm and 
> > > > > > -emit-llvm-bc since we don't get the handling for Backend_Emit* in 
> > > > > > EmitAssemblyHelper::EmitAssembly.
> > > > >
> > > > >
> > > > > I was not trying to achieve this. And your approach of an 
> > > > > "OptimizeOnly" or "DisableCodeGen" on the lot::Config for this 
> > > > > purpose makes sense.
> > > >
> > > >
> > > > I'm confused - are you saying you now think 
> > > > https://reviews.llvm.org/D31100 and https://reviews.llvm.org/D31101 are 
> > > > the right approach?
> > >
> > >
> > > I believe your patch is the right approach when clang needs to get the 
> > > optimized IR, which is the case for -emit-llvm/-emit-bc. I believe that 
> > > it shouldn't do that when it expects an object file.
> >
> >
> > What about for -S, which presumably maps to Backend_EmitAssembly?
>
>
> Should be handled by LTO (we added it recently I think, at least to libLTO).
>
> > The LTO Config does have a CodeGenFileType field, which defaults to 
> > ObjectFile, but could be set here to AssemblyFile (see the handling in 
> > EmitAssemblyHelper::AddEmitPasses). I believe if you include the test case 
> > I added in https://reviews.llvm.org/D31101 which emits assembly that it 
> > will fail with this patch, for example. Since clang already has to handle 
> > codegen for all output types, I am not sure why it is better to have the 
> > LTO API handle the output for some of the cases and not others?
>
> It is not better, and I don't suggest that. I believe all the cases should go 
> through the LTO API preferably (or the LTO API should always use clang for 
> codegen, but I don't believe anyone would consider that).


I went ahead and updated my clang patch https://reviews.llvm.org/D31101 to only 
fall back to the clang handling in the -emit-llvm and -emit-llvm-bc cases.

I removed the test changes I had made to test/CodeGen/function-sections.c, you 
can include them here instead as a test for this fix.


https://reviews.llvm.org/D31114



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


[PATCH] D31101: [ThinLTO] Use clang's existing code gen handling for ThinLTO backends

2017-03-20 Thread Teresa Johnson via Phabricator via cfe-commits
tejohnson updated this revision to Diff 92324.
tejohnson added a comment.

As discussed in the review threads for https://reviews.llvm.org/D31114 and 
https://reviews.llvm.org/D31100, only fall
back to clang's output file emission for -emit-llvm and -emit-llvm-bc.


https://reviews.llvm.org/D31101

Files:
  lib/CodeGen/BackendUtil.cpp
  test/CodeGen/thinlto-emit-llvm.c


Index: test/CodeGen/thinlto-emit-llvm.c
===
--- /dev/null
+++ test/CodeGen/thinlto-emit-llvm.c
@@ -0,0 +1,10 @@
+// Test to ensure -emit-llvm and -emit-llvm-bc work when invoking the
+// ThinLTO backend path.
+// RUN: %clang -O2 %s -flto=thin -c -o %t.o
+// RUN: llvm-lto -thinlto -o %t %t.o
+// RUN: %clang_cc1 -O2 -x ir %t.o -fthinlto-index=%t.thinlto.bc -emit-llvm -o 
- | FileCheck %s
+// RUN: %clang_cc1 -O2 -x ir %t.o -fthinlto-index=%t.thinlto.bc -emit-llvm-bc 
-o - | llvm-dis -o - | FileCheck %s
+
+// CHECK: define void @foo()
+void foo() {
+}
Index: lib/CodeGen/BackendUtil.cpp
===
--- lib/CodeGen/BackendUtil.cpp
+++ lib/CodeGen/BackendUtil.cpp
@@ -897,7 +897,8 @@
 
 static void runThinLTOBackend(ModuleSummaryIndex *CombinedIndex, Module *M,
   std::unique_ptr OS,
-  std::string SampleProfile) {
+  std::string SampleProfile,
+  bool SkipCodeGen) {
   StringMap>
   ModuleToDefinedGVSummaries;
   
CombinedIndex->collectDefinedGVSummariesPerModule(ModuleToDefinedGVSummaries);
@@ -949,6 +950,7 @@
   };
   lto::Config Conf;
   Conf.SampleProfile = SampleProfile;
+  Conf.SkipCodeGen = SkipCodeGen;
   if (Error E = thinBackend(
   Conf, 0, AddStream, *M, *CombinedIndex, ImportList,
   ModuleToDefinedGVSummaries[M->getModuleIdentifier()], ModuleMap)) {
@@ -984,9 +986,16 @@
 // of an error).
 bool DoThinLTOBackend = CombinedIndex != nullptr;
 if (DoThinLTOBackend) {
-  runThinLTOBackend(CombinedIndex.get(), M, std::move(OS),
-CGOpts.SampleProfileFile);
-  return;
+  bool UsesCodeGen = (Action != Backend_EmitNothing &&
+  Action != Backend_EmitBC &&
+  Action != Backend_EmitLL);
+  if (UsesCodeGen) {
+runThinLTOBackend(CombinedIndex.get(), M, std::move(OS),
+  CGOpts.SampleProfileFile, /*SkipCodeGen*/false);
+return;
+  } else
+runThinLTOBackend(CombinedIndex.get(), M, nullptr,
+  CGOpts.SampleProfileFile, /*SkipCodeGen*/true);
 }
   }
 


Index: test/CodeGen/thinlto-emit-llvm.c
===
--- /dev/null
+++ test/CodeGen/thinlto-emit-llvm.c
@@ -0,0 +1,10 @@
+// Test to ensure -emit-llvm and -emit-llvm-bc work when invoking the
+// ThinLTO backend path.
+// RUN: %clang -O2 %s -flto=thin -c -o %t.o
+// RUN: llvm-lto -thinlto -o %t %t.o
+// RUN: %clang_cc1 -O2 -x ir %t.o -fthinlto-index=%t.thinlto.bc -emit-llvm -o - | FileCheck %s
+// RUN: %clang_cc1 -O2 -x ir %t.o -fthinlto-index=%t.thinlto.bc -emit-llvm-bc -o - | llvm-dis -o - | FileCheck %s
+
+// CHECK: define void @foo()
+void foo() {
+}
Index: lib/CodeGen/BackendUtil.cpp
===
--- lib/CodeGen/BackendUtil.cpp
+++ lib/CodeGen/BackendUtil.cpp
@@ -897,7 +897,8 @@
 
 static void runThinLTOBackend(ModuleSummaryIndex *CombinedIndex, Module *M,
   std::unique_ptr OS,
-  std::string SampleProfile) {
+  std::string SampleProfile,
+  bool SkipCodeGen) {
   StringMap>
   ModuleToDefinedGVSummaries;
   CombinedIndex->collectDefinedGVSummariesPerModule(ModuleToDefinedGVSummaries);
@@ -949,6 +950,7 @@
   };
   lto::Config Conf;
   Conf.SampleProfile = SampleProfile;
+  Conf.SkipCodeGen = SkipCodeGen;
   if (Error E = thinBackend(
   Conf, 0, AddStream, *M, *CombinedIndex, ImportList,
   ModuleToDefinedGVSummaries[M->getModuleIdentifier()], ModuleMap)) {
@@ -984,9 +986,16 @@
 // of an error).
 bool DoThinLTOBackend = CombinedIndex != nullptr;
 if (DoThinLTOBackend) {
-  runThinLTOBackend(CombinedIndex.get(), M, std::move(OS),
-CGOpts.SampleProfileFile);
-  return;
+  bool UsesCodeGen = (Action != Backend_EmitNothing &&
+  Action != Backend_EmitBC &&
+  Action != Backend_EmitLL);
+  if (UsesCodeGen) {
+runThinLTOBackend(CombinedIndex.get(), M, std::move(OS),
+  CGOpts.SampleProfileFile, /*SkipCodeGen*/false);
+return;
+  } else
+runThinLTOBackend(CombinedIndex.get(), M, nullptr,
+  CGOpts.SampleProfileFile, /*SkipCodeGen*/true);
 }
   }
 
__

[PATCH] D31097: [clang-tidy] don't warn about implicit widening casts in function calls

2017-03-20 Thread Daniel Marjamäki via Phabricator via cfe-commits
danielmarjamaki added a comment.

I believe there is pointless code in relativeIntSizes etc. If there is for 
instance "a+b" then the result can't be a char type.

  static int relativeIntSizes(BuiltinType::Kind Kind) {
switch (Kind) {
case BuiltinType::UChar:
  return 1;
case BuiltinType::SChar:
  return 1;
case BuiltinType::Char_U:
  return 1;
case BuiltinType::Char_S:
  return 1;
case BuiltinType::UShort:
  return 2;
case BuiltinType::Short:
  return 2;
case BuiltinType::UInt:
  return 3;
case BuiltinType::Int:
  return 3;
case BuiltinType::ULong:
  return 4;
case BuiltinType::Long:
  return 4;
case BuiltinType::ULongLong:
  return 5;
case BuiltinType::LongLong:
  return 5;
case BuiltinType::UInt128:
  return 6;
case BuiltinType::Int128:
  return 6;
default:
  return 0;
}
  }


Repository:
  rL LLVM

https://reviews.llvm.org/D31097



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


[PATCH] D31082: [mips][msa] Range adjustment for ldi_b builtin function operand

2017-03-20 Thread Simon Dardis via Phabricator via cfe-commits
sdardis accepted this revision.
sdardis added a comment.
This revision is now accepted and ready to land.

Can you add a test to test/CodeGen/builtins-mips-msa.c covering the new 
extended range for ldi.b ?

LGTM.


https://reviews.llvm.org/D31082



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


[PATCH] D31097: [clang-tidy] don't warn about implicit widening casts in function calls

2017-03-20 Thread Daniel Marjamäki via Phabricator via cfe-commits
danielmarjamaki updated this revision to Diff 92322.
danielmarjamaki added a comment.

Remove warnings for implicit casts.


Repository:
  rL LLVM

https://reviews.llvm.org/D31097

Files:
  clang-tidy/misc/MisplacedWideningCastCheck.cpp
  clang-tidy/misc/MisplacedWideningCastCheck.h
  docs/clang-tidy/checks/misc-misplaced-widening-cast.rst
  test/clang-tidy/misc-misplaced-widening-cast-explicit-only.cpp
  test/clang-tidy/misc-misplaced-widening-cast.cpp

Index: test/clang-tidy/misc-misplaced-widening-cast.cpp
===
--- test/clang-tidy/misc-misplaced-widening-cast.cpp
+++ test/clang-tidy/misc-misplaced-widening-cast.cpp
@@ -6,13 +6,11 @@
   long l;
 
   l = a * b;
-  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: either cast from 'int' to 'long' is ineffective, or there is loss of precision before the conversion [misc-misplaced-widening-cast]
   l = (long)(a * b);
   // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: either cast from 'int' to 'long'
   l = (long)a * b;
 
   l = a << 8;
-  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: either cast from 'int' to 'long'
   l = (long)(a << 8);
   // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: either cast from 'int' to 'long'
   l = (long)b << 8;
@@ -25,9 +23,7 @@
   bool l;
 
   l = a * b == c;
-  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: either cast from 'int' to 'long'
   l = c == a * b;
-  // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: either cast from 'int' to 'long'
   l = (long)(a * b) == c;
   // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: either cast from 'int' to 'long'
   l = c == (long)(a * b);
@@ -38,24 +34,21 @@
 
 void init(unsigned int n) {
   long l1 = n << 8;
-  // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: either cast from 'unsigned int' to 'long'
   long l2 = (long)(n << 8);
   // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: either cast from 'unsigned int' to 'long'
   long l3 = (long)n << 8;
 }
 
 void call(unsigned int n) {
   func(n << 8);
-  // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: either cast from 'unsigned int' to 'long'
   func((long)(n << 8));
   // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: either cast from 'unsigned int' to 'long'
   func((long)n << 8);
 }
 
 long ret(int a) {
   if (a < 0) {
 return a * 1000;
-// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: either cast from 'int' to 'long'
   } else if (a > 0) {
 return (long)(a * 1000);
 // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: either cast from 'int' to 'long'
Index: test/clang-tidy/misc-misplaced-widening-cast-explicit-only.cpp
===
--- test/clang-tidy/misc-misplaced-widening-cast-explicit-only.cpp
+++ test/clang-tidy/misc-misplaced-widening-cast-explicit-only.cpp
@@ -1,58 +0,0 @@
-// RUN: %check_clang_tidy %s misc-misplaced-widening-cast %t -- -config="{CheckOptions: [{key: misc-misplaced-widening-cast.CheckImplicitCasts, value: 0}]}" --
-
-void func(long arg) {}
-
-void assign(int a, int b) {
-  long l;
-
-  l = a * b;
-  l = (long)(a * b);
-  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: either cast from 'int' to 'long' is ineffective, or there is loss of precision before the conversion [misc-misplaced-widening-cast]
-  l = (long)a * b;
-
-  l = a << 8;
-  l = (long)(a << 8);
-  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: either cast from 'int' to 'long'
-  l = (long)b << 8;
-
-  l = static_cast(a * b);
-  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: either cast from 'int' to 'long'
-}
-
-void compare(int a, int b, long c) {
-  bool l;
-
-  l = a * b == c;
-  l = c == a * b;
-  l = (long)(a * b) == c;
-  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: either cast from 'int' to 'long'
-  l = c == (long)(a * b);
-  // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: either cast from 'int' to 'long'
-  l = (long)a * b == c;
-  l = c == (long)a * b;
-}
-
-void init(unsigned int n) {
-  long l1 = n << 8;
-  long l2 = (long)(n << 8);
-  // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: either cast from 'unsigned int' to 'long'
-  long l3 = (long)n << 8;
-}
-
-void call(unsigned int n) {
-  func(n << 8);
-  func((long)(n << 8));
-  // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: either cast from 'unsigned int' to 'long'
-  func((long)n << 8);
-}
-
-long ret(int a) {
-  if (a < 0) {
-return a * 1000;
-  } else if (a > 0) {
-return (long)(a * 1000);
-// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: either cast from 'int' to 'long'
-  } else {
-return (long)a * 1000;
-  }
-}
Index: docs/clang-tidy/checks/misc-misplaced-widening-cast.rst
===
--- docs/clang-tidy/checks/misc-misplaced-widening-cast.rst
+++ docs/clang-tidy/checks/misc-misplaced-widening-cast.rst
@@ -32,18 +32,7 @@
 return (long)x * 1000;
 }
 
-Implicit casts
---
-
-Forgetting to place the cast at all is at least as dangerous and at least as
-common as misplacing it. If :option:`CheckImplicitCasts` is enabled the check
-also detect

[PATCH] D23418: [analyzer] Added a reusable constraint system to the CloneDetector

2017-03-20 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added a comment.

I think this is awesome.

Would anybody like to move concrete constraint class definitions to a separate 
header + translation unit, so that to highlight how simple the primary 
interface is to a person who haven't gone through all the discussion?




Comment at: include/clang/Analysis/CloneDetection.h:172
+  /// Generates and stores search data for all statements in the body of
+  ///the given Decl.
+  void analyzeCodeBody(const Decl *D);

Strange spacing.



Comment at: include/clang/Analysis/CloneDetection.h:178
+  template 
+  void constrainClones(std::vector &CloneGroups, T C) {
+C.constrain(CloneGroups);

Should this pair of functions be made static?



Comment at: include/clang/Analysis/CloneDetection.h:218-219
+///
+/// This class should be the base class of all constraints that are used in
+/// combination with the CloneDetector class.
+/// As constraints are specified in the form of template parameters, this class

While you could enforce this with `static_assert>` in the detector, i think we shouldn't be strictly enforcing this.

Providing useful utility functions is pretty much the only purpose of this 
class, so it intends to be useful, but this shouldn't block users from 
implementing the `constrain()` method completely from scratch.

Also, we could probably move the method that groups clones by hashes here as 
the third utility method, if more than one hash function is eventually used(?)



Comment at: include/clang/Analysis/CloneDetection.h:318
+///
+/// This constraint searches for clones
+struct OnlyLargestCloneConstraint : CloneConstraint {

This comment looks incomplete.



Comment at: lib/Analysis/CloneDetection.cpp:308
+/// sequence in the \p Group.
+static bool containsAnyInGroup(StmtSequence &Stmt,
+   CloneDetector::CloneGroup &Group) {

I remember some buildbots complained about conflicting names between variables 
and classes. Could we rename the `Stmt` parameter? Something like `Seq` is fine 
with me.



Comment at: lib/Analysis/CloneDetection.cpp:335-336
 
-// Storage for the signatures of the direct child statements. This is only
-// needed if the current statement is a CompoundStmt.
-std::vector ChildSignatures;
-const CompoundStmt *CS = dyn_cast(S);
+void OnlyLargestCloneConstraint::constrain(
+std::vector &Result) {
+  std::vector IndexesToRemove;

In particular, this method doesn't use any `CloneConstraint`'s utility methods, 
as far as i understand.



Comment at: lib/StaticAnalyzer/Checkers/CloneChecker.cpp:81-83
+  Detector.findClones(AllCloneGroups, RecursiveCloneTypeIIConstraint(),
+  MinComplexityConstraint(MinComplexity),
+  MinGroupSizeConstraint(2), OnlyLargestCloneConstraint());

Yay. I like how it looks.


https://reviews.llvm.org/D23418



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


r298245 - Add more examples to clang-format configuration

2017-03-20 Thread Sylvestre Ledru via cfe-commits
Author: sylvestre
Date: Mon Mar 20 07:56:40 2017
New Revision: 298245

URL: http://llvm.org/viewvc/llvm-project?rev=298245&view=rev
Log:
Add more examples to clang-format configuration

Reviewers: djasper

Reviewed By: djasper

Subscribers: klimek, cfe-commits

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

Modified:
cfe/trunk/docs/ClangFormatStyleOptions.rst
cfe/trunk/include/clang/Format/Format.h

Modified: cfe/trunk/docs/ClangFormatStyleOptions.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ClangFormatStyleOptions.rst?rev=298245&r1=298244&r2=298245&view=diff
==
--- cfe/trunk/docs/ClangFormatStyleOptions.rst (original)
+++ cfe/trunk/docs/ClangFormatStyleOptions.rst Mon Mar 20 07:56:40 2017
@@ -327,7 +327,7 @@ the configuration (without a prefix: ``A
 
 **AlwaysBreakAfterDefinitionReturnType** 
(``DefinitionReturnTypeBreakingStyle``)
   The function definition return type breaking style to use.  This
-  option is deprecated and is retained for backwards compatibility.
+  option is **deprecated** and is retained for backwards compatibility.
 
   Possible values:
 
@@ -455,10 +455,36 @@ the configuration (without a prefix: ``A
   If ``false``, a function call's arguments will either be all on the
   same line or will have one line each.
 
+  .. code-block:: c++
+
+true:
+void f() {
+  f(, ,
+aaa);
+}
+
+false:
+void f() {
+  f(,
+,
+aaa);
+}
+
 **BinPackParameters** (``bool``)
   If ``false``, a function declaration's or function definition's
   parameters will either all be on the same line or will have one line each.
 
+  .. code-block:: c++
+
+true:
+void f(int , int ,
+   int aaa) {}
+
+false:
+void f(int ,
+   int ,
+   int aaa) {}
+
 **BraceWrapping** (``BraceWrappingFlags``)
   Control of individual brace wrapping cases.
 
@@ -623,12 +649,45 @@ the configuration (without a prefix: ``A
   * ``BOS_None`` (in configuration: ``None``)
 Break after operators.
 
+.. code-block:: c++
+
+   LooongType loongVariable =
+   someLongFunction();
+
+   bool value = a +
+a ==
+a &&
+a >
+c;
+
   * ``BOS_NonAssignment`` (in configuration: ``NonAssignment``)
 Break before operators that aren't assignments.
 
+.. code-block:: c++
+
+   LooongType loongVariable =
+   someLongFunction();
+
+   bool value = a
++ a
+== a
+&& a
+   > c;
+
   * ``BOS_All`` (in configuration: ``All``)
 Break before operators.
 
+.. code-block:: c++
+
+   LooongType loongVariable
+   = someLongFunction();
+
+   bool value = a
++ a
+== a
+&& a
+   > c;
+
 
 
 **BreakBeforeBraces** (``BraceBreakingStyle``)
@@ -837,6 +896,12 @@ the configuration (without a prefix: ``A
   A regular expression that describes comments with special meaning,
   which should not be split into lines or otherwise changed.
 
+  .. code-block:: c++
+
+ CommentPragmas: '^ FOOBAR pragma:'
+ // Will leave the following line unaffected
+ #include  // FOOBAR pragma: keep
+
 **ConstructorInitializerAllOnOneLineOrOnePerLine** (``bool``)
   If the constructor initializers don't fit on a line, put each
   initializer on its own line.
@@ -979,6 +1044,16 @@ the configuration (without a prefix: ``A
 **IndentWidth** (``unsigned``)
   The number of columns to use for indentation.
 
+  .. code-block:: c++
+
+ IndentWidth: 3
+ void f() {
+someFunction();
+if (true, false) {
+   f();
+}
+ }
+
 **IndentWrappedFunctionNames** (``bool``)
   

[PATCH] D30990: Add more examples to clang-format configuration

2017-03-20 Thread Sylvestre Ledru via Phabricator via cfe-commits
sylvestre.ledru updated this revision to Diff 92316.
sylvestre.ledru marked an inline comment as done.

https://reviews.llvm.org/D30990

Files:
  docs/ClangFormatStyleOptions.rst
  include/clang/Format/Format.h

Index: include/clang/Format/Format.h
===
--- include/clang/Format/Format.h
+++ include/clang/Format/Format.h
@@ -204,7 +204,7 @@
   bool AllowShortLoopsOnASingleLine;
 
   /// \brief Different ways to break after the function definition return type.
-  /// This option is deprecated and is retained for backwards compatibility.
+  /// This option is **deprecated** and is retained for backwards compatibility.
   enum DefinitionReturnTypeBreakingStyle {
 /// Break after return type automatically.
 /// ``PenaltyReturnTypeOnItsOwnLine`` is taken into account.
@@ -287,7 +287,7 @@
   };
 
   /// \brief The function definition return type breaking style to use.  This
-  /// option is deprecated and is retained for backwards compatibility.
+  /// option is **deprecated** and is retained for backwards compatibility.
   DefinitionReturnTypeBreakingStyle AlwaysBreakAfterDefinitionReturnType;
 
   /// \brief The function declaration return type breaking style to use.
@@ -318,19 +318,73 @@
 
   /// \brief If ``false``, a function call's arguments will either be all on the
   /// same line or will have one line each.
+  /// \code
+  ///   true:
+  ///   void f() {
+  /// f(, ,
+  ///   aaa);
+  ///   }
+  ///
+  ///   false:
+  ///   void f() {
+  /// f(,
+  ///   ,
+  ///   aaa);
+  ///   }
+  /// \endcode
   bool BinPackArguments;
 
   /// \brief If ``false``, a function declaration's or function definition's
   /// parameters will either all be on the same line or will have one line each.
+  /// \code
+  ///   true:
+  ///   void f(int , int ,
+  ///  int aaa) {}
+  ///
+  ///   false:
+  ///   void f(int ,
+  ///  int ,
+  ///  int aaa) {}
+  /// \endcode
   bool BinPackParameters;
 
   /// \brief The style of breaking before or after binary operators.
   enum BinaryOperatorStyle {
 /// Break after operators.
+/// \code
+///LooongType loongVariable =
+///someLongFunction();
+///
+///bool value = a +
+/// a ==
+/// a &&
+/// a >
+/// c;
+/// \endcode
 BOS_None,
 /// Break before operators that aren't assignments.
+/// \code
+///LooongType loongVariable =
+///someLongFunction();
+///
+///bool value = a
+/// + a
+/// == a
+/// && a
+///> c;
+/// \endcode
 BOS_NonAssignment,
 /// Break before operators.
+/// \code
+///LooongType loongVariable
+///= someLongFunction();
+///
+///bool value = a
+/// + a
+/// == a
+/// && a
+///> c;
+/// \endcode
 BOS_All,
   };
 
@@ -665,6 +719,11 @@
 
   /// \brief A regular expression that describes comments with special meaning,
   /// which should not be split into lines or otherwise changed.
+  /// \code
+  ///CommentPragmas: '^ FOOBAR pragma:'
+  ///// Will leave the following line unaffected
+  ///#include  // FOOBAR pragma: keep
+  /// \endcode
   std::string CommentPragmas;
 
   /// \brief If ``true``, in the class inheritance expression clang-format will
@@ -824,6 +883,15 @@
   bool IndentCaseLabels;
 
   /// \brief The number of columns to use for indentation.
+  /// \code
+  ///IndentWidth: 3
+  ///void f() {
+  ///   someFunction();
+  ///   if (true, false) {
+  ///  f();
+  ///   }
+  ///}
+  /// \endcode
   unsigned IndentWidth;
 
   //

[PATCH] D30415: Fix -mno-altivec cannot overwrite -maltivec option

2017-03-20 Thread Ulrich Weigand via Phabricator via cfe-commits
uweigand added a comment.

In https://reviews.llvm.org/D30415#704761, @echristo wrote:

> In https://reviews.llvm.org/D30415#703652, @uweigand wrote:
>
> > I'm a bit confused by this discussion.  -faltivec and -maltivec are simply 
> > aliases, they do exactly the same thing; the clang-internal variable 
> > OPT_faltivec indicates the use of either -faltivec or -maltivec.
>
>
> They didn't used to, I arranged it so that they did (technically breaking gcc 
> compatibility) a while ago.


Well, mainline GCC doesn't have -faltivec at all and never had, I think this 
was only an Apple GCC extension ...  Not sure what exactly the semantics of 
that was.

>> Or is the suggestion to simply remove the alias -faltivec, and leave 
>> -maltivec as-is?  I'd be less opposed to this since it probably breaks fewer 
>> users ... but I'm still not quite sure what it actually buys us.   And in 
>> any case the patch currently under discussion here would still be necessary 
>> then, to fix -maltivec -mno-altivec ...
> 
> No, remove faltivec and move forward with -maltivec/-mno-altivec but you 
> should be able to remove a lot of the special handling at that point.

I'm still confused as to what exactly you're refering to here.  As far as I can 
see, every single thing triggered by -faltivec / -maltivec in the compiler 
frontend would still be needed exactly the same if we only supported the 
-maltivec option name.  So the only thing we'd save is literally the two lines 
in include/clang/Driver/Options.td that set up the alias.

Do you have an example of the "special handling" to remove you're thinking of?


https://reviews.llvm.org/D30415



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


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

2017-03-20 Thread Daniel Marjamäki via Phabricator via cfe-commits
danielmarjamaki updated this revision to Diff 92315.
danielmarjamaki marked an inline comment as done.
danielmarjamaki added a comment.

Fix review comment. Made isShiftOverflow() static.


Repository:
  rL LLVM

https://reviews.llvm.org/D30295

Files:
  include/clang/StaticAnalyzer/Core/PathSensitive/CheckerHelpers.h
  lib/StaticAnalyzer/Checkers/ConversionChecker.cpp
  lib/StaticAnalyzer/Checkers/UndefResultChecker.cpp
  lib/StaticAnalyzer/Core/CheckerHelpers.cpp
  test/Analysis/bitwise-ops.c

Index: test/Analysis/bitwise-ops.c
===
--- test/Analysis/bitwise-ops.c
+++ test/Analysis/bitwise-ops.c
@@ -29,4 +29,18 @@
   default:
 return 0;
   }
-}
\ No newline at end of file
+}
+
+int testOverflowShift(int a) {
+  if (a == 323) {
+return 1 << a; // expected-warning{{The result of the '<<' expression is undefined due to shift count >= width of type}}
+  }
+  return 0;
+}
+
+int testNegativeShift(int a) {
+  if (a == -5) {
+return 1 << a; // expected-warning{{The result of the '<<' expression is undefined due to negative value on the right side of operand}}
+  }
+  return 0;
+}
Index: lib/StaticAnalyzer/Core/CheckerHelpers.cpp
===
--- lib/StaticAnalyzer/Core/CheckerHelpers.cpp
+++ lib/StaticAnalyzer/Core/CheckerHelpers.cpp
@@ -94,3 +94,40 @@
 
   return std::make_pair(VD, RHS);
 }
+
+bool clang::ento::isExprResultConformsComparisonRule(
+CheckerContext &C, BinaryOperatorKind CompRule, const Expr *LHSExpr,
+const SVal RHSVal) {
+  ProgramStateRef State = C.getState();
+
+  SVal LHSVal = C.getSVal(LHSExpr);
+  if (LHSVal.isUnknownOrUndef() || !LHSVal.getAs())
+return false;
+
+  SValBuilder &Bldr = C.getSValBuilder();
+  SVal Eval =
+  Bldr.evalBinOp(State, CompRule, LHSVal, RHSVal, Bldr.getConditionType());
+  if (Eval.isUnknownOrUndef())
+return false;
+  ConstraintManager &CM = C.getConstraintManager();
+  ProgramStateRef StTrue, StFalse;
+  std::tie(StTrue, StFalse) = CM.assumeDual(State, Eval.castAs());
+  return StTrue && !StFalse;
+}
+
+// Is E value greater or equal than Val?
+bool clang::ento::isGreaterEqual(CheckerContext &C, const Expr *E,
+ unsigned long long Val) {
+  llvm::APSInt In;
+  E->EvaluateAsInt(In, C.getASTContext());
+
+  DefinedSVal V =
+  C.getSValBuilder().makeIntVal(Val, C.getASTContext().LongLongTy);
+  return isExprResultConformsComparisonRule(C, BO_GE, E, V);
+}
+
+// Is E value negative?
+bool clang::ento::isNegative(CheckerContext &C, const Expr *E) {
+  DefinedSVal V = C.getSValBuilder().makeIntVal(0, false);
+  return isExprResultConformsComparisonRule(C, BO_LT, E, V);
+}
Index: lib/StaticAnalyzer/Checkers/UndefResultChecker.cpp
===
--- lib/StaticAnalyzer/Checkers/UndefResultChecker.cpp
+++ lib/StaticAnalyzer/Checkers/UndefResultChecker.cpp
@@ -17,6 +17,7 @@
 #include "clang/StaticAnalyzer/Core/Checker.h"
 #include "clang/StaticAnalyzer/Core/CheckerManager.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h"
+#include "clang/StaticAnalyzer/Core/PathSensitive/CheckerHelpers.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h"
 #include "llvm/ADT/SmallString.h"
 #include "llvm/Support/raw_ostream.h"
@@ -59,6 +60,11 @@
   return StOutBound && !StInBound;
 }
 
+static bool isShiftOverflow(CheckerContext &C, const BinaryOperator *B) {
+  return isGreaterEqual(C, B->getRHS(),
+C.getASTContext().getIntWidth(B->getLHS()->getType()));
+}
+
 void UndefResultChecker::checkPostStmt(const BinaryOperator *B,
CheckerContext &C) const {
   ProgramStateRef state = C.getState();
@@ -97,18 +103,31 @@
 }
 
 if (Ex) {
-  OS << "The " << (isLeft ? "left" : "right")
- << " operand of '"
+  OS << "The " << (isLeft ? "left" : "right") << " operand of '"
  << BinaryOperator::getOpcodeStr(B->getOpcode())
  << "' is a garbage value";
   if (isArrayIndexOutOfBounds(C, Ex))
 OS << " due to array index out of bounds";
-}
-else {
+} else {
   // Neither operand was undefined, but the result is undefined.
-  OS << "The result of the '"
- << BinaryOperator::getOpcodeStr(B->getOpcode())
- << "' expression is undefined";
+  if ((B->getOpcode() == BinaryOperatorKind::BO_Shl ||
+   B->getOpcode() == BinaryOperatorKind::BO_Shr) &&
+  isNegative(C, B->getRHS())) {
+OS << "The result of the '"
+   << BinaryOperator::getOpcodeStr(B->getOpcode())
+   << "' expression is undefined due to negative value on the right "
+  "side of operand";
+  } else if ((B->getOpcode() == BinaryOperatorKind::BO_Shl ||
+  B->getOpcode() == BinaryOperatorKind::BO_Shr) &&
+ isShiftOverflow(C, B)) {
+OS << 

[PATCH] D31121: [clangd] Add support for vscode extension configuration

2017-03-20 Thread Krasimir Georgiev via Phabricator via cfe-commits
krasimir added a comment.

It looks pretty good! I just have a minor suggestion.




Comment at: clangd/clients/clangd-vscode/package.json:45
+"default": "clangd",
+"description": "The path to clangd executable"
+},

krasimir wrote:
> Maybe prepend a `, for example: /usr/bin/clangd` to the "description".
meh, it's OK like that.


https://reviews.llvm.org/D31121



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


[PATCH] D30990: Add more examples to clang-format configuration

2017-03-20 Thread Daniel Jasper via Phabricator via cfe-commits
djasper accepted this revision.
djasper added a comment.
This revision is now accepted and ready to land.

Looks good, just minor remarks.




Comment at: include/clang/Format/Format.h:974
+  ///# With:
+  ///MacroBlockBegin: "^\
+  ///NS_MAP_BEGIN|\

I'd contract these to a single line.



Comment at: include/clang/Format/Format.h:1007
+  ///int f() {  int f() {
+  ///int = 1;   int i = 1;
+  ///   i = foo();

nit: The indent on the right is incorrect (i.e. should not be different).


https://reviews.llvm.org/D30990



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


[PATCH] D31121: [clangd] Add support for vscode extension configuration

2017-03-20 Thread Krasimir Georgiev via Phabricator via cfe-commits
krasimir added inline comments.



Comment at: clangd/clients/clangd-vscode/package.json:45
+"default": "clangd",
+"description": "The path to clangd executable"
+},

Maybe prepend a `, for example: /usr/bin/clangd` to the "description".



Comment at: clangd/clients/clangd-vscode/src/extension.ts:19
 export function activate(context: vscode.ExtensionContext) {
-// TODO: make this configurable
-const clangdPath = '/usr/bin/clangd';
+const clangdPath = getConfig('path', '/usr/bin/clangd');
+const clangdArgs = getConfig('arguments', []);

I feel that this is too platform-specific and redundant because "clangd.path" 
already has a default value.


https://reviews.llvm.org/D31121



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


[PATCH] D30830: [OpenCL] Fix extension guards for atomic functions

2017-03-20 Thread James Price via Phabricator via cfe-commits
jprice added a comment.

Ping - maybe this got lost in the noise.

I don't have commit access - could somebody commit this on my behalf please?


https://reviews.llvm.org/D30830



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


[PATCH] D30990: Add more examples to clang-format configuration

2017-03-20 Thread Sylvestre Ledru via Phabricator via cfe-commits
sylvestre.ledru added a comment.

Daniel, is that ok with you?


https://reviews.llvm.org/D30990



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


Re: r295156 - Add a definition for __STRUCT_PARM_ALIGN__ for elfv2 and 64-bit darwin platforms to match what other compilers produce.

2017-03-20 Thread Iain Sandoe via cfe-commits

> On 16 Mar 2017, at 22:43, Eric Christopher  wrote:
> 
> ... and ppc64 darwin preprocessor stuff isn't tested at all. We should really 
> just delete ppc darwin support at some point. Adding Iain here since he's 
> said that he's working on the platform :)

Indeed I am, and hope to have a set of MC layer patches that make a working 32 
and 64 b assembler before euroLLVM.

I’m still working on getting an ABI match for ppc64 on Darwin, so it’s hard to 
comment except to state that the intention of the ABI is that entities are 
naturally aligned, so the 64b port ought to behave in a similar way to most 
others.

The alignment rules for Darwin32 ABI (especially embedded aggregate content) is 
somewhat special (inherited from the system on which it was based), however 
those are the subject of later patches (and therefore any changes needed could 
be accommodated along with them).

iain

> 
> At any rate I added a single test in r298006
> 
> -eric
> 
> On Wed, Feb 15, 2017 at 12:13 AM Eric Christopher  wrote:
> The PPC one should inherit from this. You're right I should have tested it 
> though. Mostly ppc Darwin isn't well supported.
> 
> 
> On Wed, Feb 15, 2017, 12:06 AM Tim Shen  wrote:
> On Wed, Feb 15, 2017, 00:01 Eric Christopher via cfe-commits 
>  wrote:
> Author: echristo
> Date: Wed Feb 15 01:50:11 2017
> New Revision: 295156
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=295156&view=rev
> Log:
> Add a definition for __STRUCT_PARM_ALIGN__ for elfv2 and 64-bit darwin 
> platforms to match what other compilers produce.
> 
> Modified:
> cfe/trunk/lib/Basic/Targets.cpp
> cfe/trunk/test/Preprocessor/init.c
> 
> Modified: cfe/trunk/lib/Basic/Targets.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=295156&r1=295155&r2=295156&view=diff
> ==
> --- cfe/trunk/lib/Basic/Targets.cpp (original)
> +++ cfe/trunk/lib/Basic/Targets.cpp Wed Feb 15 01:50:11 2017
> @@ -1232,6 +1232,11 @@ void PPCTargetInfo::getTargetDefines(con
>if (LongDoubleWidth == 128)
>  Builder.defineMacro("__LONG_DOUBLE_128__");
> 
> +  // Define this for elfv2 (64-bit only) or 64-bit darwin.
> +  if (ABI == "elfv2" ||
> +  (getTriple().getOS() == llvm::Triple::Darwin && PointerWidth == 64))
> 
> I also see a "DarwinTargetInfo". Maybe this should be put there as well?
> 
> +Builder.defineMacro("__STRUCT_PARM_ALIGN__", "16");
> +
>if (Opts.AltiVec) {
>  Builder.defineMacro("__VEC__", "10206");
>  Builder.defineMacro("__ALTIVEC__");
> 
> Modified: cfe/trunk/test/Preprocessor/init.c
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Preprocessor/init.c?rev=295156&r1=295155&r2=295156&view=diff
> ==
> --- cfe/trunk/test/Preprocessor/init.c (original)
> +++ cfe/trunk/test/Preprocessor/init.c Wed Feb 15 01:50:11 2017
> @@ -5635,6 +5635,7 @@
>  // PPC64LE:#define __SIZE_MAX__ 18446744073709551615UL
>  // PPC64LE:#define __SIZE_TYPE__ long unsigned int
>  // PPC64LE:#define __SIZE_WIDTH__ 64
> +// PPC64LE:#define __STRUCT_PARM_ALIGN__ 16
>  // PPC64LE:#define __UINT16_C_SUFFIX__
>  // PPC64LE:#define __UINT16_MAX__ 65535
>  // PPC64LE:#define __UINT16_TYPE__ unsigned short
> 
> 
> ___
> 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


r298238 - [scan-build-py] use python tempfile for tempdir

2017-03-20 Thread Laszlo Nagy via cfe-commits
Author: rizsotto
Date: Mon Mar 20 04:03:24 2017
New Revision: 298238

URL: http://llvm.org/viewvc/llvm-project?rev=298238&view=rev
Log:
[scan-build-py] use python tempfile for tempdir

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

Modified:
cfe/trunk/tools/scan-build-py/libscanbuild/__init__.py
cfe/trunk/tools/scan-build-py/libscanbuild/arguments.py
cfe/trunk/tools/scan-build-py/libscanbuild/intercept.py

Modified: cfe/trunk/tools/scan-build-py/libscanbuild/__init__.py
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/scan-build-py/libscanbuild/__init__.py?rev=298238&r1=298237&r2=298238&view=diff
==
--- cfe/trunk/tools/scan-build-py/libscanbuild/__init__.py (original)
+++ cfe/trunk/tools/scan-build-py/libscanbuild/__init__.py Mon Mar 20 04:03:24 
2017
@@ -41,12 +41,6 @@ def duplicate_check(method):
 return predicate
 
 
-def tempdir():
-""" Return the default temorary directory. """
-
-return os.getenv('TMPDIR', os.getenv('TEMP', os.getenv('TMP', '/tmp')))
-
-
 def run_build(command, *args, **kwargs):
 """ Run and report build command execution
 

Modified: cfe/trunk/tools/scan-build-py/libscanbuild/arguments.py
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/scan-build-py/libscanbuild/arguments.py?rev=298238&r1=298237&r2=298238&view=diff
==
--- cfe/trunk/tools/scan-build-py/libscanbuild/arguments.py (original)
+++ cfe/trunk/tools/scan-build-py/libscanbuild/arguments.py Mon Mar 20 04:03:24 
2017
@@ -17,7 +17,8 @@ import os
 import sys
 import argparse
 import logging
-from libscanbuild import reconfigure_logging, tempdir
+import tempfile
+from libscanbuild import reconfigure_logging
 from libscanbuild.clang import get_checkers
 
 __all__ = ['parse_args_for_intercept_build', 'parse_args_for_analyze_build',
@@ -187,7 +188,7 @@ def create_analyze_parser(from_build_com
 '--output',
 '-o',
 metavar='',
-default=tempdir(),
+default=tempfile.gettempdir(),
 help="""Specifies the output directory for analyzer reports.
 Subdirectory will be created if default directory is targeted.""")
 output.add_argument(

Modified: cfe/trunk/tools/scan-build-py/libscanbuild/intercept.py
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/scan-build-py/libscanbuild/intercept.py?rev=298238&r1=298237&r2=298238&view=diff
==
--- cfe/trunk/tools/scan-build-py/libscanbuild/intercept.py (original)
+++ cfe/trunk/tools/scan-build-py/libscanbuild/intercept.py Mon Mar 20 04:03:24 
2017
@@ -31,7 +31,7 @@ import logging
 from libear import build_libear, TemporaryDirectory
 from libscanbuild import command_entry_point, compiler_wrapper, \
 wrapper_environment, run_command, run_build
-from libscanbuild import duplicate_check, tempdir
+from libscanbuild import duplicate_check
 from libscanbuild.compilation import split_command
 from libscanbuild.arguments import parse_args_for_intercept_build
 from libscanbuild.shell import encode, decode
@@ -84,7 +84,7 @@ def capture(args):
 for entry in itertools.chain(previous, current)
 if os.path.exists(entry['file']) and not duplicate(entry))
 
-with TemporaryDirectory(prefix='intercept-', dir=tempdir()) as tmp_dir:
+with TemporaryDirectory(prefix='intercept-') as tmp_dir:
 # run the build command
 environment = setup_environment(args, tmp_dir)
 exit_code = run_build(args.build, env=environment)


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


[PATCH] D30087: [Driver] Unify linking of OpenMP runtime

2017-03-20 Thread Jonas Hahnfeld via Phabricator via cfe-commits
Hahnfeld added a comment.

Another ping


https://reviews.llvm.org/D30087



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


[PATCH] D30489: [analyzer] catch out of bounds for VLA

2017-03-20 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun added a comment.

In https://reviews.llvm.org/D30489#689947, @zaks.anna wrote:

> Should we just remove ArrayBoundChecker.cpp or is there a value in keeping it 
> around?


I think once ArrayBoundCheckerV2 is in production we should only keep 
ArrayBoundChecker there as educational purpuses for now. However, in the 
future, as the constraint manager and the core analyzer gets smarter, the V2 
checker might get more and more similar to the original one. Once this patch is 
accepted, I might run the analyzer with V2 check enabled on some open source 
projects. It would be great to have it moved out of alpha soon.

> 
> 
>> If no, an alternative approach would be to properly set the constraints on 
>> the extent of the VLA's memory region.
> 
> For information I tried to set the extent for the VLA.. by copy/pasting some 
> code from the other diff. Ideally I don't think it should be set in 
> checkPreStmt but this was an experiment...
> 
>   void ArrayBoundCheckerV2::checkPreStmt(const ArraySubscriptExpr *A, 
> CheckerContext &C) const
>   {
> ASTContext &Ctx = C.getASTContext();
> QualType T = A->getBase()->IgnoreCasts()->getType();
> const VariableArrayType *VLA = Ctx.getAsVariableArrayType(T);
> if (!VLA)
>   return;
>   
> ProgramStateRef State = C.getState();
>   
> SVal ElementCount = State->getSVal(VLA->getSizeExpr(), 
> C.getLocationContext());
> QualType ElementType = VLA->getElementType();
> ASTContext &AstContext = C.getASTContext();
> CharUnits TypeSize = AstContext.getTypeSizeInChars(ElementType);
>   
> if (Optional DefinedSize =
>   ElementCount.getAs()) {
>   SVal AV = State->getSVal(A->getBase(), C.getLocationContext());
>   const SubRegion *Region = AV.getAsRegion()->getAs();
>   SValBuilder &svalBuilder = C.getSValBuilder();
>   DefinedOrUnknownSVal Extent = Region->getExtent(svalBuilder);
>   // size in Bytes = ElementCount*TypeSize
>   SVal SizeInBytes = svalBuilder.evalBinOpNN(
> State, BO_Mul, ElementCount.castAs(),
> svalBuilder.makeArrayIndex(TypeSize.getQuantity()),
> svalBuilder.getArrayIndexType());
>   DefinedOrUnknownSVal extentMatchesSize = svalBuilder.evalEQ(
> State, Extent, SizeInBytes.castAs());
>   State = State->assume(extentMatchesSize, true);
>   C.addTransition(State);
> }
>   }

You probably get an Unknown value for  `State->getSVal(VLA->getSizeExpr(), 
C.getLocationContext());`,  because the sizeExpr is not in the environment, it 
is already evaluated, its value has been used up, it is no longer needed. So in 
case the correct constraints are missing from the VLAs, you should add these 
assumptions at a point where this value is guaranteed to be available, probably 
right after the evaluation of the declaration.


Repository:
  rL LLVM

https://reviews.llvm.org/D30489



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


[PATCH] D31097: [clang-tidy] don't warn about implicit widening casts in function calls

2017-03-20 Thread Daniel Marjamäki via Phabricator via cfe-commits
danielmarjamaki added a comment.



In https://reviews.llvm.org/D31097#704628, @alexfh wrote:

> In https://reviews.llvm.org/D31097#704626, @alexfh wrote:
>
> > In https://reviews.llvm.org/D31097#704621, @xazax.hun wrote:
> >
> > > I wonder whether warning on implicit casts still makes sense for example 
> > > in mission critical code. So maybe it is worth to have a configuration 
> > > option with the default setting being less strict and chatty. What do you 
> > > think?
> >
> >
> > But it's not about "misplaced casts", it's about implicit conversions and 
> > -Wconversion diagnostic can take care of this.
>
>
> Actually, the diagnostics about implicit casts here might be useful (but 
> maybe in a separate check). I have to look again at 
> https://reviews.llvm.org/D17987.


there can definitely be bugs when there are such implicit casts.

but this checking has no precision at all. I am against that we don't care 
about precision.

adding casts to silence such warnings are dangerous too. I have seen for 
instance in Clang repo when there is "loss of sign" warning and the developer 
fix that by casting for instance a "size_t" to "int" and then there is 
logically loss of precision.

In https://reviews.llvm.org/D31097#704626, @alexfh wrote:

> In https://reviews.llvm.org/D31097#704621, @xazax.hun wrote:
>
> > I wonder whether warning on implicit casts still makes sense for example in 
> > mission critical code. So maybe it is worth to have a configuration option 
> > with the default setting being less strict and chatty. What do you think?
>
>
> But it's not about "misplaced casts", it's about implicit conversions and 
> -Wconversion diagnostic can take care of this.


I agree..

Just want to advertise the analyzer ConversionChecker also in case you didn't 
know about it. That is supposed to be a precise checker for loss of precision 
and loss of sign. It does not detect this loss of precision in implicit casts 
but I would like that is taken care of.


Repository:
  rL LLVM

https://reviews.llvm.org/D31097



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