r205611 - clang-format: Don't merge simple blocks in case statements.

[Daniel Jasper]

Author: djasper
Date: Fri Apr  4 01:46:23 2014
New Revision: 205611

URL: http://llvm.org/viewvc/llvm-project?rev=205611&view=rev
Log:
clang-format: Don't merge simple blocks in case statements.

Before:
  switch (a) {
  case 1: { return 'a'; }
  }

After:
  switch (a) {
  case 1: {
return 'a';
  }
  }

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

Modified: cfe/trunk/lib/Format/Format.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/Format.cpp?rev=205611&r1=205610&r2=205611&view=diff
==
--- cfe/trunk/lib/Format/Format.cpp (original)
+++ cfe/trunk/lib/Format/Format.cpp Fri Apr  4 01:46:23 2014
@@ -623,7 +623,7 @@ private:
 AnnotatedLine &Line = **I;
 if (Line.First->isOneOf(tok::kw_if, tok::kw_while, tok::kw_do, 
tok::r_brace,
 tok::kw_else, tok::kw_try, tok::kw_catch,
-tok::kw_for,
+tok::kw_for, tok::kw_case,
 // This gets rid of all ObjC @ keywords and 
methods.
 tok::at, tok::minus, tok::plus))
   return 0;

Modified: cfe/trunk/unittests/Format/FormatTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTest.cpp?rev=205611&r1=205610&r2=205611&view=diff
==
--- cfe/trunk/unittests/Format/FormatTest.cpp (original)
+++ cfe/trunk/unittests/Format/FormatTest.cpp Fri Apr  4 01:46:23 2014
@@ -511,6 +511,9 @@ TEST_F(FormatTest, FormatsSwitchStatemen
"  f();\n"
"  break;\n"
"}\n"
+   "case 2: {\n"
+   "  break;\n"
+   "}\n"
"}");
   verifyFormat("switch (x) {\n"
"case 1: {\n"


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: clang-format: better detection for multiplication operator

[Daniel Jasper]

I think this makes more sense for now. If we stumble upon bugs requiring
the fix for the other operators, we still have your other patch.


On Thu, Apr 3, 2014 at 10:58 PM, Johannes Kapfhammer wrote:

> On Sun, Mar 30, 2014 at 07:45:51PM +0200, Daniel Jasper wrote:
> > All in all, I think a much easier solution for the mentioned bug would be
> > to treat "<<" similar to how we treat assignments, i.e. if we find a <<,
> we
> > assume the RHS to be an expression (that's the very first "if" in
> > determineTokenType()).
> >
> Not sure if that's the right place.  The "if" branch you are talking
> about will set all preceding stars (on the same level) to
> TT_PointerOrReference:
>
> Before: cout << a *a << b *b << c *c;
> After:  cout << a *a << b *b << c * b;
> My Fix: cout << a * a << b * b << c * c;
>
> So we need the special care for operator<< at least in a new
> "else if".  I've added a "light" version of this patch below, note
> that it only handles operator<< and doesn't work with other operators.
> Doing it the way I did in the last mail has the additional benefit
> that it works for all operators and not just "<<" (in particular
> operator+ is hard to get otherwise).  But we probably won't need this.
>
> --
>
> From 16d81e7e3a0dedd5d51f963a134b26eb9c63b777 Mon Sep 17 00:00:00 2001
> From: Kapfhammer 
> Date: Sun, 30 Mar 2014 12:04:17 +0200
> Subject: [PATCH] Use binary operators as an indicator of for an expression
> and
>  extend the test suite.
>
> This solves the issue where the star was too often interpreted as a
> pointer, e.g "cout< "cout << a * b;".  By marking statements more often an expression, the
> function determineStarAmpUsage() is more reliable.
>
> The test suite was extended.
> ---
>  lib/Format/TokenAnnotator.cpp   |  5 +
>  unittests/Format/FormatTest.cpp | 15 +++
>  2 files changed, 20 insertions(+)
>
> diff --git a/lib/Format/TokenAnnotator.cpp b/lib/Format/TokenAnnotator.cpp
> index 0034235..7fbbdae 100644
> --- a/lib/Format/TokenAnnotator.cpp
> +++ b/lib/Format/TokenAnnotator.cpp
> @@ -681,6 +681,11 @@ private:
>Previous->Type = TT_PointerOrReference;
>  }
>}
> +} else if (Current.is(tok::lessless) &&
> +   !Line.First->isOneOf(tok::kw_template, tok::kw_using) &&
>

How does this change the behavior in any way?


> +   (!Current.Previous ||
> +Current.Previous->isNot(tok::kw_operator))) {
>

I wonder whether we can just use:

} else if (Current.is(tok::lessless) && !Line.MustBeDeclaration) { ..



> +  Contexts.back().IsExpression = true;
>  } else if (Current.isOneOf(tok::kw_return, tok::kw_throw)) {
>Contexts.back().IsExpression = true;
>  } else if (Current.is(tok::l_paren) && !Line.MustBeDeclaration &&
> diff --git a/unittests/Format/FormatTest.cpp
> b/unittests/Format/FormatTest.cpp
> index 5395fd9..7478a23 100644
> --- a/unittests/Format/FormatTest.cpp
> +++ b/unittests/Format/FormatTest.cpp
> @@ -4625,6 +4625,21 @@ TEST_F(FormatTest, UnderstandsRvalueReferences) {
>verifyGoogleFormat("#define WHILE(a, b, c) while (a && (b == c))");
>  }
>
> +TEST_F(FormatTest, FormatsMultiplicationOperator) {
> +  verifyFormat("operator*(type *a)");
> +  verifyFormat("operator<<(type *a)");
> +  verifyFormat("{ cout << (a * b); }");
> +  verifyFormat("{ cout << a * b; }");
> +  verifyFormat("{ cout << a * b << c * d; }");
> +  verifyFormat("type (*f)(type *a)");
> +  verifyFormat("type (&f)(type *a)");
> +  verifyFormat("void f(type *a)");
> +  verifyFormat("using f = void (*)(a *b)");
> +  verifyFormat("template  +  verifyFormat("using f = void (c::*)(a *b)");
> +  verifyFormat("template ");
>

There are many tests here that don't contain a "<<". What are they testing?

+}
>
+
>  TEST_F(FormatTest, FormatsBinaryOperatorsPrecedingEquals) {
>verifyFormat("void f() {\n"
> "  x[a -\n"
> --
> 1.9.1
>
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r205609 - Basic: rename VisualStudio to Windows

[Saleem Abdulrasool]

Author: compnerd
Date: Fri Apr  4 00:08:53 2014
New Revision: 205609

URL: http://llvm.org/viewvc/llvm-project?rev=205609&view=rev
Log:
Basic: rename VisualStudio to Windows

Visual Studio is the Integrated Development Environment.  The toolchain is
generally referred to MSVC.  Rename the target information to be more precise as
per the recommendation of Reid Kleckner.

Modified:
cfe/trunk/lib/Basic/Targets.cpp

Modified: cfe/trunk/lib/Basic/Targets.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=205609&r1=205608&r2=205609&view=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Fri Apr  4 00:08:53 2014
@@ -3066,9 +3066,9 @@ public:
 namespace {
 
 // x86-32 Windows Visual Studio target
-class VisualStudioWindowsX86_32TargetInfo : public WindowsX86_32TargetInfo {
+class MicrosoftX86_32TargetInfo : public WindowsX86_32TargetInfo {
 public:
-  VisualStudioWindowsX86_32TargetInfo(const llvm::Triple &Triple)
+  MicrosoftX86_32TargetInfo(const llvm::Triple &Triple)
   : WindowsX86_32TargetInfo(Triple) {
 LongDoubleWidth = LongDoubleAlign = 64;
 LongDoubleFormat = &llvm::APFloat::IEEEdouble;
@@ -3300,9 +3300,9 @@ public:
 
 namespace {
 // x86-64 Windows Visual Studio target
-class VisualStudioWindowsX86_64TargetInfo : public WindowsX86_64TargetInfo {
+class MicrosoftX86_64TargetInfo : public WindowsX86_64TargetInfo {
 public:
-  VisualStudioWindowsX86_64TargetInfo(const llvm::Triple &Triple)
+  MicrosoftX86_64TargetInfo(const llvm::Triple &Triple)
   : WindowsX86_64TargetInfo(Triple) {
 LongDoubleWidth = LongDoubleAlign = 64;
 LongDoubleFormat = &llvm::APFloat::IEEEdouble;
@@ -6290,7 +6290,7 @@ static TargetInfo *AllocateTarget(const
   case llvm::Triple::GNU:
 return new MinGWX86_32TargetInfo(Triple);
   case llvm::Triple::MSVC:
-return new VisualStudioWindowsX86_32TargetInfo(Triple);
+return new MicrosoftX86_32TargetInfo(Triple);
   }
 }
 case llvm::Triple::Haiku:
@@ -6333,7 +6333,7 @@ static TargetInfo *AllocateTarget(const
   case llvm::Triple::GNU:
 return new MinGWX86_64TargetInfo(Triple);
   case llvm::Triple::MSVC:
-return new VisualStudioWindowsX86_64TargetInfo(Triple);
+return new MicrosoftX86_64TargetInfo(Triple);
   }
 }
 case llvm::Triple::NaCl:


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r205608 - Extend -Wtautological-constant-out-of-range-compare to handle boolean values

[Richard Trieu]

Author: rtrieu
Date: Thu Apr  3 23:13:47 2014
New Revision: 205608

URL: http://llvm.org/viewvc/llvm-project?rev=205608&view=rev
Log:
Extend -Wtautological-constant-out-of-range-compare to handle boolean values
better.  This warning will now trigger on the following conditionals:

bool b;
int i;

if (b > 1) {}  // always false
if (0 <= (i > 5)) {} // always true
if (-1 > b) {} // always false

Patch by Per Viberg.

Added:
cfe/trunk/test/Sema/bool-compare.c
cfe/trunk/test/SemaCXX/bool-compare.cpp
Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/AST/Expr.cpp
cfe/trunk/lib/Sema/SemaChecking.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=205608&r1=205607&r2=205608&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Thu Apr  3 23:13:47 
2014
@@ -4728,8 +4728,9 @@ def warn_lunsigned_always_true_compariso
   "comparison of unsigned%select{| enum}2 expression %0 is always %1">,
   InGroup;
 def warn_out_of_range_compare : Warning<
-  "comparison of constant %0 with expression of type %1 is always "
-  "%select{false|true}2">, InGroup;
+  "comparison of %select{constant %0|true|false}1 with " 
+  "%select{expression of type %2|boolean expression}3 is always "
+  "%select{false|true}4">, InGroup;
 def warn_runsigned_always_true_comparison : Warning<
   "comparison of %0 unsigned%select{| enum}2 expression is always %1">,
   InGroup;

Modified: cfe/trunk/lib/AST/Expr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Expr.cpp?rev=205608&r1=205607&r2=205608&view=diff
==
--- cfe/trunk/lib/AST/Expr.cpp (original)
+++ cfe/trunk/lib/AST/Expr.cpp Thu Apr  3 23:13:47 2014
@@ -121,6 +121,8 @@ bool Expr::isKnownToHaveBooleanValue() c
 switch (UO->getOpcode()) {
 case UO_Plus:
   return UO->getSubExpr()->isKnownToHaveBooleanValue();
+case UO_LNot:
+  return true;
 default:
   return false;
 }

Modified: cfe/trunk/lib/Sema/SemaChecking.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaChecking.cpp?rev=205608&r1=205607&r2=205608&view=diff
==
--- cfe/trunk/lib/Sema/SemaChecking.cpp (original)
+++ cfe/trunk/lib/Sema/SemaChecking.cpp Thu Apr  3 23:13:47 2014
@@ -5334,90 +5334,182 @@ static void DiagnoseOutOfRangeComparison
   if (!S.ActiveTemplateInstantiations.empty())
 return;
 
+  // TODO: Investigate using GetExprRange() to get tighter bounds
+  // on the bit ranges.
+  QualType OtherT = Other->getType();
+  IntRange OtherRange = IntRange::forValueOfType(S.Context, OtherT);
+  unsigned OtherWidth = OtherRange.Width;
+
+  bool OtherIsBooleanType = Other->isKnownToHaveBooleanValue();
+
   // 0 values are handled later by CheckTrivialUnsignedComparison().
-  if (Value == 0)
+  if ((Value == 0) && (!OtherIsBooleanType))
 return;
 
   BinaryOperatorKind op = E->getOpcode();
-  QualType OtherT = Other->getType();
-  QualType ConstantT = Constant->getType();
-  QualType CommonT = E->getLHS()->getType();
-  if (S.Context.hasSameUnqualifiedType(OtherT, ConstantT))
-return;
-  assert((OtherT->isIntegerType() && ConstantT->isIntegerType())
- && "comparison with non-integer type");
-
-  bool ConstantSigned = ConstantT->isSignedIntegerType();
-  bool CommonSigned = CommonT->isSignedIntegerType();
-
-  bool EqualityOnly = false;
+  bool IsTrue = true;
 
-  // TODO: Investigate using GetExprRange() to get tighter bounds on
-  // on the bit ranges.
-  IntRange OtherRange = IntRange::forValueOfType(S.Context, OtherT);
-  unsigned OtherWidth = OtherRange.Width;
-  
-  if (CommonSigned) {
-// The common type is signed, therefore no signed to unsigned conversion.
-if (!OtherRange.NonNegative) {
-  // Check that the constant is representable in type OtherT.
-  if (ConstantSigned) {
-if (OtherWidth >= Value.getMinSignedBits())
-  return;
-  } else { // !ConstantSigned
-if (OtherWidth >= Value.getActiveBits() + 1)
-  return;
+  // Used for diagnostic printout.
+  enum {
+LiteralConstant = 0,
+CXXBoolLiteralTrue,
+CXXBoolLiteralFalse
+  } LiteralOrBoolConstant = LiteralConstant;
+
+  if (!OtherIsBooleanType) {
+QualType ConstantT = Constant->getType();
+QualType CommonT = E->getLHS()->getType();
+
+if (S.Context.hasSameUnqualifiedType(OtherT, ConstantT))
+  return;
+assert((OtherT->isIntegerType() && ConstantT->isIntegerType()) &&
+   "comparison with non-integer type");
+
+bool ConstantSigned = ConstantT->isSignedIntegerType();
+bool CommonSigned = CommonT->isSignedIntegerType();
+
+bool Equal

Re: r205506 - [OPENMP] Small update for C++11

[Alexey Bataev]

Ok, I'll rename them all to VE (var expr, because actually it is 
declrefexprs with refs to vardecls). Is it acceptable?


Best regards,
Alexey Bataev
=
Software Engineer
Intel Compiler Team
Intel Corp.

4 Апрель 2014 г. 6:51:29, Aaron Ballman писал:

On Thu, Apr 3, 2014 at 10:47 PM, Alexey Bataev  wrote:

Hi Richard,
Thanks for review.
But I made this changes just to be fully compatible with the previous one
made by Aaron Ballman (see changes in revision 203937).


Most of my changes retained the original variable name. In retrospect,
I probably should have used it as an opportunity to improve the
identifiers.

~Aaron


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r205606 - CodeGen: Don't create branch weight metadata from empty profiles

[Justin Bogner]

Author: bogner
Date: Thu Apr  3 21:48:51 2014
New Revision: 205606

URL: http://llvm.org/viewvc/llvm-project?rev=205606&view=rev
Log:
CodeGen: Don't create branch weight metadata from empty profiles

If all of our weights are zero when calculating branch weights, it
means we haven't profiled the code in question. Avoid creating a
metadata node that says all branches are equally likely in this case.

The test also checks constructs that hit the other createBranchWeights
overload. These were already working.

Added:
cfe/trunk/test/Profile/Inputs/c-unprofiled-blocks.profdata
cfe/trunk/test/Profile/c-unprofiled-blocks.c
Modified:
cfe/trunk/lib/CodeGen/CodeGenPGO.cpp

Modified: cfe/trunk/lib/CodeGen/CodeGenPGO.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenPGO.cpp?rev=205606&r1=205605&r2=205606&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenPGO.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenPGO.cpp Thu Apr  3 21:48:51 2014
@@ -1004,9 +1004,13 @@ llvm::MDNode *CodeGenPGO::createBranchWe
   if (Weights.size() < 2)
 return nullptr;
 
+  // Check for empty weights.
+  uint64_t MaxWeight = *std::max_element(Weights.begin(), Weights.end());
+  if (MaxWeight == 0)
+return nullptr;
+
   // Calculate how to scale down to 32-bits.
-  uint64_t Scale = calculateWeightScale(*std::max_element(Weights.begin(),
-  Weights.end()));
+  uint64_t Scale = calculateWeightScale(MaxWeight);
 
   SmallVector ScaledWeights;
   ScaledWeights.reserve(Weights.size());

Added: cfe/trunk/test/Profile/Inputs/c-unprofiled-blocks.profdata
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Profile/Inputs/c-unprofiled-blocks.profdata?rev=205606&view=auto
==
--- cfe/trunk/test/Profile/Inputs/c-unprofiled-blocks.profdata (added)
+++ cfe/trunk/test/Profile/Inputs/c-unprofiled-blocks.profdata Thu Apr  3 
21:48:51 2014
@@ -0,0 +1,32 @@
+never_called
+9
+9
+0
+0
+0
+0
+0
+0
+0
+0
+0
+
+main
+1
+1
+1
+
+dead_code
+10
+10
+1
+0
+0
+0
+0
+0
+0
+0
+0
+0
+

Added: cfe/trunk/test/Profile/c-unprofiled-blocks.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Profile/c-unprofiled-blocks.c?rev=205606&view=auto
==
--- cfe/trunk/test/Profile/c-unprofiled-blocks.c (added)
+++ cfe/trunk/test/Profile/c-unprofiled-blocks.c Thu Apr  3 21:48:51 2014
@@ -0,0 +1,68 @@
+// Blocks that we have no profile data for (ie, it was never reached in 
training
+// runs) shouldn't have any branch weight metadata added.
+
+// RUN: %clang_cc1 -triple x86_64-apple-macosx10.9 -main-file-name 
c-unprofiled-blocks.c %s -o - -emit-llvm 
-fprofile-instr-use=%S/Inputs/c-unprofiled-blocks.profdata | FileCheck 
-check-prefix=PGOUSE %s
+
+// PGOUSE-LABEL: @never_called(i32 %i)
+int never_called(int i) {
+  // PGOUSE: br i1 %{{[^,]*}}, label %{{[^,]*}}, label %{{[^,]*}}{{$}}
+  if (i) {}
+
+  // PGOUSE: br i1 %{{[^,]*}}, label %{{[^,]*}}, label %{{[^,]*}}{{$}}
+  for (i = 0; i < 100; ++i) {
+  }
+
+  // PGOUSE: br i1 %{{[^,]*}}, label %{{[^,]*}}, label %{{[^,]*}}{{$}}
+  while (--i) {}
+
+  // PGOUSE: br i1 %{{[^,]*}}, label %{{[^,]*}}, label %{{[^,]*}}{{$}}
+  do {} while (i++ < 75);
+
+  // PGOUSE: switch {{.*}} [
+  // PGOUSE-NEXT: i32 12
+  // PGOUSE-NEXT: i32 82
+  // PGOUSE-NEXT: ]{{$}}
+  switch (i) {
+  case 12: return 3;
+  case 82: return 0;
+  default: return 89;
+  }
+}
+
+// PGOUSE-LABEL: @dead_code(i32 %i)
+int dead_code(int i) {
+  // PGOUSE: br {{.*}}, !prof !{{[0-9]+}}
+  if (i) {
+// This branch is never reached.
+
+// PGOUSE: br i1 %{{[^,]*}}, label %{{[^,]*}}, label %{{[^,]*}}{{$}}
+if (!i) {}
+
+// PGOUSE: br i1 %{{[^,]*}}, label %{{[^,]*}}, label %{{[^,]*}}{{$}}
+for (i = 0; i < 100; ++i) {
+}
+
+// PGOUSE: br i1 %{{[^,]*}}, label %{{[^,]*}}, label %{{[^,]*}}{{$}}
+while (--i) {}
+
+// PGOUSE: br i1 %{{[^,]*}}, label %{{[^,]*}}, label %{{[^,]*}}{{$}}
+do {} while (i++ < 75);
+
+// PGOUSE: switch {{.*}} [
+// PGOUSE-NEXT: i32 12
+// PGOUSE-NEXT: i32 82
+// PGOUSE-NEXT: ]{{$}}
+switch (i) {
+case 12: return 3;
+case 82: return 0;
+default: return 89;
+}
+  }
+  return 2;
+}
+
+// PGOUSE-LABEL: @main(i32 %argc, i8** %argv)
+int main(int argc, const char *argv[]) {
+  dead_code(0);
+  return 0;
+}


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r205506 - [OPENMP] Small update for C++11

[Aaron Ballman]

On Thu, Apr 3, 2014 at 10:47 PM, Alexey Bataev  wrote:
> Hi Richard,
> Thanks for review.
> But I made this changes just to be fully compatible with the previous one
> made by Aaron Ballman (see changes in revision 203937).

Most of my changes retained the original variable name. In retrospect,
I probably should have used it as an opportunity to improve the
identifiers.

~Aaron
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r205506 - [OPENMP] Small update for C++11

[Richard Smith]

On Thu, Apr 3, 2014 at 7:47 PM, Alexey Bataev  wrote:

> Hi Richard,
> Thanks for review.
> But I made this changes just to be fully compatible with the previous one
> made by Aaron Ballman (see changes in revision 203937).
>

Yes, those are bad names too. Feel free to fix them all =)


> Best regards,
> Alexey Bataev
> =
> Software Engineer
> Intel Compiler Team
> Intel Corp.
>
> 3 Апрель 2014 г. 22:04:27, Richard Smith писал:
>
>> On Wed, Apr 2, 2014 at 7:55 PM, Alexey Bataev > > wrote:
>>
>> Author: abataev
>> Date: Wed Apr  2 21:55:46 2014
>> New Revision: 205506
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=205506&view=rev
>> Log:
>> [OPENMP] Small update for C++11
>>
>> Modified:
>> cfe/trunk/lib/Sema/TreeTransform.h
>> cfe/trunk/lib/Serialization/ASTWriterStmt.cpp
>>
>> Modified: cfe/trunk/lib/Sema/TreeTransform.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/
>> TreeTransform.h?rev=205506&r1=205505&r2=205506&view=diff
>> 
>> ==
>> --- cfe/trunk/lib/Sema/TreeTransform.h (original)
>> +++ cfe/trunk/lib/Sema/TreeTransform.h Wed Apr  2 21:55:46 2014
>> @@ -6439,10 +6439,8 @@ OMPClause *
>>  TreeTransform::TransformOMPCopyinClause(OMPCopyinClause
>> *C) {
>>llvm::SmallVector Vars;
>>Vars.reserve(C->varlist_size());
>> -  for (OMPCopyinClause::varlist_iterator I = C->varlist_begin(),
>> - E = C->varlist_end();
>> -   I != E; ++I) {
>> -ExprResult EVar = getDerived().TransformExpr(cast(*I));
>> +  for (auto *I : C->varlists()) {
>>
>>
>> This is not an iterator, so should not be named I.
>>
>> +ExprResult EVar = getDerived().TransformExpr(cast(I));
>>  if (EVar.isInvalid())
>>return 0;
>>  Vars.push_back(EVar.take());
>>
>> Modified: cfe/trunk/lib/Serialization/ASTWriterStmt.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/
>> Serialization/ASTWriterStmt.cpp?rev=205506&r1=205505&r2=205506&view=diff
>> 
>> ==
>> --- cfe/trunk/lib/Serialization/ASTWriterStmt.cpp (original)
>> +++ cfe/trunk/lib/Serialization/ASTWriterStmt.cpp Wed Apr  2
>> 21:55:46 2014
>> @@ -1719,10 +1719,8 @@ void OMPClauseWriter::VisitOMPSharedClau
>>  void OMPClauseWriter::VisitOMPCopyinClause(OMPCopyinClause *C) {
>>Record.push_back(C->varlist_size());
>>Writer->Writer.AddSourceLocation(C->getLParenLoc(), Record);
>> -  for (OMPCopyinClause::varlist_iterator I = C->varlist_begin(),
>> - E = C->varlist_end();
>> -   I != E; ++I)
>> -Writer->Writer.AddStmt(*I);
>> +  for (auto *I : C->varlists())
>>
>>
>> Likewise.
>>
>> +Writer->Writer.AddStmt(I);
>>  }
>>
>>  //===---
>> ---===//
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@cs.uiuc.edu 
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>>
>>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Allow multiple modules with the same name to coexist in the module cache

[Richard Smith]

On Thu, Apr 3, 2014 at 3:40 PM, Ben Langmuir  wrote:

>
> On Mar 28, 2014, at 2:45 PM, Richard Smith  wrote:
>
> On Fri, Mar 28, 2014 at 1:12 PM, Ben Langmuir  wrote:
>
>> This patch allows multiple modules that have the same name to coexist in
>> the module cache.  To differentiate between two modules with the same name,
>> we will consider the path the module map file that they are defined by*
>> part of the 'key' for looking up the precompiled module (pcm file).
>>  Specifically, this patch renames the precompiled module (pcm) files from
>>
>> cache-path//Foo.pcm
>>
>> to
>>
>> cache-path//Foo-.pcm
>>
>
> From a high level, I don't really see why we need a second hash here.
> Shouldn't the -I options be included in the ? If I build the
> same module with different -I flags, that should resolve to different .pcm
> files, regardless of whether it makes the module name resolve to a
> different module.map file.
>
> Are you trying to cope with the case where the -I path finds multiple
> module.map files defining the same module (where it's basically chance
> which one will get built and used)? I don't really feel like this is the
> right solution to that problem either -- we should remove the 'luck' aspect
> and use some sane mechanism to determine which module.map files are loaded,
> and in what order.
>
> Is this addressing some other case?
>
>
>
>> In addition, I've taught the ASTReader to re-resolve the names of
>> imported modules during module loading so that if the header search context
>> changes between when a module was originally built and when it is loaded we
>> can rebuild it if necessary.  For example, if module A imports module B
>>
>> first time:
>> clang -I /path/to/A -I /path/to/B ...
>>
>> second time:
>> clang -I /path/to/A -I /different/path/to/B ...
>>
>> will now rebuild A as expected.
>>
>>
>> * in the case of inferred modules, we use the module map file that
>> *allowed* the inference, not the __inferred_module.map file, since the
>> inferred file path is the same for every inferred module.
>
>
>
> Review comments on the patch itself:
>
>  +  /// the inferrence (e.g. contained 'module *') rather than the virtual
>
> Typo 'inference', 'Module *'.
>
> +  /// For an explanaition of \p ModuleMap, see Module::ModuleMap.
>
> Typo 'explanation'.
>
> +  // safe becuase the FileManager is shared between the compiler
> instances.
>
> Typo 'because'
>
> +  // the inferred module. If this->ModuleMap is nullptr, then we are using
> +  // -emit-module directly, and we cannot have an inferred module.
>
> I don't understand what this comment is trying to say. If we're using
> -emit-module, then we were given a module map on the command-line; should
> that not be referred to by this->ModuleMap? (Also, why 'this->'?) How can a
> top-level module be inferred? Is that a framework-specific thing?
>
> +StringRef ModuleMap = this->ModuleMap ? this->ModuleMap->getName() :
> InFile;
>
> Please pick a different variable name rather than shadowing a member of
> '*this' here.
>
> +// Construct the name -.pcm which
> should
> +// be globally unique to this particular module.
> +llvm::APInt Code(64, llvm::hash_value(ModuleMapPath));
> +SmallString<128> HashStr;
> +Code.toStringUnsigned(HashStr);
>
> Use base 36, like the module hash.
>
>
> I've attached an updated patch.  Changes since the previous one:
> 1. Fixed the typos and other issues Richard pointed out
> 2. I've added code to canonicalize the module map path (using realpath); I
> was getting spurious failures on case-intensitive filesystems.
>

This part is probably not OK, because it'll do the wrong thing on some
build farms (where the canonical path is not predictable, but the path that
make_absolute returns is, by careful control of $PWD). I'll look into this
more, but will be traveling for the next couple of days.

3. I've moved the initialization of the MainFileID (in source manager) from
> Execute() to BeginSourceFile(), since we are now potentially creating file
> ids for module map files during pch loading and need to be able to find the
> main file reliably to construct a correct include stack.
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r205506 - [OPENMP] Small update for C++11

[Alexey Bataev]

Hi Richard,
Thanks for review.
But I made this changes just to be fully compatible with the previous 
one made by Aaron Ballman (see changes in revision 203937).


Best regards,
Alexey Bataev
=
Software Engineer
Intel Compiler Team
Intel Corp.

3 Апрель 2014 г. 22:04:27, Richard Smith писал:

On Wed, Apr 2, 2014 at 7:55 PM, Alexey Bataev mailto:a.bat...@hotmail.com>> wrote:

Author: abataev
Date: Wed Apr  2 21:55:46 2014
New Revision: 205506

URL: http://llvm.org/viewvc/llvm-project?rev=205506&view=rev
Log:
[OPENMP] Small update for C++11

Modified:
cfe/trunk/lib/Sema/TreeTransform.h
cfe/trunk/lib/Serialization/ASTWriterStmt.cpp

Modified: cfe/trunk/lib/Sema/TreeTransform.h
URL:

http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/TreeTransform.h?rev=205506&r1=205505&r2=205506&view=diff

==
--- cfe/trunk/lib/Sema/TreeTransform.h (original)
+++ cfe/trunk/lib/Sema/TreeTransform.h Wed Apr  2 21:55:46 2014
@@ -6439,10 +6439,8 @@ OMPClause *
 TreeTransform::TransformOMPCopyinClause(OMPCopyinClause
*C) {
   llvm::SmallVector Vars;
   Vars.reserve(C->varlist_size());
-  for (OMPCopyinClause::varlist_iterator I = C->varlist_begin(),
- E = C->varlist_end();
-   I != E; ++I) {
-ExprResult EVar = getDerived().TransformExpr(cast(*I));
+  for (auto *I : C->varlists()) {


This is not an iterator, so should not be named I.

+ExprResult EVar = getDerived().TransformExpr(cast(I));
 if (EVar.isInvalid())
   return 0;
 Vars.push_back(EVar.take());

Modified: cfe/trunk/lib/Serialization/ASTWriterStmt.cpp
URL:

http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTWriterStmt.cpp?rev=205506&r1=205505&r2=205506&view=diff

==
--- cfe/trunk/lib/Serialization/ASTWriterStmt.cpp (original)
+++ cfe/trunk/lib/Serialization/ASTWriterStmt.cpp Wed Apr  2
21:55:46 2014
@@ -1719,10 +1719,8 @@ void OMPClauseWriter::VisitOMPSharedClau
 void OMPClauseWriter::VisitOMPCopyinClause(OMPCopyinClause *C) {
   Record.push_back(C->varlist_size());
   Writer->Writer.AddSourceLocation(C->getLParenLoc(), Record);
-  for (OMPCopyinClause::varlist_iterator I = C->varlist_begin(),
- E = C->varlist_end();
-   I != E; ++I)
-Writer->Writer.AddStmt(*I);
+  for (auto *I : C->varlists())


Likewise.

+Writer->Writer.AddStmt(I);
 }

 
//===--===//


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu 
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits




___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Driver: add target definition for Windows on ARM

[Saleem Abdulrasool]

  Address review comments

Hi rnk, t.p.northover, rafael,

http://llvm-reviews.chandlerc.com/D3241

CHANGE SINCE LAST DIFF
  http://llvm-reviews.chandlerc.com/D3241?vs=8254&id=8362#toc

Files:
  include/clang/Basic/DiagnosticDriverKinds.td
  lib/Basic/Targets.cpp
  lib/Driver/ToolChain.cpp
  lib/Driver/Tools.cpp
  test/Driver/windows-arm-minimal-arch.c
  test/Parser/arm-windows-calling-convention-handling.c
  test/Preprocessor/woa-defaults.c
Index: include/clang/Basic/DiagnosticDriverKinds.td
===
--- include/clang/Basic/DiagnosticDriverKinds.td
+++ include/clang/Basic/DiagnosticDriverKinds.td
@@ -82,6 +82,9 @@
 def err_drv_malformed_sanitizer_blacklist : Error<
   "malformed sanitizer blacklist: '%0'">;
 
+def err_target_unsupported_arch
+  : Error<"the target architecture '%0' is not supported by the target '%1'">;
+
 def err_drv_I_dash_not_supported : Error<
   "'%0' not supported, please use -iquote instead">;
 def err_drv_unknown_argument : Error<"unknown argument: '%0'">;
Index: lib/Basic/Targets.cpp
===
--- lib/Basic/Targets.cpp
+++ lib/Basic/Targets.cpp
@@ -3708,6 +3708,9 @@
   static const Builtin::Info BuiltinInfo[];
 
   static bool shouldUseInlineAtomic(const llvm::Triple &T) {
+if (T.isOSWindows())
+  return true;
+
 // On linux, binaries targeting old cpus call functions in libgcc to
 // perform atomic operations. The implementation in libgcc then calls into
 // the kernel which on armv6 and newer uses ldrex and strex. The net result
@@ -3774,19 +3777,30 @@
 if (IsThumb) {
   // Thumb1 add sp, #imm requires the immediate value be multiple of 4,
   // so set preferred for small types to 32.
-  if (T.isOSBinFormatMachO())
+  if (T.isOSBinFormatMachO()) {
 DescriptionString = BigEndian ?
   "E-m:o-p:32:32-i1:8:32-i8:8:32-i16:16:32-i64:64-"
   "v128:64:128-a:0:32-n32-S64" :
   "e-m:o-p:32:32-i1:8:32-i8:8:32-i16:16:32-i64:64-"
   "v128:64:128-a:0:32-n32-S64";
-  else
+  } else if (T.isOSWindows()) {
+// FIXME: this is invalid for WindowsCE
+assert(!BigEndian && "Windows on ARM does not support big endian");
+DescriptionString = "e"
+"-m:e"
+"-p:32:32"
+"-i1:8:32-i8:8:32-i16:16:32-i64:64"
+"-v128:64:128"
+"-a:0:32"
+"-n32"
+"-S64";
+  } else {
 DescriptionString = BigEndian ?
   "E-m:e-p:32:32-i1:8:32-i8:8:32-i16:16:32-i64:64-"
   "v128:64:128-a:0:32-n32-S64" :
   "e-m:e-p:32:32-i1:8:32-i8:8:32-i16:16:32-i64:64-"
   "v128:64:128-a:0:32-n32-S64";
-
+  }
 } else {
   if (T.isOSBinFormatMachO())
 DescriptionString = BigEndian ?
@@ -4093,12 +4107,14 @@
 
 // FIXME: It's more complicated than this and we don't really support
 // interworking.
-if (5 <= CPUArchVer && CPUArchVer <= 8)
+// Windows on ARM does not "support" interworking
+if (5 <= CPUArchVer && CPUArchVer <= 8 && !getTriple().isOSWindows())
   Builder.defineMacro("__THUMB_INTERWORK__");
 
 if (ABI == "aapcs" || ABI == "aapcs-linux" || ABI == "aapcs-vfp") {
   // Embedded targets on Darwin follow AAPCS, but not EABI.
-  if (!getTriple().isOSDarwin())
+  // Windows on ARM follows AAPCS VFP, but does not conform to EABI.
+  if (!getTriple().isOSDarwin() && !getTriple().isOSWindows())
 Builder.defineMacro("__ARM_EABI__");
   Builder.defineMacro("__ARM_PCS", "1");
 
@@ -4371,6 +4387,66 @@
 } // end anonymous namespace.
 
 namespace {
+class WindowsARMTargetInfo : public WindowsTargetInfo {
+public:
+  WindowsARMTargetInfo(const llvm::Triple &Triple)
+: WindowsTargetInfo(Triple) {
+TLSSupported = false;
+WCharType = UnsignedShort;
+SizeType = UnsignedInt;
+UserLabelPrefix = "";
+  }
+  void getVisualStudioDefines(const LangOptions &Opts,
+  MacroBuilder &Builder) const {
+WindowsTargetInfo::getVisualStudioDefines(Opts, Builder);
+
+// FIXME: this is invalid for WindowsCE
+Builder.defineMacro("_M_ARM_NT", "1");
+Builder.defineMacro("_M_ARMT", "_M_ARM");
+Builder.defineMacro("_M_THUMB", "_M_ARM");
+// TODO base this on the actual triple
+Builder.defineMacro("_M_ARM", "7");
+// TODO map the complete set of values
+// 31: VFPv3 40: VFPv4
+Builder.defineMacro("_M_ARM_FP", "31");
+  }
+};
+
+// Windows ARM + IA-64 C++ ABI Target
+class ItaniumWindowsARMleTargetInfo : public WindowsARMTargetInfo {
+public:
+  ItaniumWindowsARMleTargetInfo(const llvm::Triple &Triple)

r205598 - Add clang-cl alias to allow users to disable c4005

[Reid Kleckner]

Author: rnk
Date: Thu Apr  3 20:36:55 2014
New Revision: 205598

URL: http://llvm.org/viewvc/llvm-project?rev=205598&view=rev
Log:
Add clang-cl alias to allow users to disable c4005

If we ever want three or more aliases, at that point we should put MSVC
warning ids in DiagnosticGroups.td.  We can use that to support #pragma
warning.

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

Modified: cfe/trunk/include/clang/Driver/CLCompatOptions.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/CLCompatOptions.td?rev=205598&r1=205597&r2=205598&view=diff
==
--- cfe/trunk/include/clang/Driver/CLCompatOptions.td (original)
+++ cfe/trunk/include/clang/Driver/CLCompatOptions.td Thu Apr  3 20:36:55 2014
@@ -121,6 +121,8 @@ def _SLASH_WX : CLFlag<"WX">, HelpText<"
 def _SLASH_WX_ : CLFlag<"WX-">, HelpText<"Do not treat warnings as errors">,
   Alias, AliasArgs<["no-error"]>;
 def _SLASH_w_flag : CLFlag<"w">, HelpText<"Disable all warnings">, Alias;
+def _SLASH_wd4005 : CLFlag<"wd4005">, Alias,
+  AliasArgs<["no-macro-redefined"]>;
 def _SLASH_vd : CLJoined<"vd">, HelpText<"Control vtordisp placement">,
   Alias;
 def _SLASH_Z7 : CLFlag<"Z7">, Alias;

Modified: cfe/trunk/test/Driver/cl-options.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/cl-options.c?rev=205598&r1=205597&r2=205598&view=diff
==
--- cfe/trunk/test/Driver/cl-options.c (original)
+++ cfe/trunk/test/Driver/cl-options.c Thu Apr  3 20:36:55 2014
@@ -129,6 +129,10 @@
 // WJoined: "-cc1"
 // WJoined: "-Wunused-pragmas"
 
+// For some warning ids, we can map from MSVC warning to Clang warning.
+// RUN: %clang_cl -wd4005 -### -- %s 2>&1 | FileCheck -check-prefix=wd4005 %s
+// wd4005: "-cc1"
+// wd4005: "-Wno-macro-redefined"
 
 // Ignored options. Check that we don't get "unused during compilation" errors.
 // (/Zs is for syntax-only)


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Driver: add target definition for Windows on ARM

[Saleem Abdulrasool]

Comment at: lib/Basic/Targets.cpp:4416
@@ +4415,3 @@
+Builder.defineMacro("__stdcall", "");
+// The __inline keyword is similar to GNU inline.
+// http://msdn.microsoft.com/en-us/library/z8y1yy88(v=vs.71).aspx

David Majnemer wrote:
> Saleem Abdulrasool wrote:
> > Saleem Abdulrasool wrote:
> > > Reid Kleckner wrote:
> > > > I'm pretty sure this is wrong.  MSVC's __inline semantics are identical 
> > > > to C++ inline, with an extra quirk for extern __inline, which forces 
> > > > code emission.  Clang handles this in 
> > > > ASTContext::GetGVALinkageForFunction() under -fms-compatibility.  David 
> > > > is working on a patch for 'extern __inline' at the moment.
> > > > 
> > > > Perhaps we should change the way this works so that we treat '__inline' 
> > > > as C++ inline in C mode and 'inline' as C99 inline, and the __inline 
> > > > spelling would be enabled by -fms-extensions, which I assume you're 
> > > > using.
> > > I think that should be controlled by -fms-compatibility no?  
> > > -fms-extensions is enabling extensions a la /Ze right?  (BTW, on a 
> > > separate but related topic, perhaps -fms-compatibility should imply 
> > > -fms-extensions since /Ze is default?).
> > > 
> > > That said, I can double check if __inline can be handled with the work 
> > > that David did to support it.  If it can, then this can be entirely 
> > > removed, which is even better!
> > BTW, an easy way to see the difference in behaviour is:
> > 
> > clang -cc1 -triple thumbv7-windows -Os -fms-compatibility -S - -o - <<< 
> > '__inline int f(int i) { return i + 32; } int g(int i) { return f(i) * 2; }'
> > 
> > With this definition you see label emissions for both f and g, and without 
> > only for g.
> First of all, this has nothing at all to do with `__inline`. `_inline` and 
> `inline` are both equally affected.
> Second of all, this has nothing at all to do with ARM, X64 and X86 are both 
> equally affected.
> Third of all, this macro definition of `__inline` will give `f` a strong 
> definition, which is definitely wrong.
> 
> It appears that the right thing to do is make 
> `ASTContext::GetGVALinkageForFunction` select `GVA_StrongODR` instead of 
> `GVA_CXXInline` if we respect `/Zc:inline-`
> 
> However, this is all very dubious.
I didnt realise that inline and _inline/__inline behaved similarly in this 
regard.  However, you are absolutely correct on the point that this is not ARM 
specific, and that this is not the exactly the same semantics and should be 
split up, which I will do.


http://llvm-reviews.chandlerc.com/D3241
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r205591 - Put macro redefinition warnings under -Wmacro-redefined

[Reid Kleckner]

Author: rnk
Date: Thu Apr  3 19:17:16 2014
New Revision: 205591

URL: http://llvm.org/viewvc/llvm-project?rev=205591&view=rev
Log:
Put macro redefinition warnings under -Wmacro-redefined

This is consistent with -Wbuiltin-macro-redefined, and puts this common
extension warning under a flag.

Reviewers: rsmith

Differential Revision: http://llvm-reviews.chandlerc.com/D3283

Added:
cfe/trunk/test/Preprocessor/macro_redefined.c
Modified:
cfe/trunk/include/clang/Basic/DiagnosticGroups.td
cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td
cfe/trunk/test/Misc/warning-flags.c

Modified: cfe/trunk/include/clang/Basic/DiagnosticGroups.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticGroups.td?rev=205591&r1=205590&r2=205591&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticGroups.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticGroups.td Thu Apr  3 19:17:16 2014
@@ -48,6 +48,7 @@ def ImplicitConversionFloatingPointToBoo
   DiagGroup<"implicit-conversion-floating-point-to-bool">;
 def ObjCLiteralConversion : DiagGroup<"objc-literal-conversion">;
 def BadArrayNewLength : DiagGroup<"bad-array-new-length">;
+def MacroRedefined : DiagGroup<"macro-redefined">;
 def BuiltinMacroRedefined : DiagGroup<"builtin-macro-redefined">;
 def BuiltinRequiresHeader : DiagGroup<"builtin-requires-header">;
 def C99Compat : DiagGroup<"c99-compat">;

Modified: cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td?rev=205591&r1=205590&r2=205591&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td Thu Apr  3 19:17:16 2014
@@ -316,7 +316,7 @@ def ext_pp_extra_tokens_at_eol : ExtWarn
 def ext_pp_comma_expr : Extension<"comma operator in operand of #if">;
 def ext_pp_bad_vaargs_use : Extension<
   "__VA_ARGS__ can only appear in the expansion of a C99 variadic macro">;
-def ext_pp_macro_redef : ExtWarn<"%0 macro redefined">;
+def ext_pp_macro_redef : ExtWarn<"%0 macro redefined">, 
InGroup;
 def ext_variadic_macro : Extension<"variadic macros are a C99 feature">,
   InGroup;
 def warn_cxx98_compat_variadic_macro : Warning<

Modified: cfe/trunk/test/Misc/warning-flags.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Misc/warning-flags.c?rev=205591&r1=205590&r2=205591&view=diff
==
--- cfe/trunk/test/Misc/warning-flags.c (original)
+++ cfe/trunk/test/Misc/warning-flags.c Thu Apr  3 19:17:16 2014
@@ -18,7 +18,7 @@ This test serves two purposes:
 
 The list of warnings below should NEVER grow.  It should gradually shrink to 0.
 
-CHECK: Warnings without flags (106):
+CHECK: Warnings without flags (105):
 CHECK-NEXT:   ext_delete_void_ptr_operand
 CHECK-NEXT:   ext_expected_semi_decl_list
 CHECK-NEXT:   ext_explicit_specialization_storage_class
@@ -28,7 +28,6 @@ CHECK-NEXT:   ext_missing_declspec
 CHECK-NEXT:   ext_missing_whitespace_after_macro_name
 CHECK-NEXT:   ext_new_paren_array_nonconst
 CHECK-NEXT:   ext_plain_complex
-CHECK-NEXT:   ext_pp_macro_redef
 CHECK-NEXT:   ext_template_arg_extra_parens
 CHECK-NEXT:   ext_typecheck_comparison_of_pointer_integer
 CHECK-NEXT:   ext_typecheck_cond_incompatible_operands

Added: cfe/trunk/test/Preprocessor/macro_redefined.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Preprocessor/macro_redefined.c?rev=205591&view=auto
==
--- cfe/trunk/test/Preprocessor/macro_redefined.c (added)
+++ cfe/trunk/test/Preprocessor/macro_redefined.c Thu Apr  3 19:17:16 2014
@@ -0,0 +1,19 @@
+// RUN: %clang_cc1 %s -Eonly -verify -Wno-all -Wmacro-redefined -DCLI_MACRO=1 
-DWMACRO_REDEFINED
+// RUN: %clang_cc1 %s -Eonly -verify -Wno-all -Wno-macro-redefined 
-DCLI_MACRO=1
+
+#ifndef WMACRO_REDEFINED
+// expected-no-diagnostics
+#endif
+
+#ifdef WMACRO_REDEFINED
+// expected-note@1 {{previous definition is here}}
+// expected-warning@+2 {{macro redefined}}
+#endif
+#define CLI_MACRO
+
+#ifdef WMACRO_REDEFINED
+// expected-note@+3 {{previous definition is here}}
+// expected-warning@+3 {{macro redefined}}
+#endif
+#define REGULAR_MACRO
+#define REGULAR_MACRO 1


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Put macro redefinition warnings under -Wmacro-redefined

[Reid Kleckner]

  Closed by commit rL205591 (authored by @rnk).

CHANGED PRIOR TO COMMIT
  http://llvm-reviews.chandlerc.com/D3283?vs=8354&id=8359#toc

http://llvm-reviews.chandlerc.com/D3283

COMMIT
  http://llvm-reviews.chandlerc.com/rL205591
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Put macro redefinition warnings under -Wmacro-redefined

[Reid Kleckner]

  Thanks!



Comment at: include/clang/Basic/DiagnosticGroups.td:51-52
@@ -50,3 +50,4 @@
 def BadArrayNewLength : DiagGroup<"bad-array-new-length">;
+def MacroRedefined : DiagGroup<"macro-redefined">;
 def BuiltinMacroRedefined : DiagGroup<"builtin-macro-redefined">;
 def BuiltinRequiresHeader : DiagGroup<"builtin-requires-header">;

Richard Smith wrote:
> Do you think there's value in making `BuiltinMacroRedefined` a subgroup of 
> `MacroRedefined`? I'm torn here -- logically one is a subset of the other, 
> but redefining a builtin macro is a more serious offense.
I'd leave it as is.  No need to impose artificial hierarchy.  Users might 
accidentally suppress -Wbuiltin-macro-redefined with -Wno-macro-redefined.


http://llvm-reviews.chandlerc.com/D3283

BRANCH
  macro-redef

ARCANIST PROJECT
  clang
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Put macro redefinition warnings under -Wmacro-redefined

[Richard Smith]

  LGTM



Comment at: include/clang/Basic/DiagnosticGroups.td:51-52
@@ -50,3 +50,4 @@
 def BadArrayNewLength : DiagGroup<"bad-array-new-length">;
+def MacroRedefined : DiagGroup<"macro-redefined">;
 def BuiltinMacroRedefined : DiagGroup<"builtin-macro-redefined">;
 def BuiltinRequiresHeader : DiagGroup<"builtin-requires-header">;

Do you think there's value in making `BuiltinMacroRedefined` a subgroup of 
`MacroRedefined`? I'm torn here -- logically one is a subset of the other, but 
redefining a builtin macro is a more serious offense.


http://llvm-reviews.chandlerc.com/D3283

BRANCH
  macro-redef

ARCANIST PROJECT
  clang
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r205580 - Turn off -Wmissing-noreturn warning for blocks

[Fariborz Jahanian]

Author: fjahanian
Date: Thu Apr  3 18:06:35 2014
New Revision: 205580

URL: http://llvm.org/viewvc/llvm-project?rev=205580&view=rev
Log:
Turn off -Wmissing-noreturn warning for blocks 
as there is no way to attach this attribute to the
block literal. // rdar://16274746

Modified:
cfe/trunk/lib/Sema/AnalysisBasedWarnings.cpp
cfe/trunk/test/Sema/return-noreturn.c

Modified: cfe/trunk/lib/Sema/AnalysisBasedWarnings.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/AnalysisBasedWarnings.cpp?rev=205580&r1=205579&r2=205580&view=diff
==
--- cfe/trunk/lib/Sema/AnalysisBasedWarnings.cpp (original)
+++ cfe/trunk/lib/Sema/AnalysisBasedWarnings.cpp Thu Apr  3 18:06:35 2014
@@ -413,8 +413,7 @@ struct CheckFallThroughDiagnostics {
   diag::err_noreturn_block_has_return_expr;
 D.diag_AlwaysFallThrough_ReturnsNonVoid =
   diag::err_falloff_nonvoid_block;
-D.diag_NeverFallThroughOrReturn =
-  diag::warn_suggest_noreturn_block;
+D.diag_NeverFallThroughOrReturn = 0;
 D.funMode = Block;
 return D;
   }
@@ -449,10 +448,7 @@ struct CheckFallThroughDiagnostics {
 }
 
 // For blocks / lambdas.
-return ReturnsVoid && !HasNoReturn
-&& ((funMode == Lambda) ||
-D.getDiagnosticLevel(diag::warn_suggest_noreturn_block, 
FuncLoc)
-  == DiagnosticsEngine::Ignored);
+return ReturnsVoid && !HasNoReturn;
   }
 };
 

Modified: cfe/trunk/test/Sema/return-noreturn.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/return-noreturn.c?rev=205580&r1=205579&r2=205580&view=diff
==
--- cfe/trunk/test/Sema/return-noreturn.c (original)
+++ cfe/trunk/test/Sema/return-noreturn.c Thu Apr  3 18:06:35 2014
@@ -2,7 +2,7 @@
 
 int j;
 void test1() { // expected-warning {{function 'test1' could be declared with 
attribute 'noreturn'}}
-  ^ (void) { while (1) { } }(); // expected-warning {{block could be declared 
with attribute 'noreturn'}}
+  ^ (void) { while (1) { } }();
   ^ (void) { if (j) while (1) { } }();
   while (1) { }
 }
@@ -40,3 +40,13 @@ test4() {
 _Noreturn void test5() {
   test2_positive();
 }
+
+// rdar://16274746
+void test6()
+{
+(void)^{ 
+   for(;;)
+;
+ };
+}
+


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

[PATCH] Put macro redefinition warnings under -Wmacro-redefined

[Reid Kleckner]

Hi rsmith,

This is consistent with -Wbuiltin-macro-redefined, and puts this common
extension warning under a flag.

http://llvm-reviews.chandlerc.com/D3283

Files:
  include/clang/Basic/DiagnosticGroups.td
  include/clang/Basic/DiagnosticLexKinds.td
  test/Misc/warning-flags.c
  test/Preprocessor/macro_redefined.c

Index: include/clang/Basic/DiagnosticGroups.td
===
--- include/clang/Basic/DiagnosticGroups.td
+++ include/clang/Basic/DiagnosticGroups.td
@@ -48,6 +48,7 @@
   DiagGroup<"implicit-conversion-floating-point-to-bool">;
 def ObjCLiteralConversion : DiagGroup<"objc-literal-conversion">;
 def BadArrayNewLength : DiagGroup<"bad-array-new-length">;
+def MacroRedefined : DiagGroup<"macro-redefined">;
 def BuiltinMacroRedefined : DiagGroup<"builtin-macro-redefined">;
 def BuiltinRequiresHeader : DiagGroup<"builtin-requires-header">;
 def C99Compat : DiagGroup<"c99-compat">;
Index: include/clang/Basic/DiagnosticLexKinds.td
===
--- include/clang/Basic/DiagnosticLexKinds.td
+++ include/clang/Basic/DiagnosticLexKinds.td
@@ -316,7 +316,7 @@
 def ext_pp_comma_expr : Extension<"comma operator in operand of #if">;
 def ext_pp_bad_vaargs_use : Extension<
   "__VA_ARGS__ can only appear in the expansion of a C99 variadic macro">;
-def ext_pp_macro_redef : ExtWarn<"%0 macro redefined">;
+def ext_pp_macro_redef : ExtWarn<"%0 macro redefined">, 
InGroup;
 def ext_variadic_macro : Extension<"variadic macros are a C99 feature">,
   InGroup;
 def warn_cxx98_compat_variadic_macro : Warning<
Index: test/Misc/warning-flags.c
===
--- test/Misc/warning-flags.c
+++ test/Misc/warning-flags.c
@@ -18,7 +18,7 @@
 
 The list of warnings below should NEVER grow.  It should gradually shrink to 0.
 
-CHECK: Warnings without flags (106):
+CHECK: Warnings without flags (105):
 CHECK-NEXT:   ext_delete_void_ptr_operand
 CHECK-NEXT:   ext_expected_semi_decl_list
 CHECK-NEXT:   ext_explicit_specialization_storage_class
@@ -28,7 +28,6 @@
 CHECK-NEXT:   ext_missing_whitespace_after_macro_name
 CHECK-NEXT:   ext_new_paren_array_nonconst
 CHECK-NEXT:   ext_plain_complex
-CHECK-NEXT:   ext_pp_macro_redef
 CHECK-NEXT:   ext_template_arg_extra_parens
 CHECK-NEXT:   ext_typecheck_comparison_of_pointer_integer
 CHECK-NEXT:   ext_typecheck_cond_incompatible_operands
Index: test/Preprocessor/macro_redefined.c
===
--- /dev/null
+++ test/Preprocessor/macro_redefined.c
@@ -0,0 +1,19 @@
+// RUN: %clang_cc1 %s -Eonly -verify -Wno-all -Wmacro-redefined -DCLI_MACRO=1 
-DWMACRO_REDEFINED
+// RUN: %clang_cc1 %s -Eonly -verify -Wno-all -Wno-macro-redefined 
-DCLI_MACRO=1
+
+#ifndef WMACRO_REDEFINED
+// expected-no-diagnostics
+#endif
+
+#ifdef WMACRO_REDEFINED
+// expected-note@1 {{previous definition is here}}
+// expected-warning@+2 {{macro redefined}}
+#endif
+#define CLI_MACRO
+
+#ifdef WMACRO_REDEFINED
+// expected-note@+3 {{previous definition is here}}
+// expected-warning@+3 {{macro redefined}}
+#endif
+#define REGULAR_MACRO
+#define REGULAR_MACRO 1
Index: include/clang/Basic/DiagnosticGroups.td
===
--- include/clang/Basic/DiagnosticGroups.td
+++ include/clang/Basic/DiagnosticGroups.td
@@ -48,6 +48,7 @@
   DiagGroup<"implicit-conversion-floating-point-to-bool">;
 def ObjCLiteralConversion : DiagGroup<"objc-literal-conversion">;
 def BadArrayNewLength : DiagGroup<"bad-array-new-length">;
+def MacroRedefined : DiagGroup<"macro-redefined">;
 def BuiltinMacroRedefined : DiagGroup<"builtin-macro-redefined">;
 def BuiltinRequiresHeader : DiagGroup<"builtin-requires-header">;
 def C99Compat : DiagGroup<"c99-compat">;
Index: include/clang/Basic/DiagnosticLexKinds.td
===
--- include/clang/Basic/DiagnosticLexKinds.td
+++ include/clang/Basic/DiagnosticLexKinds.td
@@ -316,7 +316,7 @@
 def ext_pp_comma_expr : Extension<"comma operator in operand of #if">;
 def ext_pp_bad_vaargs_use : Extension<
   "__VA_ARGS__ can only appear in the expansion of a C99 variadic macro">;
-def ext_pp_macro_redef : ExtWarn<"%0 macro redefined">;
+def ext_pp_macro_redef : ExtWarn<"%0 macro redefined">, InGroup;
 def ext_variadic_macro : Extension<"variadic macros are a C99 feature">,
   InGroup;
 def warn_cxx98_compat_variadic_macro : Warning<
Index: test/Misc/warning-flags.c
===
--- test/Misc/warning-flags.c
+++ test/Misc/warning-flags.c
@@ -18,7 +18,7 @@
 
 The list of warnings below should NEVER grow.  It should gradually shrink to 0.
 
-CHECK: Warnings without flags (106):
+CHECK: Warnings without flags (105):
 CHECK-NEXT:   ext_delete_void_ptr_operand
 CHECK-NEXT:   ext_expected_semi_decl_list
 CHECK-NEXT:   ext_explicit_specialization_stor

[libcxxabi] r205573 - Include stdlib.h for getenv when !NDEBUG.

[Joerg Sonnenberger]

Author: joerg
Date: Thu Apr  3 17:00:08 2014
New Revision: 205573

URL: http://llvm.org/viewvc/llvm-project?rev=205573&view=rev
Log:
Include stdlib.h for getenv when !NDEBUG.

Modified:
libcxxabi/trunk/src/Unwind/libunwind.cpp

Modified: libcxxabi/trunk/src/Unwind/libunwind.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/src/Unwind/libunwind.cpp?rev=205573&r1=205572&r2=205573&view=diff
==
--- libcxxabi/trunk/src/Unwind/libunwind.cpp (original)
+++ libcxxabi/trunk/src/Unwind/libunwind.cpp Thu Apr  3 17:00:08 2014
@@ -316,6 +316,7 @@ void _unw_remove_dynamic_fde(unw_word_t
 
 // Add logging hooks in Debug builds only
 #ifndef NDEBUG
+#include 
 
 _LIBUNWIND_HIDDEN
 bool logAPIs() {


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r205436 - Extend the SSE2 comment lexing to AVX2. Only 16byte align when not on AVX2.

[Richard Smith]

On Thu, Apr 3, 2014 at 4:04 AM, Stephen Canon  wrote:

> On Apr 2, 2014, at 3:14 PM, Chris Lattner  wrote:
>
> > On Apr 2, 2014, at 12:14 PM, Chris Lattner  wrote:
> >
> >> On Apr 2, 2014, at 10:27 AM, Roman Divacky 
> wrote:
> >>
> >>> Author: rdivacky
> >>> Date: Wed Apr  2 12:27:03 2014
> >>> New Revision: 205436
> >>>
> >>> URL: http://llvm.org/viewvc/llvm-project?rev=205436&view=rev
> >>> Log:
> >>> Extend the SSE2 comment lexing to AVX2. Only 16byte align when not on
> AVX2.
> >>>
> >>> This provides some 3% speedup when preprocessing gcc.c as a single
> file.
> >>
> >> Nice!
> >
> > I haven't looked closely at them, but would any of the SSE 4.2 "string
> processing" instructions be helpful here?
>
> For simply scanning for '/', SSE4.2 won't be a win; it's usually not
> significantly faster than PCMPEQB + PMOVMSKB in strchr-type loops.
>
> One could use it to search for "*/" instead, which would be somewhat more
> interesting.


It would, alas, not be correct. There can be escaped newlines between the *
and the /.


>  There's no 32B VPCMPESTRI however, so if there aren't many false-positive
> '/' characters in block comments (I expect this to be the case), then using
> AVX2 to scan for '/' should still win.
>
> - Steve
> ___
> cfe-commits mailing list
> cfe-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Fix for CUDA codegen due to missing generation of implicit address space conversions

[Jingyue Wu]

  Looks like my patch r204677 already fixed this problem...

http://llvm-reviews.chandlerc.com/D2462
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [LLVMdev] 3.4.1 Release Plans

[David Fang]

Hi Tom,
Rafael has approved (in IRC):
LLVM: r196168, r196987, r197572, r197574
clang: r197577

Iain has approved LLVM r198744.

Jim, would you approve backporting the remaining patches to 3.4.1?
These remaining two patches only affects behavior on OS X 10.6 and 
earlier.

LLVM: r196970 (.weak_definition for older cctools, by me)
clang: r196981 (suppress -Q option for legacy assemblers)


David


Hi David,

I haven't seen any response from code owners about these patches.
Maybe it would help to send an email with different subjects to
both llvm-commits and cfe-commits and cc the code owners again.

Thanks,
Tom

On Fri, Mar 28, 2014 at 10:19:38PM -0400, David Fang wrote:

Hi Tom,
Thanks for doing this.  I would like to nominate the following
patches to be backported to release_34 (3.4.1).

LLVM:
r196168, r196970 -- .weak_definition vs. .weak_def_can_be_hidden
(r196168 is Rafael's, 970 is mine)
r196987, r197572, r197574 -- [ABI] f64,i64 alignment on ppc-darwin
all Rafael's, 196987 is a cosmetic change that made it easier
to apply the others.
r198744 [Iain Sandoe] -- FDE cross-section relocs for EH

https://github.com/fangism/llvm/tree/powerpc-darwin8-rel-3.4

- - - - - - - - - - - - - - - - - -
Clang:
r197577 [Rafael] -- f64 alignment ppc-darwin struct layout
r196981 [me] -- suppress -Q for legacy system assembler

https://github.com/fangism/clang/tree/powerpc-darwin8-rel-3.4


I have already been testing and packaging with these patches, which live
on my 'powerpc-darwin8-rel-3.4' branch (tracks release_34), which were
included in my own port of release-3.4.  My testing of that branch
covers powerpc-darwin8/9, i386-darwin10, x86_64-darwin11 (even though it
is named powerpc-darwin8).  As 3.4.1 approaches, I will re-merge this
branch for testing.

I am also currently using powerpc-darwin8-rel-3.4 as my bootstrapping
C++11 compiler for llvm/clang trunk (3.5).


Iain and I are aware of more powerpc-darwin8 ABI issues that have not yet
been fixed in trunk.  (Some patches exist, but not yet posted.)  As things
stand now, the release I've made comes with this warning that
powerpc-darwin ABI fixes are still to come, so ABI 'breakage' by 'fixing'
is to be expected.

Your darwin-legacy co-maintainer,

David



Hi,

We are now about halfway between the 3.4 and 3.5 releases, and I would
like to start preparing for a 3.4.1 release.  Here is my proposed release
schedule:

Mar 26 - April 9: Identify and backport additional bug fixes to the 3.4 branch.
April 9 - April 18: Testing Phase
April 18: 3.4.1 Release

How you can help:

- If you have any bug fixes you think should be included to 3.4.1, send
 me an email with the SVN revision in trunk and also cc the code owner
 and llvm-commits (or cfe-commits if it is a clang patch).

- Start integrating the 3.4 branch into your project or OS distribution
 to and check for any issues.

- Volunteer as a tester for the testing phase.

Thank you,

Tom
___
LLVM Developers mailing list
llvm...@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



--
David Fang
http://www.csl.cornell.edu/~fang/





--
David Fang
http://www.csl.cornell.edu/~fang/

___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] AArch64: Add command line option to select big or little endian

[Simon Atanasyan]

  Support -EB/-EL is essential for MIPS. But I do not see any problems in 
inverting the aliasing. It looks like we need to change only a couple of lines 
in the `computeTargetTriple()` routine in that case.

http://llvm-reviews.chandlerc.com/D3215
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r205557 - vector [Sema]. Check for proper use of 's' char prefix

[Fariborz Jahanian]

Author: fjahanian
Date: Thu Apr  3 14:43:01 2014
New Revision: 205557

URL: http://llvm.org/viewvc/llvm-project?rev=205557&view=rev
Log:
vector [Sema]. Check for proper use of 's' char prefix
(which indicates vector expression is a string of hex
values) instead of crashing in code gen. // rdar://16492792

Modified:
cfe/trunk/lib/Sema/SemaExprMember.cpp
cfe/trunk/test/Sema/types.c

Modified: cfe/trunk/lib/Sema/SemaExprMember.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExprMember.cpp?rev=205557&r1=205556&r2=205557&view=diff
==
--- cfe/trunk/lib/Sema/SemaExprMember.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExprMember.cpp Thu Apr  3 14:43:01 2014
@@ -292,7 +292,7 @@ CheckExtVectorComponent(Sema &S, QualTyp
 
   // This flag determines whether or not CompName has an 's' char prefix,
   // indicating that it is a string of hex values to be used as vector indices.
-  bool HexSwizzle = *compStr == 's' || *compStr == 'S';
+  bool HexSwizzle = (*compStr == 's' || *compStr == 'S') && compStr[1];
 
   bool HasRepeated = false;
   bool HasIndex[16] = {};

Modified: cfe/trunk/test/Sema/types.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/types.c?rev=205557&r1=205556&r2=205557&view=diff
==
--- cfe/trunk/test/Sema/types.c (original)
+++ cfe/trunk/test/Sema/types.c Thu Apr  3 14:43:01 2014
@@ -73,3 +73,11 @@ typedef int __attribute__ ((ext_vector_t
 enum { e_2 } x3 __attribute__((vector_size(64))); // expected-error {{invalid 
vector element type}}
 
 int x4 __attribute__((ext_vector_type(64)));  // expected-error 
{{'ext_vector_type' attribute only applies to types}}
+
+// rdar://16492792
+typedef __attribute__ ((ext_vector_type(32),__aligned__(32))) unsigned char 
uchar32;
+
+void convert() {
+uchar32 r = 0;
+r.s[ 1234 ] = 1; // expected-error {{illegal vector component name 's'}}
+}


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] AArch64: Add command line option to select big or little endian

[Reid Kleckner]

On Thu, Apr 3, 2014 at 12:55 AM, scott douglass wrote:

>
>   The -EB/-EL options already exist, but effect only the MIPS backend
> (they are silently ignored for ARM target).  This patch introduces
> -mbig-endian/-mlittle-endian as aliases for them.  The options are:
>

OMG.  Those were added last year and it doesn't look like it was reviewed.
 I doubt we can remove them, but let's not encourage them.


>   [this is really just a restatement of what Tim said earlier]
>   1. leave it as it is (possibly removing the tests for -EB/-EL from ARM
> targets)
>   2. invert the aliasing (but that would mean otherwise needless changes
> to the MIPS targets)
>

Let's do this.  It's really not that big of a deal.


>   3. explicitly fault use of -EL/-EB for ARM targets (doesn't seem
> worthwhile)
>
>   Personally I vote for 1 with the -EB/-EL tests removed (or left in).
>
> http://llvm-reviews.chandlerc.com/D3215
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Fix for CUDA codegen due to missing generation of implicit address space conversions

[Justin Holewinski]

  Sorry, just noticed this now.  Does this still need review?

http://llvm-reviews.chandlerc.com/D2462
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [LLVMdev] 3.4.1 Release Plans

[Renato Golin]

On 3 April 2014 17:05, Tim Northover  wrote:
> (and the mangling one myself -- Clang 3.4 was broken and
> in ABI violation in that respect, I don't like providing compatibility
> with broken).

I could accept this argument. Plus, this will create less problems
with external projects than the enum issue.

cheers,
--renato
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [LLVMdev] 3.4.1 Release Plans

[Renato Golin]

On 3 April 2014 19:46, Richard Smith  wrote:
> I really don't think we can change these enumerators.

Same here.


> I think the latter option is the right choice. The pain of preserving the
> ABI belongs with our hard-working branch maintainers (and they always have
> the option of rejecting a change because it would break the ABI).

Absolutely!

--renato
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r205554 - -fms-extensions: Error out on #pragma init_seg

[Reid Kleckner]

Author: rnk
Date: Thu Apr  3 14:04:24 2014
New Revision: 205554

URL: http://llvm.org/viewvc/llvm-project?rev=205554&view=rev
Log:
-fms-extensions: Error out on #pragma init_seg

By ignoring this pragma with a warning, we're essentially miscompiling
the user's program.  WebKit / Blink use this pragma to disable dynamic
initialization and finalization of some static data, and running the
dtors crashes the program.

Error out for now, so that /fallback compiles the TU correctly with
MSVC.  This pragma should be implemented some time this month, and we
can remove this hack.

Added:
cfe/trunk/test/CodeGenCXX/pragma-init_seg.cpp
Modified:
cfe/trunk/include/clang/Parse/Parser.h
cfe/trunk/lib/Parse/ParsePragma.cpp

Modified: cfe/trunk/include/clang/Parse/Parser.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Parse/Parser.h?rev=205554&r1=205553&r2=205554&view=diff
==
--- cfe/trunk/include/clang/Parse/Parser.h (original)
+++ cfe/trunk/include/clang/Parse/Parser.h Thu Apr  3 14:04:24 2014
@@ -154,6 +154,7 @@ class Parser : public CodeCompletionHand
   std::unique_ptr MSDetectMismatchHandler;
   std::unique_ptr MSPointersToMembers;
   std::unique_ptr MSVtorDisp;
+  std::unique_ptr MSInitSeg;
 
   std::unique_ptr CommentSemaHandler;
 

Modified: cfe/trunk/lib/Parse/ParsePragma.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParsePragma.cpp?rev=205554&r1=205553&r2=205554&view=diff
==
--- cfe/trunk/lib/Parse/ParsePragma.cpp (original)
+++ cfe/trunk/lib/Parse/ParsePragma.cpp Thu Apr  3 14:04:24 2014
@@ -124,6 +124,12 @@ struct PragmaMSVtorDisp : public PragmaH
 Token &FirstToken) override;
 };
 
+struct PragmaMSInitSeg : public PragmaHandler {
+  explicit PragmaMSInitSeg() : PragmaHandler("init_seg") {}
+  void HandlePragma(Preprocessor &PP, PragmaIntroducerKind Introducer,
+Token &FirstToken) override;
+};
+
 }  // end namespace
 
 void Parser::initializePragmaHandlers() {
@@ -175,6 +181,8 @@ void Parser::initializePragmaHandlers()
 PP.AddPragmaHandler(MSPointersToMembers.get());
 MSVtorDisp.reset(new PragmaMSVtorDisp());
 PP.AddPragmaHandler(MSVtorDisp.get());
+MSInitSeg.reset(new PragmaMSInitSeg());
+PP.AddPragmaHandler(MSInitSeg.get());
   }
 }
 
@@ -214,6 +222,8 @@ void Parser::resetPragmaHandlers() {
 MSPointersToMembers.reset();
 PP.RemovePragmaHandler(MSVtorDisp.get());
 MSVtorDisp.reset();
+PP.RemovePragmaHandler(MSInitSeg.get());
+MSInitSeg.reset();
   }
 
   PP.RemovePragmaHandler("STDC", FPContractHandler.get());
@@ -1204,6 +1214,14 @@ void PragmaMSVtorDisp::HandlePragma(Prep
   PP.EnterToken(AnnotTok);
 }
 
+void PragmaMSInitSeg::HandlePragma(Preprocessor &PP,
+   PragmaIntroducerKind Introducer,
+   Token &Tok) {
+  unsigned ID = PP.getDiagnostics().getCustomDiagID(
+  DiagnosticsEngine::Error, "'#pragma init_seg' not implemented");
+  PP.Diag(Tok.getLocation(), ID);
+}
+
 /// \brief Handle the Microsoft \#pragma detect_mismatch extension.
 ///
 /// The syntax is:

Added: cfe/trunk/test/CodeGenCXX/pragma-init_seg.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/pragma-init_seg.cpp?rev=205554&view=auto
==
--- cfe/trunk/test/CodeGenCXX/pragma-init_seg.cpp (added)
+++ cfe/trunk/test/CodeGenCXX/pragma-init_seg.cpp Thu Apr  3 14:04:24 2014
@@ -0,0 +1,16 @@
+// RUN: not %clang_cc1 %s -triple=i686-pc-win32 -fms-extensions 
-emit-llvm-only 2>&1 | FileCheck %s
+
+// Reduced from WebKit.
+
+// FIXME: Implement this pragma and test the codegen.  We probably want to
+// completely skip @llvm.global_ctors and just create global function pointers
+// to the initializer with the right section.
+
+// CHECK: '#pragma init_seg' not implemented
+#pragma init_seg(".unwantedstaticinits")
+struct A {
+  A();
+  ~A();
+  int a;
+};
+A a;


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [LLVMdev] 3.4.1 Release Plans

[Richard Smith]

On Thu, Apr 3, 2014 at 1:42 AM, Renato Golin wrote:

> On 3 April 2014 08:51, Richard Smith  wrote:
>
>> It looks like this could be raised to 100% by restoring the prior order
>> of the llvm::Intrinsic enum?
>>
>
> Do we want to go that far?
>
> I'm not against it, I've done this before, but I'm just making sure we
> know what we're getting into.
>

Virtually all the intrinsics have been renumbered. Suppose some
dynamically-linked LLVM frontend tries to create a call to an 'fabs'
intrinsic. If the libLLVM DSO is upgraded from 3.4.0 to 3.4.1, they'll
start creating a 'floor' intrinsic instead. If we want to support people
using the C++ ABI and upgrading an LLVM DSO, I really don't think we can
change these enumerators.

If we keep the order in trunk, we'll have created a rule of which enum
> orders can't be changed (which messes up the code), if we change the stable
> branch only, we'll make it harder to backport and create further dot
> releases.
>
> By all means, now is the time to experiment (on stable branches), so if
> you want the latter, I won't oppose, but the former will face public
> opposition right and left, I predict.
>

I think the latter option is the right choice. The pain of preserving the
ABI belongs with our hard-working branch maintainers (and they always have
the option of rejecting a change because it would break the ABI).
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r205548 - Revert r205436:

[Richard Smith]

On Thu, Apr 3, 2014 at 11:04 AM, Roman Divacky  wrote:

> Author: rdivacky
> Date: Thu Apr  3 13:04:52 2014
> New Revision: 205548
>
> URL: http://llvm.org/viewvc/llvm-project?rev=205548&view=rev
> Log:
> Revert r205436:
>
> Extend the SSE2 comment lexing to AVX2. Only 16byte align when not
> on AVX2.
>
> This provides some 3% speedup when preprocessing gcc.c as a single
> file.
>
>
> The patch is wrong, it always uses SSE2, and when I fix that there's no
> speedup
> at all. I am not sure where the 3% came from previously.
>
> --Thi lie, and those below, will be ignored--
>
> MLex/Lexer.cpp
>
> Modified:
> cfe/trunk/lib/Lex/Lexer.cpp
>
> Modified: cfe/trunk/lib/Lex/Lexer.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/Lexer.cpp?rev=205548&r1=205547&r2=205548&view=diff
>
> ==
> --- cfe/trunk/lib/Lex/Lexer.cpp (original)
> +++ cfe/trunk/lib/Lex/Lexer.cpp Thu Apr  3 13:04:52 2014
> @@ -2251,8 +2251,6 @@ static bool isEndOfBlockCommentWithEscap
>
>  #ifdef __SSE2__
>  #include 
> -#elif __AVX2__
> -#include 
>  #elif __ALTIVEC__
>  #include 
>  #undef bool
> @@ -2308,33 +2306,17 @@ bool Lexer::SkipBlockComment(Token &Resu
>  // If there is a code-completion point avoid the fast scan
> because it
>  // doesn't check for '\0'.
>  !(PP && PP->getCodeCompletionFileLoc() == FileLoc)) {
> -#ifndef __AVX2__
>// While not aligned to a 16-byte boundary.
>while (C != '/' && ((intptr_t)CurPtr & 0x0F) != 0)
>  C = *CurPtr++;
> -#endif
>

Many comments are short; perhaps the speedup came from using vector ops for
short misaligned comments?

   if (C == '/') goto FoundSlash;
>
>  #ifdef __SSE2__
> -#define VECTOR_TYPE __m128i
> -#define SET1_EPI8(v)_mm_set1_epi8(v)
> -#define CMPEQ_EPI8(v1,v2)   _mm_cmpeq_epi8(v1,v2)
> -#define MOVEMASK_EPI8(v)_mm_movemask_epi8(v)
> -#define STEP16
> -#elif __AVX2__
> -#define VECTOR_TYPE __m256i
> -#define SET1_EPI8(v)_mm256_set1_epi8(v)
> -#define CMPEQ_EPI8(v1,v2)   _mm256_cmpeq_epi8(v1,v2)
> -#define MOVEMASK_EPI8(v)_mm256_movemask_epi8(v)
> -#define STEP32
> -#endif
> -
> -#if defined(__SSE2__) || defined(__AVX2__)
> -  VECTOR_TYPE Slashes = SET1_EPI8('/');
> -  while (CurPtr+STEP <= BufferEnd) {
> -int cmp = MOVEMASK_EPI8(CMPEQ_EPI8(*(const VECTOR_TYPE*)CurPtr,
> -Slashes));
> +  __m128i Slashes = _mm_set1_epi8('/');
> +  while (CurPtr+16 <= BufferEnd) {
> +int cmp = _mm_movemask_epi8(_mm_cmpeq_epi8(*(const
> __m128i*)CurPtr,
> +Slashes));
>  if (cmp != 0) {
>// Adjust the pointer to point directly after the first slash.
> It's
>// not necessary to set C here, it will be overwritten at the
> end of
> @@ -2342,13 +2324,8 @@ bool Lexer::SkipBlockComment(Token &Resu
>CurPtr += llvm::countTrailingZeros(cmp) + 1;
>goto FoundSlash;
>  }
> -CurPtr += STEP;
> +CurPtr += 16;
>}
> -#undef VECTOR_TYPE
> -#undef SET1_EPI8
> -#undef CMPEQ_EPI8
> -#undef MOVEMASK_EPI8
> -#undef STEP
>  #elif __ALTIVEC__
>__vector unsigned char Slashes = {
>  '/', '/', '/', '/',  '/', '/', '/', '/',
>
>
> ___
> cfe-commits mailing list
> cfe-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Add support for optimization reports.

[Richard Smith]

On Thu, Apr 3, 2014 at 11:14 AM, Diego Novillo  wrote:

> On Thu, Apr 3, 2014 at 2:04 PM, Richard Smith 
> wrote:
> >
> >   Looks mostly fine. I'm concerned about a -R option affecting the debug
> info that ends up in the object file. I'm also concerned that the
> diagnostic quality will degrade if you build with no debug info enabled at
> all.
> >   It seems to me that if we can afford the IR size increase from
> `-dwarf-column-info`, we can afford the IR size increase from storing the
> frontend's notion of 'source location' into the IR, and that would allow us
> to do the right thing without `-g` and to deal properly with macro
> expansions etc. (It's only 32 bits per location...)
>
> But we *do* enable line table information when -Rpass= is given. We
> also enable column information, so all we alter is that we'll be
> emitting dwarf LOCs in final codegen.
>
> If you don't think dwarf LOC generation is fine, we could do one of two
> things:
>
> 1- We already have srcloc metadata. It would be a matter of generating
> them on every IR node when -Rpass= is used.
> 2- If -Rpass= is used but we found it necessary to force line and
> column table generation, we could note that so that the code generator
> out of the back end does not emit DWARF LOCs. Eric, if this doesn't
> sound silly to you, how hard would it be?


I think either of these could work. Option 1 seems cleaner to me, and has
the advantage of preserving macro and inclusion information. We could
probably piggyback on the debug location emission code to emit the !srcloc
in the right places.

> 
> > Comment at: lib/Frontend/CompilerInvocation.cpp:523
> > @@ -522,1 +522,3 @@
> >
> > +  if (Arg *A = Args.getLastArg(OPT_Rpass_EQ)) {
> > +StringRef Val = A->getValue();
> > 
> > ... so we take the last -Rpass= option, rather than combining them? I
> find that unintuitive, FWIW, but maybe this is the right model.
>
> I could combine them with '|'. Perhaps, that's a more intuitive model
> for the command line. How's that sound?


Sounds good to me.
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Add support for optimization reports.

[Diego Novillo]

On Apr 3, 2014 2:14 PM, "Diego Novillo"  wrote:

>
> But we *do* enable line table information when -Rpass= is given. We
> also enable column information, so all we alter is that we'll be
> emitting dwarf LOCs in final codegen.
>
> If you don't think dwarf LOC generation is fine, we could do one of two
things:
>
> 1- We already have srcloc metadata. It would be a matter of generating
> them on every IR node when -Rpass= is used.

Though, note that this would be a waste since we would have to replicate
the exact same mechanism that -gline-tables-only and -gcolumn-info
implement. For debug build, we'd effectively double the memory used to
store this info.

I have a slight preference for option 2.

> 2- If -Rpass= is used but we found it necessary to force line and
> column table generation, we could note that so that the code generator
> out of the back end does not emit DWARF LOCs. Eric, if this doesn't
> sound silly to you, how hard would it be?
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Add support for optimization reports.

[Diego Novillo]

On Thu, Apr 3, 2014 at 2:04 PM, Richard Smith  wrote:
>
>   Looks mostly fine. I'm concerned about a -R option affecting the debug info 
> that ends up in the object file. I'm also concerned that the diagnostic 
> quality will degrade if you build with no debug info enabled at all.
>   It seems to me that if we can afford the IR size increase from 
> `-dwarf-column-info`, we can afford the IR size increase from storing the 
> frontend's notion of 'source location' into the IR, and that would allow us 
> to do the right thing without `-g` and to deal properly with macro expansions 
> etc. (It's only 32 bits per location...)

But we *do* enable line table information when -Rpass= is given. We
also enable column information, so all we alter is that we'll be
emitting dwarf LOCs in final codegen.

If you don't think dwarf LOC generation is fine, we could do one of two things:

1- We already have srcloc metadata. It would be a matter of generating
them on every IR node when -Rpass= is used.
2- If -Rpass= is used but we found it necessary to force line and
column table generation, we could note that so that the code generator
out of the back end does not emit DWARF LOCs. Eric, if this doesn't
sound silly to you, how hard would it be?

> 
> Comment at: lib/Frontend/CompilerInvocation.cpp:523
> @@ -522,1 +522,3 @@
>
> +  if (Arg *A = Args.getLastArg(OPT_Rpass_EQ)) {
> +StringRef Val = A->getValue();
> 
> ... so we take the last -Rpass= option, rather than combining them? I find 
> that unintuitive, FWIW, but maybe this is the right model.

I could combine them with '|'. Perhaps, that's a more intuitive model
for the command line. How's that sound?


Diego.

___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [LLVMdev] 3.4.1 Release Plans

[Rafael Espíndola]

On 28 March 2014 22:19, David Fang  wrote:
> Hi Tom,
> Thanks for doing this.  I would like to nominate the following
> patches to be backported to release_34 (3.4.1).
>
> LLVM:
> r196168, r196970 -- .weak_definition vs. .weak_def_can_be_hidden
> (r196168 is Rafael's, 970 is mine)
> r196987, r197572, r197574 -- [ABI] f64,i64 alignment on ppc-darwin
> all Rafael's, 196987 is a cosmetic change that made it easier
> to apply the others.
> r198744 [Iain Sandoe] -- FDE cross-section relocs for EH
>
> https://github.com/fangism/llvm/tree/powerpc-darwin8-rel-3.4
>
> - - - - - - - - - - - - - - - - - -
> Clang:
> r197577 [Rafael] -- f64 alignment ppc-darwin struct layout
> r196981 [me] -- suppress -Q for legacy system assembler
>
> https://github.com/fangism/clang/tree/powerpc-darwin8-rel-3.4
>

For what it is worth, I think this is fine. The changes are either low
risk for being ppc-darwin local or are simple cleanups.

Cheers,
Rafael
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r205548 - Revert r205436:

[Roman Divacky]

Author: rdivacky
Date: Thu Apr  3 13:04:52 2014
New Revision: 205548

URL: http://llvm.org/viewvc/llvm-project?rev=205548&view=rev
Log:
Revert r205436:

Extend the SSE2 comment lexing to AVX2. Only 16byte align when not on 
AVX2.

This provides some 3% speedup when preprocessing gcc.c as a single file.


The patch is wrong, it always uses SSE2, and when I fix that there's no speedup
at all. I am not sure where the 3% came from previously.

--Thi lie, and those below, will be ignored--

MLex/Lexer.cpp

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

Modified: cfe/trunk/lib/Lex/Lexer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/Lexer.cpp?rev=205548&r1=205547&r2=205548&view=diff
==
--- cfe/trunk/lib/Lex/Lexer.cpp (original)
+++ cfe/trunk/lib/Lex/Lexer.cpp Thu Apr  3 13:04:52 2014
@@ -2251,8 +2251,6 @@ static bool isEndOfBlockCommentWithEscap
 
 #ifdef __SSE2__
 #include 
-#elif __AVX2__
-#include 
 #elif __ALTIVEC__
 #include 
 #undef bool
@@ -2308,33 +2306,17 @@ bool Lexer::SkipBlockComment(Token &Resu
 // If there is a code-completion point avoid the fast scan because it
 // doesn't check for '\0'.
 !(PP && PP->getCodeCompletionFileLoc() == FileLoc)) {
-#ifndef __AVX2__
   // While not aligned to a 16-byte boundary.
   while (C != '/' && ((intptr_t)CurPtr & 0x0F) != 0)
 C = *CurPtr++;
-#endif
 
   if (C == '/') goto FoundSlash;
 
 #ifdef __SSE2__
-#define VECTOR_TYPE __m128i
-#define SET1_EPI8(v)_mm_set1_epi8(v)
-#define CMPEQ_EPI8(v1,v2)   _mm_cmpeq_epi8(v1,v2)
-#define MOVEMASK_EPI8(v)_mm_movemask_epi8(v)
-#define STEP16
-#elif __AVX2__
-#define VECTOR_TYPE __m256i
-#define SET1_EPI8(v)_mm256_set1_epi8(v)
-#define CMPEQ_EPI8(v1,v2)   _mm256_cmpeq_epi8(v1,v2)
-#define MOVEMASK_EPI8(v)_mm256_movemask_epi8(v)
-#define STEP32
-#endif
-
-#if defined(__SSE2__) || defined(__AVX2__)
-  VECTOR_TYPE Slashes = SET1_EPI8('/');
-  while (CurPtr+STEP <= BufferEnd) {
-int cmp = MOVEMASK_EPI8(CMPEQ_EPI8(*(const VECTOR_TYPE*)CurPtr,
-Slashes));
+  __m128i Slashes = _mm_set1_epi8('/');
+  while (CurPtr+16 <= BufferEnd) {
+int cmp = _mm_movemask_epi8(_mm_cmpeq_epi8(*(const __m128i*)CurPtr,
+Slashes));
 if (cmp != 0) {
   // Adjust the pointer to point directly after the first slash. It's
   // not necessary to set C here, it will be overwritten at the end of
@@ -2342,13 +2324,8 @@ bool Lexer::SkipBlockComment(Token &Resu
   CurPtr += llvm::countTrailingZeros(cmp) + 1;
   goto FoundSlash;
 }
-CurPtr += STEP;
+CurPtr += 16;
   }
-#undef VECTOR_TYPE
-#undef SET1_EPI8
-#undef CMPEQ_EPI8
-#undef MOVEMASK_EPI8
-#undef STEP
 #elif __ALTIVEC__
   __vector unsigned char Slashes = {
 '/', '/', '/', '/',  '/', '/', '/', '/',


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r205543 - Teach getTemplateInstantiationPattern to deal with generic lambdas.

[Richard Smith]

Thanks!


On Thu, Apr 3, 2014 at 9:32 AM, Faisal Vali  wrote:

> Author: faisalv
> Date: Thu Apr  3 11:32:21 2014
> New Revision: 205543
>
> URL: http://llvm.org/viewvc/llvm-project?rev=205543&view=rev
> Log:
> Teach getTemplateInstantiationPattern to deal with generic lambdas.
>
> No functionality change.
>
> When determining the pattern for instantiating a generic lambda call
> operator specialization - we must not go drilling down for the 'prototype'
> (i.e. as written) pattern - rather we must use our partially transformed
>  pattern (whose DeclRefExprs are wired correctly to any enclosing lambda's
> decls that should be mapped correctly in a local instantiation scope) that
> is the templated pattern of the specialization's primary template (even
> though the primary template might be instantiated from a 'prototype'
> member-template).  Previously, the drilling down was haltted by marking the
> instantiated-from primary template as a member-specialization (incorrectly).
>
> This prompted Richard to remark (
> http://llvm-reviews.chandlerc.com/D1784?id=4687#inline-10272)
> "It's a bit nasty to (essentially) set this bit incorrectly. Can you put
> the check into getTemplateInstantiationPattern instead?"
>
> In my reckless youth, I chose to ignore that comment.  With the passage of
> time, I have come to learn the value of bowing to the will of the angry
> Gods ;)
>
>
>
> Modified:
> cfe/trunk/include/clang/AST/ASTLambda.h
> cfe/trunk/lib/AST/Decl.cpp
> cfe/trunk/lib/Sema/SemaTemplateInstantiate.cpp
>
> Modified: cfe/trunk/include/clang/AST/ASTLambda.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTLambda.h?rev=205543&r1=205542&r2=205543&view=diff
>
> ==
> --- cfe/trunk/include/clang/AST/ASTLambda.h (original)
> +++ cfe/trunk/include/clang/AST/ASTLambda.h Thu Apr  3 11:32:21 2014
> @@ -36,9 +36,9 @@ inline bool isLambdaCallOperator(const D
>return isLambdaCallOperator(cast(DC));
>  }
>
> -inline bool isGenericLambdaCallOperatorSpecialization(CXXMethodDecl *MD) {
> +inline bool isGenericLambdaCallOperatorSpecialization(const CXXMethodDecl
> *MD) {
>if (!MD) return false;
> -  CXXRecordDecl *LambdaClass = MD->getParent();
> +  const CXXRecordDecl *LambdaClass = MD->getParent();
>if (LambdaClass && LambdaClass->isGenericLambda())
>  return isLambdaCallOperator(MD) &&
>  MD->isFunctionTemplateSpecialization();
>
> Modified: cfe/trunk/lib/AST/Decl.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Decl.cpp?rev=205543&r1=205542&r2=205543&view=diff
>
> ==
> --- cfe/trunk/lib/AST/Decl.cpp (original)
> +++ cfe/trunk/lib/AST/Decl.cpp Thu Apr  3 11:32:21 2014
> @@ -13,6 +13,7 @@
>
>  #include "clang/AST/Decl.h"
>  #include "clang/AST/ASTContext.h"
> +#include "clang/AST/ASTLambda.h"
>  #include "clang/AST/ASTMutationListener.h"
>  #include "clang/AST/Attr.h"
>  #include "clang/AST/DeclCXX.h"
> @@ -2830,14 +2831,34 @@ FunctionDecl *FunctionDecl::getTemplateI
>// Handle class scope explicit specialization special case.
>if (getTemplateSpecializationKind() == TSK_ExplicitSpecialization)
>  return getClassScopeSpecializationPattern();
> -
> +
> +  // If this is a generic lambda call operator specialization, its
> +  // instantiation pattern is always its primary template's pattern
> +  // even if its primary template was instantiated from another
> +  // member template (which happens with nested generic lambdas).
> +  // Since a lambda's call operator's body is transformed eagerly,
> +  // we don't have to go hunting for a prototype definition template
> +  // (i.e. instantiated-from-member-template) to use as an instantiation
> +  // pattern.
> +
> +  if (isGenericLambdaCallOperatorSpecialization(
> +  dyn_cast(this))) {
> +assert(getPrimaryTemplate() && "A generic lambda specialization must
> be "
> +   "generated from a primary call
> operator "
> +   "template");
> +assert(getPrimaryTemplate()->getTemplatedDecl()->getBody() &&
> +   "A generic lambda call operator template must always have a
> body - "
> +   "even if instantiated from a prototype (i.e. as written)
> member "
> +   "template");
> +return getPrimaryTemplate()->getTemplatedDecl();
> +  }
> +
>if (FunctionTemplateDecl *Primary = getPrimaryTemplate()) {
>  while (Primary->getInstantiatedFromMemberTemplate()) {
>// If we have hit a point where the user provided a specialization
> of
>// this template, we're done looking.
>if (Primary->isMemberSpecialization())
>  break;
> -
>Primary = Primary->getInstantiatedFromMemberTemplate();
>  }
>
>
> Modified: cfe/trunk/lib/Sema/SemaTemplateInstantiate.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/

Re: r205506 - [OPENMP] Small update for C++11

[Richard Smith]

On Wed, Apr 2, 2014 at 7:55 PM, Alexey Bataev  wrote:

> Author: abataev
> Date: Wed Apr  2 21:55:46 2014
> New Revision: 205506
>
> URL: http://llvm.org/viewvc/llvm-project?rev=205506&view=rev
> Log:
> [OPENMP] Small update for C++11
>
> Modified:
> cfe/trunk/lib/Sema/TreeTransform.h
> cfe/trunk/lib/Serialization/ASTWriterStmt.cpp
>
> Modified: cfe/trunk/lib/Sema/TreeTransform.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/TreeTransform.h?rev=205506&r1=205505&r2=205506&view=diff
>
> ==
> --- cfe/trunk/lib/Sema/TreeTransform.h (original)
> +++ cfe/trunk/lib/Sema/TreeTransform.h Wed Apr  2 21:55:46 2014
> @@ -6439,10 +6439,8 @@ OMPClause *
>  TreeTransform::TransformOMPCopyinClause(OMPCopyinClause *C) {
>llvm::SmallVector Vars;
>Vars.reserve(C->varlist_size());
> -  for (OMPCopyinClause::varlist_iterator I = C->varlist_begin(),
> - E = C->varlist_end();
> -   I != E; ++I) {
> -ExprResult EVar = getDerived().TransformExpr(cast(*I));
> +  for (auto *I : C->varlists()) {
>

This is not an iterator, so should not be named I.


> +ExprResult EVar = getDerived().TransformExpr(cast(I));
>  if (EVar.isInvalid())
>return 0;
>  Vars.push_back(EVar.take());
>
> Modified: cfe/trunk/lib/Serialization/ASTWriterStmt.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTWriterStmt.cpp?rev=205506&r1=205505&r2=205506&view=diff
>
> ==
> --- cfe/trunk/lib/Serialization/ASTWriterStmt.cpp (original)
> +++ cfe/trunk/lib/Serialization/ASTWriterStmt.cpp Wed Apr  2 21:55:46 2014
> @@ -1719,10 +1719,8 @@ void OMPClauseWriter::VisitOMPSharedClau
>  void OMPClauseWriter::VisitOMPCopyinClause(OMPCopyinClause *C) {
>Record.push_back(C->varlist_size());
>Writer->Writer.AddSourceLocation(C->getLParenLoc(), Record);
> -  for (OMPCopyinClause::varlist_iterator I = C->varlist_begin(),
> - E = C->varlist_end();
> -   I != E; ++I)
> -Writer->Writer.AddStmt(*I);
> +  for (auto *I : C->varlists())
>

Likewise.


> +Writer->Writer.AddStmt(I);
>  }
>
>
>  
> //===--===//
>
>
> ___
> cfe-commits mailing list
> cfe-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Add support for optimization reports.

[Richard Smith]

  Looks mostly fine. I'm concerned about a -R option affecting the debug info 
that ends up in the object file. I'm also concerned that the diagnostic quality 
will degrade if you build with no debug info enabled at all.

  It seems to me that if we can afford the IR size increase from 
`-dwarf-column-info`, we can afford the IR size increase from storing the 
frontend's notion of 'source location' into the IR, and that would allow us to 
do the right thing without `-g` and to deal properly with macro expansions etc. 
(It's only 32 bits per location...)



Comment at: lib/Driver/Tools.cpp:3394
@@ +3393,3 @@
+// remarks.
+CmdArgs.push_back("-dwarf-column-info");
+A->render(Args, CmdArgs);

I don't think it's OK for a diagnostic option to affect the contents of the 
object file.


Comment at: lib/Frontend/CompilerInvocation.cpp:523
@@ -522,1 +522,3 @@
 
+  if (Arg *A = Args.getLastArg(OPT_Rpass_EQ)) {
+StringRef Val = A->getValue();

... so we take the last -Rpass= option, rather than combining them? I find that 
unintuitive, FWIW, but maybe this is the right model.


http://llvm-reviews.chandlerc.com/D3226
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Adding type info for f16c floating-point type

[Yunzhong Gao]

  A fourth ping...

http://llvm-reviews.chandlerc.com/D2750
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] OpenCL - use AST PrintingPolicy when emitting kernel arg metadata

[Fraser Cormack]

Ah yes, sorry about that! An updated patch is attached.

On 03/04/14 15:50, Joey Gouly wrote:

If you add a test, it LGTM!

-Original Message-
From: cfe-commits-boun...@cs.uiuc.edu
[mailto:cfe-commits-boun...@cs.uiuc.edu] On Behalf Of Fraser Cormack
Sent: 03 April 2014 12:04
To: llvm cfe
Subject: [PATCH] OpenCL - use AST PrintingPolicy when emitting kernel arg
metadata

Hi,

This patch uses the AST PrintingPolicy when emitting OpenCL kernel arg
metadata in order to pretty print the 'half' type, if supported.

Cheers,
Fraser




--
Fraser Cormack
Compiler Developer
Codeplay Software Ltd
45 York Place, Edinburgh, EH1 3HP
Tel: 0131 466 0503
Fax: 0131 557 6600
Website: http://www.codeplay.com
Twitter: https://twitter.com/codeplaysoft

This email and any attachments may contain confidential and /or privileged 
information and  is for use  by the addressee only. If you are not the intended 
recipient, please notify Codeplay Software Ltd immediately and delete the 
message from your computer. You may not copy or forward it,or use or disclose 
its contents to any other person. Any views or other information in this 
message which do not relate to our business are not authorized by Codeplay 
software Ltd, nor does this message form part of any contract unless so stated.
As internet communications are capable of data corruption Codeplay Software Ltd 
does not accept any responsibility for any changes made to this message after 
it was sent. Please note that Codeplay Software Ltd does not accept any 
liability or responsibility for viruses and it is your responsibility to scan 
any attachments.
Company registered in England and Wales, number: 04567874
Registered office: 81 Linkfield Street, Redhill RH1 6BY

Index: lib/CodeGen/CodeGenFunction.cpp
===
--- lib/CodeGen/CodeGenFunction.cpp	(revision 205539)
+++ lib/CodeGen/CodeGenFunction.cpp	(working copy)
@@ -338,6 +338,7 @@
   // Create MDNodes that represent the kernel arg metadata.
   // Each MDNode is a list in the form of "key", N number of values which is
   // the same number of values as their are kernel arguments.
+  const PrintingPolicy &Policy = ASTCtx.getPrintingPolicy();
 
   // MDNode for the kernel argument address space qualifiers.
   SmallVector addressQuals;
@@ -372,7 +373,8 @@
 pointeeTy.getAddressSpace(;
 
   // Get argument type name.
-  std::string typeName = pointeeTy.getUnqualifiedType().getAsString() + "*";
+  std::string typeName =
+  pointeeTy.getUnqualifiedType().getAsString(Policy) + "*";
 
   // Turn "unsigned type" to "utype"
   std::string::size_type pos = typeName.find("unsigned");
@@ -398,7 +400,7 @@
   addressQuals.push_back(Builder.getInt32(AddrSpc));
 
   // Get argument type name.
-  std::string typeName = ty.getUnqualifiedType().getAsString();
+  std::string typeName = ty.getUnqualifiedType().getAsString(Policy);
 
   // Turn "unsigned type" to "utype"
   std::string::size_type pos = typeName.find("unsigned");
Index: test/CodeGenOpenCL/kernel-arg-info.cl
===
--- test/CodeGenOpenCL/kernel-arg-info.cl	(revision 205539)
+++ test/CodeGenOpenCL/kernel-arg-info.cl	(working copy)
@@ -18,3 +18,11 @@
 // CHECK: metadata !{metadata !"kernel_arg_type", metadata !"image1d_t", metadata !"image2d_t", metadata !"image2d_array_t"}
 // CHECK: metadata !{metadata !"kernel_arg_type_qual", metadata !"", metadata !"", metadata !""}
 // CHECK: metadata !{metadata !"kernel_arg_name", metadata !"img1", metadata !"img2", metadata !"img3"}
+
+kernel void foo3(__global half * X) {
+}
+// CHECK: metadata !{metadata !"kernel_arg_addr_space", i32 1}
+// CHECK: metadata !{metadata !"kernel_arg_access_qual", metadata !"none"}
+// CHECK: metadata !{metadata !"kernel_arg_type", metadata !"half*"}
+// CHECK: metadata !{metadata !"kernel_arg_type_qual", metadata !""}
+// CHECK: metadata !{metadata !"kernel_arg_name", metadata !"X"}
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r205436 - Extend the SSE2 comment lexing to AVX2. Only 16byte align when not on AVX2.

[Roman Divacky]

On Thu, Apr 03, 2014 at 10:13:15AM +0100, Jay Foad wrote:
> Hi Roman,
> 
> On 2 April 2014 18:27, Roman Divacky  wrote:
> >  #ifdef __SSE2__
> > -  __m128i Slashes = _mm_set1_epi8('/');
> > -  while (CurPtr+16 <= BufferEnd) {
> > -int cmp = _mm_movemask_epi8(_mm_cmpeq_epi8(*(const __m128i*)CurPtr,
> > -Slashes));
> > +#define VECTOR_TYPE __m128i
> > +#define SET1_EPI8(v)_mm_set1_epi8(v)
> > +#define CMPEQ_EPI8(v1,v2)   _mm_cmpeq_epi8(v1,v2)
> > +#define MOVEMASK_EPI8(v)_mm_movemask_epi8(v)
> > +#define STEP16
> > +#elif __AVX2__
> > +#define VECTOR_TYPE __m256i
> > +#define SET1_EPI8(v)_mm256_set1_epi8(v)
> > +#define CMPEQ_EPI8(v1,v2)   _mm256_cmpeq_epi8(v1,v2)
> > +#define MOVEMASK_EPI8(v)_mm256_movemask_epi8(v)
> > +#define STEP32
> > +#endif
> 
> Surely any machine with AVX2 also has SSE2, and if both are defined
> then your code will prefer to use the SSE2 intrinsics. This doesn't
> seem right. Am I missing something?

You're absolutely right. I fixed that and rebenchmarked and now
there's no difference at all. I have no explanation for the previous
3% speedup (but it was proved at 95% significance over 10 samples).

I'll revert my commit. Sorry for the noise.

Roman
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Add support for optimization reports.

[Diego Novillo]

On Wed, Apr 2, 2014 at 10:03 PM, Diego Novillo  wrote:
> On Mon, Mar 31, 2014 at 8:05 PM, Quentin Colombet  wrote:
>
>> 
>> Comment at: lib/CodeGen/CodeGenAction.cpp:419
>> @@ -394,1 +418,3 @@
>> +  OptimizationReportHandler(cast(DI));
>> +return;
>>default:
>> 
>> This does not follow the same pattern as the previous handler, i.e., with 
>> the fall through setting the DiagID to use the default handler (the 
>> ComputeDiagID part etc.).
>>
>> My guess is we want to push the check of 
>> CodeGenOpts.OptimizationReportPattern into OptimizationReportHandler and 
>> check the return of that.
>>
>> If we do not want to follow the same pattern, we should comment on that. 
>> Indeed, I think it is important to explain why we are not reporting anything 
>> when CodeGenOpts.OptimizationReportPattern is not set.
>
> I've been thinking about this a bit, and I'm not completely sure how
> to handle it.  My initial idea with these optimization remarks is to
> allow clients to emit them unconditionally, and allow the diagnostic
> machinery check whether the report should be generated.
>
> In the inliner, you'll see that to generate a remark, it calls the
> diagnostic directly. If there is a regexp pattern given and it matches
> the word 'inline', then it gets emitted.
>
> The downside of this is that when the front end is not involved (say,
> when using opt) the remark is always emitted. So, I think I'm not
> going to be able to do this unconditionally. However, I would like to
> avoid adding a cl::opt flag to every pass we want to add optimization
> remarks to.
>
> Another thing that I'm doing is using the pass's DEBUG_NAME as the
> optimization name. I suppose that's OK, but it may not be. I'm open to
> any suggestions on how to expose this to 'opt'.

I've been thinking about the following approach.

Add a -pass-remarks=regexp to 'opt'. When the driver sees
-Rpass=regexp, it adds -pass-remarks=regexp to the backend command
line. I then implement some supporting code similar to
lib/Support/Debug.cpp. Passes call this support routine, which in turn
will generate a real diagnostic only if the regexp matches the given
pass name.

This way, the low-level diagnostic handlers can use the same structure
as the others and we get a way of specifying optimization reports from
the driver and opt.

How does that sound?


Diego.
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r205543 - Teach getTemplateInstantiationPattern to deal with generic lambdas.

[Faisal Vali]

Author: faisalv
Date: Thu Apr  3 11:32:21 2014
New Revision: 205543

URL: http://llvm.org/viewvc/llvm-project?rev=205543&view=rev
Log:
Teach getTemplateInstantiationPattern to deal with generic lambdas.

No functionality change.

When determining the pattern for instantiating a generic lambda call operator 
specialization - we must not go drilling down for the 'prototype' (i.e. as 
written) pattern - rather we must use our partially transformed  pattern (whose 
DeclRefExprs are wired correctly to any enclosing lambda's decls that should be 
mapped correctly in a local instantiation scope) that is the templated pattern 
of the specialization's primary template (even though the primary template 
might be instantiated from a 'prototype' member-template).  Previously, the 
drilling down was haltted by marking the instantiated-from primary template as 
a member-specialization (incorrectly). 

This prompted Richard to remark 
(http://llvm-reviews.chandlerc.com/D1784?id=4687#inline-10272) 
"It's a bit nasty to (essentially) set this bit incorrectly. Can you put the 
check into getTemplateInstantiationPattern instead?"

In my reckless youth, I chose to ignore that comment.  With the passage of 
time, I have come to learn the value of bowing to the will of the angry Gods ;) 



Modified:
cfe/trunk/include/clang/AST/ASTLambda.h
cfe/trunk/lib/AST/Decl.cpp
cfe/trunk/lib/Sema/SemaTemplateInstantiate.cpp

Modified: cfe/trunk/include/clang/AST/ASTLambda.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTLambda.h?rev=205543&r1=205542&r2=205543&view=diff
==
--- cfe/trunk/include/clang/AST/ASTLambda.h (original)
+++ cfe/trunk/include/clang/AST/ASTLambda.h Thu Apr  3 11:32:21 2014
@@ -36,9 +36,9 @@ inline bool isLambdaCallOperator(const D
   return isLambdaCallOperator(cast(DC));
 }
 
-inline bool isGenericLambdaCallOperatorSpecialization(CXXMethodDecl *MD) {
+inline bool isGenericLambdaCallOperatorSpecialization(const CXXMethodDecl *MD) 
{
   if (!MD) return false;
-  CXXRecordDecl *LambdaClass = MD->getParent();
+  const CXXRecordDecl *LambdaClass = MD->getParent();
   if (LambdaClass && LambdaClass->isGenericLambda())
 return isLambdaCallOperator(MD) && 
 MD->isFunctionTemplateSpecialization();

Modified: cfe/trunk/lib/AST/Decl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Decl.cpp?rev=205543&r1=205542&r2=205543&view=diff
==
--- cfe/trunk/lib/AST/Decl.cpp (original)
+++ cfe/trunk/lib/AST/Decl.cpp Thu Apr  3 11:32:21 2014
@@ -13,6 +13,7 @@
 
 #include "clang/AST/Decl.h"
 #include "clang/AST/ASTContext.h"
+#include "clang/AST/ASTLambda.h"
 #include "clang/AST/ASTMutationListener.h"
 #include "clang/AST/Attr.h"
 #include "clang/AST/DeclCXX.h"
@@ -2830,14 +2831,34 @@ FunctionDecl *FunctionDecl::getTemplateI
   // Handle class scope explicit specialization special case.
   if (getTemplateSpecializationKind() == TSK_ExplicitSpecialization)
 return getClassScopeSpecializationPattern();
-
+  
+  // If this is a generic lambda call operator specialization, its 
+  // instantiation pattern is always its primary template's pattern
+  // even if its primary template was instantiated from another 
+  // member template (which happens with nested generic lambdas).
+  // Since a lambda's call operator's body is transformed eagerly, 
+  // we don't have to go hunting for a prototype definition template 
+  // (i.e. instantiated-from-member-template) to use as an instantiation 
+  // pattern.
+
+  if (isGenericLambdaCallOperatorSpecialization(
+  dyn_cast(this))) {
+assert(getPrimaryTemplate() && "A generic lambda specialization must be "
+   "generated from a primary call operator "
+   "template");
+assert(getPrimaryTemplate()->getTemplatedDecl()->getBody() &&
+   "A generic lambda call operator template must always have a body - "
+   "even if instantiated from a prototype (i.e. as written) member "
+   "template");
+return getPrimaryTemplate()->getTemplatedDecl();
+  }
+  
   if (FunctionTemplateDecl *Primary = getPrimaryTemplate()) {
 while (Primary->getInstantiatedFromMemberTemplate()) {
   // If we have hit a point where the user provided a specialization of
   // this template, we're done looking.
   if (Primary->isMemberSpecialization())
 break;
-  
   Primary = Primary->getInstantiatedFromMemberTemplate();
 }
 

Modified: cfe/trunk/lib/Sema/SemaTemplateInstantiate.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaTemplateInstantiate.cpp?rev=205543&r1=205542&r2=205543&view=diff
==
--- cfe/trunk/lib/Sema/SemaTemplateInstantiate.cpp (original)
+++ cfe/trunk/lib/Se

Re: [LLVMdev] 3.4.1 Release Plans

[Tim Northover]

> OK, I know Tim has replied to this thread, but I just want to make sure
> there are no surprises.

I am watching, and broadly support the inclusion of the NEON
improvements (and the mangling one myself -- Clang 3.4 was broken and
in ABI violation in that respect, I don't like providing compatibility
with broken).

But I definitely wouldn't press for any special ABI consideration to
be granted to us at the LLVM level. I was also waiting for some
general consensus on the ABI issue before weighing in.

Cheers.

Tim.
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [LLVMdev] 3.4.1 Release Plans

[Tom Stellard]

On Thu, Apr 03, 2014 at 04:31:31PM +0100, Renato Golin wrote:
> On 3 April 2014 15:51, Tom Stellard  wrote:
> > 1. Rename the intrinsics so that they end up at the bottom of the list.
> > These are only accessed via clang builtins, so the names should matter,
> > right?
> 
> No, that would create API compatibility. We don't know if there is any
> external tool that uses the same generated files/enums.
> 

I thought these were new intrinsics, so there would be no external tools
that relied on specific names.

> 
> > 2. Don't generate the intrinsic enum at buildtime.  Generate it once
> > offline and check it in and then modify the build system to use this
> > copy.
> 
> This would work well on release branches, but not on trunk, as that's
> the whole point of TableGen. I can't think of an easy way to make it
> work for further point releases, though.
> 

I'm suggesting doing this on the release branch only.  If I understand
correctly, this is essentially what you are suggesting below, right?

> 
> > 3. Don't add these intrinsics.
> 
> That would be the easiest, but maybe not the best solution. As I said
> before, this is the first stable dot release we do and I don't think
> it's going to be perfect. We'll probably get many things wrong and
> people shouldn't be afraid of experimentation to the detriment of
> early commitment to defective procedures.
> 
> We could create an extra step of the dot release to move all new enum
> fields to the bottom on the generated files to keep compatibility.
> Further dot releases will have to kludge new patches on top of those
> modified branches. If that doens't work, from release 3.5 we won't
> change the branch 3.4 any more, so whatever we do wrong, we can easily
> discard and try again.
> 
> 
> > Also, before we get too far into this, I would really like to get
> > approval from Tim Northover (AArch64 code owner) and Evan Cheng (ARM
> > code owner) for merging these patches.  Can you ping them and ask them
> > to reply on list with their response.
> 
> I think we need to get our procedure settled first.
> 
> The probability of the patches being accepted by the overall community
> but refused by the code owners is very small, especially with so many
> core developers copied and replying to this thread (and other past
> threads). So, getting the approval of the code owners would be a good
> thing, but not at this stage, I think.
> 

OK, I know Tim has replied to this thread, but I just want to make sure
there are no surprises.  The subject of the email doesn't make it clear
that we are discussing merging these specific patches into the stable
branch, and I want to make sure all interested parties, especially code
owners have a chance to respond.

-Tom

> So far, the only worrying issues I have seen, as mentioned by
> Jiangning before, were:
> 
> * int64_t mangling changes
> * llvm::intrinsic enum order
> 
> My personal opinion is that the uint64_t should not be applied, since
> it changes the mangling in respect to 3.4, and the enum should be
> fixed (by moving the new ones to the end on the generated files).
> 
> cheers,
> --renato
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [LLVMdev] 3.4.1 Release Plans

[Renato Golin]

On 3 April 2014 15:51, Tom Stellard  wrote:
> 1. Rename the intrinsics so that they end up at the bottom of the list.
> These are only accessed via clang builtins, so the names should matter,
> right?

No, that would create API compatibility. We don't know if there is any
external tool that uses the same generated files/enums.


> 2. Don't generate the intrinsic enum at buildtime.  Generate it once
> offline and check it in and then modify the build system to use this
> copy.

This would work well on release branches, but not on trunk, as that's
the whole point of TableGen. I can't think of an easy way to make it
work for further point releases, though.


> 3. Don't add these intrinsics.

That would be the easiest, but maybe not the best solution. As I said
before, this is the first stable dot release we do and I don't think
it's going to be perfect. We'll probably get many things wrong and
people shouldn't be afraid of experimentation to the detriment of
early commitment to defective procedures.

We could create an extra step of the dot release to move all new enum
fields to the bottom on the generated files to keep compatibility.
Further dot releases will have to kludge new patches on top of those
modified branches. If that doens't work, from release 3.5 we won't
change the branch 3.4 any more, so whatever we do wrong, we can easily
discard and try again.


> Also, before we get too far into this, I would really like to get
> approval from Tim Northover (AArch64 code owner) and Evan Cheng (ARM
> code owner) for merging these patches.  Can you ping them and ask them
> to reply on list with their response.

I think we need to get our procedure settled first.

The probability of the patches being accepted by the overall community
but refused by the code owners is very small, especially with so many
core developers copied and replying to this thread (and other past
threads). So, getting the approval of the code owners would be a good
thing, but not at this stage, I think.

So far, the only worrying issues I have seen, as mentioned by
Jiangning before, were:

* int64_t mangling changes
* llvm::intrinsic enum order

My personal opinion is that the uint64_t should not be applied, since
it changes the mangling in respect to 3.4, and the enum should be
fixed (by moving the new ones to the end on the generated files).

cheers,
--renato
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r205533 - Revert "Add support for named values in the parser."

[Samuel Benzaquen]

Awesome. Will use the next time. Hopefully there won't be a next time =)

On Thu, Apr 3, 2014 at 11:21 AM, David Blaikie  wrote:

> Also, we have a script that does this for you, - somewhere in
> llvm/utils/git or something (git-svnrevert?)
>
> On Thu, Apr 3, 2014 at 6:48 AM, Tobias Grosser  wrote:
> > On 04/03/2014 03:43 PM, Samuel Benzaquen wrote:
> >>
> >> On Thu, Apr 3, 2014 at 9:41 AM, Tobias Grosser 
> wrote:
> >>
> >>> On 04/03/2014 02:50 PM, Samuel Benzaquen wrote:
> >>>
>  Author: sbenza
>  Date: Thu Apr  3 07:50:47 2014
>  New Revision: 205533
> 
>  URL: http://llvm.org/viewvc/llvm-project?rev=205533&view=rev
>  Log:
>  Revert "Add support for named values in the parser."
>  This was submitted before it was ready.
> 
>  This reverts commit 62060a01e095cf35eb9ca42a333752d12714f35c.
> 
> >>>
> >>> Hi Samuel,
> >>>
> >>> please use the svn revision numbers as references.
> >>>
> >>
> >> Oh. Sorry.
> >> Can I update the description on that submission? or that was a 'for the
> >> future' comment?
> >
> >
> > Hi Samuel,
> >
> > I was a little brief, sorry! This was just meant as an advice for the
> > future.
> >
> > Have a good day,
> >
> > Tobias
> >
> > ___
> > cfe-commits mailing list
> > cfe-commits@cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r205533 - Revert "Add support for named values in the parser."

[David Blaikie]

Also, we have a script that does this for you, - somewhere in
llvm/utils/git or something (git-svnrevert?)

On Thu, Apr 3, 2014 at 6:48 AM, Tobias Grosser  wrote:
> On 04/03/2014 03:43 PM, Samuel Benzaquen wrote:
>>
>> On Thu, Apr 3, 2014 at 9:41 AM, Tobias Grosser  wrote:
>>
>>> On 04/03/2014 02:50 PM, Samuel Benzaquen wrote:
>>>
 Author: sbenza
 Date: Thu Apr  3 07:50:47 2014
 New Revision: 205533

 URL: http://llvm.org/viewvc/llvm-project?rev=205533&view=rev
 Log:
 Revert "Add support for named values in the parser."
 This was submitted before it was ready.

 This reverts commit 62060a01e095cf35eb9ca42a333752d12714f35c.

>>>
>>> Hi Samuel,
>>>
>>> please use the svn revision numbers as references.
>>>
>>
>> Oh. Sorry.
>> Can I update the description on that submission? or that was a 'for the
>> future' comment?
>
>
> Hi Samuel,
>
> I was a little brief, sorry! This was just meant as an advice for the
> future.
>
> Have a good day,
>
> Tobias
>
> ___
> cfe-commits mailing list
> cfe-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [LLVMdev] 3.4.1 Release Plans

[Tom Stellard]

Hi David,

I haven't seen any response from code owners about these patches.
Maybe it would help to send an email with different subjects to
both llvm-commits and cfe-commits and cc the code owners again.

Thanks,
Tom

On Fri, Mar 28, 2014 at 10:19:38PM -0400, David Fang wrote:
> Hi Tom,
>   Thanks for doing this.  I would like to nominate the following 
> patches to be backported to release_34 (3.4.1).
> 
> LLVM:
> r196168, r196970 -- .weak_definition vs. .weak_def_can_be_hidden
>   (r196168 is Rafael's, 970 is mine)
> r196987, r197572, r197574 -- [ABI] f64,i64 alignment on ppc-darwin
>   all Rafael's, 196987 is a cosmetic change that made it easier
>   to apply the others.
> r198744 [Iain Sandoe] -- FDE cross-section relocs for EH
> 
> https://github.com/fangism/llvm/tree/powerpc-darwin8-rel-3.4
> 
> - - - - - - - - - - - - - - - - - -
> Clang:
> r197577 [Rafael] -- f64 alignment ppc-darwin struct layout
> r196981 [me] -- suppress -Q for legacy system assembler
> 
> https://github.com/fangism/clang/tree/powerpc-darwin8-rel-3.4
> 
> 
> I have already been testing and packaging with these patches, which live 
> on my 'powerpc-darwin8-rel-3.4' branch (tracks release_34), which were 
> included in my own port of release-3.4.  My testing of that branch
> covers powerpc-darwin8/9, i386-darwin10, x86_64-darwin11 (even though it 
> is named powerpc-darwin8).  As 3.4.1 approaches, I will re-merge this 
> branch for testing.
> 
> I am also currently using powerpc-darwin8-rel-3.4 as my bootstrapping 
> C++11 compiler for llvm/clang trunk (3.5).
> 
> 
> Iain and I are aware of more powerpc-darwin8 ABI issues that have not yet 
> been fixed in trunk.  (Some patches exist, but not yet posted.)  As things 
> stand now, the release I've made comes with this warning that 
> powerpc-darwin ABI fixes are still to come, so ABI 'breakage' by 'fixing' 
> is to be expected.
> 
> Your darwin-legacy co-maintainer,
> 
> David
> 
> 
> > Hi,
> >
> > We are now about halfway between the 3.4 and 3.5 releases, and I would
> > like to start preparing for a 3.4.1 release.  Here is my proposed release
> > schedule:
> >
> > Mar 26 - April 9: Identify and backport additional bug fixes to the 3.4 
> > branch.
> > April 9 - April 18: Testing Phase
> > April 18: 3.4.1 Release
> >
> > How you can help:
> >
> > - If you have any bug fixes you think should be included to 3.4.1, send
> >  me an email with the SVN revision in trunk and also cc the code owner
> >  and llvm-commits (or cfe-commits if it is a clang patch).
> >
> > - Start integrating the 3.4 branch into your project or OS distribution
> >  to and check for any issues.
> >
> > - Volunteer as a tester for the testing phase.
> >
> > Thank you,
> >
> > Tom
> > ___
> > LLVM Developers mailing list
> > llvm...@cs.uiuc.edu http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
> 
> -- 
> David Fang
> http://www.csl.cornell.edu/~fang/
> 
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Implementation of #pragma (data|code|const|bss)_seg

[Aaron Ballman]

On Thu, Apr 3, 2014 at 10:52 AM, David Majnemer
 wrote:
> I don't think __declspec(code_seg) should be part of this, it's complexity
> is more on the order of dllimport/dllexport as it has complex inheritance
> rules.

Ah, okay, good to know. I only asked because I know it's related. :-)

~Aaron
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Implementation of #pragma (data|code|const|bss)_seg

[David Majnemer]

I don't think __declspec(code_seg) should be part of this, it's complexity
is more on the order of dllimport/dllexport as it has complex inheritance
rules.

On Thursday, April 3, 2014, Aaron Ballman  wrote:

> Would it make sense to also add __declspec(code_seg) as part of this
> patch? http://msdn.microsoft.com/en-us/library/dn636922.aspx
> Especially since MSDN recommends it over #pragma code_seg.
>
> The patch is missing parser test cases.
>
> More comments below.
>
> > Index: include/clang/Basic/Attr.td
> > ===
> > --- include/clang/Basic/Attr.td
> > +++ include/clang/Basic/Attr.td
> > @@ -1069,7 +1069,7 @@
> >  }
> >
> >  def Section : InheritableAttr {
> > -  let Spellings = [GCC<"section">];
> > +  let Spellings = [GCC<"section">, Declspec<"allocate">];
> >let Args = [StringArgument<"Name">];
> >let Subjects = SubjectList<[Function, GlobalVar,
> >ObjCMethod, ObjCProperty], ErrorDiag,
>
> I'd love to see:
>
> + let Documentation = [Anything other than Undocumented];
>
> ;-)
>
> > Index: include/clang/Basic/DiagnosticParseKinds.td
> > ===
> > --- include/clang/Basic/DiagnosticParseKinds.td
> > +++ include/clang/Basic/DiagnosticParseKinds.td
> > @@ -771,6 +771,8 @@
> >"missing ')' after '#pragma %0' - ignoring">, InGroup;
> >  def warn_pragma_expected_identifier : Warning<
> >"expected identifier in '#pragma %0' - ignored">,
> InGroup;
> > +def warn_pragma_expected_string : Warning<
> > +  "expected string literal in '#pragma %0' - ignored">,
> InGroup;
>
> This could be combined with warn_pragma_expected_identifier using a
> %select.
>
> >  def warn_pragma_expected_integer : Warning<
> >"expected integer between %0 and %1 inclusive in '#pragma %2' -
> ignored">,
> >InGroup;
> > Index: include/clang/Basic/DiagnosticSemaKinds.td
> > ===
> > --- include/clang/Basic/DiagnosticSemaKinds.td
> > +++ include/clang/Basic/DiagnosticSemaKinds.td
> > @@ -516,6 +516,7 @@
> >Warning<"ms_struct may not produce MSVC-compatible layouts for
> classes "
> >"with base classes or virtual functions">,
> >DefaultError, InGroup;
> > +def err_section_conflict : Error<"%0 causes a section type conflict
> with %1">;
> >
> >  def warn_pragma_unused_undeclared_var : Warning<
> >"undeclared variable %0 used as an argument for '#pragma unused'">,
> > Index: include/clang/Basic/TokenKinds.def
> > ===
> > --- include/clang/Basic/TokenKinds.def
> > +++ include/clang/Basic/TokenKinds.def
> > @@ -684,6 +684,11 @@
> >  // handles them.
> >  ANNOTATION(pragma_ms_vtordisp)
> >
> > +// Annotation for all microsoft #pragmas...
> > +// The lexer produces these so that they only take effect when the
> parser
> > +// handles them.
> > +ANNOTATION(pragma_ms_pragma)
> > +
> >  // Annotation for #pragma OPENCL EXTENSION...
> >  // The lexer produces these so that they only take effect when the
> parser
> >  // handles them.
> > Index: include/clang/Parse/Parser.h
> > ===
> > --- include/clang/Parse/Parser.h
> > +++ include/clang/Parse/Parser.h
> > @@ -154,6 +154,11 @@
> >std::unique_ptr MSDetectMismatchHandler;
> >std::unique_ptr MSPointersToMembers;
> >std::unique_ptr MSVtorDisp;
> > +  std::unique_ptr MSDataSeg;
> > +  std::unique_ptr MSBSSSeg;
> > +  std::unique_ptr MSConstSeg;
> > +  std::unique_ptr MSCodeSeg;
> > +  std::unique_ptr MSSection;
> >
> >std::unique_ptr CommentSemaHandler;
> >
> > @@ -475,6 +480,12 @@
> >
> >void HandlePragmaMSVtorDisp();
> >
> > +  void HandlePragmaMSPragma();
> > +  unsigned HandlePragmaMSSection(llvm::StringRef PragmaName,
> > + SourceLocation PragmaLocation);
> > +  unsigned HandlePragmaMSSeg(llvm::StringRef PragmaName,
> > + SourceLocation PragmaLocation);
>
> I'm not too keen on Seg as the name. Perhaps
> HandlePragmaMSSegment? Sorry, did I mention I like my bikesheds red?
>
> > +
> >/// \brief Handle the annotation token produced for
> >/// #pragma align...
> >void HandlePragmaAlign();
> > Index: include/clang/Sema/Sema.h
> > ===
> > --- include/clang/Sema/Sema.h
> > +++ include/clang/Sema/Sema.h
> > @@ -274,6 +274,15 @@
> >  PVDK_Reset  ///< #pragma vtordisp()
> >};
> >
> > +  enum PragmaMsStackAction {
> > +PSK_Reset,// #pragma ()
> > +PSK_Set,  // #pragma ("name")
> > +PSK_Push, // #pragma (push[, id])
> > +PSK_Push_Set, // #pragma (push[, id], "name")
> > +PSK_Pop,  // #pragma (pop[, id])
> > +PSK_Pop_Set,  // #pragma (pop[, id], "name")
> > +  };
> > +
> >/// \brief Whether to insert vt

Re: [LLVMdev] 3.4.1 Release Plans

[Tom Stellard]

On Thu, Apr 03, 2014 at 01:41:59PM +0800, Jiangning Liu wrote:
> Hi Tom,
> 
> Please refer to attached abi-compliance-checker report for those patches
> I'm asking for back porting to 3.4.1.
> 
> Test Results
> --
> Total Header Files882 <#Headers>Total Shared Libraries2 <#Libs>Total
> Symbols / Types5491 / 2756Verdict
> 
> *Incompatible(0.1%)*
> 
> So the backward compatibility is 99.9%, and I don't see big issues.

The compatibility needs to be 100%, and in this case I know that
changing the Intrinsic enum will cause problems, because I also changed
this enum when preparing R600 patches for distros to apply on top of LLVM
3.3 and it broke Ubuntu's clang package.

I can see three solutions to this problem (in order of preference)

1. Rename the intrinsics so that they end up at the bottom of the list.
These are only accessed via clang builtins, so the names should matter,
right?

2. Don't generate the intrinsic enum at buildtime.  Generate it once
offline and check it in and then modify the build system to use this
copy.

3. Don't add these intrinsics.

Also, before we get too far into this, I would really like to get
approval from Tim Northover (AArch64 code owner) and Evan Cheng (ARM
code owner) for merging these patches.  Can you ping them and ask them
to reply on list with their response.

Thanks,
Tom

> 
> Thanks,
> -Jiangning
> 
> 
> 2014-04-02 23:36 GMT+08:00 Tom Stellard :
> 
> > On Wed, Apr 02, 2014 at 03:38:18PM +0100, Tim Northover wrote:
> > > Hi Renato,
> > >
> > > > Apart from this one, I don't see any problem with the merges regarding
> > > > ABI compatibility.
> > >
> > > I think Tom meant ABI compatibility in the libLLVMWhatever.so
> > > libraries (and headers) rather than generated code. The 3.4.1 binaries
> > > should be drop-in replacements for whatever systems we produce.
> > >
> >
> > Yes, I was talking about LLVM's library ABI compatibility with 3.4.0
> > rather AARCH64 ABI compatibility.
> >
> > -Tom
> > ___
> > cfe-commits mailing list
> > cfe-commits@cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> >
> 
> 
> 
> -- 
> Thanks,
> -Jiangning


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

RE: [PATCH] OpenCL - use AST PrintingPolicy when emitting kernel arg metadata

[Joey Gouly]

If you add a test, it LGTM!

-Original Message-
From: cfe-commits-boun...@cs.uiuc.edu
[mailto:cfe-commits-boun...@cs.uiuc.edu] On Behalf Of Fraser Cormack
Sent: 03 April 2014 12:04
To: llvm cfe
Subject: [PATCH] OpenCL - use AST PrintingPolicy when emitting kernel arg
metadata

Hi,

This patch uses the AST PrintingPolicy when emitting OpenCL kernel arg 
metadata in order to pretty print the 'half' type, if supported.

Cheers,
Fraser

-- 
Fraser Cormack
Compiler Developer
Codeplay Software Ltd
45 York Place, Edinburgh, EH1 3HP
Tel: 0131 466 0503
Fax: 0131 557 6600
Website: http://www.codeplay.com
Twitter: https://twitter.com/codeplaysoft

This email and any attachments may contain confidential and /or privileged
information and  is for use  by the addressee only. If you are not the
intended recipient, please notify Codeplay Software Ltd immediately and
delete the message from your computer. You may not copy or forward it,or use
or disclose its contents to any other person. Any views or other information
in this message which do not relate to our business are not authorized by
Codeplay software Ltd, nor does this message form part of any contract
unless so stated.
As internet communications are capable of data corruption Codeplay Software
Ltd does not accept any responsibility for any changes made to this message
after it was sent. Please note that Codeplay Software Ltd does not accept
any liability or responsibility for viruses and it is your responsibility to
scan any attachments.
Company registered in England and Wales, number: 04567874
Registered office: 81 Linkfield Street, Redhill RH1 6BY




___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Implementation of #pragma (data|code|const|bss)_seg

[Aaron Ballman]

Would it make sense to also add __declspec(code_seg) as part of this
patch? http://msdn.microsoft.com/en-us/library/dn636922.aspx
Especially since MSDN recommends it over #pragma code_seg.

The patch is missing parser test cases.

More comments below.

> Index: include/clang/Basic/Attr.td
> ===
> --- include/clang/Basic/Attr.td
> +++ include/clang/Basic/Attr.td
> @@ -1069,7 +1069,7 @@
>  }
>
>  def Section : InheritableAttr {
> -  let Spellings = [GCC<"section">];
> +  let Spellings = [GCC<"section">, Declspec<"allocate">];
>let Args = [StringArgument<"Name">];
>let Subjects = SubjectList<[Function, GlobalVar,
>ObjCMethod, ObjCProperty], ErrorDiag,

I'd love to see:

+ let Documentation = [Anything other than Undocumented];

;-)

> Index: include/clang/Basic/DiagnosticParseKinds.td
> ===
> --- include/clang/Basic/DiagnosticParseKinds.td
> +++ include/clang/Basic/DiagnosticParseKinds.td
> @@ -771,6 +771,8 @@
>"missing ')' after '#pragma %0' - ignoring">, InGroup;
>  def warn_pragma_expected_identifier : Warning<
>"expected identifier in '#pragma %0' - ignored">, InGroup;
> +def warn_pragma_expected_string : Warning<
> +  "expected string literal in '#pragma %0' - ignored">, 
> InGroup;

This could be combined with warn_pragma_expected_identifier using a %select.

>  def warn_pragma_expected_integer : Warning<
>"expected integer between %0 and %1 inclusive in '#pragma %2' - ignored">,
>InGroup;
> Index: include/clang/Basic/DiagnosticSemaKinds.td
> ===
> --- include/clang/Basic/DiagnosticSemaKinds.td
> +++ include/clang/Basic/DiagnosticSemaKinds.td
> @@ -516,6 +516,7 @@
>Warning<"ms_struct may not produce MSVC-compatible layouts for classes "
>"with base classes or virtual functions">,
>DefaultError, InGroup;
> +def err_section_conflict : Error<"%0 causes a section type conflict with 
> %1">;
>
>  def warn_pragma_unused_undeclared_var : Warning<
>"undeclared variable %0 used as an argument for '#pragma unused'">,
> Index: include/clang/Basic/TokenKinds.def
> ===
> --- include/clang/Basic/TokenKinds.def
> +++ include/clang/Basic/TokenKinds.def
> @@ -684,6 +684,11 @@
>  // handles them.
>  ANNOTATION(pragma_ms_vtordisp)
>
> +// Annotation for all microsoft #pragmas...
> +// The lexer produces these so that they only take effect when the parser
> +// handles them.
> +ANNOTATION(pragma_ms_pragma)
> +
>  // Annotation for #pragma OPENCL EXTENSION...
>  // The lexer produces these so that they only take effect when the parser
>  // handles them.
> Index: include/clang/Parse/Parser.h
> ===
> --- include/clang/Parse/Parser.h
> +++ include/clang/Parse/Parser.h
> @@ -154,6 +154,11 @@
>std::unique_ptr MSDetectMismatchHandler;
>std::unique_ptr MSPointersToMembers;
>std::unique_ptr MSVtorDisp;
> +  std::unique_ptr MSDataSeg;
> +  std::unique_ptr MSBSSSeg;
> +  std::unique_ptr MSConstSeg;
> +  std::unique_ptr MSCodeSeg;
> +  std::unique_ptr MSSection;
>
>std::unique_ptr CommentSemaHandler;
>
> @@ -475,6 +480,12 @@
>
>void HandlePragmaMSVtorDisp();
>
> +  void HandlePragmaMSPragma();
> +  unsigned HandlePragmaMSSection(llvm::StringRef PragmaName,
> + SourceLocation PragmaLocation);
> +  unsigned HandlePragmaMSSeg(llvm::StringRef PragmaName,
> + SourceLocation PragmaLocation);

I'm not too keen on Seg as the name. Perhaps
HandlePragmaMSSegment? Sorry, did I mention I like my bikesheds red?

> +
>/// \brief Handle the annotation token produced for
>/// #pragma align...
>void HandlePragmaAlign();
> Index: include/clang/Sema/Sema.h
> ===
> --- include/clang/Sema/Sema.h
> +++ include/clang/Sema/Sema.h
> @@ -274,6 +274,15 @@
>  PVDK_Reset  ///< #pragma vtordisp()
>};
>
> +  enum PragmaMsStackAction {
> +PSK_Reset,// #pragma ()
> +PSK_Set,  // #pragma ("name")
> +PSK_Push, // #pragma (push[, id])
> +PSK_Push_Set, // #pragma (push[, id], "name")
> +PSK_Pop,  // #pragma (pop[, id])
> +PSK_Pop_Set,  // #pragma (pop[, id], "name")
> +  };
> +
>/// \brief Whether to insert vtordisps prior to virtual bases in the 
> Microsoft
>/// C++ ABI.  Possible values are 0, 1, and 2, which mean:
>///
> @@ -289,6 +298,30 @@
>/// \brief Source location for newly created implicit MSInheritanceAttrs
>SourceLocation ImplicitMSInheritanceAttrLoc;
>
> +  template
> +  struct PragmaStack {
> +struct Slot {
> +  llvm::StringRef StackSlotLabel;
> +  ValueType Value;
> +  SourceLocation PragmaLocation;
> +}

Re: [PATCH] Division by zero

[Anders Rönnholm]

Hi Jordan, see below for comments and questions.

< Hi, Anders. I have some high-level concerns about this checker as it's 
structured now. First (and most mundanely), the checker is conflating values 
and locations. A particular symbol in the analyzer can  get(MR);

but with set i'm only able to get them all.
DivZeroMapTy DivZeroes = State->get();

/Anders

On Apr 1, 2014, at 7:45 , Anders Rönnholm 
mailto:anders.ronnh...@evidente.se>> wrote:

Hi,

I have a new patch i'd like to get reviewed for a different kind of division by 
zero than the already existing one.

This patch check for division by variable that is later compared against 0. 
Either the comparison is useless or there is division by zero.

It catches scenarios like these:

void f(int y) {
x = 100 / y;
if (y == 0) {}
}

//Anders___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r205533 - Revert "Add support for named values in the parser."

[Samuel Benzaquen]

On Thu, Apr 3, 2014 at 9:41 AM, Tobias Grosser  wrote:

> On 04/03/2014 02:50 PM, Samuel Benzaquen wrote:
>
>> Author: sbenza
>> Date: Thu Apr  3 07:50:47 2014
>> New Revision: 205533
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=205533&view=rev
>> Log:
>> Revert "Add support for named values in the parser."
>> This was submitted before it was ready.
>>
>> This reverts commit 62060a01e095cf35eb9ca42a333752d12714f35c.
>>
>
> Hi Samuel,
>
> please use the svn revision numbers as references.
>

Oh. Sorry.
Can I update the description on that submission? or that was a 'for the
future' comment?


>
> Thanks,
> Tobias
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r205533 - Revert "Add support for named values in the parser."

[Tobias Grosser]

On 04/03/2014 03:43 PM, Samuel Benzaquen wrote:

On Thu, Apr 3, 2014 at 9:41 AM, Tobias Grosser  wrote:


On 04/03/2014 02:50 PM, Samuel Benzaquen wrote:


Author: sbenza
Date: Thu Apr  3 07:50:47 2014
New Revision: 205533

URL: http://llvm.org/viewvc/llvm-project?rev=205533&view=rev
Log:
Revert "Add support for named values in the parser."
This was submitted before it was ready.

This reverts commit 62060a01e095cf35eb9ca42a333752d12714f35c.



Hi Samuel,

please use the svn revision numbers as references.



Oh. Sorry.
Can I update the description on that submission? or that was a 'for the
future' comment?


Hi Samuel,

I was a little brief, sorry! This was just meant as an advice for the 
future.


Have a good day,
Tobias

___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r205533 - Revert "Add support for named values in the parser."

[Tobias Grosser]

On 04/03/2014 02:50 PM, Samuel Benzaquen wrote:

Author: sbenza
Date: Thu Apr  3 07:50:47 2014
New Revision: 205533

URL: http://llvm.org/viewvc/llvm-project?rev=205533&view=rev
Log:
Revert "Add support for named values in the parser."
This was submitted before it was ready.

This reverts commit 62060a01e095cf35eb9ca42a333752d12714f35c.


Hi Samuel,

please use the svn revision numbers as references.

Thanks,
Tobias
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

[PATCH] clang-format: Add SpacesInParenthesesStyle

[Aaron Wishnick]

This patch adds an option to control when spaces are added inside of
parentheses. My employer's style guide mandates that spaces go inside the
outermost pair of parentheses, but not the rest. For example:

if( someFunction(a, b, c) ) {
  doThing( f(x), f(g(x)) );
}

My attached patch implements this feature with a new option,
SpacesInParenthesesStyle, which can either be "Always" (the previous
behavior, and the default), or "Outermost", the new behavior used by my
organization.

Does this seem like a reasonable strategy? The new option defaults to the
previous behavior. I see that a different approach was taken with
SpaceBeforeParensOptions. I went with this approach, because the option
applies to spaces inserted inside of parentheses due to
SpacesInParentheses, SpaceInEmptyParentheses,
SpacesInCStyleCastParentheses, etc.

Thanks,
Aaron

N.B. I originally sent this to the cfe-dev list by mistake, sorry for the
noise!


SpacesInParenthesesStyle.patch
Description: Binary data
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r205536 - Code cleanup (re-indent)

[Logan Chien]

Author: logan
Date: Thu Apr  3 08:12:44 2014
New Revision: 205536

URL: http://llvm.org/viewvc/llvm-project?rev=205536&view=rev
Log:
Code cleanup (re-indent)

Modified:
cfe/trunk/lib/Driver/Tools.cpp

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=205536&r1=205535&r2=205536&view=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Thu Apr  3 08:12:44 2014
@@ -839,13 +839,13 @@ void Clang::AddARMTargetArgs(const ArgLi
 true))
 CmdArgs.push_back("-no-implicit-float");
 
-// llvm does not support reserving registers in general. There is support
-// for reserving r9 on ARM though (defined as a platform-specific register
-// in ARM EABI).
-if (Args.hasArg(options::OPT_ffixed_r9)) {
-  CmdArgs.push_back("-backend-option");
-  CmdArgs.push_back("-arm-reserve-r9");
-}
+  // llvm does not support reserving registers in general. There is support
+  // for reserving r9 on ARM though (defined as a platform-specific register
+  // in ARM EABI).
+  if (Args.hasArg(options::OPT_ffixed_r9)) {
+CmdArgs.push_back("-backend-option");
+CmdArgs.push_back("-arm-reserve-r9");
+  }
 }
 
 /// getARM64TargetCPU - Get the (LLVM) name of the ARM64 cpu we are targeting.


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Add support for named values in the parser.

[Samuel Benzaquen]

  I rolled back the premature cl and sent it again.
  Please review on this thread instead.

http://llvm-reviews.chandlerc.com/D3276
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

[PATCH] Add support for named values in the parser.

[Samuel Benzaquen]

Hi pcc,

Add support for named values in the parser.

http://llvm-reviews.chandlerc.com/D3276

Files:
  include/clang/ASTMatchers/Dynamic/Parser.h
  include/clang/ASTMatchers/Dynamic/VariantValue.h
  lib/ASTMatchers/Dynamic/Parser.cpp
  unittests/ASTMatchers/Dynamic/ParserTest.cpp
  unittests/ASTMatchers/Dynamic/VariantValueTest.cpp
Index: include/clang/ASTMatchers/Dynamic/Parser.h
===
--- include/clang/ASTMatchers/Dynamic/Parser.h
+++ include/clang/ASTMatchers/Dynamic/Parser.h
@@ -18,13 +18,14 @@
 ///
 /// \code
 /// Grammar for the expressions supported:
-/// :=  | 
+/// :=  |  | 
 ///:=  | 
 ///  := "quoted string"
 ///   := [0-9]+
-///  := () |
-///().bind()
-///:= [a-zA-Z]+
+/// := 
+///  := () |
+///().bind()
+/// := [a-zA-Z]+
 ///   :=  | ,
 /// \endcode
 ///
@@ -62,6 +63,19 @@
   public:
 virtual ~Sema();
 
+/// \brief Lookup a value by name.
+///
+/// This can be used in the Sema layer to declare known constants or to
+/// allow to split an expression in pieces.
+///
+/// \param Name The name of the value to lookup.
+///
+/// \return The named value. It could be any type that VariantValue
+///   supports. A 'nothing' value means that the name is not recognized.
+virtual VariantValue getNamedValue(StringRef Name) {
+  return VariantValue();
+}
+
 /// \brief Process a matcher expression.
 ///
 /// All the arguments passed here have already been processed.
@@ -100,6 +114,21 @@
   Diagnostics *Error) = 0;
   };
 
+  /// \brief Sema implementation that uses the matcher registry to process the
+  ///   tokens.
+  class RegistrySema : public Parser::Sema {
+   public:
+virtual ~RegistrySema();
+llvm::Optional lookupMatcherCtor(StringRef MatcherName,
+  const SourceRange &NameRange,
+  Diagnostics *Error) override;
+VariantMatcher actOnMatcherExpression(MatcherCtor Ctor,
+  const SourceRange &NameRange,
+  StringRef BindID,
+  ArrayRef Args,
+  Diagnostics *Error) override;
+  };
+
   /// \brief Parse a matcher expression, creating matchers from the registry.
   ///
   /// This overload creates matchers calling directly into the registry. If the
Index: include/clang/ASTMatchers/Dynamic/VariantValue.h
===
--- include/clang/ASTMatchers/Dynamic/VariantValue.h
+++ include/clang/ASTMatchers/Dynamic/VariantValue.h
@@ -78,7 +78,8 @@
   /// \brief Clones the provided matchers.
   ///
   /// They should be the result of a polymorphic matcher.
-  static VariantMatcher PolymorphicMatcher(std::vector Matchers);
+  static VariantMatcher
+  PolymorphicMatcher(std::vector Matchers);
 
   /// \brief Creates a 'variadic' operator matcher.
   ///
@@ -208,6 +209,9 @@
   VariantValue(const std::string &String);
   VariantValue(const VariantMatcher &Matchers);
 
+  /// \brief Returns true iff this is an empty value.
+  bool isNothing() const { return Type == VT_Nothing; }
+
   /// \brief Unsigned value functions.
   bool isUnsigned() const;
   unsigned getUnsigned() const;
Index: lib/ASTMatchers/Dynamic/Parser.cpp
===
--- lib/ASTMatchers/Dynamic/Parser.cpp
+++ lib/ASTMatchers/Dynamic/Parser.cpp
@@ -424,8 +424,18 @@
 *Value = Tokenizer->consumeNextToken().Value;
 return true;
 
-  case TokenInfo::TK_Ident:
+  case TokenInfo::TK_Ident: {
+// Identifier could be a name known by Sema as a named value.
+const VariantValue NamedValue =
+S->getNamedValue(Tokenizer->peekNextToken().Text);
+if (!NamedValue.isNothing()) {
+  Tokenizer->consumeNextToken();  // Actually consume it.
+  *Value = NamedValue;
+  return true;
+}
+// Fallback to full matcher parsing.
 return parseMatcherExpressionImpl(Value);
+  }
 
   case TokenInfo::TK_CodeCompletion:
 addExpressionCompletions();
@@ -457,27 +467,23 @@
Diagnostics *Error)
 : Tokenizer(Tokenizer), S(S), Error(Error) {}
 
-class RegistrySema : public Parser::Sema {
-public:
-  virtual ~RegistrySema() {}
-  llvm::Optional lookupMatcherCtor(StringRef MatcherName,
-const SourceRange &NameRange,
-Diagnostics *Error) {
-return Registry::lookupMatcherCtor(MatcherName, NameRange, Error);
-  }
-  VariantMatcher actOnMatcherExpression(MatcherCtor Ctor,
-const SourceRange &NameRange,
-StringRef BindID,
-  

r205533 - Revert "Add support for named values in the parser."

[Samuel Benzaquen]

Author: sbenza
Date: Thu Apr  3 07:50:47 2014
New Revision: 205533

URL: http://llvm.org/viewvc/llvm-project?rev=205533&view=rev
Log:
Revert "Add support for named values in the parser."
This was submitted before it was ready.

This reverts commit 62060a01e095cf35eb9ca42a333752d12714f35c.

Modified:
cfe/trunk/include/clang/ASTMatchers/Dynamic/Parser.h
cfe/trunk/include/clang/ASTMatchers/Dynamic/VariantValue.h
cfe/trunk/lib/ASTMatchers/Dynamic/Parser.cpp
cfe/trunk/unittests/ASTMatchers/Dynamic/ParserTest.cpp
cfe/trunk/unittests/ASTMatchers/Dynamic/VariantValueTest.cpp

Modified: cfe/trunk/include/clang/ASTMatchers/Dynamic/Parser.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/Dynamic/Parser.h?rev=205533&r1=205532&r2=205533&view=diff
==
--- cfe/trunk/include/clang/ASTMatchers/Dynamic/Parser.h (original)
+++ cfe/trunk/include/clang/ASTMatchers/Dynamic/Parser.h Thu Apr  3 07:50:47 
2014
@@ -18,14 +18,13 @@
 ///
 /// \code
 /// Grammar for the expressions supported:
-/// :=  |  | 
+/// :=  | 
 ///:=  | 
 ///  := "quoted string"
 ///   := [0-9]+
-/// := 
-///  := () |
-///().bind()
-/// := [a-zA-Z]+
+///  := () |
+///().bind()
+///:= [a-zA-Z]+
 ///   :=  | ,
 /// \endcode
 ///
@@ -63,19 +62,6 @@ public:
   public:
 virtual ~Sema();
 
-/// \brief Lookup a value by name.
-///
-/// This can be used in the Sema layer to declare known constants or to
-/// allow to split an expression in pieces.
-///
-/// \param Name The name of the value to lookup.
-///
-/// \return The named value. It could be any type that VariantValue
-///   supports. A 'nothing' value means that the name is not recognized.
-virtual VariantValue getNamedValue(StringRef Name) {
-  return VariantValue();
-}
-
 /// \brief Process a matcher expression.
 ///
 /// All the arguments passed here have already been processed.
@@ -114,21 +100,6 @@ public:
   Diagnostics *Error) = 0;
   };
 
-  /// \brief Sema implementation that uses the matcher registry to process the
-  ///   tokens.
-  class RegistrySema : public Parser::Sema {
-   public:
-virtual ~RegistrySema();
-llvm::Optional lookupMatcherCtor(StringRef MatcherName,
-  const SourceRange &NameRange,
-  Diagnostics *Error) override;
-VariantMatcher actOnMatcherExpression(MatcherCtor Ctor,
-  const SourceRange &NameRange,
-  StringRef BindID,
-  ArrayRef Args,
-  Diagnostics *Error) override;
-  };
-
   /// \brief Parse a matcher expression, creating matchers from the registry.
   ///
   /// This overload creates matchers calling directly into the registry. If the

Modified: cfe/trunk/include/clang/ASTMatchers/Dynamic/VariantValue.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/Dynamic/VariantValue.h?rev=205533&r1=205532&r2=205533&view=diff
==
--- cfe/trunk/include/clang/ASTMatchers/Dynamic/VariantValue.h (original)
+++ cfe/trunk/include/clang/ASTMatchers/Dynamic/VariantValue.h Thu Apr  3 
07:50:47 2014
@@ -78,8 +78,7 @@ public:
   /// \brief Clones the provided matchers.
   ///
   /// They should be the result of a polymorphic matcher.
-  static VariantMatcher
-  PolymorphicMatcher(std::vector Matchers);
+  static VariantMatcher PolymorphicMatcher(std::vector 
Matchers);
 
   /// \brief Creates a 'variadic' operator matcher.
   ///
@@ -209,9 +208,6 @@ public:
   VariantValue(const std::string &String);
   VariantValue(const VariantMatcher &Matchers);
 
-  /// \brief Returns true iff this is an empty value.
-  bool isNothing() const { return Type == VT_Nothing; }
-
   /// \brief Unsigned value functions.
   bool isUnsigned() const;
   unsigned getUnsigned() const;

Modified: cfe/trunk/lib/ASTMatchers/Dynamic/Parser.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/ASTMatchers/Dynamic/Parser.cpp?rev=205533&r1=205532&r2=205533&view=diff
==
--- cfe/trunk/lib/ASTMatchers/Dynamic/Parser.cpp (original)
+++ cfe/trunk/lib/ASTMatchers/Dynamic/Parser.cpp Thu Apr  3 07:50:47 2014
@@ -424,18 +424,8 @@ bool Parser::parseExpressionImpl(Variant
 *Value = Tokenizer->consumeNextToken().Value;
 return true;
 
-  case TokenInfo::TK_Ident: {
-// Identifier could be a name known by Sema as a named value.
-const VariantValue NamedValue =
-S->getNamedValue(Tokenizer->peekNextToken().Text);
-if (!NamedValue.isNothing()) {
- 

Re: r205526 - x

[Daniel Jasper]

Oops, forgot proper CL description (git ... :-( ).

Just a typo I fixed on the way and forgot to merge in with the actual
change.


On Thu, Apr 3, 2014 at 2:00 PM, Daniel Jasper  wrote:

> Author: djasper
> Date: Thu Apr  3 07:00:27 2014
> New Revision: 205526
>
> URL: http://llvm.org/viewvc/llvm-project?rev=205526&view=rev
> Log:
> x
>
> Modified:
> cfe/trunk/lib/Format/ContinuationIndenter.cpp
>
> Modified: cfe/trunk/lib/Format/ContinuationIndenter.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/ContinuationIndenter.cpp?rev=205526&r1=205525&r2=205526&view=diff
>
> ==
> --- cfe/trunk/lib/Format/ContinuationIndenter.cpp (original)
> +++ cfe/trunk/lib/Format/ContinuationIndenter.cpp Thu Apr  3 07:00:27 2014
> @@ -350,7 +350,7 @@ unsigned ContinuationIndenter::addTokenO
>
>// Breaking before the first "<<" is generally not desirable if the LHS
> is
>// short. Also always add the penalty if the LHS is split over mutliple
> lines
> -  // to avoid unncessary line breaks that just work around this penalty.
> +  // to avoid unnecessary line breaks that just work around this penalty.
>if (NextNonComment->is(tok::lessless) &&
>State.Stack.back().FirstLessLess == 0 &&
>(State.Column <= Style.ColumnLimit / 3 ||
>
>
> ___
> cfe-commits mailing list
> cfe-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r205527 - clang-format: Prefer an additional line-break over hanging indent.

[Daniel Jasper]

Author: djasper
Date: Thu Apr  3 07:00:33 2014
New Revision: 205527

URL: http://llvm.org/viewvc/llvm-project?rev=205527&view=rev
Log:
clang-format: Prefer an additional line-break over hanging indent.

Don't allow the RHS of an operator to be split over multiple
lines unless there is a line-break right after the operator.

Before:
  if ( && b || // break
  ) {
  }

After:
  if ( &&
  b || // break
  ) {
  }

In most cases, this seems to increase readability.

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

Modified: cfe/trunk/lib/Format/ContinuationIndenter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/ContinuationIndenter.cpp?rev=205527&r1=205526&r2=205527&view=diff
==
--- cfe/trunk/lib/Format/ContinuationIndenter.cpp (original)
+++ cfe/trunk/lib/Format/ContinuationIndenter.cpp Thu Apr  3 07:00:33 2014
@@ -609,6 +609,18 @@ unsigned ContinuationIndenter::moveState
   std::max(std::max(State.Column, NewParenState.Indent),
State.Stack.back().LastSpace);
 
+// Don't allow the RHS of an operator to be split over multiple lines 
unless
+// there is a line-break right after the operator.
+// Exclude relational operators, as there, it is always more desirable to
+// have the LHS 'left' of the RHS.
+// FIXME: Implement this for '<<' and BreakBeforeBinaryOperators.
+if (!Newline && Previous && Previous->Type == TT_BinaryOperator &&
+!Previous->isOneOf(tok::lessless, tok::question, tok::colon) &&
+Previous->getPrecedence() > prec::Assignment &&
+Previous->getPrecedence() != prec::Relational &&
+!Style.BreakBeforeBinaryOperators)
+  NewParenState.NoLineBreak = true;
+
 // Do not indent relative to the fake parentheses inserted for "." or "->".
 // This is a special case to make the following to statements consistent:
 //   OuterFunction(InnerFunctionCall( // break

Modified: cfe/trunk/unittests/Format/FormatTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTest.cpp?rev=205527&r1=205526&r2=205527&view=diff
==
--- cfe/trunk/unittests/Format/FormatTest.cpp (original)
+++ cfe/trunk/unittests/Format/FormatTest.cpp Thu Apr  3 07:00:33 2014
@@ -2889,8 +2889,9 @@ TEST_F(FormatTest, ExpressionIndentation
"aa +\n"
"bbb) {\n}");
   verifyFormat("if () {\n"
-   "} else if (a && b > // break\n"
-   "c) {\n"
+   "} else if (a &&\n"
+   "   b > // break\n"
+   "   c) {\n"
"}");
 
   // Presence of a trailing comment used to change indentation of b.


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r205526 - x

[Daniel Jasper]

Author: djasper
Date: Thu Apr  3 07:00:27 2014
New Revision: 205526

URL: http://llvm.org/viewvc/llvm-project?rev=205526&view=rev
Log:
x

Modified:
cfe/trunk/lib/Format/ContinuationIndenter.cpp

Modified: cfe/trunk/lib/Format/ContinuationIndenter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/ContinuationIndenter.cpp?rev=205526&r1=205525&r2=205526&view=diff
==
--- cfe/trunk/lib/Format/ContinuationIndenter.cpp (original)
+++ cfe/trunk/lib/Format/ContinuationIndenter.cpp Thu Apr  3 07:00:27 2014
@@ -350,7 +350,7 @@ unsigned ContinuationIndenter::addTokenO
 
   // Breaking before the first "<<" is generally not desirable if the LHS is
   // short. Also always add the penalty if the LHS is split over mutliple lines
-  // to avoid unncessary line breaks that just work around this penalty.
+  // to avoid unnecessary line breaks that just work around this penalty.
   if (NextNonComment->is(tok::lessless) &&
   State.Stack.back().FirstLessLess == 0 &&
   (State.Column <= Style.ColumnLimit / 3 ||


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

[PATCH] OpenCL - use AST PrintingPolicy when emitting kernel arg metadata

[Fraser Cormack]

Hi,

This patch uses the AST PrintingPolicy when emitting OpenCL kernel arg 
metadata in order to pretty print the 'half' type, if supported.


Cheers,
Fraser

--
Fraser Cormack
Compiler Developer
Codeplay Software Ltd
45 York Place, Edinburgh, EH1 3HP
Tel: 0131 466 0503
Fax: 0131 557 6600
Website: http://www.codeplay.com
Twitter: https://twitter.com/codeplaysoft

This email and any attachments may contain confidential and /or privileged 
information and  is for use  by the addressee only. If you are not the intended 
recipient, please notify Codeplay Software Ltd immediately and delete the 
message from your computer. You may not copy or forward it,or use or disclose 
its contents to any other person. Any views or other information in this 
message which do not relate to our business are not authorized by Codeplay 
software Ltd, nor does this message form part of any contract unless so stated.
As internet communications are capable of data corruption Codeplay Software Ltd 
does not accept any responsibility for any changes made to this message after 
it was sent. Please note that Codeplay Software Ltd does not accept any 
liability or responsibility for viruses and it is your responsibility to scan 
any attachments.
Company registered in England and Wales, number: 04567874
Registered office: 81 Linkfield Street, Redhill RH1 6BY

Index: lib/CodeGen/CodeGenFunction.cpp
===
--- lib/CodeGen/CodeGenFunction.cpp	(revision 205523)
+++ lib/CodeGen/CodeGenFunction.cpp	(working copy)
@@ -338,6 +338,7 @@
   // Create MDNodes that represent the kernel arg metadata.
   // Each MDNode is a list in the form of "key", N number of values which is
   // the same number of values as their are kernel arguments.
+  const PrintingPolicy &Policy = ASTCtx.getPrintingPolicy();
 
   // MDNode for the kernel argument address space qualifiers.
   SmallVector addressQuals;
@@ -372,7 +373,8 @@
 pointeeTy.getAddressSpace(;
 
   // Get argument type name.
-  std::string typeName = pointeeTy.getUnqualifiedType().getAsString() + "*";
+  std::string typeName =
+  pointeeTy.getUnqualifiedType().getAsString(Policy) + "*";
 
   // Turn "unsigned type" to "utype"
   std::string::size_type pos = typeName.find("unsigned");
@@ -398,7 +400,7 @@
   addressQuals.push_back(Builder.getInt32(AddrSpc));
 
   // Get argument type name.
-  std::string typeName = ty.getUnqualifiedType().getAsString();
+  std::string typeName = ty.getUnqualifiedType().getAsString(Policy);
 
   // Turn "unsigned type" to "utype"
   std::string::size_type pos = typeName.find("unsigned");
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r205436 - Extend the SSE2 comment lexing to AVX2. Only 16byte align when not on AVX2.

[Stephen Canon]

On Apr 2, 2014, at 3:14 PM, Chris Lattner  wrote:

> On Apr 2, 2014, at 12:14 PM, Chris Lattner  wrote:
> 
>> On Apr 2, 2014, at 10:27 AM, Roman Divacky  wrote:
>> 
>>> Author: rdivacky
>>> Date: Wed Apr  2 12:27:03 2014
>>> New Revision: 205436
>>> 
>>> URL: http://llvm.org/viewvc/llvm-project?rev=205436&view=rev
>>> Log:
>>> Extend the SSE2 comment lexing to AVX2. Only 16byte align when not on AVX2.
>>> 
>>> This provides some 3% speedup when preprocessing gcc.c as a single file.
>> 
>> Nice!
> 
> I haven’t looked closely at them, but would any of the SSE 4.2 “string 
> processing” instructions be helpful here?

For simply scanning for '/', SSE4.2 won't be a win; it's usually not 
significantly faster than PCMPEQB + PMOVMSKB in strchr-type loops.

One could use it to search for "*/" instead, which would be somewhat more 
interesting.  There's no 32B VPCMPESTRI however, so if there aren't many 
false-positive '/' characters in block comments (I expect this to be the case), 
then using AVX2 to scan for '/' should still win.

– Steve
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [patch] Improvement to implicit scalar-vector conversions

[Stephen Canon]

Committed as r205521 after addressing John's notes and explicitly exempting CL 
from this change.

– Steve

On Apr 2, 2014, at 4:43 PM, John McCall  wrote:

> On Mar 26, 2014, at 5:34 PM, Stephen Canon  wrote:
>> ExtVectors currently support basic operations with scalar data (which is 
>> interpreted as an implicit splat).  However, this support has some serious 
>> issues.  Most critically, at present the type of the result depends on 
>> operand order:
> 
> I think the language design here makes a lot of sense, especially dropping 
> the Open CL restriction.  Style nits:
> 
> +  if (isa(Target))
> +Target = cast(Target)->getElementType().getTypePtr();
> 
> The idiomatic way to do this is
>  if (auto VecTy = dyn_cast(Target))
>Target = VecTy->getElementType().getTypePtr();
> 
>   if (vectorEltTy->isIntegralType(S.Context)) {
> if (!scalarTy->isIntegralType(S.Context)) return true;
> -int order = S.Context.getIntegerTypeOrder(vectorEltTy, scalarTy);
> -if (order < 0) return true;
> -if (order > 0) scalarCast = CK_IntegralCast;
> +scalarCast = CK_IntegralCast;
>   } else if (vectorEltTy->isRealFloatingType()) {
> if (scalarTy->isRealFloatingType()) {
> -  int order = S.Context.getFloatingTypeOrder(vectorEltTy, scalarTy);
> -  if (order < 0) return true;
> -  if (order > 0) scalarCast = CK_FloatingCast;
> +scalarCast = CK_FloatingCast;
> 
> You seem to be randomly 4-indenting here.
> 
> +  // If there's an ext-vector type and a scalar, try to promote (and
> +  // only promote) and splat the scalar to the vector type.
> 
> This comment is no longer accurate.
> 
> +static void splats(int i, long l, __uint128_t t, float f, double d) {
> +short8 vs = 0;
> +int4 vi = i;
> +ulong2 vl = (unsigned long)l;
> +float2 vf = f;
> +double2 vd = d;
> 
> We try to be consistent about 2-indenting even in test cases.  Obviously 
> that’s not always true going back, but in new code...
> 
> Otherwise looks good.
> 
> John.


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r205521 - Improved semantics for implicit scalar -> extvector conversions.

[Stephen Canon]

Author: scanon
Date: Thu Apr  3 05:33:25 2014
New Revision: 205521

URL: http://llvm.org/viewvc/llvm-project?rev=205521&view=rev
Log:
Improved semantics for implicit scalar -> extvector conversions.

Modified:
cfe/trunk/lib/Sema/SemaChecking.cpp
cfe/trunk/lib/Sema/SemaExpr.cpp
cfe/trunk/test/Sema/ext_vector_casts.c

Modified: cfe/trunk/lib/Sema/SemaChecking.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaChecking.cpp?rev=205521&r1=205520&r2=205521&view=diff
==
--- cfe/trunk/lib/Sema/SemaChecking.cpp (original)
+++ cfe/trunk/lib/Sema/SemaChecking.cpp Thu Apr  3 05:33:25 2014
@@ -5780,6 +5780,8 @@ void CheckImplicitConversion(Sema &S, Ex
 Source = cast(Source)->getElementType().getTypePtr();
 Target = cast(Target)->getElementType().getTypePtr();
   }
+  if (auto VecTy = dyn_cast(Target))
+Target = VecTy->getElementType().getTypePtr();
 
   // Strip complex types.
   if (isa(Source)) {

Modified: cfe/trunk/lib/Sema/SemaExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExpr.cpp?rev=205521&r1=205520&r2=205521&view=diff
==
--- cfe/trunk/lib/Sema/SemaExpr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExpr.cpp Thu Apr  3 05:33:25 2014
@@ -6696,35 +6696,40 @@ QualType Sema::InvalidOperands(SourceLoc
   return QualType();
 }
 
-/// Try to convert a value of non-vector type to a vector type by
-/// promoting (and only promoting) the type to the element type of the
-/// vector and then performing a vector splat.
+/// Try to convert a value of non-vector type to a vector type by converting
+/// the type to the element type of the vector and then performing a splat.
+/// If the language is OpenCL, we only use conversions that promote scalar
+/// rank; for C, Obj-C, and C++ we allow any real scalar conversion except
+/// for float->int.
 ///
 /// \param scalar - if non-null, actually perform the conversions
 /// \return true if the operation fails (but without diagnosing the failure)
-static bool tryVectorPromoteAndSplat(Sema &S, ExprResult *scalar,
+static bool tryVectorConvertAndSplat(Sema &S, ExprResult *scalar,
  QualType scalarTy,
  QualType vectorEltTy,
  QualType vectorTy) {
   // The conversion to apply to the scalar before splatting it,
   // if necessary.
   CastKind scalarCast = CK_Invalid;
-
+  
   if (vectorEltTy->isIntegralType(S.Context)) {
-if (!scalarTy->isIntegralType(S.Context)) return true;
-int order = S.Context.getIntegerTypeOrder(vectorEltTy, scalarTy);
-if (order < 0) return true;
-if (order > 0) scalarCast = CK_IntegralCast;
+if (!scalarTy->isIntegralType(S.Context))
+  return true;
+if (S.getLangOpts().OpenCL &&
+S.Context.getIntegerTypeOrder(vectorEltTy, scalarTy) < 0)
+  return true;
+scalarCast = CK_IntegralCast;
   } else if (vectorEltTy->isRealFloatingType()) {
 if (scalarTy->isRealFloatingType()) {
-  int order = S.Context.getFloatingTypeOrder(vectorEltTy, scalarTy);
-  if (order < 0) return true;
-  if (order > 0) scalarCast = CK_FloatingCast;
-} else if (scalarTy->isIntegralType(S.Context)) {
+  if (S.getLangOpts().OpenCL &&
+  S.Context.getFloatingTypeOrder(vectorEltTy, scalarTy) < 0)
+return true;
+  scalarCast = CK_FloatingCast;
+}
+else if (scalarTy->isIntegralType(S.Context))
   scalarCast = CK_IntegralToFloating;
-} else {
+else
   return true;
-}
   } else {
 return true;
   }
@@ -6732,7 +6737,7 @@ static bool tryVectorPromoteAndSplat(Sem
   // Adjust scalar if desired.
   if (scalar) {
 if (scalarCast != CK_Invalid)
-   *scalar = S.ImpCastExprToType(scalar->take(), vectorEltTy, scalarCast);
+  *scalar = S.ImpCastExprToType(scalar->take(), vectorEltTy, scalarCast);
 *scalar = S.ImpCastExprToType(scalar->take(), vectorTy, CK_VectorSplat);
   }
   return false;
@@ -6775,6 +6780,19 @@ QualType Sema::CheckVectorOperands(ExprR
 return RHSType;
   }
 
+  // If there's an ext-vector type and a scalar, try to convert the scalar to
+  // the vector element type and splat.
+  if (!RHSVecType && isa(LHSVecType)) {
+if (!tryVectorConvertAndSplat(*this, &RHS, RHSType,
+  LHSVecType->getElementType(), LHSType))
+  return LHSType;
+  }
+  if (!LHSVecType && isa(RHSVecType)) {
+if (!tryVectorConvertAndSplat(*this, (IsCompAssign ? 0 : &LHS), LHSType,
+  RHSVecType->getElementType(), RHSType))
+  return RHSType;
+  }
+
   // If we're allowing lax vector conversions, only the total (data) size
   // needs to be the same.
   // FIXME: Should we really be allowing this?
@@ -6785,19 +6803,6 @@ QualType Sema::CheckVectorOperands(ExprR
 return resultType;
   }
 
-  

Re: [PATCH] Sema: Add dll attribute tests for variable templates

[Hans Wennborg]

On Wed, Apr 2, 2014 at 8:37 AM, Nico Rieck  wrote:
> With all the previous patches applied, imported/exported variable
> templates only need tests.

Looks good as far as I can tell.

 - Hans
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

[libcxx] r205518 - RTTI Uniqueness: remove __name_for_load function.

[Tim Northover]

Author: tnorthover
Date: Thu Apr  3 04:12:38 2014
New Revision: 205518

URL: http://llvm.org/viewvc/llvm-project?rev=205518&view=rev
Log:
RTTI Uniqueness: remove __name_for_load function.

It's identical to name() these days. (At one point it avoided masking
of the RTTI uniqueness bit because ARM64 ignored it architecturally,
but no longer).

Modified:
libcxx/trunk/include/typeinfo

Modified: libcxx/trunk/include/typeinfo
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/typeinfo?rev=205518&r1=205517&r2=205518&view=diff
==
--- libcxx/trunk/include/typeinfo (original)
+++ libcxx/trunk/include/typeinfo Thu Apr  3 04:12:38 2014
@@ -116,7 +116,7 @@ public:
 {return *reinterpret_cast(&__type_name);}
 #else
 {if (!(__type_name & _LIBCPP_NONUNIQUE_RTTI_BIT)) return __type_name;
- const char *__ptr = __name_for_load();
+ const char *__ptr = name();
  size_t __hash = 5381;
  while (unsigned char __c = static_cast(*__ptr++))
__hash = (__hash * 33) ^ __c;
@@ -141,15 +141,7 @@ public:
   private:
 _LIBCPP_INLINE_VISIBILITY
 int __compare_nonunique_names(const type_info &__arg) const _NOEXCEPT
-{return __builtin_strcmp(__name_for_load(), __arg.__name_for_load());}
-
-_LIBCPP_INLINE_VISIBILITY
-const char *__name_for_load() const _NOEXCEPT
-{uintptr_t __data = __type_name;
-#if 1
- __data &= ~_LIBCPP_NONUNIQUE_RTTI_BIT;
-#endif
- return reinterpret_cast(__data);}
+{return __builtin_strcmp(name(), __arg.name());}
 #endif
 };
 


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r205436 - Extend the SSE2 comment lexing to AVX2. Only 16byte align when not on AVX2.

[Jay Foad]

Hi Roman,

On 2 April 2014 18:27, Roman Divacky  wrote:
>  #ifdef __SSE2__
> -  __m128i Slashes = _mm_set1_epi8('/');
> -  while (CurPtr+16 <= BufferEnd) {
> -int cmp = _mm_movemask_epi8(_mm_cmpeq_epi8(*(const __m128i*)CurPtr,
> -Slashes));
> +#define VECTOR_TYPE __m128i
> +#define SET1_EPI8(v)_mm_set1_epi8(v)
> +#define CMPEQ_EPI8(v1,v2)   _mm_cmpeq_epi8(v1,v2)
> +#define MOVEMASK_EPI8(v)_mm_movemask_epi8(v)
> +#define STEP16
> +#elif __AVX2__
> +#define VECTOR_TYPE __m256i
> +#define SET1_EPI8(v)_mm256_set1_epi8(v)
> +#define CMPEQ_EPI8(v1,v2)   _mm256_cmpeq_epi8(v1,v2)
> +#define MOVEMASK_EPI8(v)_mm256_movemask_epi8(v)
> +#define STEP32
> +#endif

Surely any machine with AVX2 also has SSE2, and if both are defined
then your code will prefer to use the SSE2 intrinsics. This doesn't
seem right. Am I missing something?

Thanks,
Jay.
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r205517 - clang-format: Understand that "auto" is a type.

[Daniel Jasper]

Author: djasper
Date: Thu Apr  3 04:00:49 2014
New Revision: 205517

URL: http://llvm.org/viewvc/llvm-project?rev=205517&view=rev
Log:
clang-format: Understand that "auto" is a type.

Before:
  MACRO(auto * a);

After:
  MACRO(auto *a);

Modified:
cfe/trunk/lib/Format/TokenAnnotator.cpp
cfe/trunk/unittests/Format/FormatTest.cpp

Modified: cfe/trunk/lib/Format/TokenAnnotator.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/TokenAnnotator.cpp?rev=205517&r1=205516&r2=205517&view=diff
==
--- cfe/trunk/lib/Format/TokenAnnotator.cpp (original)
+++ cfe/trunk/lib/Format/TokenAnnotator.cpp Thu Apr  3 04:00:49 2014
@@ -196,7 +196,7 @@ private:
   !CurrentToken->Next->HasUnescapedNewline &&
   !CurrentToken->Next->isTrailingComment())
 HasMultipleParametersOnALine = true;
-  if (CurrentToken->is(tok::kw_const) ||
+  if (CurrentToken->isOneOf(tok::kw_const, tok::kw_auto) ||
   CurrentToken->isSimpleTypeSpecifier())
 Contexts.back().IsExpression = false;
   if (!consumeToken())

Modified: cfe/trunk/unittests/Format/FormatTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTest.cpp?rev=205517&r1=205516&r2=205517&view=diff
==
--- cfe/trunk/unittests/Format/FormatTest.cpp (original)
+++ cfe/trunk/unittests/Format/FormatTest.cpp Thu Apr  3 04:00:49 2014
@@ -4554,6 +4554,12 @@ TEST_F(FormatTest, UnderstandsUsesOfStar
   verifyFormat("foo();");
   verifyFormat("foo();");
 
+  verifyIndependentOfContext("MACRO(int *i);");
+  verifyIndependentOfContext("MACRO(auto *a);");
+  verifyIndependentOfContext("MACRO(const A *a);");
+  // FIXME: Is there a way to make this work?
+  // verifyIndependentOfContext("MACRO(A *a);");
+
   // FIXME: We cannot handle this case yet; we might be able to figure out that
   // foo d > v; doesn't make sense.
   verifyFormat("foo d > v;");


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [LLVMdev] 3.4.1 Release Plans

[Renato Golin]

On 3 April 2014 08:51, Richard Smith  wrote:

> It looks like this could be raised to 100% by restoring the prior order of
> the llvm::Intrinsic enum?
>

Do we want to go that far?

I'm not against it, I've done this before, but I'm just making sure we know
what we're getting into.

If we keep the order in trunk, we'll have created a rule of which enum
orders can't be changed (which messes up the code), if we change the stable
branch only, we'll make it harder to backport and create further dot
releases.

By all means, now is the time to experiment (on stable branches), so if you
want the latter, I won't oppose, but the former will face public opposition
right and left, I predict.

cheers,
--renato
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

[PATCH] [OPENMP] parsing 'linear' clause (for directive 'omp simd')

[Alexander Musman]

Hi doug.gregor, gribozavr, ABataev, hfinkel, cbergstrom, rengolin, 
fraggamuffin, rsmith,

Please review the changes for parsing of clause 'linear'.

http://llvm-reviews.chandlerc.com/D3272

Files:
  test/OpenMP/simd_misc_messages.c
  test/OpenMP/simd_linear_messages.cpp
  test/OpenMP/simd_ast_print.cpp
  include/clang/Basic/OpenMPKinds.def
  include/clang/Basic/DiagnosticGroups.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Sema/Sema.h
  include/clang/AST/DataRecursiveASTVisitor.h
  include/clang/AST/RecursiveASTVisitor.h
  include/clang/AST/OpenMPClause.h
  tools/libclang/CIndex.cpp
  lib/Basic/OpenMPKinds.cpp
  lib/Sema/TreeTransform.h
  lib/Sema/SemaOpenMP.cpp
  lib/AST/Stmt.cpp
  lib/AST/StmtPrinter.cpp
  lib/AST/StmtProfile.cpp
  lib/Parse/ParseOpenMP.cpp
  lib/Serialization/ASTReaderStmt.cpp
  lib/Serialization/ASTWriterStmt.cpp
Index: test/OpenMP/simd_misc_messages.c
===
--- test/OpenMP/simd_misc_messages.c
+++ test/OpenMP/simd_misc_messages.c
@@ -146,6 +146,76 @@
   for (i = 0; i < 16; ++i);
 }
 
+void test_linear()
+{
+  int i;
+  // expected-error@+1 {{expected expression}} expected-error@+1 {{expected ')'}} expected-note@+1 {{to match this '('}}
+  #pragma omp simd linear(
+  for (i = 0; i < 16; ++i) ;
+  // expected-error@+2 {{expected expression}}
+  // expected-error@+1 {{expected expression}} expected-error@+1 {{expected ')'}} expected-note@+1 {{to match this '('}}
+  #pragma omp simd linear(,
+  for (i = 0; i < 16; ++i) ;
+  // expected-error@+2 {{expected expression}}
+  // expected-error@+1 {{expected expression}}
+  #pragma omp simd linear(,)
+  for (i = 0; i < 16; ++i) ;
+  // expected-error@+1 {{expected expression}}
+  #pragma omp simd linear()
+  for (i = 0; i < 16; ++i) ;
+  // expected-error@+1 {{expected expression}}
+  #pragma omp simd linear(int)
+  for (i = 0; i < 16; ++i) ;
+  // expected-error@+1 {{expected variable name}}
+  #pragma omp simd linear(0)
+  for (i = 0; i < 16; ++i) ;
+  // expected-error@+1 {{use of undeclared identifier 'x'}}
+  #pragma omp simd linear(x)
+  for (i = 0; i < 16; ++i) ;
+  // expected-error@+2 {{use of undeclared identifier 'x'}}
+  // expected-error@+1 {{use of undeclared identifier 'y'}}
+  #pragma omp simd linear(x, y)
+  for (i = 0; i < 16; ++i) ;
+  // expected-error@+3 {{use of undeclared identifier 'x'}}
+  // expected-error@+2 {{use of undeclared identifier 'y'}}
+  // expected-error@+1 {{use of undeclared identifier 'z'}}
+  #pragma omp simd linear(x, y, z)
+  for (i = 0; i < 16; ++i) ;
+
+  int x, y;
+  // expected-error@+1 {{expected expression}}
+  #pragma omp simd linear(x:)
+  for (i = 0; i < 16; ++i) ;
+  // expected-error@+1 {{expected expression}} expected-error@+1 {{expected ')'}} expected-note@+1 {{to match this '('}}
+  #pragma omp simd linear(x:,)
+  for (i = 0; i < 16; ++i) ;
+  #pragma omp simd linear(x:1)
+  for (i = 0; i < 16; ++i) ;
+  #pragma omp simd linear(x:2*2)
+  for (i = 0; i < 16; ++i) ;
+  // expected-error@+1 {{expected ')'}} expected-note@+1 {{to match this '('}}
+  #pragma omp simd linear(x:1,y)
+  for (i = 0; i < 16; ++i) ;
+  // expected-error@+1 {{expected ')'}} expected-note@+1 {{to match this '('}}
+  #pragma omp simd linear(x:1,y,z:1)
+  for (i = 0; i < 16; ++i) ;
+
+  // expected-note@+2 {{defined as linear}}
+  // expected-error@+1 {{linear variable cannot be linear}}
+  #pragma omp simd linear(x) linear(x)
+  for (i = 0; i < 16; ++i) ;
+
+  // expected-note@+2 {{defined as private}}
+  // expected-error@+1 {{private variable cannot be linear}}
+  #pragma omp simd private(x) linear(x)
+  for (i = 0; i < 16; ++i) ;
+
+  // expected-note@+2 {{defined as linear}}
+  // expected-error@+1 {{linear variable cannot be private}}
+  #pragma omp simd linear(x) private(x)
+  for (i = 0; i < 16; ++i) ;
+}
+
 void test_private()
 {
   int i;
Index: test/OpenMP/simd_linear_messages.cpp
===
--- test/OpenMP/simd_linear_messages.cpp
+++ test/OpenMP/simd_linear_messages.cpp
@@ -0,0 +1,205 @@
+// RUN: %clang_cc1 -verify -fopenmp=libiomp5 %s
+
+namespace X {
+  int x;
+};
+
+struct B {
+  static int ib; // expected-note {{'B::ib' declared here}}
+  static int bfoo() { return 8; }
+};
+
+int bfoo() { return 4; }
+
+int z;
+const int C1 = 1;
+const int C2 = 2;
+void test_linear_colons()
+{
+  int B = 0;
+  #pragma omp simd linear(B:bfoo())
+  for (int i = 0; i < 10; ++i) ;
+  // expected-error@+1 {{unexpected ':' in nested name specifier; did you mean '::'}}
+  #pragma omp simd linear(B::ib:B:bfoo())
+  for (int i = 0; i < 10; ++i) ;
+  // expected-error@+1 {{use of undeclared identifier 'ib'; did you mean 'B::ib'}}
+  #pragma omp simd linear(B:ib)
+  for (int i = 0; i < 10; ++i) ;
+  // expected-error@+1 {{unexpected ':' in nested name specifier; did you mean '::'?}}
+  #pragma omp simd linear(z:B:ib)
+  for (int i = 0; i < 10; ++i) ;
+  #pragma omp simd linear(B:B::bfoo())
+  

Re: [libcxx] r205507 - Add a section about reporting bugs and contributing patches

[Tobias Grosser]

On 04/03/2014 05:13 AM, Marshall Clow wrote:

Author: marshall
Date: Wed Apr  2 22:13:12 2014
New Revision: 205507

URL: http://llvm.org/viewvc/llvm-project?rev=205507&view=rev
Log:
Add a section about reporting bugs and contributing patches

Modified:
 libcxx/trunk/www/index.html

Modified: libcxx/trunk/www/index.html
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/index.html?rev=205507&r1=205506&r2=205507&view=diff
==
--- libcxx/trunk/www/index.html (original)
+++ libcxx/trunk/www/index.html Wed Apr  2 22:13:12 2014
@@ -207,6 +207,23 @@ against it with -fno-rtti i
(http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev";>clang mailing 
list).


+  Bug reports and patches
+  
+
+
+If you think you've found a bug in libc++, please report it using
+the http://llvm.org/bugs";>LLVM Bugzilla. If you're not sure, you
+can post a meesage to the http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev";>cfe-dev


Typo: message

Tobias


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] AArch64: Add command line option to select big or little endian

[scott douglass]

  The -EB/-EL options already exist, but effect only the MIPS backend (they are 
silently ignored for ARM target).  This patch introduces 
-mbig-endian/-mlittle-endian as aliases for them.  The options are:

  [this is really just a restatement of what Tim said earlier]
  1. leave it as it is (possibly removing the tests for -EB/-EL from ARM 
targets)
  2. invert the aliasing (but that would mean otherwise needless changes to the 
MIPS targets)
  3. explicitly fault use of -EL/-EB for ARM targets (doesn't seem worthwhile)

  Personally I vote for 1 with the -EB/-EL tests removed (or left in).

http://llvm-reviews.chandlerc.com/D3215
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [LLVMdev] 3.4.1 Release Plans

[Richard Smith]

It looks like this could be raised to 100% by restoring the prior order of
the llvm::Intrinsic enum?


On Wed, Apr 2, 2014 at 10:41 PM, Jiangning Liu wrote:

> Hi Tom,
>
> Please refer to attached abi-compliance-checker report for those patches
> I'm asking for back porting to 3.4.1.
>
> Test Results
> --
> Total Header Files 882 <#145261e7e2a6e86e_Headers>Total Shared Libraries 
> 2<#145261e7e2a6e86e_Libs> Total
> Symbols / Types5491 / 2756 Verdict
>
> *Incompatible(0.1%)*
>
> So the backward compatibility is 99.9%, and I don't see big issues.
>
> Thanks,
> -Jiangning
>
>
> 2014-04-02 23:36 GMT+08:00 Tom Stellard :
>
> On Wed, Apr 02, 2014 at 03:38:18PM +0100, Tim Northover wrote:
>> > Hi Renato,
>> >
>> > > Apart from this one, I don't see any problem with the merges regarding
>> > > ABI compatibility.
>> >
>> > I think Tom meant ABI compatibility in the libLLVMWhatever.so
>> > libraries (and headers) rather than generated code. The 3.4.1 binaries
>> > should be drop-in replacements for whatever systems we produce.
>> >
>>
>> Yes, I was talking about LLVM's library ABI compatibility with 3.4.0
>> rather AARCH64 ABI compatibility.
>>
>> -Tom
>> ___
>> cfe-commits mailing list
>> cfe-commits@cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>
>
>
> --
> Thanks,
> -Jiangning
>
> ___
> cfe-commits mailing list
> cfe-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [libcxx] r205504 - Mark C++14 status as 'complete'

[Tobias Grosser]

On 04/03/2014 04:35 AM, Marshall Clow wrote:

Author: marshall
Date: Wed Apr  2 21:35:29 2014
New Revision: 205504

URL: http://llvm.org/viewvc/llvm-project?rev=205504&view=rev
Log:
Mark C++14 status as 'complete'


#3778 is not marked as neither complete nor out of scope. Maybe it could 
need some clarification.


Tobias
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits