[PATCH] D21830: Remove -mrelax-all from Clang -O0

2016-06-29 Thread Dean Michael Berris via cfe-commits
dberris created this revision.
dberris added reviewers: echristo, rafael, grosbach.
dberris added a subscriber: cfe-commits.
Herald added a subscriber: mehdi_amini.

Remove the -mrelax-all options passed onto the integrated assembler in
-O0.

http://reviews.llvm.org/D21830

Files:
  lib/Driver/Tools.cpp
  test/Driver/integrated-as.c

Index: test/Driver/integrated-as.c
===
--- test/Driver/integrated-as.c
+++ test/Driver/integrated-as.c
@@ -1,7 +1,6 @@
 // RUN: %clang -### -c -save-temps -integrated-as %s 2>&1 | FileCheck %s
 
 // CHECK: cc1as
-// CHECK: -mrelax-all
 
 // RUN: %clang -### -fintegrated-as -c -save-temps %s 2>&1 | FileCheck %s 
-check-prefix FIAS
 
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -2721,38 +2721,10 @@
   return !UseDwarfDirectory;
 }
 
-/// \brief Check whether the given input tree contains any compilation actions.
-static bool ContainsCompileAction(const Action *A) {
-  if (isa(A) || isa(A))
-return true;
-
-  for (const auto &AI : A->inputs())
-if (ContainsCompileAction(AI))
-  return true;
-
-  return false;
-}
-
 /// \brief Check if -relax-all should be passed to the internal assembler.
-/// This is done by default when compiling non-assembler source with -O0.
 static bool UseRelaxAll(Compilation &C, const ArgList &Args) {
-  bool RelaxDefault = true;
-
-  if (Arg *A = Args.getLastArg(options::OPT_O_Group))
-RelaxDefault = A->getOption().matches(options::OPT_O0);
-
-  if (RelaxDefault) {
-RelaxDefault = false;
-for (const auto &Act : C.getActions()) {
-  if (ContainsCompileAction(Act)) {
-RelaxDefault = true;
-break;
-  }
-}
-  }
-
   return Args.hasFlag(options::OPT_mrelax_all, options::OPT_mno_relax_all,
-  RelaxDefault);
+  false);
 }
 
 // Convert an arg of the form "-gN" or "-ggdbN" or one of their aliases


Index: test/Driver/integrated-as.c
===
--- test/Driver/integrated-as.c
+++ test/Driver/integrated-as.c
@@ -1,7 +1,6 @@
 // RUN: %clang -### -c -save-temps -integrated-as %s 2>&1 | FileCheck %s
 
 // CHECK: cc1as
-// CHECK: -mrelax-all
 
 // RUN: %clang -### -fintegrated-as -c -save-temps %s 2>&1 | FileCheck %s -check-prefix FIAS
 
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -2721,38 +2721,10 @@
   return !UseDwarfDirectory;
 }
 
-/// \brief Check whether the given input tree contains any compilation actions.
-static bool ContainsCompileAction(const Action *A) {
-  if (isa(A) || isa(A))
-return true;
-
-  for (const auto &AI : A->inputs())
-if (ContainsCompileAction(AI))
-  return true;
-
-  return false;
-}
-
 /// \brief Check if -relax-all should be passed to the internal assembler.
-/// This is done by default when compiling non-assembler source with -O0.
 static bool UseRelaxAll(Compilation &C, const ArgList &Args) {
-  bool RelaxDefault = true;
-
-  if (Arg *A = Args.getLastArg(options::OPT_O_Group))
-RelaxDefault = A->getOption().matches(options::OPT_O0);
-
-  if (RelaxDefault) {
-RelaxDefault = false;
-for (const auto &Act : C.getActions()) {
-  if (ContainsCompileAction(Act)) {
-RelaxDefault = true;
-break;
-  }
-}
-  }
-
   return Args.hasFlag(options::OPT_mrelax_all, options::OPT_mno_relax_all,
-  RelaxDefault);
+  false);
 }
 
 // Convert an arg of the form "-gN" or "-ggdbN" or one of their aliases
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r274110 - [AVX512] Zero extend cmp intrinsic return value.

2016-06-29 Thread Igor Breger via cfe-commits
Author: ibreger
Date: Wed Jun 29 03:14:17 2016
New Revision: 274110

URL: http://llvm.org/viewvc/llvm-project?rev=274110&view=rev
Log:
[AVX512]  Zero extend cmp intrinsic return value.

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

Modified:
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/test/CodeGen/avx512vl-builtins.c

Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=274110&r1=274109&r2=274110&view=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Wed Jun 29 03:14:17 2016
@@ -6460,8 +6460,8 @@ static Value *EmitX86MaskedCompare(CodeG
   Indices[i] = i;
 for (unsigned i = NumElts; i != 8; ++i)
   Indices[i] = NumElts;
-Cmp = CGF.Builder.CreateShuffleVector(Cmp, UndefValue::get(Cmp->getType()),
-  Indices);
+Cmp = CGF.Builder.CreateShuffleVector(
+Cmp, llvm::Constant::getNullValue(Cmp->getType()), Indices);
   }
   return CGF.Builder.CreateBitCast(Cmp,
IntegerType::get(CGF.getLLVMContext(),

Modified: cfe/trunk/test/CodeGen/avx512vl-builtins.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/avx512vl-builtins.c?rev=274110&r1=274109&r2=274110&view=diff
==
--- cfe/trunk/test/CodeGen/avx512vl-builtins.c (original)
+++ cfe/trunk/test/CodeGen/avx512vl-builtins.c Wed Jun 29 03:14:17 2016
@@ -8,6 +8,7 @@
 __mmask8 test_mm_cmpeq_epu32_mask(__m128i __a, __m128i __b) {
   // CHECK-LABEL: @test_mm_cmpeq_epu32_mask
   // CHECK: icmp eq <4 x i32> %{{.*}}, %{{.*}}
+  // CHECK: shufflevector <4 x i1> %{{.*}}, <4 x i1> zeroinitializer, <8 x 
i32> 
   return (__mmask8)_mm_cmpeq_epu32_mask(__a, __b);
 }
 


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


Re: [PATCH] D21746: [AVX512] Zero extend cmp intrinsic return value.

2016-06-29 Thread Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL274110: [AVX512]  Zero extend cmp intrinsic return value. 
(authored by ibreger).

Changed prior to commit:
  http://reviews.llvm.org/D21746?vs=61953&id=62185#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D21746

Files:
  cfe/trunk/lib/CodeGen/CGBuiltin.cpp
  cfe/trunk/test/CodeGen/avx512vl-builtins.c

Index: cfe/trunk/test/CodeGen/avx512vl-builtins.c
===
--- cfe/trunk/test/CodeGen/avx512vl-builtins.c
+++ cfe/trunk/test/CodeGen/avx512vl-builtins.c
@@ -8,6 +8,7 @@
 __mmask8 test_mm_cmpeq_epu32_mask(__m128i __a, __m128i __b) {
   // CHECK-LABEL: @test_mm_cmpeq_epu32_mask
   // CHECK: icmp eq <4 x i32> %{{.*}}, %{{.*}}
+  // CHECK: shufflevector <4 x i1> %{{.*}}, <4 x i1> zeroinitializer, <8 x 
i32> 
   return (__mmask8)_mm_cmpeq_epu32_mask(__a, __b);
 }
 
Index: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
===
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp
@@ -6460,8 +6460,8 @@
   Indices[i] = i;
 for (unsigned i = NumElts; i != 8; ++i)
   Indices[i] = NumElts;
-Cmp = CGF.Builder.CreateShuffleVector(Cmp, UndefValue::get(Cmp->getType()),
-  Indices);
+Cmp = CGF.Builder.CreateShuffleVector(
+Cmp, llvm::Constant::getNullValue(Cmp->getType()), Indices);
   }
   return CGF.Builder.CreateBitCast(Cmp,
IntegerType::get(CGF.getLLVMContext(),


Index: cfe/trunk/test/CodeGen/avx512vl-builtins.c
===
--- cfe/trunk/test/CodeGen/avx512vl-builtins.c
+++ cfe/trunk/test/CodeGen/avx512vl-builtins.c
@@ -8,6 +8,7 @@
 __mmask8 test_mm_cmpeq_epu32_mask(__m128i __a, __m128i __b) {
   // CHECK-LABEL: @test_mm_cmpeq_epu32_mask
   // CHECK: icmp eq <4 x i32> %{{.*}}, %{{.*}}
+  // CHECK: shufflevector <4 x i1> %{{.*}}, <4 x i1> zeroinitializer, <8 x i32> 
   return (__mmask8)_mm_cmpeq_epu32_mask(__a, __b);
 }
 
Index: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
===
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp
@@ -6460,8 +6460,8 @@
   Indices[i] = i;
 for (unsigned i = NumElts; i != 8; ++i)
   Indices[i] = NumElts;
-Cmp = CGF.Builder.CreateShuffleVector(Cmp, UndefValue::get(Cmp->getType()),
-  Indices);
+Cmp = CGF.Builder.CreateShuffleVector(
+Cmp, llvm::Constant::getNullValue(Cmp->getType()), Indices);
   }
   return CGF.Builder.CreateBitCast(Cmp,
IntegerType::get(CGF.getLLVMContext(),
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D21833: [clang-tidy] Fix more enum declaration cases in misc-unused-using-decls check.

2016-06-29 Thread Haojian Wu via cfe-commits
hokein created this revision.
hokein added a reviewer: alexfh.
hokein added subscribers: cfe-commits, Eugene.Zelenko.

Fix PR28350.

http://reviews.llvm.org/D21833

Files:
  clang-tidy/misc/UnusedUsingDeclsCheck.cpp
  test/clang-tidy/misc-unused-using-decls.cpp

Index: test/clang-tidy/misc-unused-using-decls.cpp
===
--- test/clang-tidy/misc-unused-using-decls.cpp
+++ test/clang-tidy/misc-unused-using-decls.cpp
@@ -44,11 +44,13 @@
 extern ostream cout;
 ostream &endl(ostream &os);
 
-enum Color {
-  Green,
-  Red,
-  Yellow
-};
+enum Color1 { Green };
+
+enum Color2 { Red };
+
+enum Color3 { Yellow };
+
+enum Color4 { Blue };
 
 }  // namespace n
 
@@ -126,11 +128,11 @@
 using n::H;
 }
 
-using n::Color;
-// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: using decl 'Color' is unused
-using n::Green;
-// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: using decl 'Green' is unused
-using n::Red;
+using n::Color1;
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: using decl 'Color1' is unused
+using n::Color2;
+using n::Color3;
+using n::Blue;
 
 // - Usages -
 void f(B b);
@@ -144,5 +146,7 @@
   UsedFunc();
   UsedTemplateFunc();
   cout << endl;
-  int t = Red;
+  Color2 color2;
+  int t1 = Color3::Yellow;
+  int t2 = Blue;
 }
Index: clang-tidy/misc/UnusedUsingDeclsCheck.cpp
===
--- clang-tidy/misc/UnusedUsingDeclsCheck.cpp
+++ clang-tidy/misc/UnusedUsingDeclsCheck.cpp
@@ -18,6 +18,11 @@
 namespace tidy {
 namespace misc {
 
+namespace {
+// FIXME: Move this node matcher to ASTMatcher.
+const internal::VariadicDynCastAllOfMatcher enumType;
+} // namespace
+
 // A function that helps to tell whether a TargetDecl in a UsingDecl will be
 // checked. Only variable, function, function template, class template, class,
 // enum declaration and enum constant declaration are considered.
@@ -31,6 +36,7 @@
 void UnusedUsingDeclsCheck::registerMatchers(MatchFinder *Finder) {
   Finder->addMatcher(usingDecl(isExpansionInMainFile()).bind("using"), this);
   auto DeclMatcher = hasDeclaration(namedDecl().bind("used"));
+  Finder->addMatcher(loc(enumType(DeclMatcher)), this);
   Finder->addMatcher(loc(recordType(DeclMatcher)), this);
   Finder->addMatcher(loc(templateSpecializationType(DeclMatcher)), this);
   Finder->addMatcher(declRefExpr().bind("used"), this);
@@ -94,6 +100,8 @@
   removeFromFoundDecls(VD);
 } else if (const auto *ECD = dyn_cast(DRE->getDecl())) {
   removeFromFoundDecls(ECD);
+  if (const auto *ET = ECD->getType()->getAs())
+removeFromFoundDecls(ET->getDecl());
 }
   }
   // Check the uninstantiated template function usage.


Index: test/clang-tidy/misc-unused-using-decls.cpp
===
--- test/clang-tidy/misc-unused-using-decls.cpp
+++ test/clang-tidy/misc-unused-using-decls.cpp
@@ -44,11 +44,13 @@
 extern ostream cout;
 ostream &endl(ostream &os);
 
-enum Color {
-  Green,
-  Red,
-  Yellow
-};
+enum Color1 { Green };
+
+enum Color2 { Red };
+
+enum Color3 { Yellow };
+
+enum Color4 { Blue };
 
 }  // namespace n
 
@@ -126,11 +128,11 @@
 using n::H;
 }
 
-using n::Color;
-// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: using decl 'Color' is unused
-using n::Green;
-// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: using decl 'Green' is unused
-using n::Red;
+using n::Color1;
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: using decl 'Color1' is unused
+using n::Color2;
+using n::Color3;
+using n::Blue;
 
 // - Usages -
 void f(B b);
@@ -144,5 +146,7 @@
   UsedFunc();
   UsedTemplateFunc();
   cout << endl;
-  int t = Red;
+  Color2 color2;
+  int t1 = Color3::Yellow;
+  int t2 = Blue;
 }
Index: clang-tidy/misc/UnusedUsingDeclsCheck.cpp
===
--- clang-tidy/misc/UnusedUsingDeclsCheck.cpp
+++ clang-tidy/misc/UnusedUsingDeclsCheck.cpp
@@ -18,6 +18,11 @@
 namespace tidy {
 namespace misc {
 
+namespace {
+// FIXME: Move this node matcher to ASTMatcher.
+const internal::VariadicDynCastAllOfMatcher enumType;
+} // namespace
+
 // A function that helps to tell whether a TargetDecl in a UsingDecl will be
 // checked. Only variable, function, function template, class template, class,
 // enum declaration and enum constant declaration are considered.
@@ -31,6 +36,7 @@
 void UnusedUsingDeclsCheck::registerMatchers(MatchFinder *Finder) {
   Finder->addMatcher(usingDecl(isExpansionInMainFile()).bind("using"), this);
   auto DeclMatcher = hasDeclaration(namedDecl().bind("used"));
+  Finder->addMatcher(loc(enumType(DeclMatcher)), this);
   Finder->addMatcher(loc(recordType(DeclMatcher)), this);
   Finder->addMatcher(loc(templateSpecializationType(DeclMatcher)), this);
   Finder->addMatcher(declRefExpr().bind("used"), this);
@@ -94,6 +100,8 @@
   removeFromFoundDecls(VD);
 } else if (const auto *ECD = dyn_cast(DRE->getDecl())) {
   removeFromFo

Re: [PATCH] D21501: [Driver] Add support for Broadcom Vulcan core

2016-06-29 Thread pankaj gode via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL274114: [Driver][AArch64] Add support for Broadcom Vulcan 
core. (authored by pgode).

Changed prior to commit:
  http://reviews.llvm.org/D21501?vs=61192&id=62195#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D21501

Files:
  cfe/trunk/lib/Basic/Targets.cpp
  cfe/trunk/lib/Driver/Tools.cpp
  cfe/trunk/test/Driver/aarch64-cpus.c
  cfe/trunk/test/Preprocessor/aarch64-target-features.c

Index: cfe/trunk/test/Preprocessor/aarch64-target-features.c
===
--- cfe/trunk/test/Preprocessor/aarch64-target-features.c
+++ cfe/trunk/test/Preprocessor/aarch64-target-features.c
@@ -95,14 +95,16 @@
 // RUN: %clang -target aarch64 -mcpu=cortex-a73 -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-MCPU-CORTEX-A73 %s
 // RUN: %clang -target aarch64 -mcpu=exynos-m1 -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-MCPU-M1 %s
 // RUN: %clang -target aarch64 -mcpu=kryo -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-MCPU-KRYO %s
+// RUN: %clang -target aarch64 -mcpu=vulcan -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-MCPU-VULCAN %s
 // CHECK-MCPU-CYCLONE: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" 
"-target-feature" "+neon" "-target-feature" "+crypto" "-target-feature" "+zcm" 
"-target-feature" "+zcz"
 // CHECK-MCPU-A35: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" "-target-feature" 
"+neon" "-target-feature" "+crc" "-target-feature" "+crypto"
 // CHECK-MCPU-A53: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" "-target-feature" 
"+neon" "-target-feature" "+crc" "-target-feature" "+crypto"
 // CHECK-MCPU-A57: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" "-target-feature" 
"+neon" "-target-feature" "+crc" "-target-feature" "+crypto"
 // CHECK-MCPU-A72: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" "-target-feature" 
"+neon" "-target-feature" "+crc" "-target-feature" "+crypto"
 // CHECK-MCPU-CORTEX-A73: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" 
"-target-feature" "+neon" "-target-feature" "+crc" "-target-feature" "+crypto"
 // CHECK-MCPU-M1: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" "-target-feature" 
"+neon" "-target-feature" "+crc" "-target-feature" "+crypto"
 // CHECK-MCPU-KRYO: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" "-target-feature" 
"+neon" "-target-feature" "+crc" "-target-feature" "+crypto"
+// CHECK-MCPU-VULCAN: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" "-target-feature" 
"+neon" "-target-feature" "+crc" "-target-feature" "+crypto"
 
 // RUN: %clang -target x86_64-apple-macosx -arch arm64 -### -c %s 2>&1 | 
FileCheck --check-prefix=CHECK-ARCH-ARM64 %s
 // CHECK-ARCH-ARM64: "-target-cpu" "cyclone" "-target-feature" "+neon" 
"-target-feature" "+crypto" "-target-feature" "+zcm" "-target-feature" "+zcz"
Index: cfe/trunk/test/Driver/aarch64-cpus.c
===
--- cfe/trunk/test/Driver/aarch64-cpus.c
+++ cfe/trunk/test/Driver/aarch64-cpus.c
@@ -114,6 +114,20 @@
 // RUN: %clang -target arm64 -mlittle-endian -mtune=kryo -### -c %s 2>&1 | 
FileCheck -check-prefix=ARM64-KRYO %s
 // ARM64-KRYO: "-cc1"{{.*}} "-triple" "arm64{{.*}}" "-target-cpu" "kryo"
 
+// RUN: %clang -target aarch64 -mcpu=vulcan -### -c %s 2>&1 | FileCheck 
-check-prefix=VULCAN %s
+// RUN: %clang -target aarch64 -mlittle-endian -mcpu=vulcan -### -c %s 2>&1 | 
FileCheck -check-prefix=VULCAN %s
+// RUN: %clang -target aarch64_be -mlittle-endian -mcpu=vulcan -### -c %s 2>&1 
| FileCheck -check-prefix=VULCAN %s
+// RUN: %clang -target aarch64 -mtune=vulcan -### -c %s 2>&1 | FileCheck 
-check-prefix=VULCAN %s
+// RUN: %clang -target aarch64 -mlittle-endian -mtune=vulcan -### -c %s 2>&1 | 
FileCheck -check-prefix=VULCAN %s
+// RUN: %clang -target aarch64_be -mlittle-endian -mtune=vulcan -### -c %s 
2>&1 | FileCheck -check-prefix=VULCAN %s
+// VULCAN: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" "-target-cpu" "vulcan"
+
+// RUN: %clang -target arm64 -mcpu=vulcan -### -c %s 2>&1 | FileCheck 
-check-prefix=ARM64-VULCAN %s
+// RUN: %clang -target arm64 -mlittle-endian -mcpu=vulcan -### -c %s 2>&1 | 
FileCheck -check-prefix=ARM64-VULCAN %s
+// RUN: %clang -target arm64 -mtune=vulcan -### -c %s 2>&1 | FileCheck 
-check-prefix=ARM64-VULCAN %s
+// RUN: %clang -target arm64 -mlittle-endian -mtune=vulcan -### -c %s 2>&1 | 
FileCheck -check-prefix=ARM64-VULCAN %s
+// ARM64-VULCAN: "-cc1"{{.*}} "-triple" "arm64{{.*}}" "-target-cpu" "vulcan"
+
 // RUN: %clang -target aarch64_be -### -c %s 2>&1 | FileCheck 
-check-prefix=GENERIC-BE %s
 // RUN: %clang -target aarch64 -mbig-endian -### -c %s 2>&1 | FileCheck 
-check-prefix=GENERIC-BE %s
 // RUN: %clang -target aarch64_be -mbig-endian -### -c %s 2>&1 | FileCheck 
-check-prefix=GENERIC-BE %s
@@ -167,11 +181,21 @@
 // RUN: %clang -target aarch64_be -mbig-endian -mtune=exynos-m1 -### -c %s 
2>&1 | FileCheck -check-prefix=M1-BE %s
 // M1-BE: "-cc1"{{.*}} "-triple" "aarch64_be{{.*}}" "-target-cpu" "exynos-m1"
 
+// RUN: %clang -target aarch64_be -mcpu=vulcan -### -c %s 2>

r274114 - [Driver][AArch64] Add support for Broadcom Vulcan core.

2016-06-29 Thread Pankaj Gode via cfe-commits
Author: pgode
Date: Wed Jun 29 05:00:31 2016
New Revision: 274114

URL: http://llvm.org/viewvc/llvm-project?rev=274114&view=rev
Log:
[Driver][AArch64] Add support for Broadcom Vulcan core.

Adding support for new Broadcom Vulcan core (ARMv8.1A).

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



Modified:
cfe/trunk/lib/Basic/Targets.cpp
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/test/Driver/aarch64-cpus.c
cfe/trunk/test/Preprocessor/aarch64-target-features.c

Modified: cfe/trunk/lib/Basic/Targets.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=274114&r1=274113&r2=274114&view=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Wed Jun 29 05:00:31 2016
@@ -5731,6 +5731,7 @@ public:
 .Case("cortex-a73", true)
 .Case("cyclone", true)
 .Case("kryo", true)
+.Case("vulcan", true)
 .Default(false);
 return CPUKnown;
   }

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=274114&r1=274113&r2=274114&view=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Wed Jun 29 05:00:31 2016
@@ -2352,7 +2352,7 @@ static bool DecodeAArch64Mcpu(const Driv
   CPU = Split.first;
   if (CPU == "cortex-a53" || CPU == "cortex-a57" ||
   CPU == "cortex-a72" || CPU == "cortex-a35" || CPU == "exynos-m1" ||
-  CPU == "kryo"   || CPU == "cortex-a73") {
+  CPU == "kryo"   || CPU == "cortex-a73" || CPU == "vulcan") {
 Features.push_back("+neon");
 Features.push_back("+crc");
 Features.push_back("+crypto");

Modified: cfe/trunk/test/Driver/aarch64-cpus.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/aarch64-cpus.c?rev=274114&r1=274113&r2=274114&view=diff
==
--- cfe/trunk/test/Driver/aarch64-cpus.c (original)
+++ cfe/trunk/test/Driver/aarch64-cpus.c Wed Jun 29 05:00:31 2016
@@ -114,6 +114,20 @@
 // RUN: %clang -target arm64 -mlittle-endian -mtune=kryo -### -c %s 2>&1 | 
FileCheck -check-prefix=ARM64-KRYO %s
 // ARM64-KRYO: "-cc1"{{.*}} "-triple" "arm64{{.*}}" "-target-cpu" "kryo"
 
+// RUN: %clang -target aarch64 -mcpu=vulcan -### -c %s 2>&1 | FileCheck 
-check-prefix=VULCAN %s
+// RUN: %clang -target aarch64 -mlittle-endian -mcpu=vulcan -### -c %s 2>&1 | 
FileCheck -check-prefix=VULCAN %s
+// RUN: %clang -target aarch64_be -mlittle-endian -mcpu=vulcan -### -c %s 2>&1 
| FileCheck -check-prefix=VULCAN %s
+// RUN: %clang -target aarch64 -mtune=vulcan -### -c %s 2>&1 | FileCheck 
-check-prefix=VULCAN %s
+// RUN: %clang -target aarch64 -mlittle-endian -mtune=vulcan -### -c %s 2>&1 | 
FileCheck -check-prefix=VULCAN %s
+// RUN: %clang -target aarch64_be -mlittle-endian -mtune=vulcan -### -c %s 
2>&1 | FileCheck -check-prefix=VULCAN %s
+// VULCAN: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" "-target-cpu" "vulcan"
+
+// RUN: %clang -target arm64 -mcpu=vulcan -### -c %s 2>&1 | FileCheck 
-check-prefix=ARM64-VULCAN %s
+// RUN: %clang -target arm64 -mlittle-endian -mcpu=vulcan -### -c %s 2>&1 | 
FileCheck -check-prefix=ARM64-VULCAN %s
+// RUN: %clang -target arm64 -mtune=vulcan -### -c %s 2>&1 | FileCheck 
-check-prefix=ARM64-VULCAN %s
+// RUN: %clang -target arm64 -mlittle-endian -mtune=vulcan -### -c %s 2>&1 | 
FileCheck -check-prefix=ARM64-VULCAN %s
+// ARM64-VULCAN: "-cc1"{{.*}} "-triple" "arm64{{.*}}" "-target-cpu" "vulcan"
+
 // RUN: %clang -target aarch64_be -### -c %s 2>&1 | FileCheck 
-check-prefix=GENERIC-BE %s
 // RUN: %clang -target aarch64 -mbig-endian -### -c %s 2>&1 | FileCheck 
-check-prefix=GENERIC-BE %s
 // RUN: %clang -target aarch64_be -mbig-endian -### -c %s 2>&1 | FileCheck 
-check-prefix=GENERIC-BE %s
@@ -167,11 +181,21 @@
 // RUN: %clang -target aarch64_be -mbig-endian -mtune=exynos-m1 -### -c %s 
2>&1 | FileCheck -check-prefix=M1-BE %s
 // M1-BE: "-cc1"{{.*}} "-triple" "aarch64_be{{.*}}" "-target-cpu" "exynos-m1"
 
+// RUN: %clang -target aarch64_be -mcpu=vulcan -### -c %s 2>&1 | FileCheck 
-check-prefix=VULCAN-BE %s
+// RUN: %clang -target aarch64 -mbig-endian -mcpu=vulcan -### -c %s 2>&1 | 
FileCheck -check-prefix=VULCAN-BE %s
+// RUN: %clang -target aarch64_be -mbig-endian -mcpu=vulcan -### -c %s 2>&1 | 
FileCheck -check-prefix=VULCAN-BE %s
+// RUN: %clang -target aarch64_be -mtune=vulcan -### -c %s 2>&1 | FileCheck 
-check-prefix=VULCAN-BE %s
+// RUN: %clang -target aarch64 -mbig-endian -mtune=vulcan -### -c %s 2>&1 | 
FileCheck -check-prefix=VULCAN-BE %s
+// RUN: %clang -target aarch64_be -mbig-endian -mtune=vulcan -### -c %s 2>&1 | 
FileCheck -check-prefix=VULCAN-BE %s
+// VULCAN-BE: "-cc1"{{.*}} "-triple" "aarch64_be{{.*}}" "-target-cpu"

Re: [PATCH] D21367: AMDGPU: Set amdgpu_kernel calling convention for OpenCL kernels.

2016-06-29 Thread Nikolay Haustov via cfe-commits
nhaustov updated this revision to Diff 62198.
nhaustov added a comment.

Update after discussion with Sam and review from Anastasia.


http://reviews.llvm.org/D21367

Files:
  include/clang/Basic/Specifiers.h
  lib/AST/ItaniumMangle.cpp
  lib/AST/Type.cpp
  lib/AST/TypePrinter.cpp
  lib/Basic/Targets.cpp
  lib/CodeGen/CGCall.cpp
  lib/CodeGen/CGDebugInfo.cpp
  lib/CodeGen/CodeGenTypes.h
  lib/CodeGen/TargetInfo.cpp
  lib/CodeGen/TargetInfo.h
  lib/Sema/SemaType.cpp
  test/CodeGenOpenCL/amdgpu-call-kernel.cl
  test/CodeGenOpenCL/amdgpu-calling-conv.cl
  test/CodeGenOpenCL/amdgpu-num-gpr-attr.cl
  tools/libclang/CXType.cpp

Index: tools/libclang/CXType.cpp
===
--- tools/libclang/CXType.cpp
+++ tools/libclang/CXType.cpp
@@ -541,7 +541,7 @@
   TCALLINGCONV(PreserveMost);
   TCALLINGCONV(PreserveAll);
 case CC_SpirFunction: return CXCallingConv_Unexposed;
-case CC_SpirKernel: return CXCallingConv_Unexposed;
+case CC_OpenCLKernel: return CXCallingConv_Unexposed;
   break;
 }
 #undef TCALLINGCONV
Index: test/CodeGenOpenCL/amdgpu-num-gpr-attr.cl
===
--- test/CodeGenOpenCL/amdgpu-num-gpr-attr.cl
+++ test/CodeGenOpenCL/amdgpu-num-gpr-attr.cl
@@ -5,23 +5,23 @@
 
 __attribute__((amdgpu_num_vgpr(64))) // expected-no-diagnostics
 kernel void test_num_vgpr64() {
-// CHECK: define void @test_num_vgpr64() [[ATTR_VGPR64:#[0-9]+]]
+// CHECK: define amdgpu_kernel void @test_num_vgpr64() [[ATTR_VGPR64:#[0-9]+]]
 }
 
 __attribute__((amdgpu_num_sgpr(32))) // expected-no-diagnostics
 kernel void test_num_sgpr32() {
-// CHECK: define void @test_num_sgpr32() [[ATTR_SGPR32:#[0-9]+]]
+// CHECK: define amdgpu_kernel void @test_num_sgpr32() [[ATTR_SGPR32:#[0-9]+]]
 }
 
 __attribute__((amdgpu_num_vgpr(64), amdgpu_num_sgpr(32))) // expected-no-diagnostics
 kernel void test_num_vgpr64_sgpr32() {
-// CHECK: define void @test_num_vgpr64_sgpr32() [[ATTR_VGPR64_SGPR32:#[0-9]+]]
+// CHECK: define amdgpu_kernel void @test_num_vgpr64_sgpr32() [[ATTR_VGPR64_SGPR32:#[0-9]+]]
 
 }
 
 __attribute__((amdgpu_num_sgpr(20), amdgpu_num_vgpr(40))) // expected-no-diagnostics
 kernel void test_num_sgpr20_vgpr40() {
-// CHECK: define void @test_num_sgpr20_vgpr40() [[ATTR_SGPR20_VGPR40:#[0-9]+]]
+// CHECK: define amdgpu_kernel void @test_num_sgpr20_vgpr40() [[ATTR_SGPR20_VGPR40:#[0-9]+]]
 }
 
 __attribute__((amdgpu_num_vgpr(0))) // expected-no-diagnostics
Index: test/CodeGenOpenCL/amdgpu-calling-conv.cl
===
--- /dev/null
+++ test/CodeGenOpenCL/amdgpu-calling-conv.cl
@@ -0,0 +1,12 @@
+// REQUIRES: amdgpu-registered-target
+// RUN: %clang_cc1 -triple amdgcn-unknown-unknown -S -emit-llvm -o - %s | FileCheck %s
+
+// CHECK: define amdgpu_kernel void @calling_conv_amdgpu_kernel()
+kernel void calling_conv_amdgpu_kernel()
+{
+}
+
+// CHECK: define void @calling_conv_none()
+void calling_conv_none()
+{
+}
Index: test/CodeGenOpenCL/amdgpu-call-kernel.cl
===
--- /dev/null
+++ test/CodeGenOpenCL/amdgpu-call-kernel.cl
@@ -0,0 +1,14 @@
+// REQUIRES: amdgpu-registered-target
+// RUN: %clang_cc1 -triple amdgcn-unknown-unknown -S -emit-llvm -o - %s | FileCheck %s
+// CHECK: define amdgpu_kernel void @test_call_kernel(i32 addrspace(1)* nocapture %out)
+// CHECK: store i32 4, i32 addrspace(1)* %out, align 4
+
+kernel void test_kernel(global int *out)
+{
+  out[0] = 4;
+}
+
+__kernel void test_call_kernel(__global int *out)
+{
+  test_kernel(out);
+}
Index: lib/Sema/SemaType.cpp
===
--- lib/Sema/SemaType.cpp
+++ lib/Sema/SemaType.cpp
@@ -3182,15 +3182,19 @@
   CallingConv CC = S.Context.getDefaultCallingConvention(FTI.isVariadic,
  IsCXXInstanceMethod);
 
-  // Attribute AT_OpenCLKernel affects the calling convention only on
-  // the SPIR target, hence it cannot be treated as a calling
+  // Attribute AT_OpenCLKernel affects the calling convention for SPIR
+  // and AMDGPU targets, hence it cannot be treated as a calling
   // convention attribute. This is the simplest place to infer
-  // "spir_kernel" for OpenCL kernels on SPIR.
-  if (CC == CC_SpirFunction) {
+  // calling convention for OpenCL kernels.
+  if (S.getLangOpts().OpenCL) {
 for (const AttributeList *Attr = D.getDeclSpec().getAttributes().getList();
  Attr; Attr = Attr->getNext()) {
   if (Attr->getKind() == AttributeList::AT_OpenCLKernel) {
-CC = CC_SpirKernel;
+llvm::Triple::ArchType arch = S.Context.getTargetInfo().getTriple().getArch();
+if (arch == llvm::Triple::spir || arch == llvm::Triple::spir64 ||
+arch == llvm::Triple::amdgcn) {
+  CC = CC_OpenCLKernel;
+}
 break;
   }
 }
Index: lib/CodeGen/TargetInfo.h
===

Re: [PATCH] D21641: Use ArgList::hasFlag to check if -miamcu/-mno-iamcu is passed. NFC.

2016-06-29 Thread Andrey Turetskiy via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL274119: Use ArgList::hasFlag to check if -miamcu/-mno-iamcu 
is passed. NFC. (authored by aturetsk).

Changed prior to commit:
  http://reviews.llvm.org/D21641?vs=61662&id=62203#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D21641

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

Index: cfe/trunk/lib/Driver/Tools.cpp
===
--- cfe/trunk/lib/Driver/Tools.cpp
+++ cfe/trunk/lib/Driver/Tools.cpp
@@ -2247,12 +2247,10 @@
   }
 
   // Set flags to support MCU ABI.
-  if (Arg *A = Args.getLastArg(options::OPT_miamcu, options::OPT_mno_iamcu)) {
-if (A->getOption().matches(options::OPT_miamcu)) {
-  CmdArgs.push_back("-mfloat-abi");
-  CmdArgs.push_back("soft");
-  CmdArgs.push_back("-mstack-alignment=4");
-}
+  if (Args.hasFlag(options::OPT_miamcu, options::OPT_mno_iamcu, false)) {
+CmdArgs.push_back("-mfloat-abi");
+CmdArgs.push_back("soft");
+CmdArgs.push_back("-mstack-alignment=4");
   }
 }
 
Index: cfe/trunk/lib/Driver/Driver.cpp
===
--- cfe/trunk/lib/Driver/Driver.cpp
+++ cfe/trunk/lib/Driver/Driver.cpp
@@ -280,9 +280,8 @@
   }
 
   // Enforce -static if -miamcu is present.
-  if (Arg *Ar = Args.getLastArg(options::OPT_miamcu, options::OPT_mno_iamcu))
-if (Ar->getOption().matches(options::OPT_miamcu))
-  DAL->AddFlagArg(0, Opts->getOption(options::OPT_static));
+  if (Args.hasFlag(options::OPT_miamcu, options::OPT_mno_iamcu, false))
+DAL->AddFlagArg(0, Opts->getOption(options::OPT_static));
 
 // Add a default value of -mlinker-version=, if one was given and the user
 // didn't specify one.
@@ -376,24 +375,22 @@
   }
 
   // Handle -miamcu flag.
-  if (Arg *Ar = Args.getLastArg(options::OPT_miamcu, options::OPT_mno_iamcu)) {
-if (Ar->getOption().matches(options::OPT_miamcu)) {
-  if (Target.get32BitArchVariant().getArch() != llvm::Triple::x86)
-D.Diag(diag::err_drv_unsupported_opt_for_target) << "-miamcu"
- << Target.str();
-
-  if (A && !A->getOption().matches(options::OPT_m32))
-D.Diag(diag::err_drv_argument_not_allowed_with)
-<< "-miamcu" << A->getBaseArg().getAsString(Args);
-
-  Target.setArch(llvm::Triple::x86);
-  Target.setArchName("i586");
-  Target.setEnvironment(llvm::Triple::UnknownEnvironment);
-  Target.setEnvironmentName("");
-  Target.setOS(llvm::Triple::ELFIAMCU);
-  Target.setVendor(llvm::Triple::UnknownVendor);
-  Target.setVendorName("intel");
-}
+  if (Args.hasFlag(options::OPT_miamcu, options::OPT_mno_iamcu, false)) {
+if (Target.get32BitArchVariant().getArch() != llvm::Triple::x86)
+  D.Diag(diag::err_drv_unsupported_opt_for_target) << "-miamcu"
+   << Target.str();
+
+if (A && !A->getOption().matches(options::OPT_m32))
+  D.Diag(diag::err_drv_argument_not_allowed_with)
+  << "-miamcu" << A->getBaseArg().getAsString(Args);
+
+Target.setArch(llvm::Triple::x86);
+Target.setArchName("i586");
+Target.setEnvironment(llvm::Triple::UnknownEnvironment);
+Target.setEnvironmentName("");
+Target.setOS(llvm::Triple::ELFIAMCU);
+Target.setVendor(llvm::Triple::UnknownVendor);
+Target.setVendorName("intel");
   }
 
   return Target;


Index: cfe/trunk/lib/Driver/Tools.cpp
===
--- cfe/trunk/lib/Driver/Tools.cpp
+++ cfe/trunk/lib/Driver/Tools.cpp
@@ -2247,12 +2247,10 @@
   }
 
   // Set flags to support MCU ABI.
-  if (Arg *A = Args.getLastArg(options::OPT_miamcu, options::OPT_mno_iamcu)) {
-if (A->getOption().matches(options::OPT_miamcu)) {
-  CmdArgs.push_back("-mfloat-abi");
-  CmdArgs.push_back("soft");
-  CmdArgs.push_back("-mstack-alignment=4");
-}
+  if (Args.hasFlag(options::OPT_miamcu, options::OPT_mno_iamcu, false)) {
+CmdArgs.push_back("-mfloat-abi");
+CmdArgs.push_back("soft");
+CmdArgs.push_back("-mstack-alignment=4");
   }
 }
 
Index: cfe/trunk/lib/Driver/Driver.cpp
===
--- cfe/trunk/lib/Driver/Driver.cpp
+++ cfe/trunk/lib/Driver/Driver.cpp
@@ -280,9 +280,8 @@
   }
 
   // Enforce -static if -miamcu is present.
-  if (Arg *Ar = Args.getLastArg(options::OPT_miamcu, options::OPT_mno_iamcu))
-if (Ar->getOption().matches(options::OPT_miamcu))
-  DAL->AddFlagArg(0, Opts->getOption(options::OPT_static));
+  if (Args.hasFlag(options::OPT_miamcu, options::OPT_mno_iamcu, false))
+DAL->AddFlagArg(0, Opts->getOption(options::OPT_static));
 
 // Add a default value of -mlinker-version=, if one was given and the user
 // didn't specify one.
@@ -376,24 +375,22 @@
   }
 
   // Handle -miamcu flag.
-  if (Arg *Ar = Args.

r274119 - Use ArgList::hasFlag to check if -miamcu/-mno-iamcu is passed. NFC.

2016-06-29 Thread Andrey Turetskiy via cfe-commits
Author: aturetsk
Date: Wed Jun 29 05:57:17 2016
New Revision: 274119

URL: http://llvm.org/viewvc/llvm-project?rev=274119&view=rev
Log:
Use ArgList::hasFlag to check if -miamcu/-mno-iamcu is passed. NFC.

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

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

Modified: cfe/trunk/lib/Driver/Driver.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Driver.cpp?rev=274119&r1=274118&r2=274119&view=diff
==
--- cfe/trunk/lib/Driver/Driver.cpp (original)
+++ cfe/trunk/lib/Driver/Driver.cpp Wed Jun 29 05:57:17 2016
@@ -280,9 +280,8 @@ DerivedArgList *Driver::TranslateInputAr
   }
 
   // Enforce -static if -miamcu is present.
-  if (Arg *Ar = Args.getLastArg(options::OPT_miamcu, options::OPT_mno_iamcu))
-if (Ar->getOption().matches(options::OPT_miamcu))
-  DAL->AddFlagArg(0, Opts->getOption(options::OPT_static));
+  if (Args.hasFlag(options::OPT_miamcu, options::OPT_mno_iamcu, false))
+DAL->AddFlagArg(0, Opts->getOption(options::OPT_static));
 
 // Add a default value of -mlinker-version=, if one was given and the user
 // didn't specify one.
@@ -376,24 +375,22 @@ static llvm::Triple computeTargetTriple(
   }
 
   // Handle -miamcu flag.
-  if (Arg *Ar = Args.getLastArg(options::OPT_miamcu, options::OPT_mno_iamcu)) {
-if (Ar->getOption().matches(options::OPT_miamcu)) {
-  if (Target.get32BitArchVariant().getArch() != llvm::Triple::x86)
-D.Diag(diag::err_drv_unsupported_opt_for_target) << "-miamcu"
- << Target.str();
-
-  if (A && !A->getOption().matches(options::OPT_m32))
-D.Diag(diag::err_drv_argument_not_allowed_with)
-<< "-miamcu" << A->getBaseArg().getAsString(Args);
-
-  Target.setArch(llvm::Triple::x86);
-  Target.setArchName("i586");
-  Target.setEnvironment(llvm::Triple::UnknownEnvironment);
-  Target.setEnvironmentName("");
-  Target.setOS(llvm::Triple::ELFIAMCU);
-  Target.setVendor(llvm::Triple::UnknownVendor);
-  Target.setVendorName("intel");
-}
+  if (Args.hasFlag(options::OPT_miamcu, options::OPT_mno_iamcu, false)) {
+if (Target.get32BitArchVariant().getArch() != llvm::Triple::x86)
+  D.Diag(diag::err_drv_unsupported_opt_for_target) << "-miamcu"
+   << Target.str();
+
+if (A && !A->getOption().matches(options::OPT_m32))
+  D.Diag(diag::err_drv_argument_not_allowed_with)
+  << "-miamcu" << A->getBaseArg().getAsString(Args);
+
+Target.setArch(llvm::Triple::x86);
+Target.setArchName("i586");
+Target.setEnvironment(llvm::Triple::UnknownEnvironment);
+Target.setEnvironmentName("");
+Target.setOS(llvm::Triple::ELFIAMCU);
+Target.setVendor(llvm::Triple::UnknownVendor);
+Target.setVendorName("intel");
   }
 
   return Target;

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=274119&r1=274118&r2=274119&view=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Wed Jun 29 05:57:17 2016
@@ -2247,12 +2247,10 @@ void Clang::AddX86TargetArgs(const ArgLi
   }
 
   // Set flags to support MCU ABI.
-  if (Arg *A = Args.getLastArg(options::OPT_miamcu, options::OPT_mno_iamcu)) {
-if (A->getOption().matches(options::OPT_miamcu)) {
-  CmdArgs.push_back("-mfloat-abi");
-  CmdArgs.push_back("soft");
-  CmdArgs.push_back("-mstack-alignment=4");
-}
+  if (Args.hasFlag(options::OPT_miamcu, options::OPT_mno_iamcu, false)) {
+CmdArgs.push_back("-mfloat-abi");
+CmdArgs.push_back("soft");
+CmdArgs.push_back("-mstack-alignment=4");
   }
 }
 


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


r274120 - [OpenCL] Fix typo in as_type test.

2016-06-29 Thread Alexey Bader via cfe-commits
Author: bader
Date: Wed Jun 29 07:25:58 2016
New Revision: 274120

URL: http://llvm.org/viewvc/llvm-project?rev=274120&view=rev
Log:
[OpenCL] Fix typo in as_type test.

Reset astype variable in f6 function to avoid matching with wrong value from f5 
function.

Modified:
cfe/trunk/test/CodeGenOpenCL/as_type.cl

Modified: cfe/trunk/test/CodeGenOpenCL/as_type.cl
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenOpenCL/as_type.cl?rev=274120&r1=274119&r2=274120&view=diff
==
--- cfe/trunk/test/CodeGenOpenCL/as_type.cl (original)
+++ cfe/trunk/test/CodeGenOpenCL/as_type.cl Wed Jun 29 07:25:58 2016
@@ -44,7 +44,7 @@ int f5(char3 x) {
 }
 
 //CHECK: define spir_func i32 @f6(<4 x i8> %[[x:.*]])
-//CHECK: %[[astype]] = bitcast <4 x i8> %[[x]] to i32
+//CHECK: %[[astype:.*]] = bitcast <4 x i8> %[[x]] to i32
 //CHECK-NOT: shufflevector
 //CHECK: ret i32 %[[astype]]
 int f6(char4 x) {


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


r274122 - [OpenCL] Add attribute 'pure' to read_image built-in functions to enable optimizations.

2016-06-29 Thread Alexey Bader via cfe-commits
Author: bader
Date: Wed Jun 29 07:30:26 2016
New Revision: 274122

URL: http://llvm.org/viewvc/llvm-project?rev=274122&view=rev
Log:
[OpenCL] Add attribute 'pure' to read_image built-in functions to enable 
optimizations.

Reviewers: Anastasia, yaxunl

Subscribers: pekka.jaaskelainen, pxli168, cfe-commits

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

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

Modified: cfe/trunk/lib/Headers/opencl-c.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/opencl-c.h?rev=274122&r1=274121&r2=274122&view=diff
==
--- cfe/trunk/lib/Headers/opencl-c.h (original)
+++ cfe/trunk/lib/Headers/opencl-c.h Wed Jun 29 07:30:26 2016
@@ -19,7 +19,7 @@
 #define __ovld __attribute__((overloadable))
 
 // Optimizations
-
+#define __purefn __attribute__((pure))
 #define __cnfn __attribute__((const))
 
 // built-in scalar data types:
@@ -15685,142 +15685,142 @@ int printf(__constant const char* st, ..
  * in the description above are undefined.
  */
 
-float4 __ovld read_imagef(read_only image2d_t image, sampler_t sampler, int2 
coord);
-float4 __ovld read_imagef(read_only image2d_t image, sampler_t sampler, float2 
coord);
+float4 __purefn __ovld read_imagef(read_only image2d_t image, sampler_t 
sampler, int2 coord);
+float4 __purefn __ovld read_imagef(read_only image2d_t image, sampler_t 
sampler, float2 coord);
 
-int4 __ovld read_imagei(read_only image2d_t image, sampler_t sampler, int2 
coord);
-int4 __ovld read_imagei(read_only image2d_t image, sampler_t sampler, float2 
coord);
-uint4 __ovld read_imageui(read_only image2d_t image, sampler_t sampler, int2 
coord);
-uint4 __ovld read_imageui(read_only image2d_t image, sampler_t sampler, float2 
coord);
-
-float4 __ovld read_imagef(read_only image3d_t image, sampler_t sampler, int4 
coord);
-float4 __ovld read_imagef(read_only image3d_t image, sampler_t sampler, float4 
coord);
-
-int4 __ovld read_imagei(read_only image3d_t image, sampler_t sampler, int4 
coord);
-int4 __ovld read_imagei(read_only image3d_t image, sampler_t sampler, float4 
coord);
-uint4 __ovld read_imageui(read_only image3d_t image, sampler_t sampler, int4 
coord);
-uint4 __ovld read_imageui(read_only image3d_t image, sampler_t sampler, float4 
coord);
-
-float4 __ovld read_imagef(read_only image2d_array_t image_array, sampler_t 
sampler, int4 coord);
-float4 __ovld read_imagef(read_only image2d_array_t image_array, sampler_t 
sampler, float4 coord);
-
-int4 __ovld read_imagei(read_only image2d_array_t image_array, sampler_t 
sampler, int4 coord);
-int4 __ovld read_imagei(read_only image2d_array_t image_array, sampler_t 
sampler, float4 coord);
-uint4 __ovld read_imageui(read_only image2d_array_t image_array, sampler_t 
sampler, int4 coord);
-uint4 __ovld read_imageui(read_only image2d_array_t image_array, sampler_t 
sampler, float4 coord);
-
-float4 __ovld read_imagef(read_only image1d_t image, sampler_t sampler, int 
coord);
-float4 __ovld read_imagef(read_only image1d_t image, sampler_t sampler, float 
coord);
-
-int4 __ovld read_imagei(read_only image1d_t image, sampler_t sampler, int 
coord);
-int4 __ovld read_imagei(read_only image1d_t image, sampler_t sampler, float 
coord);
-uint4 __ovld read_imageui(read_only image1d_t image, sampler_t sampler, int 
coord);
-uint4 __ovld read_imageui(read_only image1d_t image, sampler_t sampler, float 
coord);
-
-float4 __ovld read_imagef(read_only image1d_array_t image_array, sampler_t 
sampler, int2 coord);
-float4 __ovld read_imagef(read_only image1d_array_t image_array, sampler_t 
sampler, float2 coord);
-
-int4 __ovld read_imagei(read_only image1d_array_t image_array, sampler_t 
sampler, int2 coord);
-int4 __ovld read_imagei(read_only image1d_array_t image_array, sampler_t 
sampler, float2 coord);
-uint4 __ovld read_imageui(read_only image1d_array_t image_array, sampler_t 
sampler, int2 coord);
-uint4 __ovld read_imageui(read_only image1d_array_t image_array, sampler_t 
sampler, float2 coord);
+int4 __purefn __ovld read_imagei(read_only image2d_t image, sampler_t sampler, 
int2 coord);
+int4 __purefn __ovld read_imagei(read_only image2d_t image, sampler_t sampler, 
float2 coord);
+uint4 __purefn __ovld read_imageui(read_only image2d_t image, sampler_t 
sampler, int2 coord);
+uint4 __purefn __ovld read_imageui(read_only image2d_t image, sampler_t 
sampler, float2 coord);
+
+float4 __purefn __ovld read_imagef(read_only image3d_t image, sampler_t 
sampler, int4 coord);
+float4 __purefn __ovld read_imagef(read_only image3d_t image, sampler_t 
sampler, float4 coord);
+
+int4 __purefn __ovld read_imagei(read_only image3d_t image, sampler_t sampler, 
int4 coord);
+int4 __purefn __ovld read_imagei(read_only image3d_t image, sampler_t sampler, 
float4 coord);
+uint4 __purefn __ovld read_imageui(read_only image3d_t image, sampler_t 
sampler, int4 coord);
+uint4 __purefn __ovld read_imageui(read_only image3d_t image, sampler_t 
sampler, 

Re: [PATCH] D21795: [OpenCL] Add attribute 'pure' to read_image built-in functions to enable optimizations.

2016-06-29 Thread Alexey Bader via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL274122: [OpenCL] Add attribute 'pure' to read_image built-in 
functions to enable… (authored by bader).

Changed prior to commit:
  http://reviews.llvm.org/D21795?vs=62094&id=62210#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D21795

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

Index: cfe/trunk/lib/Headers/opencl-c.h
===
--- cfe/trunk/lib/Headers/opencl-c.h
+++ cfe/trunk/lib/Headers/opencl-c.h
@@ -19,7 +19,7 @@
 #define __ovld __attribute__((overloadable))
 
 // Optimizations
-
+#define __purefn __attribute__((pure))
 #define __cnfn __attribute__((const))
 
 // built-in scalar data types:
@@ -15685,324 +15685,324 @@
  * in the description above are undefined.
  */
 
-float4 __ovld read_imagef(read_only image2d_t image, sampler_t sampler, int2 coord);
-float4 __ovld read_imagef(read_only image2d_t image, sampler_t sampler, float2 coord);
+float4 __purefn __ovld read_imagef(read_only image2d_t image, sampler_t sampler, int2 coord);
+float4 __purefn __ovld read_imagef(read_only image2d_t image, sampler_t sampler, float2 coord);
 
-int4 __ovld read_imagei(read_only image2d_t image, sampler_t sampler, int2 coord);
-int4 __ovld read_imagei(read_only image2d_t image, sampler_t sampler, float2 coord);
-uint4 __ovld read_imageui(read_only image2d_t image, sampler_t sampler, int2 coord);
-uint4 __ovld read_imageui(read_only image2d_t image, sampler_t sampler, float2 coord);
-
-float4 __ovld read_imagef(read_only image3d_t image, sampler_t sampler, int4 coord);
-float4 __ovld read_imagef(read_only image3d_t image, sampler_t sampler, float4 coord);
-
-int4 __ovld read_imagei(read_only image3d_t image, sampler_t sampler, int4 coord);
-int4 __ovld read_imagei(read_only image3d_t image, sampler_t sampler, float4 coord);
-uint4 __ovld read_imageui(read_only image3d_t image, sampler_t sampler, int4 coord);
-uint4 __ovld read_imageui(read_only image3d_t image, sampler_t sampler, float4 coord);
-
-float4 __ovld read_imagef(read_only image2d_array_t image_array, sampler_t sampler, int4 coord);
-float4 __ovld read_imagef(read_only image2d_array_t image_array, sampler_t sampler, float4 coord);
-
-int4 __ovld read_imagei(read_only image2d_array_t image_array, sampler_t sampler, int4 coord);
-int4 __ovld read_imagei(read_only image2d_array_t image_array, sampler_t sampler, float4 coord);
-uint4 __ovld read_imageui(read_only image2d_array_t image_array, sampler_t sampler, int4 coord);
-uint4 __ovld read_imageui(read_only image2d_array_t image_array, sampler_t sampler, float4 coord);
-
-float4 __ovld read_imagef(read_only image1d_t image, sampler_t sampler, int coord);
-float4 __ovld read_imagef(read_only image1d_t image, sampler_t sampler, float coord);
-
-int4 __ovld read_imagei(read_only image1d_t image, sampler_t sampler, int coord);
-int4 __ovld read_imagei(read_only image1d_t image, sampler_t sampler, float coord);
-uint4 __ovld read_imageui(read_only image1d_t image, sampler_t sampler, int coord);
-uint4 __ovld read_imageui(read_only image1d_t image, sampler_t sampler, float coord);
-
-float4 __ovld read_imagef(read_only image1d_array_t image_array, sampler_t sampler, int2 coord);
-float4 __ovld read_imagef(read_only image1d_array_t image_array, sampler_t sampler, float2 coord);
-
-int4 __ovld read_imagei(read_only image1d_array_t image_array, sampler_t sampler, int2 coord);
-int4 __ovld read_imagei(read_only image1d_array_t image_array, sampler_t sampler, float2 coord);
-uint4 __ovld read_imageui(read_only image1d_array_t image_array, sampler_t sampler, int2 coord);
-uint4 __ovld read_imageui(read_only image1d_array_t image_array, sampler_t sampler, float2 coord);
+int4 __purefn __ovld read_imagei(read_only image2d_t image, sampler_t sampler, int2 coord);
+int4 __purefn __ovld read_imagei(read_only image2d_t image, sampler_t sampler, float2 coord);
+uint4 __purefn __ovld read_imageui(read_only image2d_t image, sampler_t sampler, int2 coord);
+uint4 __purefn __ovld read_imageui(read_only image2d_t image, sampler_t sampler, float2 coord);
+
+float4 __purefn __ovld read_imagef(read_only image3d_t image, sampler_t sampler, int4 coord);
+float4 __purefn __ovld read_imagef(read_only image3d_t image, sampler_t sampler, float4 coord);
+
+int4 __purefn __ovld read_imagei(read_only image3d_t image, sampler_t sampler, int4 coord);
+int4 __purefn __ovld read_imagei(read_only image3d_t image, sampler_t sampler, float4 coord);
+uint4 __purefn __ovld read_imageui(read_only image3d_t image, sampler_t sampler, int4 coord);
+uint4 __purefn __ovld read_imageui(read_only image3d_t image, sampler_t sampler, float4 coord);
+
+float4 __purefn __ovld read_imagef(read_only image2d_array_t image_array, sampler_t sampler, int4 coord);
+float4 __purefn __ovld read_imagef(read_only image2d_array_t image_array, sampler_t sampler, float4 coord);
+
+int4 __purefn __ovld read_imagei(read_only imag

Re: [PATCH] D20334: [libcxx] Fix a bug in strstreambuf::overflow

2016-06-29 Thread Marshall Clow via cfe-commits
mclow.lists accepted this revision.
mclow.lists added a comment.
This revision is now accepted and ready to land.

This looks fine to me.


http://reviews.llvm.org/D20334



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


[PATCH] D21836: [AVX512][BUILTIN] Deleting two incorrect lines, conflicting SPEC

2016-06-29 Thread michael zuckerman via cfe-commits
m_zuckerman created this revision.
m_zuckerman added reviewers: AsafBadouh, igorb, delena, craig.topper.
m_zuckerman added a subscriber: cfe-commits.

By SPEC, instruction vpermilps gets IMM bigger than 15. 
Below, you can see that IMM can be any number between 0 to 255 include.  

SELECT4(src, control){
CASE(control[1:0])
0:  tmp[31:0] := src[31:0]
1:  tmp[31:0] := src[63:32]
2:  tmp[31:0] := src[95:64]
3:  tmp[31:0] := src[127:96]
ESAC
RETURN tmp[31:0]
}

tmp_dst[31:0] := SELECT4(a[127:0], imm8[1:0])
tmp_dst[63:32] := SELECT4(a[127:0], imm8[3:2])
tmp_dst[95:64] := SELECT4(a[127:0], imm8[5:4])
tmp_dst[127:96] := SELECT4(a[127:0], imm8[7:6])
FOR j := 0 to 3
i := j*32
IF k[j]
dst[i+31:i] := tmp_dst[i+31:i]
ELSE
dst[i+31:i] := src[i+31:i]
FI
ENDFOR
dst[MAX:128] := 0 

http://reviews.llvm.org/D21836

Files:
  lib/Sema/SemaChecking.cpp

Index: lib/Sema/SemaChecking.cpp
===
--- lib/Sema/SemaChecking.cpp
+++ lib/Sema/SemaChecking.cpp
@@ -1389,7 +1389,6 @@
   case X86::BI__builtin_ia32_extractf32x4_mask:
   case X86::BI__builtin_ia32_extracti32x4_mask:
   case X86::BI__builtin_ia32_vpermilpd_mask:
-  case X86::BI__builtin_ia32_vpermilps_mask:
   case X86::BI__builtin_ia32_extractf64x2_512_mask:
   case X86::BI__builtin_ia32_extracti64x2_512_mask:
 i = 1; l = 0; u = 3;
@@ -1461,7 +1460,6 @@
   case X86::BI__builtin_ia32_roundps256:
   case X86::BI__builtin_ia32_roundpd256:
   case X86::BI__builtin_ia32_vpermilpd256_mask:
-  case X86::BI__builtin_ia32_vpermilps256_mask:
 i = 1; l = 0; u = 15;
 break;
   case X86::BI__builtin_ia32_roundss:
@@ -1566,6 +1564,8 @@
   case X86::BI__builtin_ia32_fpclasspd512_mask:
   case X86::BI__builtin_ia32_fpclasssd_mask:
   case X86::BI__builtin_ia32_fpcla_mask:
+  case X86::BI__builtin_ia32_vpermilps_mask:
+  case X86::BI__builtin_ia32_vpermilps256_mask:
 i = 1; l = 0; u = 255;
 break;
   case X86::BI__builtin_ia32_palignr:


Index: lib/Sema/SemaChecking.cpp
===
--- lib/Sema/SemaChecking.cpp
+++ lib/Sema/SemaChecking.cpp
@@ -1389,7 +1389,6 @@
   case X86::BI__builtin_ia32_extractf32x4_mask:
   case X86::BI__builtin_ia32_extracti32x4_mask:
   case X86::BI__builtin_ia32_vpermilpd_mask:
-  case X86::BI__builtin_ia32_vpermilps_mask:
   case X86::BI__builtin_ia32_extractf64x2_512_mask:
   case X86::BI__builtin_ia32_extracti64x2_512_mask:
 i = 1; l = 0; u = 3;
@@ -1461,7 +1460,6 @@
   case X86::BI__builtin_ia32_roundps256:
   case X86::BI__builtin_ia32_roundpd256:
   case X86::BI__builtin_ia32_vpermilpd256_mask:
-  case X86::BI__builtin_ia32_vpermilps256_mask:
 i = 1; l = 0; u = 15;
 break;
   case X86::BI__builtin_ia32_roundss:
@@ -1566,6 +1564,8 @@
   case X86::BI__builtin_ia32_fpclasspd512_mask:
   case X86::BI__builtin_ia32_fpclasssd_mask:
   case X86::BI__builtin_ia32_fpcla_mask:
+  case X86::BI__builtin_ia32_vpermilps_mask:
+  case X86::BI__builtin_ia32_vpermilps256_mask:
 i = 1; l = 0; u = 255;
 break;
   case X86::BI__builtin_ia32_palignr:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D21836: [AVX512][BUILTIN][vpermilps][intrinsics] Fixing two incorrect IMM check.

2016-06-29 Thread Igor Breger via cfe-commits
igorb accepted this revision.
igorb added a comment.
This revision is now accepted and ready to land.

LGTM


http://reviews.llvm.org/D21836



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


Re: [PATCH] D21803: [libcxxabi] Provide a fallback __cxa_thread_atexit() implementation

2016-06-29 Thread Tavian Barnes via cfe-commits
tavianator updated this revision to Diff 62218.
tavianator added a comment.

Added error handling for pthread_key uses


http://reviews.llvm.org/D21803

Files:
  cmake/config-ix.cmake
  src/CMakeLists.txt
  src/cxa_thread_atexit.cpp
  test/CMakeLists.txt
  test/cxa_thread_atexit_test.pass.cpp
  test/libcxxabi/test/config.py
  test/lit.site.cfg.in

Index: test/lit.site.cfg.in
===
--- test/lit.site.cfg.in
+++ test/lit.site.cfg.in
@@ -13,7 +13,6 @@
 config.enable_32bit = "@LIBCXXABI_BUILD_32_BITS@"
 config.target_info  = "@LIBCXXABI_TARGET_INFO@"
 config.executor = "@LIBCXXABI_EXECUTOR@"
-config.thread_atexit= "@LIBCXXABI_HAS_CXA_THREAD_ATEXIT_IMPL@"
 config.libcxxabi_shared = "@LIBCXXABI_ENABLE_SHARED@"
 config.enable_shared= "@LIBCXX_ENABLE_SHARED@"
 config.enable_exceptions= "@LIBCXXABI_ENABLE_EXCEPTIONS@"
Index: test/libcxxabi/test/config.py
===
--- test/libcxxabi/test/config.py
+++ test/libcxxabi/test/config.py
@@ -37,8 +37,6 @@
 super(Configuration, self).configure_features()
 if not self.get_lit_bool('enable_exceptions', True):
 self.config.available_features.add('libcxxabi-no-exceptions')
-if self.get_lit_bool('thread_atexit', True):
-self.config.available_features.add('thread_atexit')
 
 def configure_compile_flags(self):
 self.cxx.compile_flags += ['-DLIBCXXABI_NO_TIMER']
Index: test/cxa_thread_atexit_test.pass.cpp
===
--- test/cxa_thread_atexit_test.pass.cpp
+++ test/cxa_thread_atexit_test.pass.cpp
@@ -8,7 +8,6 @@
 //===--===//
 
 // REQUIRES: linux
-// REQUIRES: thread_atexit
 
 #include 
 #include 
Index: test/CMakeLists.txt
===
--- test/CMakeLists.txt
+++ test/CMakeLists.txt
@@ -16,7 +16,6 @@
 pythonize_bool(LIBCXXABI_ENABLE_THREADS)
 pythonize_bool(LIBCXXABI_ENABLE_EXCEPTIONS)
 pythonize_bool(LIBCXXABI_USE_LLVM_UNWINDER)
-pythonize_bool(LIBCXXABI_HAS_CXA_THREAD_ATEXIT_IMPL)
 set(LIBCXXABI_TARGET_INFO "libcxx.test.target_info.LocalTI" CACHE STRING
 "TargetInfo to use when setting up test environment.")
 set(LIBCXXABI_EXECUTOR "None" CACHE STRING
Index: src/cxa_thread_atexit.cpp
===
--- src/cxa_thread_atexit.cpp
+++ src/cxa_thread_atexit.cpp
@@ -8,19 +8,85 @@
 //===--===//
 
 #include "cxxabi.h"
+#include 
+#include 
+#include "abort_message.h"
 
 namespace __cxxabiv1 {
-extern "C" {
+namespace {
+  typedef void (*Dtor)(void *);
+
+  struct DtorList {
+Dtor dtor;
+void* obj;
+DtorList* next;
+  };
+
+  void run_dtors(void* ptr) {
+auto elem = static_cast(ptr);
+while (elem) {
+  auto saved = elem;
+  elem = elem->next;
+  saved->dtor(saved->obj);
+  std::free(saved);
+}
+  }
+
+  class DtorListHolder {
+  public:
+DtorListHolder() {
+  if (pthread_key_create(&key_, run_dtors) != 0) {
+abort_message("cannot create pthread key for __cxa_thread_atexit()");
+  }
+}
+
+~DtorListHolder() {
+  run_dtors(get());
+  pthread_key_delete(key_);
+}
+
+DtorList* get() {
+  return static_cast(pthread_getspecific(key_));
+}
+
+bool set(DtorList* list) {
+  return pthread_setspecific(key_, list) == 0;
+}
+
+  private:
+pthread_key_t key_;
+  };
+} // namespace
 
-#ifdef HAVE___CXA_THREAD_ATEXIT_IMPL
+extern "C" {
 
-_LIBCXXABI_FUNC_VIS int __cxa_thread_atexit(void (*dtor)(void *), void *obj,
+_LIBCXXABI_FUNC_VIS int __cxa_thread_atexit(Dtor dtor, void *obj,
 void *dso_symbol) throw() {
-  extern int __cxa_thread_atexit_impl(void (*)(void *), void *, void *);
-  return __cxa_thread_atexit_impl(dtor, obj, dso_symbol);
-}
+  extern int __cxa_thread_atexit_impl(Dtor, void *, void *)
+__attribute__((__weak__));
+
+  if (__cxa_thread_atexit_impl) {
+return __cxa_thread_atexit_impl(dtor, obj, dso_symbol);
+  } else {
+static DtorListHolder dtors;
+
+auto head = static_cast(std::malloc(sizeof(DtorList)));
+if (!head) {
+  return -1;
+}
+
+head->dtor = dtor;
+head->obj = obj;
+head->next = dtors.get();
+
+if (!dtors.set(head)) {
+  std::free(head);
+  return -1;
+}
 
-#endif // HAVE__CXA_THREAD_ATEXIT_IMPL
+return 0;
+  }
+}
 
 } // extern "C"
 } // namespace __cxxabiv1
Index: src/CMakeLists.txt
===
--- src/CMakeLists.txt
+++ src/CMakeLists.txt
@@ -41,10 +41,6 @@
 
 include_directories("${LIBCXXABI_LIBCXX_INCLUDES}")
 
-if (LIBCXXABI_HAS_CXA_THREAD_ATEXIT_IMPL)
-

Re: [PATCH] D21803: [libcxxabi] Provide a fallback __cxa_thread_atexit() implementation

2016-06-29 Thread Ben Craig via cfe-commits
bcraig added subscribers: rmaprath, bcraig.
bcraig added a comment.

You should look at __thread_specific_ptr in libcxx's .  It does a lot 
of these things in order to satisfy the requirements of 
notify_all_at_thread_exit, set_value_at_thread_exit, and 
make_ready_at_thread_exit.

@rmaprath has been doing some work to make the threading runtime library 
swappable.  I don't recall if his work extended to libcxxabi or not, but I'll 
page him anyway.

This implementation of __cxa_thread_atexit doesn't interact nicely with shared 
libraries.  The following sequence of events causes unloaded code to get 
invoked.

- Create thread 42
- Load library foo from thread 42
- Call a function with a thread_local object with a dtor.
- Unload library foo.
- Join thread 42

glibc does some extra work during __cxa_thread_atexit_impl to bump the 
reference count of the shared library so that the user's "unload" doesn't 
actually unload the library.



Comment at: src/cxa_thread_atexit.cpp:40
@@ +39,3 @@
+
+~DtorListHolder() {
+  run_dtors(get());

I think this is correct, but it needs some comments because it is not obvious 
what (or why) this is implemented this way.

More specifically, document the cases where run_dtors is run because of 
~DtorListHolder vs. the cases where run_dtors is run because of the callback 
registered at pthread_key_create.


http://reviews.llvm.org/D21803



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


Re: [PATCH] D20867: [PCH] Fix timestamp check on windows hosts.

2016-06-29 Thread pierre gousseau via cfe-commits
pgousseau added a comment.

Ping!


http://reviews.llvm.org/D20867



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


Re: [PATCH] D18035: [GCC] PR23529 Mangler part of attrbute abi_tag support

2016-06-29 Thread Dmitry Polukhin via cfe-commits
DmitryPolukhin updated this revision to Diff 62213.
DmitryPolukhin marked 2 inline comments as done.
DmitryPolukhin added a comment.

Use SmallVector instead of SmallSetVector and sort the vector when needed.


http://reviews.llvm.org/D18035

Files:
  lib/AST/ItaniumMangle.cpp
  lib/Sema/SemaDeclAttr.cpp
  test/CodeGenCXX/mangle-abi-tag.cpp
  test/PCH/attrs.c
  test/SemaCXX/attr-abi-tag-syntax.cpp

Index: test/SemaCXX/attr-abi-tag-syntax.cpp
===
--- test/SemaCXX/attr-abi-tag-syntax.cpp
+++ test/SemaCXX/attr-abi-tag-syntax.cpp
@@ -16,28 +16,18 @@
 // expected-warning@-1 {{'abi_tag' attribute on anonymous namespace ignored}}
 
 inline namespace N __attribute__((__abi_tag__)) {}
-// FIXME: remove this warning as soon as attribute fully supported.
-// expected-warning@-2 {{'__abi_tag__' attribute ignored}}
 
 } // namespcace N2
 
 __attribute__((abi_tag("B", "A"))) extern int a1;
-// FIXME: remove this warning as soon as attribute fully supported.
-// expected-warning@-2 {{'abi_tag' attribute ignored}}
 
 __attribute__((abi_tag("A", "B"))) extern int a1;
 // expected-note@-1 {{previous declaration is here}}
-// FIXME: remove this warning as soon as attribute fully supported.
-// expected-warning@-3 {{'abi_tag' attribute ignored}}
 
 __attribute__((abi_tag("A", "C"))) extern int a1;
 // expected-error@-1 {{'abi_tag' C missing in original declaration}}
-// FIXME: remove this warning as soon as attribute fully supported.
-// expected-warning@-3 {{'abi_tag' attribute ignored}}
 
 extern int a2;
 // expected-note@-1 {{previous declaration is here}}
 __attribute__((abi_tag("A")))extern int a2;
 // expected-error@-1 {{cannot add 'abi_tag' attribute in a redeclaration}}
-// FIXME: remove this warning as soon as attribute fully supported.
-// expected-warning@-3 {{'abi_tag' attribute ignored}}
Index: test/PCH/attrs.c
===
--- test/PCH/attrs.c
+++ test/PCH/attrs.c
@@ -9,7 +9,7 @@
 #define HEADER
 
 int f(int) __attribute__((visibility("default"), overloadable));
-int g(int) __attribute__((abi_tag("foo", "bar", "baz"), no_sanitize("address", "memory"))); // expected-warning {{ignored}}
+int g(int) __attribute__((abi_tag("foo", "bar", "baz"), no_sanitize("address", "memory")));
 
 #else
 
Index: test/CodeGenCXX/mangle-abi-tag.cpp
===
--- /dev/null
+++ test/CodeGenCXX/mangle-abi-tag.cpp
@@ -0,0 +1,204 @@
+// RUN: %clang_cc1 %s -emit-llvm -triple %itanium_abi_triple -std=c++11 -o - | FileCheck %s
+// RUN: %clang_cc1 %s -emit-llvm -triple i686-linux-gnu -std=c++11 -o - | FileCheck %s
+// RUN: %clang_cc1 %s -emit-llvm -triple x86_64-linux-gnu -std=c++11 -o - | FileCheck %s
+
+struct __attribute__((abi_tag("A", "B"))) A { };
+
+struct B: A { };
+
+template
+
+struct C {
+};
+
+struct D { A* p; };
+
+template
+struct __attribute__((abi_tag("C", "D"))) E {
+};
+
+struct __attribute__((abi_tag("A", "B"))) F { };
+
+A a1;
+// CHECK-DAG: @_Z2a1B1AB1B =
+
+__attribute__((abi_tag("C", "D")))
+A a2;
+// CHECK-DAG: @_Z2a2B1AB1BB1CB1D =
+
+B a3;
+// CHECK-DAG: @a3 =
+
+C a4;
+// CHECK-DAG: @_Z2a4B1AB1B =
+
+D a5;
+// CHECK-DAG: @a5 =
+
+E a6;
+// CHECK-DAG: @_Z2a6B1CB1D =
+
+E a7;
+// CHECK-DAG: @_Z2a7B1AB1BB1CB1D =
+
+template<>
+struct E {
+  static float a8;
+};
+float E::a8;
+// CHECK-DAG: @_ZN1EB1CB1DIfE2a8E =
+
+template<>
+struct E {
+  static bool a9;
+};
+bool E::a9;
+// CHECK-DAG: @_ZN1EB1CB1DI1FB1AB1BE2a9E =
+
+struct __attribute__((abi_tag("A", "B"))) A10 {
+  virtual ~A10() {}
+} a10;
+// vtable
+// CHECK-DAG: @_ZTV3A10B1AB1B =
+// typeinfo
+// CHECK-DAG: @_ZTI3A10B1AB1B =
+
+struct __attribute__((abi_tag("A"))) B11 {
+  static A10 b;
+};
+A10 B11::b;
+// B11[abi:A]::b[abi:B]
+// CHECK-DAG: @_ZN3B11B1A1bB1BE =
+
+__attribute__ ((abi_tag("C", "D")))
+void* f1() {
+  return 0;
+}
+// CHECK-DAG: define {{.*}} @_Z2f1B1CB1Dv(
+
+__attribute__ ((abi_tag("C", "D")))
+A* f2() {
+  return 0;
+}
+// CHECK-DAG: define {{.*}} @_Z2f2B1AB1BB1CB1Dv(
+
+B* f3() {
+  return 0;
+}
+// CHECK-DAG: define {{.*}} @_Z2f3v(
+
+C* f4() {
+  return 0;
+}
+// CHECK-DAG: define {{.*}} @_Z2f4B1AB1Bv(
+
+D* f5() {
+  return 0;
+}
+// CHECK-DAG: define {{.*}} @_Z2f5v(
+
+E* f6() {
+  return 0;
+}
+// CHECK-DAG: define {{.*}} @_Z2f6B1CB1Dv(
+
+E* f7() {
+  return 0;
+}
+// CHECK-DAG: define {{.*}} @_Z2f7B1AB1BB1CB1Dv(
+
+void f8(E*) {
+}
+// CHECK-DAG: define {{.*}} @_Z2f8P1EB1CB1DI1AB1AB1BE(
+
+inline namespace Names1 __attribute__((__abi_tag__)) {
+class C1 {};
+}
+C1 f9() { return C1(); }
+// CHECK-DAG: @_Z2f9B6Names1v(
+
+inline namespace Names2 __attribute__((__abi_tag__("Tag1", "Tag2"))) {
+class C2 {};
+}
+C2 f10() { return C2(); }
+// CHECK-DAG: @_Z3f10B4Tag1B4Tag2v(
+
+void __attribute__((abi_tag("A"))) f11(A) {}
+// f11[abi:A](A[abi:A][abi:B])
+// CHECK-DAG: define {{.*}} @_Z3f11B1A1AB1AB1B(
+
+A f12(A) { return A(); }
+// f12(A[abi:A][abi:B])
+// CH

Re: [PATCH] D21773: [clang] Update an optimization remark test for change D18777

2016-06-29 Thread Li Huang via cfe-commits
lihuang added a comment.

Hi Adam,

The change in http://reviews.llvm.org/D18777 breaks this test becasue it 
converts some sexts to zexts, which cannot be eliminated by 
indvar-simplification after widening IV.

The IR after indvar-simplification and before loop-vectorization is like:

  ...
  %indvars.iv = phi i64 [ %indvars.iv.next, %for.body ], [ 0, 
%for.body.preheader ]
  ...
  add nuw nsw i64 %indvars.iv, 2  // i + 2
  %12 = trunc i64 %11 to i32
  %idxprom2047 = zext i32 %12 to i64
  %arrayidx21 = getelementptr inbounds i32, i32* %C, i64 %idxprom2047
  ...
  %14 = add nuw nsw i64 %indvars.iv, 3// i + 3
  %15 = trunc i64 %14 to i32
  %idxprom2448 = zext i32 %15 to i64
  ...

IV is promoted to 64-bit but the trunc/zext cannot be eliminated (at least 
cannot be eliminated with the -O1 pass pipeline). Then optimzation remark 
becomes:

  optimization-remark-options.c:17:3: remark: loop not vectorized: cannot 
identify array bounds
 [-Rpass-analysis=loop-vectorize]
  for (int i = 0; i < N; i++) {


http://reviews.llvm.org/D21773



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


r274126 - [X86][SSE2] Updated tests to match llvm\test\CodeGen\X86\sse2-intrinsics-fast-isel-x86_64.ll

2016-06-29 Thread Simon Pilgrim via cfe-commits
Author: rksimon
Date: Wed Jun 29 09:04:08 2016
New Revision: 274126

URL: http://llvm.org/viewvc/llvm-project?rev=274126&view=rev
Log:
[X86][SSE2] Updated tests to match 
llvm\test\CodeGen\X86\sse2-intrinsics-fast-isel-x86_64.ll

Modified:
cfe/trunk/test/CodeGen/sse2-builtins.c

Modified: cfe/trunk/test/CodeGen/sse2-builtins.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/sse2-builtins.c?rev=274126&r1=274125&r2=274126&view=diff
==
--- cfe/trunk/test/CodeGen/sse2-builtins.c (original)
+++ cfe/trunk/test/CodeGen/sse2-builtins.c Wed Jun 29 09:04:08 2016
@@ -701,6 +701,14 @@ __m128i test_mm_loadu_si128(__m128i cons
   return _mm_loadu_si128(A);
 }
 
+__m128i test_mm_loadu_si64(void const* A) {
+  // CHECK-LABEL: test_mm_loadu_si64
+  // CHECK: load i64, i64* %{{.*}}, align 1{{$}}
+  // CHECK: insertelement <2 x i64> undef, i64 %{{.*}}, i32 0
+  // CHECK: insertelement <2 x i64> %{{.*}}, i64 0, i32 1
+  return _mm_loadu_si64(A);
+}
+
 __m128i test_mm_madd_epi16(__m128i A, __m128i B) {
   // CHECK-LABEL: test_mm_madd_epi16
   // CHECK: call <4 x i32> @llvm.x86.sse2.pmadd.wd(<8 x i16> %{{.*}}, <8 x 
i16> %{{.*}})
@@ -1532,12 +1540,3 @@ __m128i test_mm_xor_si128(__m128i A, __m
   // CHECK: xor <2 x i64> %{{.*}}, %{{.*}}
   return _mm_xor_si128(A, B);
 }
-
-__m128i test_mm_loadu_si64(void const* A) {
-  // CHECK-LABEL: test_mm_loadu_si64
-  // CHECK: load i64, i64* %{{.*}}, align 1{{$}}
-  // CHECK: insertelement <2 x i64> undef, i64 %{{.*}}, i32 0
-  // CHECK: insertelement <2 x i64> %{{.*}}, i64 0, i32 1
-  return _mm_loadu_si64(A);
-}
-


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


Re: [PATCH] D21833: [clang-tidy] Fix more enum declaration cases in misc-unused-using-decls check.

2016-06-29 Thread Aaron Ballman via cfe-commits
aaron.ballman added a subscriber: aaron.ballman.


Comment at: clang-tidy/misc/UnusedUsingDeclsCheck.cpp:22
@@ +21,3 @@
+namespace {
+// FIXME: Move this node matcher to ASTMatcher.
+const internal::VariadicDynCastAllOfMatcher enumType;

Can you fix this fixme as a prerequisite to this patch? It should be pretty 
trivial, and I'd hate for it to get forgotten post-commit.


Comment at: test/clang-tidy/misc-unused-using-decls.cpp:152
@@ -148,1 +151,2 @@
+  int t2 = Blue;
 }

We're now lacking a test that says "Green is unused" like we had before. Can 
you add another test case to bring back the similar diagnostic?


http://reviews.llvm.org/D21833



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


Re: [PATCH] D21510: [libc++] Check hash before calling __hash_table key_eq function

2016-06-29 Thread Kwasi Mensah via cfe-commits
kmensah added a comment.

Another friendly Ping


Repository:
  rL LLVM

http://reviews.llvm.org/D21510



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


Re: r274064 - AvailabilityAttr: we accept "macos" as the platform name.

2016-06-29 Thread Aaron Ballman via cfe-commits
On Tue, Jun 28, 2016 at 4:55 PM, Manman Ren via cfe-commits
 wrote:
> Author: mren
> Date: Tue Jun 28 15:55:30 2016
> New Revision: 274064
>
> URL: http://llvm.org/viewvc/llvm-project?rev=274064&view=rev
> Log:
> AvailabilityAttr: we accept "macos" as the platform name.
>
> We continue accepting "macosx" but canonicalize it to "macos", When emitting
> diagnostics, we use "macOS" instead of "OS X".
>
> The PlatformName in TargetInfo is changed from "macosx" to "macos" so we can
> directly compare the Platform in AvailabilityAttr with the PlatformName
> in TargetInfo.
>
> rdar://26795172
> rdar://26800775
>
> Modified:
> cfe/trunk/include/clang-c/Index.h
> cfe/trunk/include/clang/Basic/Attr.td
> cfe/trunk/include/clang/Basic/AttrDocs.td
> cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
> cfe/trunk/lib/AST/Decl.cpp
> cfe/trunk/lib/Basic/Targets.cpp
> cfe/trunk/lib/Parse/ParseDecl.cpp
> cfe/trunk/test/Index/annotate-comments-availability-attrs.cpp
> cfe/trunk/test/Index/availability.c
> cfe/trunk/test/Misc/ast-print-objectivec.m
> cfe/trunk/test/Sema/attr-availability-macosx.c
> cfe/trunk/test/Sema/attr-availability.c
> cfe/trunk/test/Sema/attr-print.c
> cfe/trunk/test/SemaCXX/attr-deprecated-replacement-fixit.cpp
> cfe/trunk/test/SemaObjC/attr-availability-1.m
> cfe/trunk/test/SemaObjC/attr-availability.m
> cfe/trunk/test/SemaObjC/attr-deprecated.m
> cfe/trunk/test/SemaObjC/property-noninherited-availability-attr.m
>
> Modified: cfe/trunk/include/clang-c/Index.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang-c/Index.h?rev=274064&r1=274063&r2=274064&view=diff
> ==
> --- cfe/trunk/include/clang-c/Index.h (original)
> +++ cfe/trunk/include/clang-c/Index.h Tue Jun 28 15:55:30 2016
> @@ -2570,7 +2570,7 @@ typedef struct CXPlatformAvailability {
> * \brief A string that describes the platform for which this structure
> * provides availability information.
> *
> -   * Possible values are "ios" or "macosx".
> +   * Possible values are "ios" or "macos".
> */
>CXString Platform;
>/**
>
> Modified: cfe/trunk/include/clang/Basic/Attr.td
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=274064&r1=274063&r2=274064&view=diff
> ==
> --- cfe/trunk/include/clang/Basic/Attr.td (original)
> +++ cfe/trunk/include/clang/Basic/Attr.td Tue Jun 28 15:55:30 2016
> @@ -477,11 +477,11 @@ def Availability : InheritableAttr {
>  return llvm::StringSwitch(Platform)
>   .Case("android", "Android")
>   .Case("ios", "iOS")
> - .Case("macosx", "OS X")
> + .Case("macos", "macOS")
>   .Case("tvos", "tvOS")
>   .Case("watchos", "watchOS")
>   .Case("ios_app_extension", "iOS (App Extension)")
> - .Case("macosx_app_extension", "OS X (App Extension)")
> + .Case("macos_app_extension", "macOS (App Extension)")
>   .Case("tvos_app_extension", "tvOS (App Extension)")
>   .Case("watchos_app_extension", "watchOS (App Extension)")
>   .Default(llvm::StringRef());
>
> Modified: cfe/trunk/include/clang/Basic/AttrDocs.td
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/AttrDocs.td?rev=274064&r1=274063&r2=274064&view=diff
> ==
> --- cfe/trunk/include/clang/Basic/AttrDocs.td (original)
> +++ cfe/trunk/include/clang/Basic/AttrDocs.td Tue Jun 28 15:55:30 2016
> @@ -691,7 +691,7 @@ the function declaration for a hypotheti
>
>  .. code-block:: c++
>
> -  void f(void) 
> __attribute__((availability(macosx,introduced=10.4,deprecated=10.6,obsoleted=10.7)));
> +  void f(void) 
> __attribute__((availability(macos,introduced=10.4,deprecated=10.6,obsoleted=10.7)));
>
>  The availability attribute states that ``f`` was introduced in Mac OS X 10.4,
>  deprecated in Mac OS X 10.6, and obsoleted in Mac OS X 10.7.  This 
> information
> @@ -743,7 +743,7 @@ are:
>the ``-mios-version-min=*version*`` or ``-miphoneos-version-min=*version*``
>command-line arguments.
>
> -``macosx``
> +``macos``

Can you please continue to document that we support macosx, but that
it's deprecated?

~Aaron

>Apple's Mac OS X operating system.  The minimum deployment target is
>specified by the ``-mmacosx-version-min=*version*`` command-line argument.
>
> @@ -777,24 +777,24 @@ platform. For example:
>
>  .. code-block:: c
>
> -  void g(void) __attribute__((availability(macosx,introduced=10.4)));
> -  void g(void) __attribute__((availability(macosx,introduced=10.4))); // 
> okay, matches
> +  void g(void) __attribute__((availability(macos,introduced=10.4)));
> +  void g(void) __attribute__((availability(macos,introduced=10.4))); //

Re: [PATCH] D21830: Remove -mrelax-all from Clang -O0

2016-06-29 Thread Rafael Espíndola via cfe-commits
We need to benchmark this to see if it still makes a difference.

My canonical test is the .s of a lto of clang.

Cheers,
Rafael


On 29 June 2016 at 03:37, Dean Michael Berris  wrote:
> dberris created this revision.
> dberris added reviewers: echristo, rafael, grosbach.
> dberris added a subscriber: cfe-commits.
> Herald added a subscriber: mehdi_amini.
>
> Remove the -mrelax-all options passed onto the integrated assembler in
> -O0.
>
> http://reviews.llvm.org/D21830
>
> Files:
>   lib/Driver/Tools.cpp
>   test/Driver/integrated-as.c
>
> Index: test/Driver/integrated-as.c
> ===
> --- test/Driver/integrated-as.c
> +++ test/Driver/integrated-as.c
> @@ -1,7 +1,6 @@
>  // RUN: %clang -### -c -save-temps -integrated-as %s 2>&1 | FileCheck %s
>
>  // CHECK: cc1as
> -// CHECK: -mrelax-all
>
>  // RUN: %clang -### -fintegrated-as -c -save-temps %s 2>&1 | FileCheck %s 
> -check-prefix FIAS
>
> Index: lib/Driver/Tools.cpp
> ===
> --- lib/Driver/Tools.cpp
> +++ lib/Driver/Tools.cpp
> @@ -2721,38 +2721,10 @@
>return !UseDwarfDirectory;
>  }
>
> -/// \brief Check whether the given input tree contains any compilation 
> actions.
> -static bool ContainsCompileAction(const Action *A) {
> -  if (isa(A) || isa(A))
> -return true;
> -
> -  for (const auto &AI : A->inputs())
> -if (ContainsCompileAction(AI))
> -  return true;
> -
> -  return false;
> -}
> -
>  /// \brief Check if -relax-all should be passed to the internal assembler.
> -/// This is done by default when compiling non-assembler source with -O0.
>  static bool UseRelaxAll(Compilation &C, const ArgList &Args) {
> -  bool RelaxDefault = true;
> -
> -  if (Arg *A = Args.getLastArg(options::OPT_O_Group))
> -RelaxDefault = A->getOption().matches(options::OPT_O0);
> -
> -  if (RelaxDefault) {
> -RelaxDefault = false;
> -for (const auto &Act : C.getActions()) {
> -  if (ContainsCompileAction(Act)) {
> -RelaxDefault = true;
> -break;
> -  }
> -}
> -  }
> -
>return Args.hasFlag(options::OPT_mrelax_all, options::OPT_mno_relax_all,
> -  RelaxDefault);
> +  false);
>  }
>
>  // Convert an arg of the form "-gN" or "-ggdbN" or one of their aliases
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[libcxx] r274132 - [libcxx] Fix a bug in strstreambuf::overflow.

2016-06-29 Thread Akira Hatanaka via cfe-commits
Author: ahatanak
Date: Wed Jun 29 10:26:13 2016
New Revision: 274132

URL: http://llvm.org/viewvc/llvm-project?rev=274132&view=rev
Log:
[libcxx] Fix a bug in strstreambuf::overflow.

The end pointer should point to one past the end of the newly allocated
buffer.

rdar://problem/24265174

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

Added:

libcxx/trunk/test/std/depr/depr.str.strstreams/depr.strstreambuf/depr.strstreambuf.members/overflow.pass.cpp
Modified:
libcxx/trunk/src/strstream.cpp

Modified: libcxx/trunk/src/strstream.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/src/strstream.cpp?rev=274132&r1=274131&r2=274132&view=diff
==
--- libcxx/trunk/src/strstream.cpp (original)
+++ libcxx/trunk/src/strstream.cpp Wed Jun 29 10:26:13 2016
@@ -175,7 +175,6 @@ strstreambuf::overflow(int_type __c)
 ptrdiff_t ninp = gptr()  - eback();
 ptrdiff_t einp = egptr() - eback();
 ptrdiff_t nout = pptr()  - pbase();
-ptrdiff_t eout = epptr() - pbase();
 if (__strmode_ & __allocated)
 {
 if (__pfree_)
@@ -184,7 +183,7 @@ strstreambuf::overflow(int_type __c)
 delete [] eback();
 }
 setg(buf, buf + ninp, buf + einp);
-setp(buf + einp, buf + einp + eout);
+setp(buf + einp, buf + new_size);
 pbump(static_cast(nout));
 __strmode_ |= __allocated;
 }

Added: 
libcxx/trunk/test/std/depr/depr.str.strstreams/depr.strstreambuf/depr.strstreambuf.members/overflow.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/depr/depr.str.strstreams/depr.strstreambuf/depr.strstreambuf.members/overflow.pass.cpp?rev=274132&view=auto
==
--- 
libcxx/trunk/test/std/depr/depr.str.strstreams/depr.strstreambuf/depr.strstreambuf.members/overflow.pass.cpp
 (added)
+++ 
libcxx/trunk/test/std/depr/depr.str.strstreams/depr.strstreambuf/depr.strstreambuf.members/overflow.pass.cpp
 Wed Jun 29 10:26:13 2016
@@ -0,0 +1,32 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+// 
+
+// class strstreambuf
+
+// int overflow(int c);
+
+#include 
+#include 
+#include 
+
+int main(int, char const **argv) {
+  std::ostrstream oss;
+  std::string s;
+
+  for (int i = 0; i < 4096; ++i)
+s.push_back((i % 16) + 'a');
+
+  oss << s << std::ends;
+  std::cout << oss.str();
+  oss.freeze(false);
+
+  return 0;
+}


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


Re: [PATCH] D20334: [libcxx] Fix a bug in strstreambuf::overflow

2016-06-29 Thread Akira Hatanaka via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL274132: [libcxx] Fix a bug in strstreambuf::overflow. 
(authored by ahatanak).

Changed prior to commit:
  http://reviews.llvm.org/D20334?vs=58740&id=62225#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D20334

Files:
  libcxx/trunk/src/strstream.cpp
  
libcxx/trunk/test/std/depr/depr.str.strstreams/depr.strstreambuf/depr.strstreambuf.members/overflow.pass.cpp

Index: 
libcxx/trunk/test/std/depr/depr.str.strstreams/depr.strstreambuf/depr.strstreambuf.members/overflow.pass.cpp
===
--- 
libcxx/trunk/test/std/depr/depr.str.strstreams/depr.strstreambuf/depr.strstreambuf.members/overflow.pass.cpp
+++ 
libcxx/trunk/test/std/depr/depr.str.strstreams/depr.strstreambuf/depr.strstreambuf.members/overflow.pass.cpp
@@ -0,0 +1,32 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+// 
+
+// class strstreambuf
+
+// int overflow(int c);
+
+#include 
+#include 
+#include 
+
+int main(int, char const **argv) {
+  std::ostrstream oss;
+  std::string s;
+
+  for (int i = 0; i < 4096; ++i)
+s.push_back((i % 16) + 'a');
+
+  oss << s << std::ends;
+  std::cout << oss.str();
+  oss.freeze(false);
+
+  return 0;
+}
Index: libcxx/trunk/src/strstream.cpp
===
--- libcxx/trunk/src/strstream.cpp
+++ libcxx/trunk/src/strstream.cpp
@@ -175,16 +175,15 @@
 ptrdiff_t ninp = gptr()  - eback();
 ptrdiff_t einp = egptr() - eback();
 ptrdiff_t nout = pptr()  - pbase();
-ptrdiff_t eout = epptr() - pbase();
 if (__strmode_ & __allocated)
 {
 if (__pfree_)
 __pfree_(eback());
 else
 delete [] eback();
 }
 setg(buf, buf + ninp, buf + einp);
-setp(buf + einp, buf + einp + eout);
+setp(buf + einp, buf + new_size);
 pbump(static_cast(nout));
 __strmode_ |= __allocated;
 }


Index: libcxx/trunk/test/std/depr/depr.str.strstreams/depr.strstreambuf/depr.strstreambuf.members/overflow.pass.cpp
===
--- libcxx/trunk/test/std/depr/depr.str.strstreams/depr.strstreambuf/depr.strstreambuf.members/overflow.pass.cpp
+++ libcxx/trunk/test/std/depr/depr.str.strstreams/depr.strstreambuf/depr.strstreambuf.members/overflow.pass.cpp
@@ -0,0 +1,32 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+// 
+
+// class strstreambuf
+
+// int overflow(int c);
+
+#include 
+#include 
+#include 
+
+int main(int, char const **argv) {
+  std::ostrstream oss;
+  std::string s;
+
+  for (int i = 0; i < 4096; ++i)
+s.push_back((i % 16) + 'a');
+
+  oss << s << std::ends;
+  std::cout << oss.str();
+  oss.freeze(false);
+
+  return 0;
+}
Index: libcxx/trunk/src/strstream.cpp
===
--- libcxx/trunk/src/strstream.cpp
+++ libcxx/trunk/src/strstream.cpp
@@ -175,16 +175,15 @@
 ptrdiff_t ninp = gptr()  - eback();
 ptrdiff_t einp = egptr() - eback();
 ptrdiff_t nout = pptr()  - pbase();
-ptrdiff_t eout = epptr() - pbase();
 if (__strmode_ & __allocated)
 {
 if (__pfree_)
 __pfree_(eback());
 else
 delete [] eback();
 }
 setg(buf, buf + ninp, buf + einp);
-setp(buf + einp, buf + einp + eout);
+setp(buf + einp, buf + new_size);
 pbump(static_cast(nout));
 __strmode_ |= __allocated;
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: r274064 - AvailabilityAttr: we accept "macos" as the platform name.

2016-06-29 Thread Manman Ren via cfe-commits
Good point! In r274133.

Manman

On Wed, Jun 29, 2016 at 7:30 AM, Aaron Ballman 
wrote:

> On Tue, Jun 28, 2016 at 4:55 PM, Manman Ren via cfe-commits
>  wrote:
> > Author: mren
> > Date: Tue Jun 28 15:55:30 2016
> > New Revision: 274064
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=274064&view=rev
> > Log:
> > AvailabilityAttr: we accept "macos" as the platform name.
> >
> > We continue accepting "macosx" but canonicalize it to "macos", When
> emitting
> > diagnostics, we use "macOS" instead of "OS X".
> >
> > The PlatformName in TargetInfo is changed from "macosx" to "macos" so we
> can
> > directly compare the Platform in AvailabilityAttr with the PlatformName
> > in TargetInfo.
> >
> > rdar://26795172
> > rdar://26800775
> >
> > Modified:
> > cfe/trunk/include/clang-c/Index.h
> > cfe/trunk/include/clang/Basic/Attr.td
> > cfe/trunk/include/clang/Basic/AttrDocs.td
> > cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
> > cfe/trunk/lib/AST/Decl.cpp
> > cfe/trunk/lib/Basic/Targets.cpp
> > cfe/trunk/lib/Parse/ParseDecl.cpp
> > cfe/trunk/test/Index/annotate-comments-availability-attrs.cpp
> > cfe/trunk/test/Index/availability.c
> > cfe/trunk/test/Misc/ast-print-objectivec.m
> > cfe/trunk/test/Sema/attr-availability-macosx.c
> > cfe/trunk/test/Sema/attr-availability.c
> > cfe/trunk/test/Sema/attr-print.c
> > cfe/trunk/test/SemaCXX/attr-deprecated-replacement-fixit.cpp
> > cfe/trunk/test/SemaObjC/attr-availability-1.m
> > cfe/trunk/test/SemaObjC/attr-availability.m
> > cfe/trunk/test/SemaObjC/attr-deprecated.m
> > cfe/trunk/test/SemaObjC/property-noninherited-availability-attr.m
> >
> > Modified: cfe/trunk/include/clang-c/Index.h
> > URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang-c/Index.h?rev=274064&r1=274063&r2=274064&view=diff
> >
> ==
> > --- cfe/trunk/include/clang-c/Index.h (original)
> > +++ cfe/trunk/include/clang-c/Index.h Tue Jun 28 15:55:30 2016
> > @@ -2570,7 +2570,7 @@ typedef struct CXPlatformAvailability {
> > * \brief A string that describes the platform for which this
> structure
> > * provides availability information.
> > *
> > -   * Possible values are "ios" or "macosx".
> > +   * Possible values are "ios" or "macos".
> > */
> >CXString Platform;
> >/**
> >
> > Modified: cfe/trunk/include/clang/Basic/Attr.td
> > URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=274064&r1=274063&r2=274064&view=diff
> >
> ==
> > --- cfe/trunk/include/clang/Basic/Attr.td (original)
> > +++ cfe/trunk/include/clang/Basic/Attr.td Tue Jun 28 15:55:30 2016
> > @@ -477,11 +477,11 @@ def Availability : InheritableAttr {
> >  return llvm::StringSwitch(Platform)
> >   .Case("android", "Android")
> >   .Case("ios", "iOS")
> > - .Case("macosx", "OS X")
> > + .Case("macos", "macOS")
> >   .Case("tvos", "tvOS")
> >   .Case("watchos", "watchOS")
> >   .Case("ios_app_extension", "iOS (App Extension)")
> > - .Case("macosx_app_extension", "OS X (App Extension)")
> > + .Case("macos_app_extension", "macOS (App Extension)")
> >   .Case("tvos_app_extension", "tvOS (App Extension)")
> >   .Case("watchos_app_extension", "watchOS (App Extension)")
> >   .Default(llvm::StringRef());
> >
> > Modified: cfe/trunk/include/clang/Basic/AttrDocs.td
> > URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/AttrDocs.td?rev=274064&r1=274063&r2=274064&view=diff
> >
> ==
> > --- cfe/trunk/include/clang/Basic/AttrDocs.td (original)
> > +++ cfe/trunk/include/clang/Basic/AttrDocs.td Tue Jun 28 15:55:30 2016
> > @@ -691,7 +691,7 @@ the function declaration for a hypotheti
> >
> >  .. code-block:: c++
> >
> > -  void f(void)
> __attribute__((availability(macosx,introduced=10.4,deprecated=10.6,obsoleted=10.7)));
> > +  void f(void)
> __attribute__((availability(macos,introduced=10.4,deprecated=10.6,obsoleted=10.7)));
> >
> >  The availability attribute states that ``f`` was introduced in Mac OS X
> 10.4,
> >  deprecated in Mac OS X 10.6, and obsoleted in Mac OS X 10.7.  This
> information
> > @@ -743,7 +743,7 @@ are:
> >the ``-mios-version-min=*version*`` or
> ``-miphoneos-version-min=*version*``
> >command-line arguments.
> >
> > -``macosx``
> > +``macos``
>
> Can you please continue to document that we support macosx, but that
> it's deprecated?
>
> ~Aaron
>
> >Apple's Mac OS X operating system.  The minimum deployment target is
> >specified by the ``-mmacosx-version-min=*version*`` command-line
> argument.
> >
> > @@ -777,24 +777,24 @@ platform. For example:
> >
> >  .. code-block:: c
> 

r274133 - AvailabilityAttr: update the document for macosx

2016-06-29 Thread Manman Ren via cfe-commits
Author: mren
Date: Wed Jun 29 10:50:08 2016
New Revision: 274133

URL: http://llvm.org/viewvc/llvm-project?rev=274133&view=rev
Log:
AvailabilityAttr: update the document for macosx

Modified:
cfe/trunk/include/clang/Basic/AttrDocs.td

Modified: cfe/trunk/include/clang/Basic/AttrDocs.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/AttrDocs.td?rev=274133&r1=274132&r2=274133&view=diff
==
--- cfe/trunk/include/clang/Basic/AttrDocs.td (original)
+++ cfe/trunk/include/clang/Basic/AttrDocs.td Wed Jun 29 10:50:08 2016
@@ -746,6 +746,8 @@ are:
 ``macos``
   Apple's Mac OS X operating system.  The minimum deployment target is
   specified by the ``-mmacosx-version-min=*version*`` command-line argument.
+  ``macosx`` is supported for backward-compatibility reasons, but it is
+  deprecated.
 
 ``tvos``
   Apple's tvOS operating system.  The minimum deployment target is specified by


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


Re: [PATCH] D21803: [libcxxabi] Provide a fallback __cxa_thread_atexit() implementation

2016-06-29 Thread Tavian Barnes via cfe-commits
tavianator added a comment.

In http://reviews.llvm.org/D21803#469988, @bcraig wrote:

> You should look at __thread_specific_ptr in libcxx's .  It does a lot 
> of these things in order to satisfy the requirements of 
> notify_all_at_thread_exit, set_value_at_thread_exit, and 
> make_ready_at_thread_exit.


Had a look at it.  One thing that stands out is that 
notify_all_at_thread_exit() and friends are supposed to be invoked *after* 
thread_local destructors.  But the order that pthread_key destructors run in is 
unspecified.  This could be worked around by waiting for the second iteration 
through pthread_key destructors before triggering ~__thread_struct_imp().  It 
looks like libstdc++ has a similar bug if ..._impl() isn't available.

> @rmaprath has been doing some work to make the threading runtime library 
> swappable.  I don't recall if his work extended to libcxxabi or not, but I'll 
> page him anyway.


<__threading_support>?  Seems to be libc++-specific.  There's a few other raw 
uses of pthreads in libc++abi.

> This implementation of __cxa_thread_atexit doesn't interact nicely with 
> shared libraries.  The following sequence of events causes unloaded code to 
> get invoked.

> 

> - Create thread 42

> - Load library foo from thread 42

> - Call a function with a thread_local object with a dtor.

> - Unload library foo.

> - Join thread 42

> 

>   glibc does some extra work during __cxa_thread_atexit_impl to bump the 
> reference count of the shared library so that the user's "unload" doesn't 
> actually unload the library.


Yep.  This is about as good as libc++abi can do on its own though.  Note that 
libstdc++ has similar limitations if ..._impl() isn't available.


http://reviews.llvm.org/D21803



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


Re: [PATCH] D21830: Remove -mrelax-all from Clang -O0

2016-06-29 Thread David Majnemer via cfe-commits
majnemer added a subscriber: majnemer.
majnemer added a comment.

Why are you making this change? I cannot see a justification in the description.


http://reviews.llvm.org/D21830



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


Re: [PATCH] D18171: [CUDA][OpenMP] Create generic offload action

2016-06-29 Thread Samuel Antao via cfe-commits
sfantao updated this revision to Diff 62230.
sfantao added a comment.

- Better organize how the offload action is used and add more comments to 
document what is going on.
- Rebase.


http://reviews.llvm.org/D18171

Files:
  include/clang/Driver/Action.h
  include/clang/Driver/Compilation.h
  include/clang/Driver/Driver.h
  lib/Driver/Action.cpp
  lib/Driver/Driver.cpp
  lib/Driver/ToolChain.cpp
  lib/Driver/ToolChains.cpp
  lib/Driver/ToolChains.h
  lib/Driver/Tools.cpp
  lib/Driver/Tools.h
  lib/Frontend/CreateInvocationFromCommandLine.cpp

Index: lib/Frontend/CreateInvocationFromCommandLine.cpp
===
--- lib/Frontend/CreateInvocationFromCommandLine.cpp
+++ lib/Frontend/CreateInvocationFromCommandLine.cpp
@@ -60,25 +60,25 @@
   }
 
   // We expect to get back exactly one command job, if we didn't something
-  // failed. CUDA compilation is an exception as it creates multiple jobs. If
-  // that's the case, we proceed with the first job. If caller needs particular
-  // CUDA job, it should be controlled via --cuda-{host|device}-only option
-  // passed to the driver.
+  // failed. Offload compilation is an exception as it creates multiple jobs. If
+  // that's the case, we proceed with the first job. If caller needs a
+  // particular job, it should be controlled via options (e.g.
+  // --cuda-{host|device}-only for CUDA) passed to the driver.
   const driver::JobList &Jobs = C->getJobs();
-  bool CudaCompilation = false;
+  bool OffloadCompilation = false;
   if (Jobs.size() > 1) {
 for (auto &A : C->getActions()){
   // On MacOSX real actions may end up being wrapped in BindArchAction
   if (isa(A))
 A = *A->input_begin();
-  if (isa(A)) {
-CudaCompilation = true;
+  if (isa(A)) {
+OffloadCompilation = true;
 break;
   }
 }
   }
   if (Jobs.size() == 0 || !isa(*Jobs.begin()) ||
-  (Jobs.size() > 1 && !CudaCompilation)) {
+  (Jobs.size() > 1 && !OffloadCompilation)) {
 SmallString<256> Msg;
 llvm::raw_svector_ostream OS(Msg);
 Jobs.Print(OS, "; ", true);
Index: lib/Driver/Tools.h
===
--- lib/Driver/Tools.h
+++ lib/Driver/Tools.h
@@ -57,8 +57,7 @@
const Driver &D, const llvm::opt::ArgList &Args,
llvm::opt::ArgStringList &CmdArgs,
const InputInfo &Output,
-   const InputInfoList &Inputs,
-   const ToolChain *AuxToolChain) const;
+   const InputInfoList &Inputs) const;
 
   void AddAArch64TargetArgs(const llvm::opt::ArgList &Args,
 llvm::opt::ArgStringList &CmdArgs) const;
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -288,12 +288,46 @@
  !O.hasFlag(options::DriverOption) && !O.hasFlag(options::LinkerInput);
 }
 
+/// \brief Add the C++ include args of other offloading toolchains. If this is a
+/// host job, the device toolchains are added. If this is a device job, the host
+/// toolchains will be added.
+static void addExtraOffloadCXXStdlibIncludeArgs(Compilation &C,
+const JobAction &JA,
+const ArgList &Args,
+ArgStringList &CmdArgs) {
+
+  if (JA.isHostOffloading(Action::OFK_Cuda))
+C.getSingleOffloadToolChain()
+->AddClangCXXStdlibIncludeArgs(Args, CmdArgs);
+  else if (JA.isDeviceOffloading(Action::OFK_Cuda))
+C.getSingleOffloadToolChain()
+->AddClangCXXStdlibIncludeArgs(Args, CmdArgs);
+
+  // TODO: Add support for other programming models here.
+}
+
+/// \brief Add the include args that are specific of each offloading programming
+/// model.
+static void addExtraOffloadSpecificIncludeArgs(Compilation &C,
+   const JobAction &JA,
+   const ArgList &Args,
+   ArgStringList &CmdArgs) {
+
+  if (JA.isHostOffloading(Action::OFK_Cuda))
+C.getSingleOffloadToolChain()->AddCudaIncludeArgs(
+Args, CmdArgs);
+  else if (JA.isDeviceOffloading(Action::OFK_Cuda))
+C.getSingleOffloadToolChain()->AddCudaIncludeArgs(
+Args, CmdArgs);
+
+  // TODO: Add support for other programming models here.
+}
+
 void Clang::AddPreprocessingOptions(Compilation &C, const JobAction &JA,
 const Driver &D, const ArgList &Args,
 ArgStringList &CmdArgs,
 const InputInfo &Output,
-const InputInfoList &Inputs,
-const ToolChain *

Re: [PATCH] D18171: [CUDA][OpenMP] Create generic offload action

2016-06-29 Thread Samuel Antao via cfe-commits
sfantao added a comment.

@tra, any other comments/suggestions about this patch?

Thanks!
Samuel


http://reviews.llvm.org/D18171



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


Re: [PATCH] D18172: [CUDA][OpenMP] Add a generic offload action builder

2016-06-29 Thread Samuel Antao via cfe-commits
sfantao updated this revision to Diff 62231.
sfantao added a comment.

- Rebase.


http://reviews.llvm.org/D18172

Files:
  include/clang/Driver/Compilation.h
  lib/Driver/Driver.cpp

Index: lib/Driver/Driver.cpp
===
--- lib/Driver/Driver.cpp
+++ lib/Driver/Driver.cpp
@@ -1387,131 +1387,523 @@
   }
 }
 
-// For each unique --cuda-gpu-arch= argument creates a TY_CUDA_DEVICE
-// input action and then wraps each in CudaDeviceAction paired with
-// appropriate GPU arch name. In case of partial (i.e preprocessing
-// only) or device-only compilation, each device action is added to /p
-// Actions and /p Current is released. Otherwise the function creates
-// and returns a new CudaHostAction which wraps /p Current and device
-// side actions.
-static Action *buildCudaActions(Compilation &C, DerivedArgList &Args,
-const Arg *InputArg, Action *HostAction,
-ActionList &Actions) {
-  Arg *PartialCompilationArg = Args.getLastArg(
-  options::OPT_cuda_host_only, options::OPT_cuda_device_only,
-  options::OPT_cuda_compile_host_device);
-  bool CompileHostOnly =
-  PartialCompilationArg &&
-  PartialCompilationArg->getOption().matches(options::OPT_cuda_host_only);
-  bool CompileDeviceOnly =
-  PartialCompilationArg &&
-  PartialCompilationArg->getOption().matches(options::OPT_cuda_device_only);
-
-  if (CompileHostOnly) {
-  OffloadAction::HostDependence HDep(
+namespace {
+/// \brief Provides a convenient interface for different programming models to
+/// generate the required device actions.
+class OffloadingActionBuilder {
+  /// \brief Flag used to trace errors in the builder.
+  bool IsValid;
+
+  /// \brief The compilation that is using this builder.
+  Compilation &C;
+
+  /// \brief The derived arguments associated with this builder.
+  DerivedArgList &Args;
+
+  /// \brief Map between an input argument and the offload kinds used to process
+  /// it.
+  std::map InputArgToOffloadKindMap;
+
+  /// \brief Builder interface. It doesn't build anything or keep any state.
+  class DeviceActionBuilder {
+  public:
+typedef llvm::SmallVector PhasesTy;
+
+enum ActionBuilderReturnCode {
+  // The builder acted successfully on the current action.
+  ABRT_Success,
+  // The builder didn't have to act on the current action.
+  ABRT_Inactive,
+  // The builder was successful and requested the host action to not be
+  // generated.
+  ABRT_Ignore_Host,
+};
+
+  protected:
+/// \brief Compilation associated with this builder.
+Compilation &C;
+
+/// \brief Tool chains associated with this builder. The same programming
+/// model may have associated one or more tool chains.
+SmallVector ToolChains;
+
+/// \brief The derived arguments associated with this builder.
+DerivedArgList &Args;
+
+/// \brief The inputs associated with this builder.
+const Driver::InputList &Inputs;
+
+/// \brief The associated offload kind.
+Action::OffloadKind AssociatedOffloadKind;
+
+  public:
+DeviceActionBuilder(Compilation &C, DerivedArgList &Args,
+const Driver::InputList &Inputs,
+Action::OffloadKind AssociatedOffloadKind)
+: C(C), Args(Args), Inputs(Inputs),
+  AssociatedOffloadKind(AssociatedOffloadKind) {}
+virtual ~DeviceActionBuilder() {}
+
+// \brief Fill up the array \a DA with all the device dependences that
+// should be added to the provided host action \a HostAction. By default it
+// is inactive.
+virtual ActionBuilderReturnCode
+getDeviceDepences(OffloadAction::DeviceDependences &DA, phases::ID CurPhase,
+  phases::ID FinalPhase, PhasesTy &Phases) {
+  return ABRT_Inactive;
+}
+
+// \brief Update the state to include the provided host action \a HostAction
+// as a dependency of the current device action. By default it is inactive.
+virtual ActionBuilderReturnCode addDeviceDepences(Action *HostAction) {
+  return ABRT_Inactive;
+}
+
+// \brief Append top level actions generated by the builder. Return true if
+// errors were found.
+virtual void appendTopLevelActions(ActionList &AL) {}
+
+// \brief Append linker actions generated by the builder. Return true if
+// errors were found.
+virtual void appendLinkDependences(OffloadAction::DeviceDependences &DA) {}
+
+// \brief Initialize the builder. Return true if any initialization errors
+// are found.
+virtual bool initialize() { return false; }
+
+// \brief Return true if this builder is valid. We have a valid builder if
+// we have associated device tool chains.
+bool isValid() { return !ToolChains.empty(); }
+
+// \brief Return the associated offload kind.
+Action::OffloadKind getAssociatedOffloadKind() {
+  return AssociatedOffloadKind;
+}
+  };
+

[PATCH] D21840: [Driver][CUDA][OpenMP] Reimplement tool selection in the driver.

2016-06-29 Thread Samuel Antao via cfe-commits
sfantao created this revision.
sfantao added reviewers: echristo, tra, jlebar, hfinkel, ABataev, rsmith.
sfantao added subscribers: carlo.bertolli, arpith-jacob, caomhin, 
andreybokhanko, Hahnfeld, cfe-commits.
Herald added a subscriber: mehdi_amini.

This creates a tool selector in the driver that replaces the existing one. The 
goal is to better organize the code and make the selector easier to scale, in 
particular in the presence of offload actions that can be collapsed. 

The current implementation became more confusing when the support for 
offloading actions was added. This concern was expressed by Eric in 
http://reviews.llvm.org/D9888.

This patch does not add new testing, it preserves the existing functionality.

http://reviews.llvm.org/D21840

Files:
  include/clang/Driver/Action.h
  lib/Driver/Driver.cpp

Index: lib/Driver/Driver.cpp
===
--- lib/Driver/Driver.cpp
+++ lib/Driver/Driver.cpp
@@ -2330,142 +2330,294 @@
 }
   }
 }
-// Collapse an offloading action looking for a job of the given type. The input
-// action is changed to the input of the collapsed sequence. If we effectively
-// had a collapse return the corresponding offloading action, otherwise return
-// null.
-template 
-static OffloadAction *collapseOffloadingAction(Action *&CurAction) {
-  if (!CurAction)
-return nullptr;
-  if (auto *OA = dyn_cast(CurAction)) {
-if (OA->hasHostDependence())
-  if (auto *HDep = dyn_cast(OA->getHostDependence())) {
-CurAction = HDep;
-return OA;
-  }
-if (OA->hasSingleDeviceDependence())
-  if (auto *DDep = dyn_cast(OA->getSingleDeviceDependence())) {
-CurAction = DDep;
-return OA;
+
+namespace {
+/// \brief Utility class to control the collapse of dependent actions and select
+/// the tools accordingly.
+class ToolSelector final {
+  /// \brief The tool chain this selector refers to.
+  const ToolChain &TC;
+
+  /// \brief The compilation this selector refers to.
+  const Compilation &C;
+
+  /// \brief The base action this selector refers to.
+  const JobAction *BaseAction;
+
+  /// \brief Set to true if the current toolchain refers to host actions.
+  bool IsHostSelector;
+
+  /// \brief Set to true if save-temps and embed-bitcode functionalities are
+  /// active.
+  bool SaveTemps;
+  bool EmbedBitcode;
+
+  /// \brief Get dependence action or null if that does not exist. If \a
+  /// CanBeCollapsed is false, that action must be legal to collapse or null
+  /// will be returned.
+  const JobAction *getDependenceAction(const ActionList &Inputs,
+   ActionList &SavedOffloadAction,
+   bool CanBeCollapsed = true) {
+// An option can be collapsed only if it has a single input.
+if (Inputs.size() != 1)
+  return nullptr;
+
+Action *CurAction = *Inputs.begin();
+if (!CurAction->isCollapsingWithDependingActionLegal() && CanBeCollapsed)
+  return nullptr;
+
+// If the input action is an offload action. Look through it and save any
+// offload action that can be dropped in the event of a collapse.
+if (auto *OA = dyn_cast(CurAction)) {
+  // If the depending action is a device action, we will attempt to collapse
+  // only with other device actions. Otherwise, we would do the same but
+  // with host actions only.
+  if (!IsHostSelector) {
+if (OA->hasSingleDeviceDependence(/*DoNotConsiderHostActions=*/true)) {
+  CurAction =
+  OA->getSingleDeviceDependence(/*DoNotConsiderHostActions=*/true);
+  if (!CurAction->isCollapsingWithDependingActionLegal() &&
+  CanBeCollapsed)
+return nullptr;
+  SavedOffloadAction.push_back(OA);
+  return dyn_cast(CurAction);
+}
+  } else if (OA->hasHostDependence()) {
+CurAction = OA->getHostDependence();
+if (!CurAction->isCollapsingWithDependingActionLegal() &&
+CanBeCollapsed)
+  return nullptr;
+SavedOffloadAction.push_back(OA);
+return dyn_cast(CurAction);
   }
+  return nullptr;
+}
+
+return dyn_cast(CurAction);
   }
-  return nullptr;
-}
-// Returns a Tool for a given JobAction.  In case the action and its
-// predecessors can be combined, updates Inputs with the inputs of the
-// first combined action. If one of the collapsed actions is a
-// CudaHostAction, updates CollapsedCHA with the pointer to it so the
-// caller can deal with extra handling such action requires.
-static const Tool *selectToolForJob(Compilation &C, bool SaveTemps,
-bool EmbedBitcode, const ToolChain *TC,
-const JobAction *JA,
-const ActionList *&Inputs,
-ActionList &CollapsedOffloadAction) {
-  const Tool *ToolForJob = nullptr;
-  CollapsedOffloadAction.

Re: [PATCH] D21803: [libcxxabi] Provide a fallback __cxa_thread_atexit() implementation

2016-06-29 Thread Ben Craig via cfe-commits
bcraig added a comment.

In http://reviews.llvm.org/D21803#470060, @tavianator wrote:

> In http://reviews.llvm.org/D21803#469988, @bcraig wrote:
>
> > You should look at __thread_specific_ptr in libcxx's .  It does a 
> > lot of these things in order to satisfy the requirements of 
> > notify_all_at_thread_exit, set_value_at_thread_exit, and 
> > make_ready_at_thread_exit.
>
>
> Had a look at it.  One thing that stands out is that 
> notify_all_at_thread_exit() and friends are supposed to be invoked *after* 
> thread_local destructors.  But the order that pthread_key destructors run in 
> is unspecified.  This could be worked around by waiting for the second 
> iteration through pthread_key destructors before triggering 
> ~__thread_struct_imp().  It looks like libstdc++ has a similar bug if 
> ..._impl() isn't available.


It also intentionally leaks the pthread key.  Does the __thread_specific_ptr 
rationale hold for this change as well?

> > This implementation of __cxa_thread_atexit doesn't interact nicely with 
> > shared libraries.  The following sequence of events causes unloaded code to 
> > get invoked.

> 

> > 

> 

> > - Create thread 42

> 

> > - Load library foo from thread 42

> 

> > - Call a function with a thread_local object with a dtor.

> 

> > - Unload library foo.

> 

> > - Join thread 42

> 

> > 

> 

> >   glibc does some extra work during __cxa_thread_atexit_impl to bump the 
> > reference count of the shared library so that the user's "unload" doesn't 
> > actually unload the library.

> 

> 

> Yep.  This is about as good as libc++abi can do on its own though.  Note that 
> libstdc++ has similar limitations if ..._impl() isn't available.


I was going to tell you that this is implementable with dladdr (which I think 
Android has).  Then I looked more at the "prevent unloading" side of things, 
and it looks like that requires digging into the library structures directly.  
Ugh.

Comment on the limitation in the source, but you don't need to change any code 
for this item.


http://reviews.llvm.org/D21803



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


Re: [PATCH] D21783: [CodeView] Implement support for bitfields in Clang

2016-06-29 Thread Reid Kleckner via cfe-commits
rnk accepted this revision.
rnk added a comment.

lgtm

Cute, preserves debug info compatibility at the cost of some complexity.


http://reviews.llvm.org/D21783



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


Re: [PATCH] D21700: [SemaExpr] Support lax conversions in assignments with vector and scalars with same size

2016-06-29 Thread Reid Kleckner via cfe-commits
rnk added a comment.

After writing r266366, we discovered that GCC accepts none of the code in that 
test case, so we should consider turning -flax-vector-conversions off by 
default.



Comment at: test/Sema/vector-cast.c:65
@@ -59,1 +64,3 @@
+  d = f2;
+  d = d + f2;
 }

Why should we allow this conversion? I don't see how <2 x float> and double 
should be convertible. I'm not sure why we allow `f2 += d` above, but I think 
of it as "widening" the type from scalar to vector.

Would it be OK for your if we tightened our lax vector conversion checks to 
just allow conversion from `<1 x T>` to `T`? The test case in the summary seems 
like pretty reasonable code, even if GCC rejects.


http://reviews.llvm.org/D21700



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


Re: [PATCH] D21367: AMDGPU: Set amdgpu_kernel calling convention for OpenCL kernels.

2016-06-29 Thread Yaxun Liu via cfe-commits
yaxunl accepted this revision.
yaxunl added a comment.
This revision is now accepted and ready to land.

LGTM. Thanks!


http://reviews.llvm.org/D21367



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


[PATCH] D21843: [Driver][OpenMP] Create tool chains for OpenMP offloading kind.

2016-06-29 Thread Samuel Antao via cfe-commits
sfantao created this revision.
sfantao added reviewers: echristo, tra, jlebar, hfinkel, ABataev, rsmith.
sfantao added subscribers: caomhin, carlo.bertolli, arpith-jacob, Hahnfeld, 
cfe-commits.
Herald added a subscriber: mehdi_amini.

This patch adds new logic to create the necessary tool chains to support 
offloading for OpenMP. The OpenMP related options are checked and the tool 
chains created accordingly. Diagnostics are emitted in case the options are 
illegal or express unknown targets.

http://reviews.llvm.org/D21843

Files:
  include/clang/Basic/DiagnosticDriverKinds.td
  include/clang/Driver/Action.h
  lib/Driver/Action.cpp
  lib/Driver/Driver.cpp
  test/Driver/openmp-offload.c

Index: test/Driver/openmp-offload.c
===
--- /dev/null
+++ test/Driver/openmp-offload.c
@@ -0,0 +1,37 @@
+///
+/// Perform several driver tests for OpenMP offloading
+///
+
+/// ###
+
+/// Check whether an invalid OpenMP target is specified:
+// RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=aaa-bbb-ccc-ddd %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-INVALID-TARGET %s
+// RUN:   %clang -### -fopenmp -fopenmp-targets=aaa-bbb-ccc-ddd %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-INVALID-TARGET %s
+// CHK-INVALID-TARGET: error: OpenMP target is invalid: 'aaa-bbb-ccc-ddd'
+
+/// ###
+
+/// Check warning for empty -fopenmp-targets
+// RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=  %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-EMPTY-OMPTARGETS %s
+// RUN:   %clang -### -fopenmp -fopenmp-targets=  %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-EMPTY-OMPTARGETS %s
+// CHK-EMPTY-OMPTARGETS: warning: joined argument expects additional value: '-fopenmp-targets='
+
+/// ###
+
+/// Check error for no -fopenmp option
+// RUN:   %clang -### -fopenmp-targets=powerpc64le-ibm-linux-gnu  %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-NO-FOPENMP %s
+// RUN:   %clang -### -fopenmp=libgomp -fopenmp-targets=powerpc64le-ibm-linux-gnu  %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-NO-FOPENMP %s
+// CHK-NO-FOPENMP: error: The option -fopenmp-targets must be used in conjunction with a -fopenmp option compatible with offloading.
+
+/// ###
+
+/// Check warning for duplicate offloading targets.
+// RUN:   %clang -### -ccc-print-phases -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu,powerpc64le-ibm-linux-gnu  %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-DUPLICATES %s
+// CHK-DUPLICATES: warning: The OpenMP offloading target 'powerpc64le-ibm-linux-gnu' is similar to target 'powerpc64le-ibm-linux-gnu' already specified - will be ignored.
Index: lib/Driver/Driver.cpp
===
--- lib/Driver/Driver.cpp
+++ lib/Driver/Driver.cpp
@@ -443,6 +443,65 @@
   }
 
   //
+  // OpenMP
+  //
+  // We need to generate an OpenMP toolchain if the user specified targets with
+  // the -fopenmp-targets option.
+  if (Arg *OpenMPTargets =
+  C.getInputArgs().getLastArg(options::OPT_fopenmp_targets_EQ)) {
+if (OpenMPTargets->getNumValues()) {
+  // We expect that -fopenmp-targets is always used in conjunction with the
+  // option -fopenmp specifying a valid runtime with offloading support,
+  // i.e. libomp or libiomp.
+  bool HasCompatibleOpenMP = C.getInputArgs().hasFlag(
+  options::OPT_fopenmp, options::OPT_fopenmp_EQ,
+  options::OPT_fno_openmp, false);
+  if (HasCompatibleOpenMP) {
+StringRef RuntimeName(CLANG_DEFAULT_OPENMP_RUNTIME);
+const Arg *A = C.getInputArgs().getLastArg(options::OPT_fopenmp_EQ);
+if (A)
+  RuntimeName = A->getValue();
+HasCompatibleOpenMP = llvm::StringSwitch(RuntimeName)
+  .Case("libomp", true)
+  .Case("libgomp", false)
+  .Case("libiomp5", true)
+  .Default(false);
+  }
+
+  if (HasCompatibleOpenMP) {
+llvm::StringMap FoundNormalizedTriples;
+for (const char *Val : OpenMPTargets->getValues()) {
+  llvm::Triple TT(Val);
+  std::string NormalizedName = TT.normalize();
+
+  // Make sure we don't have a duplicate triple.
+  auto Duplicate = FoundNormalizedTriples.find(NormalizedName);
+  if (Duplicate != FoundNormalizedTriples.end()) {
+Diag(clang::diag::warn_drv_omp_offload_target_duplicate)
+<< Val << Duplicate->second;
+continue;
+  }
+
+  // Store the current triple so that we can check for duplicates in the
+  // following iterations.
+  F

[PATCH] D21845: [Driver][OpenMP] Add specialized action builder for OpenMP offloading actions.

2016-06-29 Thread Samuel Antao via cfe-commits
sfantao created this revision.
sfantao added reviewers: echristo, tra, jlebar, hfinkel, ABataev, rsmith.
sfantao added subscribers: caomhin, carlo.bertolli, arpith-jacob, 
andreybokhanko, Hahnfeld, cfe-commits.
Herald added a subscriber: mehdi_amini.

This patch adds a new specialized action builder to create OpenMP offloading 
actions. The specialized builder is added to the action builder already 
containing the CUDA specialized builder.

OpenMP offloading dependences between host and device actions (expressed with 
OffloadActions) are different that what is used for CUDA:
 - Device compile action depends on the host compile action - the device 
frontend extracts the information about the declarations that have to be 
emitted by looking into the metadata produced by the host frontend.
 - The host link action depends on the device link actions - the device images 
are embedded in the host binary at link time.

http://reviews.llvm.org/D21845

Files:
  lib/Driver/Driver.cpp
  test/Driver/openmp-offload.c

Index: test/Driver/openmp-offload.c
===
--- test/Driver/openmp-offload.c
+++ test/Driver/openmp-offload.c
@@ -35,3 +35,106 @@
 // RUN:   %clang -### -ccc-print-phases -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu,powerpc64le-ibm-linux-gnu  %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=CHK-DUPLICATES %s
 // CHK-DUPLICATES: warning: The OpenMP offloading target 'powerpc64le-ibm-linux-gnu' is similar to target 'powerpc64le-ibm-linux-gnu' already specified - will be ignored.
+
+/// ###
+
+/// Check the phases graph when using a single target, different from the host.
+/// We should have an offload action joining the host compile and device
+/// preprocessor and another one joining the device linking outputs to the host
+/// action.
+// RUN:   %clang -ccc-print-phases -fopenmp -target powerpc64le-ibm-linux-gnu -fopenmp-targets=x86_64-pc-linux-gnu %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-PHASES %s
+// CHK-PHASES: 0: input, "[[INPUT:.+\.c]]", c, (host-openmp)
+// CHK-PHASES: 1: preprocessor, {0}, cpp-output, (host-openmp)
+// CHK-PHASES: 2: compiler, {1}, ir, (host-openmp)
+// CHK-PHASES: 3: backend, {2}, assembler, (host-openmp)
+// CHK-PHASES: 4: assembler, {3}, object, (host-openmp)
+// CHK-PHASES: 5: linker, {4}, image, (host-openmp)
+// CHK-PHASES: 6: input, "[[INPUT]]", c, (device-openmp)
+// CHK-PHASES: 7: preprocessor, {6}, cpp-output, (device-openmp)
+// CHK-PHASES: 8: compiler, {7}, ir, (device-openmp)
+// CHK-PHASES: 9: offload, "host-openmp (powerpc64le-ibm-linux-gnu)" {2}, "device-openmp (x86_64-pc-linux-gnu)" {8}, ir
+// CHK-PHASES: 10: backend, {9}, assembler, (device-openmp)
+// CHK-PHASES: 11: assembler, {10}, object, (device-openmp)
+// CHK-PHASES: 12: linker, {11}, image, (device-openmp)
+// CHK-PHASES: 13: offload, "host-openmp (powerpc64le-ibm-linux-gnu)" {5}, "device-openmp (x86_64-pc-linux-gnu)" {12}, image
+
+/// ###
+
+/// Check the phases when using multiple targets. Here we also add a library to
+/// make sure it is treated as input by the device.
+// RUN:   %clang -ccc-print-phases -lsomelib -fopenmp -target powerpc64-ibm-linux-gnu -fopenmp-targets=x86_64-pc-linux-gnu,powerpc64-ibm-linux-gnu %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-PHASES-LIB %s
+// CHK-PHASES-LIB: 0: input, "somelib", object, (host-openmp)
+// CHK-PHASES-LIB: 1: input, "[[INPUT:.+\.c]]", c, (host-openmp)
+// CHK-PHASES-LIB: 2: preprocessor, {1}, cpp-output, (host-openmp)
+// CHK-PHASES-LIB: 3: compiler, {2}, ir, (host-openmp)
+// CHK-PHASES-LIB: 4: backend, {3}, assembler, (host-openmp)
+// CHK-PHASES-LIB: 5: assembler, {4}, object, (host-openmp)
+// CHK-PHASES-LIB: 6: linker, {0, 5}, image, (host-openmp)
+// CHK-PHASES-LIB: 7: input, "somelib", object, (device-openmp)
+// CHK-PHASES-LIB: 8: input, "[[INPUT]]", c, (device-openmp)
+// CHK-PHASES-LIB: 9: preprocessor, {8}, cpp-output, (device-openmp)
+// CHK-PHASES-LIB: 10: compiler, {9}, ir, (device-openmp)
+// CHK-PHASES-LIB: 11: offload, "host-openmp (powerpc64-ibm-linux-gnu)" {3}, "device-openmp (x86_64-pc-linux-gnu)" {10}, ir
+// CHK-PHASES-LIB: 12: backend, {11}, assembler, (device-openmp)
+// CHK-PHASES-LIB: 13: assembler, {12}, object, (device-openmp)
+// CHK-PHASES-LIB: 14: linker, {7, 13}, image, (device-openmp)
+// CHK-PHASES-LIB: 15: input, "somelib", object, (device-openmp)
+// CHK-PHASES-LIB: 16: input, "[[INPUT]]", c, (device-openmp)
+// CHK-PHASES-LIB: 17: preprocessor, {16}, cpp-output, (device-openmp)
+// CHK-PHASES-LIB: 18: compiler, {17}, ir, (device-openmp)
+// CHK-PHASES-LIB: 19: offload, "host-openmp (powerpc64-ibm-linux-gnu)" {3}, "device-openmp (powerpc64-ibm-linux-gnu)" {18}, ir
+// CHK-PHASES-LIB: 20: backend, {19}, assembler, (device-openmp)
+// CHK-PHASES-LIB: 21: assembler, {20}, object, (device-openmp)
+// CH

Re: [PATCH] D21334: Add TargetInfo for 32-bit and 64-bit RenderScript

2016-06-29 Thread Pirama Arumuga Nainar via cfe-commits
pirama added a comment.

Ping...


http://reviews.llvm.org/D21334



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


Re: [PATCH] D20602: Add .rgba syntax extension to ext_vector_type types

2016-06-29 Thread Pirama Arumuga Nainar via cfe-commits
pirama added a comment.

Ping...


http://reviews.llvm.org/D20602



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


Re: [PATCH] D21803: [libcxxabi] Provide a fallback __cxa_thread_atexit() implementation

2016-06-29 Thread Asiri Rathnayake via cfe-commits
rmaprath added a comment.

In http://reviews.llvm.org/D21803#470060, @tavianator wrote:

> In http://reviews.llvm.org/D21803#469988, @bcraig wrote:
>
> > @rmaprath has been doing some work to make the threading runtime library 
> > swappable.  I don't recall if his work extended to libcxxabi or not, but 
> > I'll page him anyway.
>
>
> <__threading_support>?  Seems to be libc++-specific.  There's a few other raw 
> uses of pthreads in libc++abi.


Plan to get started with `libc++abi` as soon as I'm done with `libc++`, I've 
hit a couple of bumps with the latter, resolving them at the moment.

I don't see any new `pthread` dependencies introduced in this patch, so it 
sounds OK to me. Thanks for the ping though!

The patch itself looks OK to me. Will need approval from @mclow.lists or 
@ericwf.


http://reviews.llvm.org/D21803



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


[PATCH] D21847: [Driver][OpenMP] Build jobs for OpenMP offloading actions for targets using gcc tool chains.

2016-06-29 Thread Samuel Antao via cfe-commits
sfantao created this revision.
sfantao added reviewers: echristo, tra, jlebar, hfinkel, ABataev, rsmith.
sfantao added subscribers: caomhin, carlo.bertolli, arpith-jacob, 
andreybokhanko, Hahnfeld, cfe-commits.
Herald added a subscriber: mehdi_amini.

This patch adds logic to create jobs for OpenMP offloading actions by:
 - tuning the jobs result information to use the offloading prefix even for 
(device) linking actions.
 - replacing the device inputs of the host linking jobs by a linker script that 
embed them in the right sections.

With this patch, it is possible to produce a fully functional binary using 
OpenMP offloading capabilities with no separate compilation. 

http://reviews.llvm.org/D21847

Files:
  lib/Driver/Driver.cpp
  lib/Driver/Tools.cpp
  test/Driver/openmp-offload.c

Index: test/Driver/openmp-offload.c
===
--- test/Driver/openmp-offload.c
+++ test/Driver/openmp-offload.c
@@ -138,3 +138,95 @@
 // CHK-PHASES-FILES: 38: assembler, {37}, object, (device-openmp)
 // CHK-PHASES-FILES: 39: linker, {26, 32, 38}, image, (device-openmp)
 // CHK-PHASES-FILES: 40: offload, "host-openmp (powerpc64-ibm-linux-gnu)" {11}, "device-openmp (x86_64-pc-linux-gnu)" {25}, "device-openmp (powerpc64-ibm-linux-gnu)" {39}, image
+
+
+/// ###
+
+/// Check of the commands passed to each tool when using valid OpenMP targets.
+/// Here we also check that offloading does not break the use of integrated
+/// assembler. It does however preclude the merge of the host compile and
+/// backend phases. There are also two offloading specific options:
+/// -fopenmp-is-device: will tell the frontend that it will generate code for a
+/// target.
+/// -fopenmp-host-ir-file-path: specifies the host IR file that can be loaded by
+/// the target code generation to gather information about which declaration
+/// really need to be emitted.
+///
+// RUN:   %clang -### -fopenmp -o %t.out -target powerpc64le-linux -fopenmp-targets=powerpc64le-ibm-linux-gnu,x86_64-pc-linux-gnu %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-COMMANDS %s
+// Run the save temp test in a temporary folder as the linker script will be
+// created there.
+// RUN:   cd %T &&  \
+// RUN:   %clang -### -fopenmp -o %t.out -target powerpc64le-linux -fopenmp-targets=powerpc64le-ibm-linux-gnu,x86_64-pc-linux-gnu %s -save-temps 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-COMMANDS-ST %s
+// RUN:   FileCheck -check-prefix=CHK-LKS %s --input-file %t.lk
+//
+// Generate host BC file.
+//
+// CHK-COMMANDS: clang{{.*}}" "-cc1" "-triple" "powerpc64le--linux" "-emit-llvm-bc" {{.*}}"-o" "[[HOSTBC:.+\.bc]]" "-x" "c" "[[INPUT:.+\.c]]" "-fopenmp-targets=powerpc64le-ibm-linux-gnu,x86_64-pc-linux-gnu"
+// CHK-COMMANDS-ST: clang-3.9" "-cc1" "-triple" "powerpc64le--linux" "-E" {{.*}}"-fopenmp" {{.*}}"-o" "[[HOSTPP:.+\.i]]" "-x" "c" "[[INPUT:.+\.c]]"
+// CHK-COMMANDS-ST: clang-3.9" "-cc1" "-triple" "powerpc64le--linux" "-emit-llvm-bc" {{.*}}"-fopenmp" {{.*}}"-o" "[[HOSTBC:.+\.bc]]" "-x" "cpp-output" "[[HOSTPP]]" "-fopenmp-targets=powerpc64le-ibm-linux-gnu,x86_64-pc-linux-gnu"
+
+//
+// Compile for the powerpc device.
+/
+// CHK-COMMANDS: clang{{.*}}" "-cc1" "-triple" "powerpc64le-ibm-linux-gnu" "-emit-obj" {{.*}}"-fopenmp" {{.*}}"-o" "[[T1OBJ:.+\.o]]" "-x" "c" "[[INPUT]]" "-fopenmp-is-device" "-fopenmp-host-ir-file-path" "[[HOSTBC]]"
+// CHK-COMMANDS: ld" {{.*}}"-o" "[[T1BIN:.+\.out]]" {{.*}}"[[T1OBJ]]"
+// CHK-COMMANDS-ST: clang{{.*}}" "-cc1" "-triple" "powerpc64le-ibm-linux-gnu" "-E" {{.*}}"-fopenmp" {{.*}}"-o" "[[T1PP:.+\.i]]" "-x" "c" "[[INPUT]]"
+// CHK-COMMANDS-ST: clang{{.*}}" "-cc1" "-triple" "powerpc64le-ibm-linux-gnu" "-emit-llvm-bc" {{.*}}"-fopenmp" {{.*}}"-o" "[[T1BC:.+\.bc]]" "-x" "cpp-output" "[[T1PP]]" "-fopenmp-is-device" "-fopenmp-host-ir-file-path" "[[HOSTBC]]"
+// CHK-COMMANDS-ST: clang{{.*}}" "-cc1" "-triple" "powerpc64le-ibm-linux-gnu" "-S" {{.*}}"-fopenmp" {{.*}}"-o" "[[T1ASM:.+\.s]]" "-x" "ir" "[[T1BC]]"
+// CHK-COMMANDS-ST: clang{{.*}}" "-cc1as" "-triple" "powerpc64le-ibm-linux-gnu" "-filetype" "obj" {{.*}}"-o" "[[T1OBJ:.+\.o]]" "[[T1ASM]]"
+// CHK-COMMANDS-ST: ld" {{.*}}"-o" "[[T1BIN:.+\.out-device-openmp-powerpc64le-ibm-linux-gnu]]" {{.*}}[[T1OBJ]]
+
+//
+// Compile for the x86 device.
+//
+// CHK-COMMANDS: clang{{.*}}" "-cc1" "-triple" "x86_64-pc-linux-gnu" "-emit-obj"  {{.*}}"-fopenmp"  {{.*}}"-o" "[[T2OBJ:.+\.o]]" "-x" "c" "[[INPUT]]" "-fopenmp-is-device" "-fopenmp-host-ir-file-path" "[[HOSTBC]]"
+// CHK-COMMANDS: ld" {{.*}}"-o" "[[T2BIN:.+\.out]]" {{.*}}"[[T2OBJ]]"
+// CHK-COMMANDS-ST: clang{{.*}}" "-cc1" "-triple" "x86_64-pc-linux-gnu" "-E" {{.*}}"-fopenmp" {{.*}}"-o" "[[T2PP:.+\.i]]" "-x" "c" "[[INPUT]]"
+// CHK-COMMANDS-ST: clang{{.*}}" "-cc1" "-triple" "x86_64-pc-linux-gnu" "-emit-llvm-bc" {{.*}}"-fopenmp" {{.*}}"-o" "[[T2BC:.+\.bc]]" "-x" "cpp-output" "[[T2PP]]" "-fopenmp-is-device" "-fopenmp-host-ir-file-path

Re: [PATCH] D21803: [libcxxabi] Provide a fallback __cxa_thread_atexit() implementation

2016-06-29 Thread David Majnemer via cfe-commits
majnemer added inline comments.


Comment at: src/cxa_thread_atexit.cpp:64-90
@@ -18,8 +63,29 @@
+_LIBCXXABI_FUNC_VIS int __cxa_thread_atexit(Dtor dtor, void *obj,
 void *dso_symbol) throw() {
-  extern int __cxa_thread_atexit_impl(void (*)(void *), void *, void *);
-  return __cxa_thread_atexit_impl(dtor, obj, dso_symbol);
-}
+  extern int __cxa_thread_atexit_impl(Dtor, void *, void *)
+__attribute__((__weak__));
+
+  if (__cxa_thread_atexit_impl) {
+return __cxa_thread_atexit_impl(dtor, obj, dso_symbol);
+  } else {
+static DtorListHolder dtors;
+
+auto head = static_cast(std::malloc(sizeof(DtorList)));
+if (!head) {
+  return -1;
+}
+
+head->dtor = dtor;
+head->obj = obj;
+head->next = dtors.get();
+
+if (!dtors.set(head)) {
+  std::free(head);
+  return -1;
+}
 
-#endif // HAVE__CXA_THREAD_ATEXIT_IMPL
+return 0;
+  }
+}
 
 } // extern "C"

I think that this should be an opt-in mechanism, there are platforms that 
presumably never need to pay the cost of the unused code (macOS comes to mind).


http://reviews.llvm.org/D21803



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


[PATCH] D21848: [Driver][OpenMP] Add logic for offloading-specific argument translation.

2016-06-29 Thread Samuel Antao via cfe-commits
sfantao created this revision.
sfantao added reviewers: echristo, tra, jlebar, hfinkel, ABataev, rsmith.
sfantao added subscribers: caomhin, carlo.bertolli, arpith-jacob, 
andreybokhanko, Hahnfeld, cfe-commits.
Herald added a subscriber: mehdi_amini.

This patch includes support for argument translation that is specific of a 
given offloading kind. Additionally, it implements the translation for OpenMP 
device kinds in the gcc tool chain.

With this patch, it is possible to compile a functional OpenMP application with 
offloading capabilities with no separate compilation.

http://reviews.llvm.org/D21848

Files:
  include/clang/Driver/Compilation.h
  include/clang/Driver/ToolChain.h
  lib/Driver/Compilation.cpp
  lib/Driver/Driver.cpp
  lib/Driver/MSVCToolChain.cpp
  lib/Driver/ToolChains.cpp
  lib/Driver/ToolChains.h
  test/Driver/openmp-offload.c

Index: test/Driver/openmp-offload.c
===
--- test/Driver/openmp-offload.c
+++ test/Driver/openmp-offload.c
@@ -169,25 +169,25 @@
 
 //
 // Compile for the powerpc device.
-/
-// CHK-COMMANDS: clang{{.*}}" "-cc1" "-triple" "powerpc64le-ibm-linux-gnu" "-emit-obj" {{.*}}"-fopenmp" {{.*}}"-o" "[[T1OBJ:.+\.o]]" "-x" "c" "[[INPUT]]" "-fopenmp-is-device" "-fopenmp-host-ir-file-path" "[[HOSTBC]]"
+//
+// CHK-COMMANDS: clang{{.*}}" "-cc1" "-triple" "powerpc64le-ibm-linux-gnu" "-emit-obj" {{.*}}"-pic-level" "2" {{.*}}"-fopenmp" {{.*}}"-o" "[[T1OBJ:.+\.o]]" "-x" "c" "[[INPUT]]" "-fopenmp-is-device" "-fopenmp-host-ir-file-path" "[[HOSTBC]]"
 // CHK-COMMANDS: ld" {{.*}}"-o" "[[T1BIN:.+\.out]]" {{.*}}"[[T1OBJ]]"
 // CHK-COMMANDS-ST: clang{{.*}}" "-cc1" "-triple" "powerpc64le-ibm-linux-gnu" "-E" {{.*}}"-fopenmp" {{.*}}"-o" "[[T1PP:.+\.i]]" "-x" "c" "[[INPUT]]"
-// CHK-COMMANDS-ST: clang{{.*}}" "-cc1" "-triple" "powerpc64le-ibm-linux-gnu" "-emit-llvm-bc" {{.*}}"-fopenmp" {{.*}}"-o" "[[T1BC:.+\.bc]]" "-x" "cpp-output" "[[T1PP]]" "-fopenmp-is-device" "-fopenmp-host-ir-file-path" "[[HOSTBC]]"
+// CHK-COMMANDS-ST: clang{{.*}}" "-cc1" "-triple" "powerpc64le-ibm-linux-gnu" "-emit-llvm-bc" {{.*}}"-pic-level" "2" {{.*}}"-fopenmp" {{.*}}"-o" "[[T1BC:.+\.bc]]" "-x" "cpp-output" "[[T1PP]]" "-fopenmp-is-device" "-fopenmp-host-ir-file-path" "[[HOSTBC]]"
 // CHK-COMMANDS-ST: clang{{.*}}" "-cc1" "-triple" "powerpc64le-ibm-linux-gnu" "-S" {{.*}}"-fopenmp" {{.*}}"-o" "[[T1ASM:.+\.s]]" "-x" "ir" "[[T1BC]]"
 // CHK-COMMANDS-ST: clang{{.*}}" "-cc1as" "-triple" "powerpc64le-ibm-linux-gnu" "-filetype" "obj" {{.*}}"-o" "[[T1OBJ:.+\.o]]" "[[T1ASM]]"
-// CHK-COMMANDS-ST: ld" {{.*}}"-o" "[[T1BIN:.+\.out-device-openmp-powerpc64le-ibm-linux-gnu]]" {{.*}}[[T1OBJ]]
+// CHK-COMMANDS-ST: ld" {{.*}}"-shared" "-o" "[[T1BIN:.+\.out-device-openmp-powerpc64le-ibm-linux-gnu]]" {{.*}}[[T1OBJ]]
 
 //
 // Compile for the x86 device.
 //
-// CHK-COMMANDS: clang{{.*}}" "-cc1" "-triple" "x86_64-pc-linux-gnu" "-emit-obj"  {{.*}}"-fopenmp"  {{.*}}"-o" "[[T2OBJ:.+\.o]]" "-x" "c" "[[INPUT]]" "-fopenmp-is-device" "-fopenmp-host-ir-file-path" "[[HOSTBC]]"
+// CHK-COMMANDS: clang{{.*}}" "-cc1" "-triple" "x86_64-pc-linux-gnu" "-emit-obj"  {{.*}}"-pic-level" "2" {{.*}}"-fopenmp"  {{.*}}"-o" "[[T2OBJ:.+\.o]]" "-x" "c" "[[INPUT]]" "-fopenmp-is-device" "-fopenmp-host-ir-file-path" "[[HOSTBC]]"
 // CHK-COMMANDS: ld" {{.*}}"-o" "[[T2BIN:.+\.out]]" {{.*}}"[[T2OBJ]]"
 // CHK-COMMANDS-ST: clang{{.*}}" "-cc1" "-triple" "x86_64-pc-linux-gnu" "-E" {{.*}}"-fopenmp" {{.*}}"-o" "[[T2PP:.+\.i]]" "-x" "c" "[[INPUT]]"
-// CHK-COMMANDS-ST: clang{{.*}}" "-cc1" "-triple" "x86_64-pc-linux-gnu" "-emit-llvm-bc" {{.*}}"-fopenmp" {{.*}}"-o" "[[T2BC:.+\.bc]]" "-x" "cpp-output" "[[T2PP]]" "-fopenmp-is-device" "-fopenmp-host-ir-file-path" "[[HOSTBC]]"
+// CHK-COMMANDS-ST: clang{{.*}}" "-cc1" "-triple" "x86_64-pc-linux-gnu" "-emit-llvm-bc" {{.*}}"-pic-level" "2" {{.*}}"-fopenmp" {{.*}}"-o" "[[T2BC:.+\.bc]]" "-x" "cpp-output" "[[T2PP]]" "-fopenmp-is-device" "-fopenmp-host-ir-file-path" "[[HOSTBC]]"
 // CHK-COMMANDS-ST: clang{{.*}}" "-cc1" "-triple" "x86_64-pc-linux-gnu" "-S" {{.*}}"-fopenmp" {{.*}}"-o" "[[T2ASM:.+\.s]]" "-x" "ir" "[[T2BC]]"
 // CHK-COMMANDS-ST: clang{{.*}}" "-cc1as" "-triple" "x86_64-pc-linux-gnu" "-filetype" "obj" {{.*}}"-o" "[[T2OBJ:.+\.o]]" "[[T2ASM]]"
-// CHK-COMMANDS-ST: ld" {{.*}}"-o" "[[T2BIN:.+\.out-device-openmp-x86_64-pc-linux-gnu]]" {{.*}}[[T2OBJ]]
+// CHK-COMMANDS-ST: ld" {{.*}}"-shared" "-o" "[[T2BIN:.+\.out-device-openmp-x86_64-pc-linux-gnu]]" {{.*}}[[T2OBJ]]
 
 //
 // Generate host object from the BC file and link using the linker script.
@@ -228,5 +228,3 @@
 // CHK-LKS:   }
 // CHK-LKS: }
 // CHK-LKS: INSERT BEFORE .data
-
-
Index: lib/Driver/ToolChains.h
===
--- lib/Driver/ToolChains.h
+++ lib/Driver/ToolChains.h
@@ -208,6 +208,9 @@
   bool isPIEDefault() const override;
   bool isPICDefaultForced() const override;
   bool IsIntegratedAssemblerDefault() const override;
+  llvm::opt::DerivedArgList *
+

Re: [PATCH] D13909: clang-offload-bundler - offload files bundling/unbundling tool

2016-06-29 Thread Samuel Antao via cfe-commits
sfantao updated this revision to Diff 62249.
sfantao added a comment.
Herald added a subscriber: mehdi_amini.

- Reorganize file handlers. Generate empty files if no components exist in the 
bundle instead of just failing.


http://reviews.llvm.org/D13909

Files:
  test/Driver/clang-offload-bundler.c
  tools/CMakeLists.txt
  tools/clang-offload-bundler/CMakeLists.txt
  tools/clang-offload-bundler/ClangOffloadBundler.cpp

Index: tools/clang-offload-bundler/ClangOffloadBundler.cpp
===
--- /dev/null
+++ tools/clang-offload-bundler/ClangOffloadBundler.cpp
@@ -0,0 +1,683 @@
+//===-- clang-offload-bundler/ClangOffloadBundler.cpp - Clang format tool -===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+///
+/// \file
+/// \brief This file implements a clang-offload-bundler that bundles different
+/// files that relate with the same source code but different targets into a
+/// single one. Also the implements the opposite functionality, i.e. unbundle
+/// files previous created by this tool.
+///
+//===--===//
+
+#include "clang/Basic/FileManager.h"
+#include "clang/Basic/Version.h"
+#include "llvm/ADT/StringMap.h"
+#include "llvm/ADT/StringSwitch.h"
+#include "llvm/Bitcode/ReaderWriter.h"
+#include "llvm/IR/Constants.h"
+#include "llvm/IR/LLVMContext.h"
+#include "llvm/IR/Module.h"
+#include "llvm/Object/Binary.h"
+#include "llvm/Object/ELFObjectFile.h"
+#include "llvm/Object/ObjectFile.h"
+#include "llvm/Support/CommandLine.h"
+#include "llvm/Support/FileSystem.h"
+#include "llvm/Support/Path.h"
+#include "llvm/Support/Program.h"
+#include "llvm/Support/Signals.h"
+
+using namespace llvm;
+using namespace llvm::object;
+
+static cl::opt Help("h", cl::desc("Alias for -help"), cl::Hidden);
+
+// Mark all our options with this category, everything else (except for -version
+// and -help) will be hidden.
+static cl::OptionCategory
+ClangOffloadBundlerCategory("clang-offload-bundler options");
+
+static cl::list
+InputFileNames("inputs", cl::CommaSeparated, cl::OneOrMore,
+   cl::desc("[,...]"),
+   cl::cat(ClangOffloadBundlerCategory));
+static cl::list
+OutputFileNames("outputs", cl::CommaSeparated, cl::OneOrMore,
+cl::desc("[,...]"),
+cl::cat(ClangOffloadBundlerCategory));
+static cl::list
+TargetNames("targets", cl::CommaSeparated, cl::OneOrMore,
+cl::desc("[-,...]"),
+cl::cat(ClangOffloadBundlerCategory));
+static cl::opt
+FilesType("type", cl::Required,
+  cl::desc("Type of the files to be bundled/unbundled.\n"
+   "Current supported types are:\n"
+   "  i   - cpp-output\n"
+   "  ii  - c++-cpp-output\n"
+   "  ll  - llvm\n"
+   "  bc  - llvm-bc\n"
+   "  s   - assembler\n"
+   "  o   - object\n"
+   "  gch - precompiled-header\n"
+   "  ast - clang AST file"),
+  cl::cat(ClangOffloadBundlerCategory));
+static cl::opt
+Unbundle("unbundle",
+ cl::desc("Unbundle bundled file into several output files.\n"),
+ cl::init(false), cl::cat(ClangOffloadBundlerCategory));
+
+/// \brief Magic string that marks the existence of offloading data.
+#define OFFLOAD_BUNDLER_MAGIC_STR "__CLANG_OFFLOAD_BUNDLE__"
+
+/// \brief Obtain the offload kind and real machine triple out of the target
+/// information specified by the user.
+static void getOffloadKindAndTriple(StringRef Target, StringRef &OffloadKind,
+StringRef &Triple) {
+  auto KindTriplePair = Target.split('-');
+  OffloadKind = KindTriplePair.first;
+  Triple = KindTriplePair.second;
+}
+static bool hasHostKind(StringRef Target) {
+  StringRef OffloadKind;
+  StringRef Triple;
+  getOffloadKindAndTriple(Target, OffloadKind, Triple);
+  return OffloadKind == "host";
+}
+
+/// \brief Generic file handler interface.
+class FileHandler {
+public:
+  /// \brief Update the file handler with information from the header of the
+  /// bundled file
+  virtual void ReadHeader(MemoryBuffer &Input) = 0;
+  /// \brief Read the marker of the next bundled to be read in the file. The
+  /// triple of the target associated with that bundled is returned. An empty
+  /// string is returned if there are no more bundles to be read.
+  virtual StringRef ReadBundleStart(MemoryBuffer &Input) = 0;
+  /// \brief Read the marker that closes the current bundle.
+  virtual void ReadBundleEnd(MemoryBuffer &Input) = 0;
+  /// \brief Read the current bundle and write the 

Re: [PATCH] D21834: Implementing 'If statement with Initializer'

2016-06-29 Thread Anton Bikineev via cfe-commits
AntonBikineev added a subscriber: cfe-commits.
AntonBikineev updated this revision to Diff 62254.

http://reviews.llvm.org/D21834

Files:
  include/clang/AST/Stmt.h
  include/clang/Parse/Parser.h
  include/clang/Sema/Sema.h
  lib/AST/ASTImporter.cpp
  lib/AST/Stmt.cpp
  lib/Analysis/BodyFarm.cpp
  lib/CodeGen/CGStmt.cpp
  lib/Parse/ParseStmt.cpp
  lib/Parse/ParseTentative.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaExprCXX.cpp
  lib/Sema/SemaStmt.cpp
  lib/Sema/TreeTransform.h
  lib/Serialization/ASTReaderStmt.cpp
  lib/Serialization/ASTWriterStmt.cpp

Index: lib/Serialization/ASTWriterStmt.cpp
===
--- lib/Serialization/ASTWriterStmt.cpp
+++ lib/Serialization/ASTWriterStmt.cpp
@@ -129,6 +129,7 @@
 void ASTStmtWriter::VisitIfStmt(IfStmt *S) {
   VisitStmt(S);
   Record.push_back(S->isConstexpr());
+  Record.AddStmt(S->getInit());
   Record.AddDeclRef(S->getConditionVariable());
   Record.AddStmt(S->getCond());
   Record.AddStmt(S->getThen());
Index: lib/Serialization/ASTReaderStmt.cpp
===
--- lib/Serialization/ASTReaderStmt.cpp
+++ lib/Serialization/ASTReaderStmt.cpp
@@ -185,6 +185,7 @@
 void ASTStmtReader::VisitIfStmt(IfStmt *S) {
   VisitStmt(S);
   S->setConstexpr(Record[Idx++]);
+  S->setInit(Reader.ReadSubStmt());
   S->setConditionVariable(Reader.getContext(),
   ReadDeclAs(Record, Idx));
   S->setCond(Reader.ReadSubExpr());
Index: lib/Sema/TreeTransform.h
===
--- lib/Sema/TreeTransform.h
+++ lib/Sema/TreeTransform.h
@@ -1174,9 +1174,9 @@
   /// By default, performs semantic analysis to build the new statement.
   /// Subclasses may override this routine to provide different behavior.
   StmtResult RebuildIfStmt(SourceLocation IfLoc, bool IsConstexpr,
-   Sema::ConditionResult Cond, Stmt *Then,
+   Sema::ConditionResult Cond, Stmt *Init, Stmt *Then,
SourceLocation ElseLoc, Stmt *Else) {
-return getSema().ActOnIfStmt(IfLoc, IsConstexpr, Cond, Then, ElseLoc, Else);
+return getSema().ActOnIfStmt(IfLoc, IsConstexpr, Cond, Init, Then, ElseLoc, Else);
   }
 
   /// \brief Start building a new switch statement.
@@ -6225,6 +6225,11 @@
 template
 StmtResult
 TreeTransform::TransformIfStmt(IfStmt *S) {
+  // Transform the initialization statement
+  StmtResult Init = getDerived().TransformStmt(S->getInit());
+  if (Init.isInvalid())
+return StmtError();
+
   // Transform the condition
   Sema::ConditionResult Cond = getDerived().TransformCondition(
   S->getIfLoc(), S->getConditionVariable(), S->getCond(),
@@ -6257,6 +6262,7 @@
   }
 
   if (!getDerived().AlwaysRebuild() &&
+  Init.get() == S->getInit() &&
   Cond.get() == std::make_pair(S->getConditionVariable(), S->getCond()) &&
   Then.get() == S->getThen() &&
   Else.get() == S->getElse())
@@ -6263,7 +6269,7 @@
 return S;
 
   return getDerived().RebuildIfStmt(S->getIfLoc(), S->isConstexpr(), Cond,
-Then.get(), S->getElseLoc(), Else.get());
+Init.get(), Then.get(), S->getElseLoc(), Else.get());
 }
 
 template
Index: lib/Sema/SemaStmt.cpp
===
--- lib/Sema/SemaStmt.cpp
+++ lib/Sema/SemaStmt.cpp
@@ -505,7 +505,7 @@
 
 StmtResult
 Sema::ActOnIfStmt(SourceLocation IfLoc, bool IsConstexpr, ConditionResult Cond,
-  Stmt *thenStmt, SourceLocation ElseLoc,
+  Stmt *initStmt, Stmt *thenStmt, SourceLocation ElseLoc,
   Stmt *elseStmt) {
   if (Cond.isInvalid())
 Cond = ConditionResult(
@@ -524,11 +524,11 @@
 DiagnoseEmptyStmtBody(CondExpr->getLocEnd(), thenStmt,
   diag::warn_empty_if_body);
 
-  return BuildIfStmt(IfLoc, IsConstexpr, Cond, thenStmt, ElseLoc, elseStmt);
+  return BuildIfStmt(IfLoc, IsConstexpr, Cond, initStmt, thenStmt, ElseLoc, elseStmt);
 }
 
 StmtResult Sema::BuildIfStmt(SourceLocation IfLoc, bool IsConstexpr,
- ConditionResult Cond, Stmt *thenStmt,
+ ConditionResult Cond, Stmt *initStmt, Stmt *thenStmt,
  SourceLocation ElseLoc, Stmt *elseStmt) {
   if (Cond.isInvalid())
 return StmtError();
@@ -539,7 +539,7 @@
   DiagnoseUnusedExprResult(thenStmt);
   DiagnoseUnusedExprResult(elseStmt);
 
-  return new (Context) IfStmt(Context, IfLoc, IsConstexpr, Cond.get().first,
+  return new (Context) IfStmt(Context, IfLoc, IsConstexpr, initStmt, Cond.get().first,
   Cond.get().second, thenStmt, ElseLoc, elseStmt);
 }
 
Index: lib/Sema/SemaExprCXX.cpp
===
--- lib/Sema/SemaExprCXX.cpp
+++ lib/Sema/SemaExprCXX.cpp
@@ -3095,6 +3095,7 @@
 
   switch (CK)

Re: [PATCH] D21666: [Tooling] Add optional argument to getFullyQualifiedName to prepend "::".

2016-06-29 Thread Reid Kleckner via cfe-commits
rnk accepted this revision.
rnk added a comment.

lgtm


http://reviews.llvm.org/D21666



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


[PATCH] D21851: [Driver][OpenMP][CUDA] Add capability to bundle object files in sections of the host binary format.

2016-06-29 Thread Samuel Antao via cfe-commits
sfantao created this revision.
sfantao added reviewers: echristo, tra, jlebar, hfinkel, ABataev.
sfantao added subscribers: caomhin, carlo.bertolli, arpith-jacob, Hahnfeld, 
andreybokhanko, cfe-commits.
Herald added a subscriber: mehdi_amini.

This patch adds the capability to bundle object files in sections of the host 
binary using a designated naming convention for these sections. This patch uses 
the functionality of the object reader already in the LLVM library to read 
bundled files, and invokes clang with the incremental linking options to create 
bundle files. 

Bundling files involves creating an IR file with the contents of the bundle 
assigned as initializers of globals binded to the designated sections. This way 
the bundling implementation is agnostic of the host object format.

The features added by this patch were requested in the RFC discussion in  
http://lists.llvm.org/pipermail/cfe-dev/2016-February/047547.html.

http://reviews.llvm.org/D21851

Files:
  test/Driver/clang-offload-bundler.c
  tools/clang-offload-bundler/ClangOffloadBundler.cpp

Index: tools/clang-offload-bundler/ClangOffloadBundler.cpp
===
--- tools/clang-offload-bundler/ClangOffloadBundler.cpp
+++ tools/clang-offload-bundler/ClangOffloadBundler.cpp
@@ -75,14 +75,23 @@
 /// \brief Magic string that marks the existence of offloading data.
 #define OFFLOAD_BUNDLER_MAGIC_STR "__CLANG_OFFLOAD_BUNDLE__"
 
+/// \brief Path to the current binary.
+static std::string BundlerExecutable;
+
 /// \brief Obtain the offload kind and real machine triple out of the target
 /// information specified by the user.
 static void getOffloadKindAndTriple(StringRef Target, StringRef &OffloadKind,
 StringRef &Triple) {
   auto KindTriplePair = Target.split('-');
   OffloadKind = KindTriplePair.first;
   Triple = KindTriplePair.second;
 }
+static StringRef getTriple(StringRef Target) {
+  StringRef OffloadKind;
+  StringRef Triple;
+  getOffloadKindAndTriple(Target, OffloadKind, Triple);
+  return Triple;
+}
 static bool hasHostKind(StringRef Target) {
   StringRef OffloadKind;
   StringRef Triple;
@@ -312,6 +321,211 @@
   ~BinaryFileHandler() {}
 };
 
+// Handler for object files. The bundles are organized by sections with a
+// designated name.
+//
+// In order to bundle we create an IR file with the content of each section and
+// use incremental linking to produce the resulting object. We also add section
+// with a single byte to state the name of the component the main object file
+// (the one we are bundling into) refers to.
+//
+// To unbundle, we use just copy the contents of the designated section. If the
+// requested bundle refer to the main object file, we just copy it with no
+// changes.
+class ObjectFileHandler : public FileHandler {
+
+  /// \brief The object file we are currently dealing with.
+  ObjectFile &Obj;
+
+  /// \brief Return the input file contents.
+  StringRef getInputFileContents() const { return Obj.getData(); }
+
+  /// \brief Return true if the provided section is an offload section and
+  /// return the triple by reference.
+  bool isOffloadSection(SectionRef CurSection, StringRef &OffloadTriple) {
+StringRef SectionName;
+CurSection.getName(SectionName);
+
+if (SectionName.empty())
+  return false;
+
+// If it does not start with the reserved suffix, just skip this section.
+if (!SectionName.startswith(OFFLOAD_BUNDLER_MAGIC_STR))
+  return false;
+
+// Return the triple that is right after the reserved prefix.
+OffloadTriple = SectionName.substr(sizeof(OFFLOAD_BUNDLER_MAGIC_STR) - 1);
+return true;
+  }
+
+  /// \brief Total number of inputs.
+  unsigned NumberOfInputs = 0;
+
+  /// \brief Total number of processed inputs, i.e, inputs that were already
+  /// read from the buffers.
+  unsigned NumberOfProcessedInputs = 0;
+
+  /// \brief LLVM context used to to create the auxiliar modules.
+  LLVMContext VMContext;
+
+  /// \brief LLVM module used to create an object with all the bundle
+  /// components.
+  std::unique_ptr AuxModule;
+
+  /// \brief The current triple we are working with.
+  StringRef CurrentTriple;
+
+  /// \brief The name of the main input file.
+  StringRef MainInputFileName;
+
+  /// \brief Iterator of the current and next section.
+  section_iterator CurrentSection;
+  section_iterator NextSection;
+
+public:
+  void ReadHeader(MemoryBuffer &Input) {}
+  StringRef ReadBundleStart(MemoryBuffer &Input) {
+
+while (NextSection != Obj.section_end()) {
+  CurrentSection = NextSection;
+  ++NextSection;
+
+  StringRef OffloadTriple;
+  // Check if the current section name starts with the reserved prefix. If
+  // so, return the triple.
+  if (isOffloadSection(*CurrentSection, OffloadTriple))
+return OffloadTriple;
+}
+return StringRef();
+  }
+  void ReadBundleEnd(MemoryBuffer &Input) {}
+  void ReadBundle(raw_fd_o

r274147 - Re-land "[MS] Don't expect vftables to be provided for extern template instantiations"

2016-06-29 Thread Reid Kleckner via cfe-commits
Author: rnk
Date: Wed Jun 29 13:29:21 2016
New Revision: 274147

URL: http://llvm.org/viewvc/llvm-project?rev=274147&view=rev
Log:
Re-land "[MS] Don't expect vftables to be provided for extern template 
instantiations"

Reverts r273305 and re-instates r273296.

We needed to fix a bug in Sema::MarkVTableUsed to ensure that operator
delete lookup occurs when the vtable is referenced. We already had a
special case to look up operator delete when dllimport was used, but I
think should really mark virtual destructors referenced any time the
vtable is used.

Added:
cfe/trunk/test/CodeGenCXX/microsoft-abi-extern-template.cpp
Modified:
cfe/trunk/lib/AST/VTableBuilder.cpp
cfe/trunk/lib/CodeGen/CGVTables.cpp
cfe/trunk/lib/Sema/SemaDeclCXX.cpp
cfe/trunk/test/CodeGenCXX/microsoft-abi-vbtables.cpp
cfe/trunk/test/CodeGenCXX/microsoft-abi-vftables.cpp

Modified: cfe/trunk/lib/AST/VTableBuilder.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/VTableBuilder.cpp?rev=274147&r1=274146&r2=274147&view=diff
==
--- cfe/trunk/lib/AST/VTableBuilder.cpp (original)
+++ cfe/trunk/lib/AST/VTableBuilder.cpp Wed Jun 29 13:29:21 2016
@@ -2545,14 +2545,13 @@ public:
 MostDerivedClassLayout(Context.getASTRecordLayout(MostDerivedClass)),
 WhichVFPtr(*Which),
 Overriders(MostDerivedClass, CharUnits(), MostDerivedClass) {
-// Only include the RTTI component if we know that we will provide a
-// definition of the vftable.  We always provide the definition of
-// dllimported classes.
+// Provide the RTTI component if RTTIData is enabled. If the vftable would
+// be available externally, we should not provide the RTTI componenent. It
+// is currently impossible to get available externally vftables with either
+// dllimport or extern template instantiations, but eventually we may add a
+// flag to support additional devirtualization that needs this.
 if (Context.getLangOpts().RTTIData)
-  if (MostDerivedClass->hasAttr() ||
-  MostDerivedClass->getTemplateSpecializationKind() !=
-  TSK_ExplicitInstantiationDeclaration)
-HasRTTIComponent = true;
+  HasRTTIComponent = true;
 
 LayoutVFTable();
 

Modified: cfe/trunk/lib/CodeGen/CGVTables.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGVTables.cpp?rev=274147&r1=274146&r2=274147&view=diff
==
--- cfe/trunk/lib/CodeGen/CGVTables.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGVTables.cpp Wed Jun 29 13:29:21 2016
@@ -794,6 +794,10 @@ CodeGenModule::getVTableLinkage(const CX
   return DiscardableODRLinkage;
 
 case TSK_ExplicitInstantiationDeclaration:
+  // Explicit instantiations in MSVC do not provide vtables, so we must 
emit
+  // our own.
+  if (getTarget().getCXXABI().isMicrosoft())
+return DiscardableODRLinkage;
   return shouldEmitAvailableExternallyVTable(*this, RD)
  ? llvm::GlobalVariable::AvailableExternallyLinkage
  : llvm::GlobalVariable::ExternalLinkage;
@@ -839,9 +843,9 @@ CodeGenVTables::GenerateClassData(const
 bool CodeGenVTables::isVTableExternal(const CXXRecordDecl *RD) {
   assert(RD->isDynamicClass() && "Non-dynamic classes have no VTable.");
 
-  // We always synthesize vtables on the import side regardless of whether or
-  // not it is an explicit instantiation declaration.
-  if (CGM.getTarget().getCXXABI().isMicrosoft() && 
RD->hasAttr())
+  // We always synthesize vtables if they are needed in the MS ABI. MSVC 
doesn't
+  // emit them even if there is an explicit template instantiation.
+  if (CGM.getTarget().getCXXABI().isMicrosoft())
 return false;
 
   // If we have an explicit instantiation declaration (and not a

Modified: cfe/trunk/lib/Sema/SemaDeclCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclCXX.cpp?rev=274147&r1=274146&r2=274147&view=diff
==
--- cfe/trunk/lib/Sema/SemaDeclCXX.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclCXX.cpp Wed Jun 29 13:29:21 2016
@@ -13425,20 +13425,18 @@ void Sema::MarkVTableUsed(SourceLocation
 // checks (i.e. operator delete() lookup) when the vtable is marked used, 
as
 // the deleting destructor is emitted with the vtable, not with the
 // destructor definition as in the Itanium ABI.
-// If it has a definition, we do the check at that point instead.
 if (Context.getTargetInfo().getCXXABI().isMicrosoft()) {
-  if (Class->hasUserDeclaredDestructor() &&
-  !Class->getDestructor()->isDefined() &&
-  !Class->getDestructor()->isDeleted()) {
-CXXDestructorDecl *DD = Class->getDestructor();
-ContextRAII SavedContext(*this, DD);
-CheckDestructor(DD);
-  } else if (Class->hasAttr()) {
-// We always syn

[PATCH] D21852: [Driver][OpenMP] Update actions builder to create bundling action when necessary.

2016-06-29 Thread Samuel Antao via cfe-commits
sfantao created this revision.
sfantao added reviewers: echristo, tra, jlebar, hfinkel, ABataev.
sfantao added subscribers: caomhin, carlo.bertolli, arpith-jacob, 
andreybokhanko, Hahnfeld, cfe-commits.
Herald added a subscriber: mehdi_amini.

In order to save the user from dealing with multiple output files (for host and 
device) while using separate compilation, a new action `OffloadBundlingAction` 
is used when the last phase is not linking. This action will then result in a 
job that uses the proposed bundling tool to create a single 
preprocessed/IR/ASM/Object file from multiple ones.

The job creation for the new action will be proposed in a separate patch.

http://reviews.llvm.org/D21852

Files:
  include/clang/Driver/Action.h
  lib/Driver/Action.cpp
  lib/Driver/Driver.cpp
  lib/Driver/ToolChain.cpp
  test/Driver/openmp-offload.c

Index: test/Driver/openmp-offload.c
===
--- test/Driver/openmp-offload.c
+++ test/Driver/openmp-offload.c
@@ -228,3 +228,31 @@
 // CHK-LKS:   }
 // CHK-LKS: }
 // CHK-LKS: INSERT BEFORE .data
+
+
+/// ###
+
+/// Check separate compilation with offloading - bundling actions
+// RUN:   %clang -### -ccc-print-phases -fopenmp -c -o %t.o -lsomelib -target powerpc64le-linux -fopenmp-targets=powerpc64le-ibm-linux-gnu,x86_64-pc-linux-gnu %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-BUACTIONS %s
+
+// CHK-BUACTIONS: 0: input, "[[INPUT:.+\.c]]", c, (host-openmp)
+// CHK-BUACTIONS: 1: preprocessor, {0}, cpp-output, (host-openmp)
+// CHK-BUACTIONS: 2: compiler, {1}, ir, (host-openmp)
+// CHK-BUACTIONS: 3: input, "[[INPUT]]", c, (device-openmp)
+// CHK-BUACTIONS: 4: preprocessor, {3}, cpp-output, (device-openmp)
+// CHK-BUACTIONS: 5: compiler, {4}, ir, (device-openmp)
+// CHK-BUACTIONS: 6: offload, "host-openmp (powerpc64le--linux)" {2}, "device-openmp (powerpc64le-ibm-linux-gnu)" {5}, ir
+// CHK-BUACTIONS: 7: backend, {6}, assembler, (device-openmp)
+// CHK-BUACTIONS: 8: assembler, {7}, object, (device-openmp)
+// CHK-BUACTIONS: 9: offload, "device-openmp (powerpc64le-ibm-linux-gnu)" {8}, object
+// CHK-BUACTIONS: 10: input, "[[INPUT]]", c, (device-openmp)
+// CHK-BUACTIONS: 11: preprocessor, {10}, cpp-output, (device-openmp)
+// CHK-BUACTIONS: 12: compiler, {11}, ir, (device-openmp)
+// CHK-BUACTIONS: 13: offload, "host-openmp (powerpc64le--linux)" {2}, "device-openmp (x86_64-pc-linux-gnu)" {12}, ir
+// CHK-BUACTIONS: 14: backend, {13}, assembler, (device-openmp)
+// CHK-BUACTIONS: 15: assembler, {14}, object, (device-openmp)
+// CHK-BUACTIONS: 16: offload, "device-openmp (x86_64-pc-linux-gnu)" {15}, object
+// CHK-BUACTIONS: 17: backend, {2}, assembler, (host-openmp)
+// CHK-BUACTIONS: 18: assembler, {17}, object, (host-openmp)
+// CHK-BUACTIONS: 19: clang-offload-bundler, {9, 16, 18}, object, (host-openmp)
\ No newline at end of file
Index: lib/Driver/ToolChain.cpp
===
--- lib/Driver/ToolChain.cpp
+++ lib/Driver/ToolChain.cpp
@@ -262,6 +262,10 @@
   case Action::VerifyPCHJobClass:
   case Action::BackendJobClass:
 return getClang();
+
+  case Action::OffloadBundlingJobClass:
+// FIXME: Add a tool for the bundling actions.
+return nullptr;
   }
 
   llvm_unreachable("Invalid tool kind.");
Index: lib/Driver/Driver.cpp
===
--- lib/Driver/Driver.cpp
+++ lib/Driver/Driver.cpp
@@ -1530,6 +1530,9 @@
 // are found.
 virtual bool initialize() { return false; }
 
+// \brief Return true if the builder can use bundling/unbundling.
+virtual bool canUseBundlerUnbundler() const { return false; }
+
 // \brief Return true if this builder is valid. We have a valid builder if
 // we have associated device tool chains.
 bool isValid() { return !ToolChains.empty(); }
@@ -1853,6 +1856,26 @@
   return ABRT_Success;
 }
 
+void appendTopLevelActions(ActionList &AL) override {
+  if (OpenMPDeviceActions.empty())
+return;
+
+  // We should always have an action for each input.
+  assert(OpenMPDeviceActions.size() == ToolChains.size() &&
+ "Number of OpenMP actions and toolchains do not match.");
+
+  // Append all device actions followed by the proper offload action.
+  auto TI = ToolChains.begin();
+  for (auto *A : OpenMPDeviceActions) {
+OffloadAction::DeviceDependences Dep;
+Dep.add(*A, **TI, /*BoundArch=*/nullptr, Action::OFK_OpenMP);
+AL.push_back(C.MakeAction(Dep, A->getType()));
+++TI;
+  }
+  // We no longer need the action stored in this builder.
+  OpenMPDeviceActions.clear();
+}
+
 void appendLinkDependences(OffloadAction::DeviceDependences &DA) override {
   assert(ToolChains.size() == DeviceLinkerInputs.size() &&
  "Toolchains and linker inputs sizes do not match.");

[PATCH] D21853: [Driver][OpenMP] Update actions builder to create unbundling action when necessary.

2016-06-29 Thread Samuel Antao via cfe-commits
sfantao created this revision.
sfantao added reviewers: echristo, tra, jlebar, hfinkel, ABataev.
sfantao added subscribers: caomhin, carlo.bertolli, arpith-jacob, 
andreybokhanko, Hahnfeld, cfe-commits.
Herald added a subscriber: mehdi_amini.

Each time that offloading support is requested by the user and the input file 
is not a source file, an action `OffloadUnbundlingAction` is created to signal 
that the input file may contain bundles, so that the proper tool is then 
invoked to attempt to extract the components of the bundle. This patch adds the 
logic to create that action in offload action builder.

The job creation for the new action will be proposed in a separate patch.

http://reviews.llvm.org/D21853

Files:
  include/clang/Driver/Action.h
  include/clang/Driver/Types.h
  lib/Driver/Action.cpp
  lib/Driver/Driver.cpp
  lib/Driver/ToolChain.cpp
  lib/Driver/Types.cpp
  test/Driver/openmp-offload.c

Index: test/Driver/openmp-offload.c
===
--- test/Driver/openmp-offload.c
+++ test/Driver/openmp-offload.c
@@ -255,4 +255,57 @@
 // CHK-BUACTIONS: 16: offload, "device-openmp (x86_64-pc-linux-gnu)" {15}, object
 // CHK-BUACTIONS: 17: backend, {2}, assembler, (host-openmp)
 // CHK-BUACTIONS: 18: assembler, {17}, object, (host-openmp)
-// CHK-BUACTIONS: 19: clang-offload-bundler, {9, 16, 18}, object, (host-openmp)
\ No newline at end of file
+// CHK-BUACTIONS: 19: clang-offload-bundler, {9, 16, 18}, object, (host-openmp)
+
+/// ###
+
+/// Check separate compilation with offloading - unbundling actions
+// RUN:   touch %t.i
+// RUN:   %clang -### -ccc-print-phases -fopenmp -o %t.out -lsomelib -target powerpc64le-linux -fopenmp-targets=powerpc64le-ibm-linux-gnu,x86_64-pc-linux-gnu %t.i 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-UBACTIONS %s
+
+// CHK-UBACTIONS: 0: input, "somelib", object, (host-openmp)
+// CHK-UBACTIONS: 1: input, "[[INPUT:.+\.i]]", cpp-output, (host-openmp)
+// CHK-UBACTIONS: 2: clang-offload-unbundler, {1}, cpp-output, (host-openmp)
+// CHK-UBACTIONS: 3: compiler, {2}, ir, (host-openmp)
+// CHK-UBACTIONS: 4: backend, {3}, assembler, (host-openmp)
+// CHK-UBACTIONS: 5: assembler, {4}, object, (host-openmp)
+// CHK-UBACTIONS: 6: linker, {0, 5}, image, (host-openmp)
+// CHK-UBACTIONS: 7: input, "somelib", object, (device-openmp)
+// CHK-UBACTIONS: 8: compiler, {2}, ir, (device-openmp)
+// CHK-UBACTIONS: 9: offload, "host-openmp (powerpc64le--linux)" {3}, "device-openmp (powerpc64le-ibm-linux-gnu)" {8}, ir
+// CHK-UBACTIONS: 10: backend, {9}, assembler, (device-openmp)
+// CHK-UBACTIONS: 11: assembler, {10}, object, (device-openmp)
+// CHK-UBACTIONS: 12: linker, {7, 11}, image, (device-openmp)
+// CHK-UBACTIONS: 13: input, "somelib", object, (device-openmp)
+// CHK-UBACTIONS: 14: compiler, {2}, ir, (device-openmp)
+// CHK-UBACTIONS: 15: offload, "host-openmp (powerpc64le--linux)" {3}, "device-openmp (x86_64-pc-linux-gnu)" {14}, ir
+// CHK-UBACTIONS: 16: backend, {15}, assembler, (device-openmp)
+// CHK-UBACTIONS: 17: assembler, {16}, object, (device-openmp)
+// CHK-UBACTIONS: 18: linker, {13, 17}, image, (device-openmp)
+// CHK-UBACTIONS: 19: offload, "host-openmp (powerpc64le--linux)" {6}, "device-openmp (powerpc64le-ibm-linux-gnu)" {12}, "device-openmp (x86_64-pc-linux-gnu)" {18}, image
+
+/// ###
+
+/// Check separate compilation with offloading - unbundling/bundling actions
+// RUN:   touch %t.i
+// RUN:   %clang -### -ccc-print-phases -fopenmp -c -o %t.o -lsomelib -target powerpc64le-linux -fopenmp-targets=powerpc64le-ibm-linux-gnu,x86_64-pc-linux-gnu %t.i 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-UBUACTIONS %s
+
+// CHK-UBUACTIONS: 0: input, "[[INPUT:.+\.i]]", cpp-output, (host-openmp)
+// CHK-UBUACTIONS: 1: clang-offload-unbundler, {0}, cpp-output, (host-openmp)
+// CHK-UBUACTIONS: 2: compiler, {1}, ir, (host-openmp)
+// CHK-UBUACTIONS: 3: compiler, {1}, ir, (device-openmp)
+// CHK-UBUACTIONS: 4: offload, "host-openmp (powerpc64le--linux)" {2}, "device-openmp (powerpc64le-ibm-linux-gnu)" {3}, ir
+// CHK-UBUACTIONS: 5: backend, {4}, assembler, (device-openmp)
+// CHK-UBUACTIONS: 6: assembler, {5}, object, (device-openmp)
+// CHK-UBUACTIONS: 7: offload, "device-openmp (powerpc64le-ibm-linux-gnu)" {6}, object
+// CHK-UBUACTIONS: 8: compiler, {1}, ir, (device-openmp)
+// CHK-UBUACTIONS: 9: offload, "host-openmp (powerpc64le--linux)" {2}, "device-openmp (x86_64-pc-linux-gnu)" {8}, ir
+// CHK-UBUACTIONS: 10: backend, {9}, assembler, (device-openmp)
+// CHK-UBUACTIONS: 11: assembler, {10}, object, (device-openmp)
+// CHK-UBUACTIONS: 12: offload, "device-openmp (x86_64-pc-linux-gnu)" {11}, object
+// CHK-UBUACTIONS: 13: backend, {2}, assembler, (host-openmp)
+// CHK-UBUACTIONS: 14: assembler, {13}, object, (host-openmp)
+// CHK-UBUACTIONS: 15: clang-offload-bundler, {7, 12, 14},

[PATCH] D21856: [Driver][OpenMP] Add support to create jobs for bundling actions.

2016-06-29 Thread Samuel Antao via cfe-commits
sfantao created this revision.
sfantao added reviewers: echristo, tra, jlebar, hfinkel, ABataev.
sfantao added subscribers: caomhin, carlo.bertolli, arpith-jacob, 
andreybokhanko, Hahnfeld, cfe-commits.
Herald added a subscriber: mehdi_amini.

This patch adds the support to create a job for the `OffloadBundlingAction` 
which will invoke the `clang-offload-bundler` tool.

http://reviews.llvm.org/D21856

Files:
  include/clang/Driver/Action.h
  include/clang/Driver/ToolChain.h
  lib/Driver/Action.cpp
  lib/Driver/ToolChain.cpp
  lib/Driver/Tools.cpp
  lib/Driver/Tools.h
  test/Driver/openmp-offload.c

Index: test/Driver/openmp-offload.c
===
--- test/Driver/openmp-offload.c
+++ test/Driver/openmp-offload.c
@@ -309,3 +309,37 @@
 // CHK-UBUACTIONS: 14: assembler, {13}, object, (host-openmp)
 // CHK-UBUACTIONS: 15: clang-offload-bundler, {7, 12, 14}, object, (host-openmp)
 
+/// ###
+
+/// Check separate compilation with offloading - bundling jobs construct
+// RUN:   %clang -### -fopenmp -c -o %t.o -lsomelib -target powerpc64le-linux -fopenmp-targets=powerpc64le-ibm-linux-gnu,x86_64-pc-linux-gnu %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-BUJOBS %s
+// RUN:   %clang -### -fopenmp -c -o %t.o -lsomelib -target powerpc64le-linux -fopenmp-targets=powerpc64le-ibm-linux-gnu,x86_64-pc-linux-gnu %s -save-temps 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-BUJOBS-ST %s
+
+// Create host BC.
+// CHK-BUJOBS: clang{{.*}}" "-cc1" "-triple" "powerpc64le--linux" "-emit-llvm-bc"  {{.*}}"-fopenmp" {{.*}}"-o" "[[HOSTBC:.+\.bc]]" "-x" "c" "[[INPUT:.+\.c]]" "-fopenmp-targets=powerpc64le-ibm-linux-gnu,x86_64-pc-linux-gnu"
+
+// CHK-BUJOBS-ST: clang{{.*}}" "-cc1" "-triple" "powerpc64le--linux" "-E"  {{.*}}"-fopenmp" {{.*}}"-o" "[[HOSTPP:.+\.i]]" "-x" "c" "[[INPUT:.+\.c]]"
+// CHK-BUJOBS-ST: clang{{.*}}" "-cc1" "-triple" "powerpc64le--linux" "-emit-llvm-bc"  {{.*}}"-fopenmp" {{.*}}"-o" "[[HOSTBC:.+\.bc]]" "-x" "cpp-output" "[[HOSTPP]]" "-fopenmp-targets=powerpc64le-ibm-linux-gnu,x86_64-pc-linux-gnu"
+
+// Create target 1 object.
+// CHK-BUJOBS: clang{{.*}}" "-cc1" "-triple" "powerpc64le-ibm-linux-gnu" "-emit-obj" {{.*}}"-fopenmp" {{.*}}"-o" "[[T1OBJ:.+\.o]]" "-x" "c" "[[INPUT]]" "-fopenmp-is-device" "-fopenmp-host-ir-file-path" "[[HOSTBC]]"
+// CHK-BUJOBS-ST: clang{{.*}}" "-cc1" "-triple" "powerpc64le-ibm-linux-gnu" "-E" {{.*}}"-fopenmp" {{.*}}"-o" "[[T1PP:.+\.i]]" "-x" "c" "[[INPUT]]"
+// CHK-BUJOBS-ST: clang{{.*}}" "-cc1" "-triple" "powerpc64le-ibm-linux-gnu" "-emit-llvm-bc" {{.*}}"-fopenmp" {{.*}}"-o" "[[T1BC:.+\.bc]]" "-x" "cpp-output" "[[T1PP]]" "-fopenmp-is-device" "-fopenmp-host-ir-file-path" "[[HOSTBC]]"
+// CHK-BUJOBS-ST: clang{{.*}}" "-cc1" "-triple" "powerpc64le-ibm-linux-gnu" "-S" {{.*}}"-fopenmp" {{.*}}"-o" "[[T1ASM:.+\.s]]" "-x" "ir" "[[T1BC]]"
+// CHK-BUJOBS-ST: clang{{.*}}" "-cc1as" "-triple" "powerpc64le-ibm-linux-gnu" "-filetype" "obj" {{.*}}"-o" "[[T1OBJ:.+\.o]]" "[[T1ASM]]"
+
+// Create target 2 object.
+// CHK-BUJOBS: clang{{.*}}" "-cc1" "-triple" "x86_64-pc-linux-gnu" "-emit-obj" {{.*}}"-fopenmp" {{.*}}"-o" "[[T2OBJ:.+\.o]]" "-x" "c" "[[INPUT]]" "-fopenmp-is-device" "-fopenmp-host-ir-file-path" "[[HOSTBC]]"
+// CHK-BUJOBS-ST: clang{{.*}}" "-cc1" "-triple" "x86_64-pc-linux-gnu" "-E" {{.*}}"-fopenmp" {{.*}}"-o" "[[T2PP:.+\.i]]" "-x" "c" "[[INPUT]]"
+// CHK-BUJOBS-ST: clang{{.*}}" "-cc1" "-triple" "x86_64-pc-linux-gnu" "-emit-llvm-bc" {{.*}}"-fopenmp" {{.*}}"-o" "[[T2BC:.+\.bc]]" "-x" "cpp-output" "[[T2PP]]" "-fopenmp-is-device" "-fopenmp-host-ir-file-path" "[[HOSTBC]]"
+// CHK-BUJOBS-ST: clang{{.*}}" "-cc1" "-triple" "x86_64-pc-linux-gnu" "-S" {{.*}}"-fopenmp" {{.*}}"-o" "[[T2ASM:.+\.s]]" "-x" "ir" "[[T2BC]]"
+// CHK-BUJOBS-ST: clang{{.*}}" "-cc1as" "-triple" "x86_64-pc-linux-gnu" "-filetype" "obj" {{.*}}"-o" "[[T2OBJ:.+\.o]]" "[[T2ASM]]"
+
+// Create host object and bundle.
+// CHK-BUJOBS: clang{{.*}}" "-cc1" "-triple" "powerpc64le--linux" "-emit-obj" {{.*}}"-fopenmp" {{.*}}"-o" "[[HOSTOBJ:.+\.o]]" "-x" "ir" "[[HOSTBC]]"
+// CHK-BUJOBS: clang-offload-bundler" "-type=o" "-targets=openmp-powerpc64le-ibm-linux-gnu,openmp-x86_64-pc-linux-gnu,host-powerpc64le--linux" "-outputs=[[RES:.+\.o]]" "-inputs=[[T1OBJ]],[[T2OBJ]],[[HOSTOBJ]]"
+// CHK-BUJOBS-ST: clang{{.*}}" "-cc1" "-triple" "powerpc64le--linux" "-S" {{.*}}"-fopenmp" {{.*}}"-o" "[[HOSTASM:.+\.s]]" "-x" "ir" "[[HOSTBC]]"
+// CHK-BUJOBS-ST: clang{{.*}}" "-cc1as" "-triple" "powerpc64le--linux" "-filetype" "obj" {{.*}}"-o" "[[HOSTOBJ:.+\.o]]" "[[HOSTASM]]"
+// CHK-BUJOBS-ST: clang-offload-bundler" "-type=o" "-targets=openmp-powerpc64le-ibm-linux-gnu,openmp-x86_64-pc-linux-gnu,host-powerpc64le--linux" "-outputs=[[RES:.+\.o]]" "-inputs=[[T1OBJ]],[[T2OBJ]],[[HOSTOBJ]]"
Index: lib/Driver/Tools.h
===
--- lib/Driver/Tools.h
+++ lib/Driver/Tools.h
@@ -135,6 +135,19 @@

r274149 - Add CapturedDecl::parameters() ArrayRef accessors following r273647.

2016-06-29 Thread Yaron Keren via cfe-commits
Author: yrnkrn
Date: Wed Jun 29 13:55:53 2016
New Revision: 274149

URL: http://llvm.org/viewvc/llvm-project?rev=274149&view=rev
Log:
Add CapturedDecl::parameters() ArrayRef accessors following r273647.


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

Modified: cfe/trunk/include/clang/AST/Decl.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Decl.h?rev=274149&r1=274148&r2=274149&view=diff
==
--- cfe/trunk/include/clang/AST/Decl.h (original)
+++ cfe/trunk/include/clang/AST/Decl.h Wed Jun 29 13:55:53 2016
@@ -3661,6 +3661,14 @@ public:
 getParams()[i] = P;
   }
 
+  // ArrayRef interface to parameters.
+  ArrayRef parameters() const {
+return {getParams(), getNumParams()};
+  }
+  MutableArrayRef parameters() {
+return {getParams(), getNumParams()};
+  }
+
   /// \brief Retrieve the parameter containing captured variables.
   ImplicitParamDecl *getContextParam() const {
 assert(ContextParam < NumParams);


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


[PATCH] D21857: [Driver][OpenMP] Add support to create jobs for unbundling actions.

2016-06-29 Thread Samuel Antao via cfe-commits
sfantao created this revision.
sfantao added reviewers: echristo, tra, jlebar, hfinkel, ABataev.
sfantao added subscribers: caomhin, carlo.bertolli, arpith-jacob, 
andreybokhanko, Hahnfeld, cfe-commits.
Herald added a subscriber: mehdi_amini.

This patch adds the support to create jobs for the `OffloadBundlingAction` 
which will invoke the `clang-offload-bundler` tool to unbundle input files.

Unlike other actions, unbundling actions have multiple outputs. Therefore, this 
patch adds the required changes to have a variant of `Tool::ConstructJob` with 
multiple outputs. 

The way the naming of the results is implemented is also slightly modified so 
that the same action can use a different offloading prefix for each use by the 
different offloading actions. 

http://reviews.llvm.org/D21857

Files:
  include/clang/Driver/Action.h
  include/clang/Driver/Tool.h
  lib/Driver/Action.cpp
  lib/Driver/Driver.cpp
  lib/Driver/Tool.cpp
  lib/Driver/Tools.cpp
  lib/Driver/Tools.h
  test/Driver/openmp-offload.c

Index: test/Driver/openmp-offload.c
===
--- test/Driver/openmp-offload.c
+++ test/Driver/openmp-offload.c
@@ -176,7 +176,7 @@
 // CHK-COMMANDS-ST: clang{{.*}}" "-cc1" "-triple" "powerpc64le-ibm-linux-gnu" "-emit-llvm-bc" {{.*}}"-pic-level" "2" {{.*}}"-fopenmp" {{.*}}"-o" "[[T1BC:.+\.bc]]" "-x" "cpp-output" "[[T1PP]]" "-fopenmp-is-device" "-fopenmp-host-ir-file-path" "[[HOSTBC]]"
 // CHK-COMMANDS-ST: clang{{.*}}" "-cc1" "-triple" "powerpc64le-ibm-linux-gnu" "-S" {{.*}}"-fopenmp" {{.*}}"-o" "[[T1ASM:.+\.s]]" "-x" "ir" "[[T1BC]]"
 // CHK-COMMANDS-ST: clang{{.*}}" "-cc1as" "-triple" "powerpc64le-ibm-linux-gnu" "-filetype" "obj" {{.*}}"-o" "[[T1OBJ:.+\.o]]" "[[T1ASM]]"
-// CHK-COMMANDS-ST: ld" {{.*}}"-shared" "-o" "[[T1BIN:.+\.out-device-openmp-powerpc64le-ibm-linux-gnu]]" {{.*}}[[T1OBJ]]
+// CHK-COMMANDS-ST: ld" {{.*}}"-shared" "-o" "[[T1BIN:.+\.out-openmp-powerpc64le-ibm-linux-gnu]]" {{.*}}[[T1OBJ]]
 
 //
 // Compile for the x86 device.
@@ -187,7 +187,7 @@
 // CHK-COMMANDS-ST: clang{{.*}}" "-cc1" "-triple" "x86_64-pc-linux-gnu" "-emit-llvm-bc" {{.*}}"-pic-level" "2" {{.*}}"-fopenmp" {{.*}}"-o" "[[T2BC:.+\.bc]]" "-x" "cpp-output" "[[T2PP]]" "-fopenmp-is-device" "-fopenmp-host-ir-file-path" "[[HOSTBC]]"
 // CHK-COMMANDS-ST: clang{{.*}}" "-cc1" "-triple" "x86_64-pc-linux-gnu" "-S" {{.*}}"-fopenmp" {{.*}}"-o" "[[T2ASM:.+\.s]]" "-x" "ir" "[[T2BC]]"
 // CHK-COMMANDS-ST: clang{{.*}}" "-cc1as" "-triple" "x86_64-pc-linux-gnu" "-filetype" "obj" {{.*}}"-o" "[[T2OBJ:.+\.o]]" "[[T2ASM]]"
-// CHK-COMMANDS-ST: ld" {{.*}}"-shared" "-o" "[[T2BIN:.+\.out-device-openmp-x86_64-pc-linux-gnu]]" {{.*}}[[T2OBJ]]
+// CHK-COMMANDS-ST: ld" {{.*}}"-shared" "-o" "[[T2BIN:.+\.out-openmp-x86_64-pc-linux-gnu]]" {{.*}}[[T2OBJ]]
 
 //
 // Generate host object from the BC file and link using the linker script.
@@ -202,20 +202,20 @@
 // Check the linker script contains what we expect.
 //
 // CHK-LKS: TARGET(binary)
-// CHK-LKS: INPUT({{.+}}.out-device-openmp-powerpc64le-ibm-linux-gnu)
-// CHK-LKS: INPUT({{.+}}.out-device-openmp-x86_64-pc-linux-gnu)
+// CHK-LKS: INPUT({{.+}}.out-openmp-powerpc64le-ibm-linux-gnu)
+// CHK-LKS: INPUT({{.+}}.out-openmp-x86_64-pc-linux-gnu)
 // CHK-LKS: SECTIONS
 // CHK-LKS: {
 // CHK-LKS:   .omp_offloading :
 // CHK-LKS:   ALIGN(0x10)
 // CHK-LKS:   {
 // CHK-LKS: . = ALIGN(0x10);
 // CHK-LKS: PROVIDE_HIDDEN(.omp_offloading.img_start.powerpc64le-ibm-linux-gnu = .);
-// CHK-LKS: {{.+}}.out-device-openmp-powerpc64le-ibm-linux-gnu
+// CHK-LKS: {{.+}}.out-openmp-powerpc64le-ibm-linux-gnu
 // CHK-LKS: PROVIDE_HIDDEN(.omp_offloading.img_end.powerpc64le-ibm-linux-gnu = .);
 // CHK-LKS: . = ALIGN(0x10);
 // CHK-LKS: PROVIDE_HIDDEN(.omp_offloading.img_start.x86_64-pc-linux-gnu = .);
-// CHK-LKS: {{.+}}.out-device-openmp-x86_64-pc-linux-gnu
+// CHK-LKS: {{.+}}.out-openmp-x86_64-pc-linux-gnu
 // CHK-LKS: PROVIDE_HIDDEN(.omp_offloading.img_end.x86_64-pc-linux-gnu = .);
 // CHK-LKS:   }
 // CHK-LKS:   .omp_offloading.entries :
@@ -343,3 +343,92 @@
 // CHK-BUJOBS-ST: clang{{.*}}" "-cc1" "-triple" "powerpc64le--linux" "-S" {{.*}}"-fopenmp" {{.*}}"-o" "[[HOSTASM:.+\.s]]" "-x" "ir" "[[HOSTBC]]"
 // CHK-BUJOBS-ST: clang{{.*}}" "-cc1as" "-triple" "powerpc64le--linux" "-filetype" "obj" {{.*}}"-o" "[[HOSTOBJ:.+\.o]]" "[[HOSTASM]]"
 // CHK-BUJOBS-ST: clang-offload-bundler" "-type=o" "-targets=openmp-powerpc64le-ibm-linux-gnu,openmp-x86_64-pc-linux-gnu,host-powerpc64le--linux" "-outputs=[[RES:.+\.o]]" "-inputs=[[T1OBJ]],[[T2OBJ]],[[HOSTOBJ]]"
+
+/// ###
+
+/// Check separate compilation with offloading - unbundling jobs construct
+// RUN:   touch %t.i
+// RUN:   %clang -###  -fopenmp -o %t.out -lsomelib -target powerpc64le-linux -fopenmp-targets=powerpc64le-ibm-linux-gnu,x86_64-pc-linux-gnu %t.i 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-UBJOBS %s
+// RUN:   %clan

RFC: Default language standard mode policy

2016-06-29 Thread Richard Smith via cfe-commits
Hi all!

I'd like to establish a policy for Clang's default language standard (if
none is specified with -std), as follows:

  Clang defaults to the most recent published standard for the selected
language that it fully implements.

The practical impact of this is that clang++ will default to C++14 for C++
compilations (for version 3.9 onwards) and will default to C++17 once our
implementation support is complete and the standard is published (whichever
happens later).

I'd suggest that we apply the same policy for clang-cl, but if it's
important that we enable a not-yet-fully-implemented standard for cl
compatibility, that seems reasonable.

The question of whether the default mode for the GCC-compatible driver
should be -std=gnuXXX or -std=cXXX is separate, but also likely worth
discussing. Enabling GNU keywords by default is a very odd choice, and if
we believe we can change our defaults without breaking the world then this
seems like a good time to do so.

I also intend to make explicit in our documentation that our -std=XXX flag
enables the selected standard, *plus all relevant issues in Defect Report
status from the relevant language committee* (it doesn't make sense to
support a language without its bugfixes).

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


Re: RFC: Default language standard mode policy

2016-06-29 Thread Nico Weber via cfe-commits
For clang-cl, we should follow cl's model of selecting a standard. Before
C++17, this was "use newest language the compiler knows about" (keyed off
-fmsc-version; clang-cl detects the system msvc version by default if
that's not passed in). After C++17, there's an explicit language flag, and
we use the same default as cl.

Last I checked (which was a while ago), libstdc++ didn't parse with
-std=c++14, at least at some version. I don't remember which version of
libstdc++ I tried (maybe 4.9?). Should that factor into the decision? Not
parsing standard library headers by default on Linux seems like a somewhat
suboptimal user experience.

On Wed, Jun 29, 2016 at 3:09 PM, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Hi all!
>
> I'd like to establish a policy for Clang's default language standard (if
> none is specified with -std), as follows:
>
>   Clang defaults to the most recent published standard for the selected
> language that it fully implements.
>
> The practical impact of this is that clang++ will default to C++14 for C++
> compilations (for version 3.9 onwards) and will default to C++17 once our
> implementation support is complete and the standard is published (whichever
> happens later).
>
> I'd suggest that we apply the same policy for clang-cl, but if it's
> important that we enable a not-yet-fully-implemented standard for cl
> compatibility, that seems reasonable.
>
> The question of whether the default mode for the GCC-compatible driver
> should be -std=gnuXXX or -std=cXXX is separate, but also likely worth
> discussing. Enabling GNU keywords by default is a very odd choice, and if
> we believe we can change our defaults without breaking the world then this
> seems like a good time to do so.
>
> I also intend to make explicit in our documentation that our -std=XXX flag
> enables the selected standard, *plus all relevant issues in Defect Report
> status from the relevant language committee* (it doesn't make sense to
> support a language without its bugfixes).
>
> Thoughts?
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: RFC: Default language standard mode policy

2016-06-29 Thread Richard Smith via cfe-commits
On Wed, Jun 29, 2016 at 12:14 PM, Nico Weber  wrote:

> For clang-cl, we should follow cl's model of selecting a standard. Before
> C++17, this was "use newest language the compiler knows about" (keyed off
> -fmsc-version; clang-cl detects the system msvc version by default if
> that's not passed in). After C++17, there's an explicit language flag, and
> we use the same default as cl.
>

Is that default something other than "the newest one"?

Last I checked (which was a while ago), libstdc++ didn't parse with
> -std=c++14, at least at some version. I don't remember which version of
> libstdc++ I tried (maybe 4.9?). Should that factor into the decision? Not
> parsing standard library headers by default on Linux seems like a somewhat
> suboptimal user experience.
>

Last time I looked into this, I saw only one problem with version 4.9: libc
doesn't provide ::gets to C++14, and earlier versions of libstdc++ assume
it's there and do "namespace std { using ::gets; }". We can add a
compatibility hack to clang to work around this.

Note that at this point I'd like to mainly focus on what our policy should
be; there are certainly technical challenges involved in actually applying
the policy (another one is that clang's test suite still has some failures
when the default is changed, but Charles Li has made tremendous headway on
this), and if we can't actually prepare for the transition in the C++
default in time for 3.9, then so be it.


> On Wed, Jun 29, 2016 at 3:09 PM, Richard Smith via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Hi all!
>>
>> I'd like to establish a policy for Clang's default language standard (if
>> none is specified with -std), as follows:
>>
>>   Clang defaults to the most recent published standard for the selected
>> language that it fully implements.
>>
>> The practical impact of this is that clang++ will default to C++14 for
>> C++ compilations (for version 3.9 onwards) and will default to C++17 once
>> our implementation support is complete and the standard is published
>> (whichever happens later).
>>
>> I'd suggest that we apply the same policy for clang-cl, but if it's
>> important that we enable a not-yet-fully-implemented standard for cl
>> compatibility, that seems reasonable.
>>
>> The question of whether the default mode for the GCC-compatible driver
>> should be -std=gnuXXX or -std=cXXX is separate, but also likely worth
>> discussing. Enabling GNU keywords by default is a very odd choice, and if
>> we believe we can change our defaults without breaking the world then this
>> seems like a good time to do so.
>>
>> I also intend to make explicit in our documentation that our -std=XXX
>> flag enables the selected standard, *plus all relevant issues in Defect
>> Report status from the relevant language committee* (it doesn't make sense
>> to support a language without its bugfixes).
>>
>> Thoughts?
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: RFC: Default language standard mode policy

2016-06-29 Thread Sean Silva via cfe-commits
On Wed, Jun 29, 2016 at 12:09 PM, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Hi all!
>
> I'd like to establish a policy for Clang's default language standard (if
> none is specified with -std), as follows:
>
>   Clang defaults to the most recent published standard for the selected
> language that it fully implements.
>
> The practical impact of this is that clang++ will default to C++14 for C++
> compilations (for version 3.9 onwards) and will default to C++17 once our
> implementation support is complete and the standard is published (whichever
> happens later).
>
> I'd suggest that we apply the same policy for clang-cl, but if it's
> important that we enable a not-yet-fully-implemented standard for cl
> compatibility, that seems reasonable.
>
> The question of whether the default mode for the GCC-compatible driver
> should be -std=gnuXXX or -std=cXXX is separate, but also likely worth
> discussing. Enabling GNU keywords by default is a very odd choice, and if
> we believe we can change our defaults without breaking the world then this
> seems like a good time to do so.
>

Using cXXX instead of gnuXXX would break the world on PS4. So for sure with
`-std=c++latest` we would end up proposing a patch to change this for the
PS4 target to gnu++latest (or gnu++11 if gnu++latest is not feasible).
(As I'm sure you're aware, we have pending to upstream a patch that makes
-std=gnu++11 the default C++ language mode on PS4 (just blocked on fixing
tests to not assume the existing std)).

It may be feasible for us to use a "-std=gnu++latest" behavior and not have
to have a PS4-specific default; CC'ing Warren and Paul.

-- Sean Silva


>
> I also intend to make explicit in our documentation that our -std=XXX flag
> enables the selected standard, *plus all relevant issues in Defect Report
> status from the relevant language committee* (it doesn't make sense to
> support a language without its bugfixes).
>
> Thoughts?
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D21803: [libcxxabi] Provide a fallback __cxa_thread_atexit() implementation

2016-06-29 Thread Tavian Barnes via cfe-commits
tavianator added a comment.

In http://reviews.llvm.org/D21803#470086, @bcraig wrote:

> It also intentionally leaks the pthread key.  Does the __thread_specific_ptr 
> rationale hold for this change as well?


Hmm, maybe?  If other global destructors run after ~DtorListHolder(), and they 
cause a thread_local to be initialized for the first time, 
__cxa_thread_atexit() might be called again.  I was thinking that dtors would 
get re-initialized in that case but it appears it does not.  So yeah, I think 
I'll need to leak the pthread_key_t.

I'm not sure how to avoid leaking the actual thread_local objects that get 
created in that situation.  There's nothing left to trigger run_dtors() a 
second time.



Comment at: src/cxa_thread_atexit.cpp:64-90
@@ -18,8 +63,29 @@
+_LIBCXXABI_FUNC_VIS int __cxa_thread_atexit(Dtor dtor, void *obj,
 void *dso_symbol) throw() {
-  extern int __cxa_thread_atexit_impl(void (*)(void *), void *, void *);
-  return __cxa_thread_atexit_impl(dtor, obj, dso_symbol);
-}
+  extern int __cxa_thread_atexit_impl(Dtor, void *, void *)
+__attribute__((__weak__));
+
+  if (__cxa_thread_atexit_impl) {
+return __cxa_thread_atexit_impl(dtor, obj, dso_symbol);
+  } else {
+static DtorListHolder dtors;
+
+auto head = static_cast(std::malloc(sizeof(DtorList)));
+if (!head) {
+  return -1;
+}
+
+head->dtor = dtor;
+head->obj = obj;
+head->next = dtors.get();
+
+if (!dtors.set(head)) {
+  std::free(head);
+  return -1;
+}
 
-#endif // HAVE__CXA_THREAD_ATEXIT_IMPL
+return 0;
+  }
+}
 
 } // extern "C"

majnemer wrote:
> I think that this should be an opt-in mechanism, there are platforms that 
> presumably never need to pay the cost of the unused code (macOS comes to 
> mind).
This file is only built for UNIX AND NOT (APPLE OR CYGWIN).  Other platforms 
use something other than __cxa_thread_atexit() I assume.


http://reviews.llvm.org/D21803



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


Re: [PATCH] D21031: [OpenCL] Allow -cl-std and other standard -cl- options in driver

2016-06-29 Thread Yaxun Liu via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL274150: [OpenCL] Allow -cl-std and other standard -cl- 
options in driver (authored by yaxunl).

Changed prior to commit:
  http://reviews.llvm.org/D21031?vs=61574&id=62267#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D21031

Files:
  cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
  cfe/trunk/include/clang/Driver/CC1Options.td
  cfe/trunk/include/clang/Driver/Options.td
  cfe/trunk/lib/Driver/Tools.cpp
  cfe/trunk/lib/Frontend/CompilerInvocation.cpp
  cfe/trunk/test/Driver/opencl.cl

Index: cfe/trunk/test/Driver/opencl.cl
===
--- cfe/trunk/test/Driver/opencl.cl
+++ cfe/trunk/test/Driver/opencl.cl
@@ -1,15 +1,39 @@
-// RUN: %clang -fsyntax-only %s
-// RUN: %clang -fsyntax-only -std=cl %s
-// RUN: %clang -fsyntax-only -std=cl1.1 %s
-// RUN: %clang -fsyntax-only -std=cl1.2 %s
-// RUN: %clang -fsyntax-only -std=cl2.0 %s
-// RUN: %clang -fsyntax-only -std=CL %s
-// RUN: %clang -fsyntax-only -std=CL1.1 %s
-// RUN: %clang -fsyntax-only -std=CL1.2 %s
-// RUN: %clang -fsyntax-only -std=CL2.0 %s
-// RUN: not %clang_cc1 -std=c99 -DOPENCL %s 2>&1 | FileCheck --check-prefix=CHECK-C99 %s
-// RUN: not %clang_cc1 -std=invalid -DOPENCL %s 2>&1 | FileCheck --check-prefix=CHECK-INVALID %s
-// CHECK-C99: error: invalid argument '-std=c99' not allowed with 'OpenCL'
-// CHECK-INVALID: error: invalid value 'invalid' in '-std=invalid'
+// RUN: %clang -S -### -cl-std=CL %s | FileCheck --check-prefix=CHECK-CL %s
+// RUN: %clang -S -### -cl-std=CL1.1 %s | FileCheck --check-prefix=CHECK-CL11 %s
+// RUN: %clang -S -### -cl-std=CL1.2 %s | FileCheck --check-prefix=CHECK-CL12 %s
+// RUN: %clang -S -### -cl-std=CL2.0 %s | FileCheck --check-prefix=CHECK-CL20 %s
+// RUN: %clang -S -### -cl-opt-disable %s | FileCheck --check-prefix=CHECK-OPT-DISABLE %s
+// RUN: %clang -S -### -cl-strict-aliasing %s | FileCheck --check-prefix=CHECK-STRICT-ALIASING %s
+// RUN: %clang -S -### -cl-std=CL1.1 -cl-strict-aliasing %s | FileCheck --check-prefix=CHECK-INVALID-OPENCL-VERSION11 %s
+// RUN: %clang -S -### -cl-std=CL1.2 -cl-strict-aliasing %s | FileCheck --check-prefix=CHECK-INVALID-OPENCL-VERSION12 %s
+// RUN: %clang -S -### -cl-std=CL2.0 -cl-strict-aliasing %s | FileCheck --check-prefix=CHECK-INVALID-OPENCL-VERSION20 %s
+// RUN: %clang -S -### -cl-single-precision-constant %s | FileCheck --check-prefix=CHECK-SINGLE-PRECISION-CONST %s
+// RUN: %clang -S -### -cl-finite-math-only %s | FileCheck --check-prefix=CHECK-FINITE-MATH-ONLY %s
+// RUN: %clang -S -### -cl-kernel-arg-info %s | FileCheck --check-prefix=CHECK-KERNEL-ARG-INFO %s
+// RUN: %clang -S -### -cl-unsafe-math-optimizations %s | FileCheck --check-prefix=CHECK-UNSAFE-MATH-OPT %s
+// RUN: %clang -S -### -cl-fast-relaxed-math %s | FileCheck --check-prefix=CHECK-FAST-RELAXED-MATH %s
+// RUN: %clang -S -### -cl-mad-enable %s | FileCheck --check-prefix=CHECK-MAD-ENABLE %s
+// RUN: %clang -S -### -cl-denorms-are-zero %s | FileCheck --check-prefix=CHECK-DENORMS-ARE-ZERO %s
+// RUN: not %clang_cc1 -cl-std=c99 -DOPENCL %s 2>&1 | FileCheck --check-prefix=CHECK-C99 %s
+// RUN: not %clang_cc1 -cl-std=invalid -DOPENCL %s 2>&1 | FileCheck --check-prefix=CHECK-INVALID %s
+
+// CHECK-CL: .*clang.* "-cc1" .* "-cl-std=CL"
+// CHECK-CL11: .*clang.* "-cc1" .* "-cl-std=CL1.1"
+// CHECK-CL12: .*clang.* "-cc1" .* "-cl-std=CL1.2"
+// CHECK-CL20: .*clang.* "-cc1" .* "-cl-std=CL2.0"
+// CHECK-OPT-DISABLE: .*clang.* "-cc1" .* "-cl-opt-disable"
+// CHECK-STRICT-ALIASING: .*clang.* "-cc1" .* "-cl-strict-aliasing"
+// CHECK-INVALID-OPENCL-VERSION11: OpenCL version 1.1 does not support the option 'cl-strict-aliasing'
+// CHECK-INVALID-OPENCL-VERSION12: OpenCL version 1.2 does not support the option 'cl-strict-aliasing'
+// CHECK-INVALID-OPENCL-VERSION20: OpenCL version 2.0 does not support the option 'cl-strict-aliasing'
+// CHECK-SINGLE-PRECISION-CONST: .*clang.* "-cc1" .* "-cl-single-precision-constant"
+// CHECK-FINITE-MATH-ONLY: .*clang.* "-cc1" .* "-cl-finite-math-only"
+// CHECK-KERNEL-ARG-INFO: .*clang.* "-cc1" .* "-cl-kernel-arg-info"
+// CHECK-UNSAFE-MATH-OPT: .*clang.* "-cc1" .* "-cl-unsafe-math-optimizations"
+// CHECK-FAST-RELAXED-MATH: .*clang.* "-cc1" .* "-cl-fast-relaxed-math"
+// CHECK-MAD-ENABLE: .*clang.* "-cc1" .* "-cl-mad-enable"
+// CHECK-DENORMS-ARE-ZERO: .*clang.* "-cc1" .* "-cl-denorms-are-zero"
+// CHECK-C99: error: invalid argument '-cl-std=c99' not allowed with 'OpenCL'
+// CHECK-INVALID: error: invalid value 'invalid' in '-cl-std=invalid'
 
 kernel void func(void);
Index: cfe/trunk/lib/Frontend/CompilerInvocation.cpp
===
--- cfe/trunk/lib/Frontend/CompilerInvocation.cpp
+++ cfe/trunk/lib/Frontend/CompilerInvocation.cpp
@@ -41,6 +41,7 @@
 #include "llvm/Support/Path.h"
 #include "llvm/Support/Process.h"
 #include "llvm/Target/TargetOptions.h"
+#include "llvm/Support

r274150 - [OpenCL] Allow -cl-std and other standard -cl- options in driver

2016-06-29 Thread Yaxun Liu via cfe-commits
Author: yaxunl
Date: Wed Jun 29 14:39:32 2016
New Revision: 274150

URL: http://llvm.org/viewvc/llvm-project?rev=274150&view=rev
Log:
[OpenCL] Allow -cl-std and other standard -cl- options in driver

Allow -cl-std and other standard -cl- options from cc1 to driver.

Added a test for the options moved.

Patch by Aaron En Ye Shi.

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

Modified:
cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
cfe/trunk/include/clang/Driver/CC1Options.td
cfe/trunk/include/clang/Driver/Options.td
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/test/Driver/opencl.cl

Modified: cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td?rev=274150&r1=274149&r2=274150&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td Wed Jun 29 
14:39:32 2016
@@ -214,4 +214,7 @@ def err_missing_vfs_overlay_file : Error
   "virtual filesystem overlay file '%0' not found">, DefaultFatal;
 def err_invalid_vfs_overlay : Error<
   "invalid virtual filesystem overlay file '%0'">, DefaultFatal;
-}
+
+def warn_option_invalid_ocl_version : Warning<
+  "OpenCL version %0 does not support the option '%1'">, InGroup;
+}
\ No newline at end of file

Modified: cfe/trunk/include/clang/Driver/CC1Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/CC1Options.td?rev=274150&r1=274149&r2=274150&view=diff
==
--- cfe/trunk/include/clang/Driver/CC1Options.td (original)
+++ cfe/trunk/include/clang/Driver/CC1Options.td Wed Jun 29 14:39:32 2016
@@ -664,31 +664,6 @@ def detailed_preprocessing_record : Flag
   HelpText<"include a detailed record of preprocessing actions">;
 
 
//===--===//
-// OpenCL Options
-//===--===//
-
-def cl_opt_disable : Flag<["-"], "cl-opt-disable">,
-  HelpText<"OpenCL only. This option disables all optimizations. The default 
is optimizations are enabled.">;
-def cl_strict_aliasing : Flag<["-"], "cl-strict-aliasing">,
-  HelpText<"OpenCL only. This option does nothing and is for compatibility 
with OpenCL 1.0">;
-def cl_single_precision_constant : Flag<["-"], "cl-single-precision-constant">,
-  HelpText<"OpenCL only. Treat double precision floating-point constant as 
single precision constant.">;
-def cl_finite_math_only : Flag<["-"], "cl-finite-math-only">,
-  HelpText<"OpenCL only. Allow floating-point optimizations that assume 
arguments and results are not NaNs or +-Inf.">;
-def cl_kernel_arg_info : Flag<["-"], "cl-kernel-arg-info">,
-  HelpText<"OpenCL only. Generate kernel argument metadata.">;
-def cl_unsafe_math_optimizations : Flag<["-"], "cl-unsafe-math-optimizations">,
-  HelpText<"OpenCL only. Allow unsafe floating-point optimizations.  Also 
implies -cl-no-signed-zeros and -cl-mad-enable">;
-def cl_fast_relaxed_math : Flag<["-"], "cl-fast-relaxed-math">,
-  HelpText<"OpenCL only. Sets -cl-finite-math-only and 
-cl-unsafe-math-optimizations, and defines __FAST_RELAXED_MATH__">;
-def cl_mad_enable : Flag<["-"], "cl-mad-enable">,
-  HelpText<"OpenCL only. Enable less precise MAD instructions to be 
generated.">;
-def cl_std_EQ : Joined<["-"], "cl-std=">,
-  HelpText<"OpenCL language standard to compile for">;
-def cl_denorms_are_zero : Flag<["-"], "cl-denorms-are-zero">,
-  HelpText<"OpenCL only. Allow denormals to be flushed to zero">;
-
-//===--===//
 // CUDA Options
 
//===--===//
 

Modified: cfe/trunk/include/clang/Driver/Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=274150&r1=274149&r2=274150&view=diff
==
--- cfe/trunk/include/clang/Driver/Options.td (original)
+++ cfe/trunk/include/clang/Driver/Options.td Wed Jun 29 14:39:32 2016
@@ -78,6 +78,7 @@ def g_flags_Group : OptionGroup<
 def i_Group   : OptionGroup<"">, Group;
 def clang_i_Group : OptionGroup<"">, Group;
 def m_Group   : OptionGroup<"">, Group;
+def opencl_Group  : OptionGroup<"">, 
Group;
 
 // Feature groups - these take command line options that correspond directly to
 // target specific features and can be translated directly from command line
@@ -366,6 +367,26 @@ def bind__at__load : Flag<["-"], "bind_a
 def bundle__loader : Separate<["-"], "bundle_loader">;
 def bundle : Flag<["-"], "bundle">;
 def b : JoinedOrSeparate<["-"], "b">, Fla

Re: RFC: Default language standard mode policy

2016-06-29 Thread Nico Weber via cfe-commits
On Wed, Jun 29, 2016 at 3:25 PM, Richard Smith 
wrote:

> On Wed, Jun 29, 2016 at 12:14 PM, Nico Weber  wrote:
>
>> For clang-cl, we should follow cl's model of selecting a standard. Before
>> C++17, this was "use newest language the compiler knows about" (keyed off
>> -fmsc-version; clang-cl detects the system msvc version by default if
>> that's not passed in). After C++17, there's an explicit language flag, and
>> we use the same default as cl.
>>
>
> Is that default something other than "the newest one"?
>

It looks like the next MSVC (which adds that flag) defaults to C++14. (See
majnemer's r273841 which implemented this in clang-cl, and
https://blogs.msdn.microsoft.com/vcblog/2016/06/07/standards-version-switches-in-the-compiler/
)


> Last I checked (which was a while ago), libstdc++ didn't parse with
>> -std=c++14, at least at some version. I don't remember which version of
>> libstdc++ I tried (maybe 4.9?). Should that factor into the decision? Not
>> parsing standard library headers by default on Linux seems like a somewhat
>> suboptimal user experience.
>>
>
> Last time I looked into this, I saw only one problem with version 4.9:
> libc doesn't provide ::gets to C++14, and earlier versions of libstdc++
> assume it's there and do "namespace std { using ::gets; }". We can add a
> compatibility hack to clang to work around this.
>
> Note that at this point I'd like to mainly focus on what our policy should
> be;
>

Fair enough. I don't have a strong opinion on that; your proposal makes
sense to me. (Except for clang-cl, which I think needs to mirror what cl
does.)


> there are certainly technical challenges involved in actually applying the
> policy (another one is that clang's test suite still has some failures when
> the default is changed, but Charles Li has made tremendous headway on
> this), and if we can't actually prepare for the transition in the C++
> default in time for 3.9, then so be it.
>
>
>> On Wed, Jun 29, 2016 at 3:09 PM, Richard Smith via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Hi all!
>>>
>>> I'd like to establish a policy for Clang's default language standard (if
>>> none is specified with -std), as follows:
>>>
>>>   Clang defaults to the most recent published standard for the selected
>>> language that it fully implements.
>>>
>>> The practical impact of this is that clang++ will default to C++14 for
>>> C++ compilations (for version 3.9 onwards) and will default to C++17 once
>>> our implementation support is complete and the standard is published
>>> (whichever happens later).
>>>
>>> I'd suggest that we apply the same policy for clang-cl, but if it's
>>> important that we enable a not-yet-fully-implemented standard for cl
>>> compatibility, that seems reasonable.
>>>
>>> The question of whether the default mode for the GCC-compatible driver
>>> should be -std=gnuXXX or -std=cXXX is separate, but also likely worth
>>> discussing. Enabling GNU keywords by default is a very odd choice, and if
>>> we believe we can change our defaults without breaking the world then this
>>> seems like a good time to do so.
>>>
>>> I also intend to make explicit in our documentation that our -std=XXX
>>> flag enables the selected standard, *plus all relevant issues in Defect
>>> Report status from the relevant language committee* (it doesn't make sense
>>> to support a language without its bugfixes).
>>>
>>> Thoughts?
>>>
>>> ___
>>> cfe-commits mailing list
>>> cfe-commits@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>>
>>>
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D21705: Include debug info for nested structs and classes

2016-06-29 Thread Reid Kleckner via cfe-commits
rnk added inline comments.


Comment at: lib/CodeGen/CGDebugInfo.cpp:1075
@@ +1074,3 @@
+  } else if (const auto *nestedRec = dyn_cast(I)) {
+if (!nestedRec->isImplicit())
+  CollectRecordNestedRecord(nestedRec, elements);

I would add `&& nestedRec->getDeclContext() == record` to this condition to 
deal with the `struct B { B(struct A*); };` test case.


Comment at: test/CodeGenObjCXX/debug-info-cyclic.mm:11
@@ -10,3 +10,3 @@
 // CHECK-SAME: identifier:
-// CHECK: ![[BMEMBERS]] = !{![[BB:[0-9]+]]}
+// CHECK: ![[BMEMBERS]] = !{![[A:[0-9]+]], ![[BB:[0-9]+]]}
   B(struct A *);

This is interesting, this test case shouldn't change. The lexical context for 
'struct A' is B, but the semantic context is the surrounding TU. We should only 
list class members that use the parent class as their DeclContext.

Also, why is this an Obj-C++ test in the first place, it only uses C++...


http://reviews.llvm.org/D21705



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


Re: RFC: Default language standard mode policy

2016-06-29 Thread Richard Smith via cfe-commits
On Wed, Jun 29, 2016 at 12:30 PM, Sean Silva  wrote:

>
>
> On Wed, Jun 29, 2016 at 12:09 PM, Richard Smith via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Hi all!
>>
>> I'd like to establish a policy for Clang's default language standard (if
>> none is specified with -std), as follows:
>>
>>   Clang defaults to the most recent published standard for the selected
>> language that it fully implements.
>>
>> The practical impact of this is that clang++ will default to C++14 for
>> C++ compilations (for version 3.9 onwards) and will default to C++17 once
>> our implementation support is complete and the standard is published
>> (whichever happens later).
>>
>> I'd suggest that we apply the same policy for clang-cl, but if it's
>> important that we enable a not-yet-fully-implemented standard for cl
>> compatibility, that seems reasonable.
>>
>> The question of whether the default mode for the GCC-compatible driver
>> should be -std=gnuXXX or -std=cXXX is separate, but also likely worth
>> discussing. Enabling GNU keywords by default is a very odd choice, and if
>> we believe we can change our defaults without breaking the world then this
>> seems like a good time to do so.
>>
>
> Using cXXX instead of gnuXXX would break the world on PS4. So for sure
> with `-std=c++latest` we would end up proposing a patch to change this for
> the PS4 target to gnu++latest (or gnu++11 if gnu++latest is not feasible).
>

OK. Out of interest, is it the GNU keywords that you need, or some other
effect of the difference between modes?


> (As I'm sure you're aware, we have pending to upstream a patch that makes
> -std=gnu++11 the default C++ language mode on PS4 (just blocked on fixing
> tests to not assume the existing std)).
>
> It may be feasible for us to use a "-std=gnu++latest" behavior and not
> have to have a PS4-specific default; CC'ing Warren and Paul.
>
> -- Sean Silva
>
>
>>
>> I also intend to make explicit in our documentation that our -std=XXX
>> flag enables the selected standard, *plus all relevant issues in Defect
>> Report status from the relevant language committee* (it doesn't make sense
>> to support a language without its bugfixes).
>>
>> Thoughts?
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: RFC: Default language standard mode policy

2016-06-29 Thread Chandler Carruth via cfe-commits
On Wed, Jun 29, 2016 at 12:47 PM Nico Weber via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Wed, Jun 29, 2016 at 3:25 PM, Richard Smith 
> wrote:
>
>> Note that at this point I'd like to mainly focus on what our policy
>> should be;
>>
>
> Fair enough. I don't have a strong opinion on that; your proposal makes
> sense to me. (Except for clang-cl, which I think needs to mirror what cl
> does.)
>

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


Re: RFC: Default language standard mode policy

2016-06-29 Thread Hal Finkel via cfe-commits
- Original Message -

> From: "Richard Smith via cfe-commits" 
> To: "cfe-commits" , "Clang Dev"
> 
> Sent: Wednesday, June 29, 2016 2:09:37 PM
> Subject: RFC: Default language standard mode policy

> Hi all!

> I'd like to establish a policy for Clang's default language standard
> (if none is specified with -std), as follows:

> Clang defaults to the most recent published standard for the selected
> language that it fully implements.

> The practical impact of this is that clang++ will default to C++14
> for C++ compilations (for version 3.9 onwards) and will default to
> C++17 once our implementation support is complete and the standard
> is published (whichever happens later).
I think that we need to include libc++ in this criteria as well. I think we'll 
also need some CMake flags to adjust the default for builds for systems on 
which this won't work. 

> I'd suggest that we apply the same policy for clang-cl, but if it's
> important that we enable a not-yet-fully-implemented standard for cl
> compatibility, that seems reasonable.

> The question of whether the default mode for the GCC-compatible
> driver should be -std=gnuXXX or -std=cXXX is separate, but also
> likely worth discussing. Enabling GNU keywords by default is a very
> odd choice, and if we believe we can change our defaults without
> breaking the world then this seems like a good time to do so.
Unfortunately, on many systems, some standard system headers won't even parse 
without GNU extensions enabled. I think we'll need to leave the GNU extensions 
on by default (at least for parsing system headers). 

> I also intend to make explicit in our documentation that our -std=XXX
> flag enables the selected standard, *plus all relevant issues in
> Defect Report status from the relevant language committee* (it
> doesn't make sense to support a language without its bugfixes).
+1 

-Hal 

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

-- 

Hal Finkel 
Assistant Computational Scientist 
Leadership Computing Facility 
Argonne National Laboratory 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [cfe-dev] RFC: Default language standard mode policy

2016-06-29 Thread Richard Smith via cfe-commits
On Wed, Jun 29, 2016 at 12:55 PM, Hal Finkel via cfe-dev <
cfe-...@lists.llvm.org> wrote:

>
> --
>
> *From: *"Richard Smith via cfe-commits" 
> *To: *"cfe-commits" , "Clang Dev" <
> cfe-...@lists.llvm.org>
> *Sent: *Wednesday, June 29, 2016 2:09:37 PM
> *Subject: *RFC: Default language standard mode policy
>
> Hi all!
>
> I'd like to establish a policy for Clang's default language standard (if
> none is specified with -std), as follows:
>
>   Clang defaults to the most recent published standard for the selected
> language that it fully implements.
>
> The practical impact of this is that clang++ will default to C++14 for C++
> compilations (for version 3.9 onwards) and will default to C++17 once our
> implementation support is complete and the standard is published (whichever
> happens later).
>
> I think that we need to include libc++ in this criteria as well. I think
> we'll also need some CMake flags to adjust the default for builds for
> systems on which this won't work.
>

Right, it doesn't make sense to change our default in a way that breaks use
of the same version of libc++, or a supported version of libstdc++ (and we
should establish how old a version of libstdc++ we support here).

However, I don't immediately see that we need to wait for libc++ to be
feature-complete before we enable the new standard in Clang. If that's what
you're suggesting, can you expand on why? We already have the SD-6 feature
test macros to test for implementation of specific features.

> I'd suggest that we apply the same policy for clang-cl, but if it's
> important that we enable a not-yet-fully-implemented standard for cl
> compatibility, that seems reasonable.
>
> The question of whether the default mode for the GCC-compatible driver
> should be -std=gnuXXX or -std=cXXX is separate, but also likely worth
> discussing. Enabling GNU keywords by default is a very odd choice, and if
> we believe we can change our defaults without breaking the world then this
> seems like a good time to do so.
>
> Unfortunately, on many systems, some standard system headers won't even
> parse without GNU extensions enabled. I think we'll need to leave the GNU
> extensions on by default (at least for parsing system headers).
>

Can you give an example? -std=c++11 works fine on a broad range of systems.
Note that this is not about GNU *extensions*, which are enabled in both
modes; it's about GNU *keywords* (and a small number of non-conforming
extensions) -- in particular, the 'typeof' GNU keyword, and support for the
asm keyword in C and the inline keyword in C89 (without __decoration__).

> I also intend to make explicit in our documentation that our -std=XXX flag
> enables the selected standard, *plus all relevant issues in Defect Report
> status from the relevant language committee* (it doesn't make sense to
> support a language without its bugfixes).
>
> +1
>
>  -Hal
>
>
> Thoughts?
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
>
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
>
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D21803: [libcxxabi] Provide a fallback __cxa_thread_atexit() implementation

2016-06-29 Thread Ben Craig via cfe-commits
bcraig added a comment.

> Hmm, maybe?  If other global destructors run after ~DtorListHolder(), and 
> they cause a thread_local to be initialized for the first time, 
> __cxa_thread_atexit() might be called again.  I was thinking that dtors would 
> get re-initialized in that case but it appears it does not.  So yeah, I think 
> I'll need to leak the pthread_key_t.

> 

> I'm not sure how to avoid leaking the actual thread_local objects that get 
> created in that situation.  There's nothing left to trigger run_dtors() a 
> second time.


I'm not concerned about the loss of memory or pthread_key resources in this 
leak, as it is a very short-lived leak (the process is going away after all).  
We do need to have an idea of what happens with the destructor invocations for 
the other kinds of resources though.

I think the C++14 spec says what should happen.

> 3.6.3 Termination

> 

> 1. [...] The completions of the destructors for all initialized objects with 
> thread storage duration within that thread are sequenced before the 
> initiation of the destructors of any object with static storage duration. If 
> the completion of the constructor or dynamic initialization of an object with 
> thread storage duration is sequenced before that of another, the completion 
> of the destructor of the second is sequenced before the initiation of the 
> destructor of the first. If the completion of the constructor or dynamic 
> initialization of an object with static storage duration is sequenced before 
> that of another, the completion of the destructor of the second is sequenced 
> before the initiation of the destructor of the first.


What that means for this implementation is that I think that 
__cxa_thread_atexit is allowed to be called during run_dtors.  If running the 
dtor for a thread local variable 'cat', we encounter a previously unseen 
thread_local 'dog', the compiler will call the ctor, then register the dtor 
with __cxa_thread_atexit.  Since it is the most recently constructed thread 
local object, I would expect the 'dog' dtor to be the next dtor to be run.  You 
may be able to support this just by moving "elem = elem->next" below the dtor 
invocation.


http://reviews.llvm.org/D21803



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


Re: [PATCH] D20602: Add .rgba syntax extension to ext_vector_type types

2016-06-29 Thread Richard Smith via cfe-commits
rsmith added inline comments.


Comment at: include/clang/Basic/DiagnosticSemaKinds.td:7907
@@ -7904,1 +7906,3 @@
+def ext_opencl_ext_vector_type_rgba_selector: ExtWarn<
+  "vector component name '%0' is an OpenCL version 2.2 feature">;
 } // end of sema category

As mentioned, normal Clang policy is to issue an `ExtWarn` in such cases unless 
there is some actual problem with accepting the feature as an extension. This 
*does* cause us to produce a diagnostic, which, as you say, is important.

The C and C++ standards are both clear that producing a diagnostic is a 
sufficient response to code that is ill-formed, and that we are still allowed 
to accept the program after producing the diagnostic; if the OpenCL 
specification says something else, it is simply broken and we should get it 
fixed.


Comment at: test/Misc/warning-flags.c:15-19
@@ -14,7 +14,7 @@
 
 If you add a new warning without a flag, this test will fail.  To fix
 this test, simply add a warning group to that warning.
 
 
 The list of warnings below should NEVER grow.  It should gradually shrink to 0.
 

Please follow these instructions.


http://reviews.llvm.org/D20602



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


[PATCH] D21860: [ASTMatcher] Add a node matcher for EnumType.

2016-06-29 Thread Haojian Wu via cfe-commits
hokein created this revision.
hokein added a reviewer: aaron.ballman.
hokein added a subscriber: cfe-commits.
Herald added a subscriber: klimek.

http://reviews.llvm.org/D21860

Files:
  docs/LibASTMatchersReference.html
  include/clang/ASTMatchers/ASTMatchers.h
  lib/ASTMatchers/Dynamic/Registry.cpp
  unittests/ASTMatchers/ASTMatchersNodeTest.cpp

Index: unittests/ASTMatchers/ASTMatchersNodeTest.cpp
===
--- unittests/ASTMatchers/ASTMatchersNodeTest.cpp
+++ unittests/ASTMatchers/ASTMatchersNodeTest.cpp
@@ -1299,6 +1299,13 @@
 hasType(rValueReferenceType();
 }
 
+TEST(TypeMatching, MatchesEnumTypes) {
+  EXPECT_TRUE(matches("enum Color { Green }; Color color;",
+  loc(enumType(;
+  EXPECT_TRUE(matches("enum class Color { Green }; Color color;",
+  loc(enumType(;
+}
+
 TEST(TypeMatching, MatchesPointersToConstTypes) {
   EXPECT_TRUE(matches("int b; int * const a = &b;",
   loc(pointerType(;
Index: lib/ASTMatchers/Dynamic/Registry.cpp
===
--- lib/ASTMatchers/Dynamic/Registry.cpp
+++ lib/ASTMatchers/Dynamic/Registry.cpp
@@ -171,6 +171,7 @@
   REGISTER_MATCHER(elaboratedType);
   REGISTER_MATCHER(enumConstantDecl);
   REGISTER_MATCHER(enumDecl);
+  REGISTER_MATCHER(enumType);
   REGISTER_MATCHER(equalsBoundNode);
   REGISTER_MATCHER(equalsIntegralValue);
   REGISTER_MATCHER(explicitCastExpr);
Index: include/clang/ASTMatchers/ASTMatchers.h
===
--- include/clang/ASTMatchers/ASTMatchers.h
+++ include/clang/ASTMatchers/ASTMatchers.h
@@ -4654,6 +4654,21 @@
 ///   matches "typedef int X"
 AST_TYPE_MATCHER(TypedefType, typedefType);
 
+/// \brief Matches enum types.
+///
+/// Given
+/// \code
+///   enum C { Green };
+///   enum class S { Red };
+///
+///   C c;
+///   S s;
+/// \endcode
+//
+/// \c enumType() matches the type of the variable declarations of both \c c 
and
+/// \c s.
+AST_TYPE_MATCHER(EnumType, enumType);
+
 /// \brief Matches template specialization types.
 ///
 /// Given
Index: docs/LibASTMatchersReference.html
===
--- docs/LibASTMatchersReference.html
+++ docs/LibASTMatchersReference.html
@@ -1448,6 +1448,21 @@
 
 
 
+MatcherType>enumTypeMatcherEnumType>...
+Matches enum types.
+
+Given
+  enum C { Green };
+  enum S { Red };
+
+  C c;
+  S s;
+
+enumType() matches the type of the variable declarations of both c and
+s.
+
+
+
 MatcherType>functionProtoTypeMatcherFunctionProtoType>...
 Matches 
FunctionProtoType nodes.
 


Index: unittests/ASTMatchers/ASTMatchersNodeTest.cpp
===
--- unittests/ASTMatchers/ASTMatchersNodeTest.cpp
+++ unittests/ASTMatchers/ASTMatchersNodeTest.cpp
@@ -1299,6 +1299,13 @@
 hasType(rValueReferenceType();
 }
 
+TEST(TypeMatching, MatchesEnumTypes) {
+  EXPECT_TRUE(matches("enum Color { Green }; Color color;",
+  loc(enumType(;
+  EXPECT_TRUE(matches("enum class Color { Green }; Color color;",
+  loc(enumType(;
+}
+
 TEST(TypeMatching, MatchesPointersToConstTypes) {
   EXPECT_TRUE(matches("int b; int * const a = &b;",
   loc(pointerType(;
Index: lib/ASTMatchers/Dynamic/Registry.cpp
===
--- lib/ASTMatchers/Dynamic/Registry.cpp
+++ lib/ASTMatchers/Dynamic/Registry.cpp
@@ -171,6 +171,7 @@
   REGISTER_MATCHER(elaboratedType);
   REGISTER_MATCHER(enumConstantDecl);
   REGISTER_MATCHER(enumDecl);
+  REGISTER_MATCHER(enumType);
   REGISTER_MATCHER(equalsBoundNode);
   REGISTER_MATCHER(equalsIntegralValue);
   REGISTER_MATCHER(explicitCastExpr);
Index: include/clang/ASTMatchers/ASTMatchers.h
===
--- include/clang/ASTMatchers/ASTMatchers.h
+++ include/clang/ASTMatchers/ASTMatchers.h
@@ -4654,6 +4654,21 @@
 ///   matches "typedef int X"
 AST_TYPE_MATCHER(TypedefType, typedefType);
 
+/// \brief Matches enum types.
+///
+/// Given
+/// \code
+///   enum C { Green };
+///   enum class S { Red };
+///
+///   C c;
+///   S s;
+/// \endcode
+//
+/// \c enumType() matches the type of the variable declarations of both \c c and
+/// \c s.
+AST_TYPE_MATCHER(EnumType, enumType);
+
 /// \brief Matches template specialization types.
 ///
 /// Given
Index: docs/LibASTMatchersReference.html
===
--- docs/LibASTMatchersReference.h

Re: [PATCH] D21833: [clang-tidy] Fix more enum declaration cases in misc-unused-using-decls check.

2016-06-29 Thread Haojian Wu via cfe-commits
hokein marked an inline comment as done.


Comment at: clang-tidy/misc/UnusedUsingDeclsCheck.cpp:22
@@ +21,3 @@
+namespace {
+// FIXME: Move this node matcher to ASTMatcher.
+const internal::VariadicDynCastAllOfMatcher enumType;

Done in D21860.


http://reviews.llvm.org/D21833



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


Re: [PATCH] D21833: [clang-tidy] Fix more enum declaration cases in misc-unused-using-decls check.

2016-06-29 Thread Haojian Wu via cfe-commits
hokein updated this revision to Diff 62278.
hokein added a comment.

Address review comments.


http://reviews.llvm.org/D21833

Files:
  clang-tidy/misc/UnusedUsingDeclsCheck.cpp
  test/clang-tidy/misc-unused-using-decls.cpp

Index: test/clang-tidy/misc-unused-using-decls.cpp
===
--- test/clang-tidy/misc-unused-using-decls.cpp
+++ test/clang-tidy/misc-unused-using-decls.cpp
@@ -44,11 +44,13 @@
 extern ostream cout;
 ostream &endl(ostream &os);
 
-enum Color {
-  Green,
-  Red,
-  Yellow
-};
+enum Color1 { Green };
+
+enum Color2 { Red };
+
+enum Color3 { Yellow };
+
+enum Color4 { Blue };
 
 }  // namespace n
 
@@ -126,11 +128,13 @@
 using n::H;
 }
 
-using n::Color;
-// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: using decl 'Color' is unused
+using n::Color1;
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: using decl 'Color1' is unused
 using n::Green;
 // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: using decl 'Green' is unused
-using n::Red;
+using n::Color2;
+using n::Color3;
+using n::Blue;
 
 // - Usages -
 void f(B b);
@@ -144,5 +148,7 @@
   UsedFunc();
   UsedTemplateFunc();
   cout << endl;
-  int t = Red;
+  Color2 color2;
+  int t1 = Color3::Yellow;
+  int t2 = Blue;
 }
Index: clang-tidy/misc/UnusedUsingDeclsCheck.cpp
===
--- clang-tidy/misc/UnusedUsingDeclsCheck.cpp
+++ clang-tidy/misc/UnusedUsingDeclsCheck.cpp
@@ -18,6 +18,11 @@
 namespace tidy {
 namespace misc {
 
+namespace {
+// FIXME: Move this node matcher to ASTMatcher.
+const internal::VariadicDynCastAllOfMatcher enumType;
+} // namespace
+
 // A function that helps to tell whether a TargetDecl in a UsingDecl will be
 // checked. Only variable, function, function template, class template, class,
 // enum declaration and enum constant declaration are considered.
@@ -31,6 +36,7 @@
 void UnusedUsingDeclsCheck::registerMatchers(MatchFinder *Finder) {
   Finder->addMatcher(usingDecl(isExpansionInMainFile()).bind("using"), this);
   auto DeclMatcher = hasDeclaration(namedDecl().bind("used"));
+  Finder->addMatcher(loc(enumType(DeclMatcher)), this);
   Finder->addMatcher(loc(recordType(DeclMatcher)), this);
   Finder->addMatcher(loc(templateSpecializationType(DeclMatcher)), this);
   Finder->addMatcher(declRefExpr().bind("used"), this);
@@ -94,6 +100,8 @@
   removeFromFoundDecls(VD);
 } else if (const auto *ECD = dyn_cast(DRE->getDecl())) {
   removeFromFoundDecls(ECD);
+  if (const auto *ET = ECD->getType()->getAs())
+removeFromFoundDecls(ET->getDecl());
 }
   }
   // Check the uninstantiated template function usage.


Index: test/clang-tidy/misc-unused-using-decls.cpp
===
--- test/clang-tidy/misc-unused-using-decls.cpp
+++ test/clang-tidy/misc-unused-using-decls.cpp
@@ -44,11 +44,13 @@
 extern ostream cout;
 ostream &endl(ostream &os);
 
-enum Color {
-  Green,
-  Red,
-  Yellow
-};
+enum Color1 { Green };
+
+enum Color2 { Red };
+
+enum Color3 { Yellow };
+
+enum Color4 { Blue };
 
 }  // namespace n
 
@@ -126,11 +128,13 @@
 using n::H;
 }
 
-using n::Color;
-// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: using decl 'Color' is unused
+using n::Color1;
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: using decl 'Color1' is unused
 using n::Green;
 // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: using decl 'Green' is unused
-using n::Red;
+using n::Color2;
+using n::Color3;
+using n::Blue;
 
 // - Usages -
 void f(B b);
@@ -144,5 +148,7 @@
   UsedFunc();
   UsedTemplateFunc();
   cout << endl;
-  int t = Red;
+  Color2 color2;
+  int t1 = Color3::Yellow;
+  int t2 = Blue;
 }
Index: clang-tidy/misc/UnusedUsingDeclsCheck.cpp
===
--- clang-tidy/misc/UnusedUsingDeclsCheck.cpp
+++ clang-tidy/misc/UnusedUsingDeclsCheck.cpp
@@ -18,6 +18,11 @@
 namespace tidy {
 namespace misc {
 
+namespace {
+// FIXME: Move this node matcher to ASTMatcher.
+const internal::VariadicDynCastAllOfMatcher enumType;
+} // namespace
+
 // A function that helps to tell whether a TargetDecl in a UsingDecl will be
 // checked. Only variable, function, function template, class template, class,
 // enum declaration and enum constant declaration are considered.
@@ -31,6 +36,7 @@
 void UnusedUsingDeclsCheck::registerMatchers(MatchFinder *Finder) {
   Finder->addMatcher(usingDecl(isExpansionInMainFile()).bind("using"), this);
   auto DeclMatcher = hasDeclaration(namedDecl().bind("used"));
+  Finder->addMatcher(loc(enumType(DeclMatcher)), this);
   Finder->addMatcher(loc(recordType(DeclMatcher)), this);
   Finder->addMatcher(loc(templateSpecializationType(DeclMatcher)), this);
   Finder->addMatcher(declRefExpr().bind("used"), this);
@@ -94,6 +100,8 @@
   removeFromFoundDecls(VD);
 } else if (const auto *ECD = dyn_cast(DRE->getDecl())) {
   removeFromFoundDecls(ECD);
+  if (const auto 

r274157 - [cmake] Move creation of ClangTargets and installation of ClangConfig.cmake from ./CMakeLists.txt -> ./cmake/modules/CMakeLists.txt.

2016-06-29 Thread Michael Gottesman via cfe-commits
Author: mgottesman
Date: Wed Jun 29 15:22:44 2016
New Revision: 274157

URL: http://llvm.org/viewvc/llvm-project?rev=274157&view=rev
Log:
[cmake] Move creation of ClangTargets and installation of ClangConfig.cmake 
from ./CMakeLists.txt -> ./cmake/modules/CMakeLists.txt.

This matches LLVM.

Added:
cfe/trunk/cmake/modules/CMakeLists.txt
Modified:
cfe/trunk/CMakeLists.txt

Modified: cfe/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/CMakeLists.txt?rev=274157&r1=274156&r2=274157&view=diff
==
--- cfe/trunk/CMakeLists.txt (original)
+++ cfe/trunk/CMakeLists.txt Wed Jun 29 15:22:44 2016
@@ -596,28 +596,7 @@ if(APPLE)
   endif()
 endif()
 
-# Generate a list of CMake library targets so that other CMake projects can
-# link against them. LLVM calls its version of this file LLVMExports.cmake, but
-# the usual CMake convention seems to be ${Project}Targets.cmake.
-set(CLANG_INSTALL_PACKAGE_DIR lib${LLVM_LIBDIR_SUFFIX}/cmake/clang)
-set(clang_cmake_builddir "${CMAKE_BINARY_DIR}/${CLANG_INSTALL_PACKAGE_DIR}")
-get_property(CLANG_EXPORTS GLOBAL PROPERTY CLANG_EXPORTS)
-export(TARGETS ${CLANG_EXPORTS} FILE 
${clang_cmake_builddir}/ClangTargets.cmake)
-
-# Install a /lib/cmake/clang/ClangConfig.cmake file so that
-# find_package(Clang) works. Install the target list with it.
-install(EXPORT ClangTargets DESTINATION ${CLANG_INSTALL_PACKAGE_DIR})
-
-install(FILES
-  ${CMAKE_CURRENT_SOURCE_DIR}/cmake/modules/ClangConfig.cmake
-  DESTINATION lib${LLVM_LIBDIR_SUFFIX}/cmake/clang)
-
-# Also copy ClangConfig.cmake to the build directory so that dependent projects
-# can build against a build directory of Clang more easily.
-configure_file(
-  ${CMAKE_CURRENT_SOURCE_DIR}/cmake/modules/ClangConfig.cmake
-  ${CLANG_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/cmake/clang/ClangConfig.cmake
-  COPYONLY)
+add_subdirectory(cmake/modules)
 
 if (CLANG_ENABLE_BOOTSTRAP)
   include(ExternalProject)

Added: cfe/trunk/cmake/modules/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/modules/CMakeLists.txt?rev=274157&view=auto
==
--- cfe/trunk/cmake/modules/CMakeLists.txt (added)
+++ cfe/trunk/cmake/modules/CMakeLists.txt Wed Jun 29 15:22:44 2016
@@ -0,0 +1,22 @@
+# Generate a list of CMake library targets so that other CMake projects can
+# link against them. LLVM calls its version of this file LLVMExports.cmake, but
+# the usual CMake convention seems to be ${Project}Targets.cmake.
+set(CLANG_INSTALL_PACKAGE_DIR lib${LLVM_LIBDIR_SUFFIX}/cmake/clang)
+set(clang_cmake_builddir "${CMAKE_BINARY_DIR}/${CLANG_INSTALL_PACKAGE_DIR}")
+get_property(CLANG_EXPORTS GLOBAL PROPERTY CLANG_EXPORTS)
+export(TARGETS ${CLANG_EXPORTS} FILE 
${clang_cmake_builddir}/ClangTargets.cmake)
+
+# Install a /lib/cmake/clang/ClangConfig.cmake file so that
+# find_package(Clang) works. Install the target list with it.
+install(EXPORT ClangTargets DESTINATION ${CLANG_INSTALL_PACKAGE_DIR})
+
+install(FILES
+  ${CMAKE_CURRENT_SOURCE_DIR}/ClangConfig.cmake
+  DESTINATION lib${LLVM_LIBDIR_SUFFIX}/cmake/clang)
+
+# Also copy ClangConfig.cmake to the build directory so that dependent projects
+# can build against a build directory of Clang more easily.
+configure_file(
+  ${CMAKE_CURRENT_SOURCE_DIR}/ClangConfig.cmake
+  ${CLANG_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/cmake/clang/ClangConfig.cmake
+  COPYONLY)


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


r274158 - [ClangConfig] Replace paths with the same value as CLANG_INSTALL_PACKAGE_DIR with a deref of the variable.

2016-06-29 Thread Michael Gottesman via cfe-commits
Author: mgottesman
Date: Wed Jun 29 15:22:46 2016
New Revision: 274158

URL: http://llvm.org/viewvc/llvm-project?rev=274158&view=rev
Log:
[ClangConfig] Replace paths with the same value as CLANG_INSTALL_PACKAGE_DIR 
with a deref of the variable.

Modified:
cfe/trunk/cmake/modules/CMakeLists.txt

Modified: cfe/trunk/cmake/modules/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/modules/CMakeLists.txt?rev=274158&r1=274157&r2=274158&view=diff
==
--- cfe/trunk/cmake/modules/CMakeLists.txt (original)
+++ cfe/trunk/cmake/modules/CMakeLists.txt Wed Jun 29 15:22:46 2016
@@ -12,11 +12,11 @@ install(EXPORT ClangTargets DESTINATION
 
 install(FILES
   ${CMAKE_CURRENT_SOURCE_DIR}/ClangConfig.cmake
-  DESTINATION lib${LLVM_LIBDIR_SUFFIX}/cmake/clang)
+  DESTINATION ${CLANG_INSTALL_PACKAGE_DIR})
 
 # Also copy ClangConfig.cmake to the build directory so that dependent projects
 # can build against a build directory of Clang more easily.
 configure_file(
   ${CMAKE_CURRENT_SOURCE_DIR}/ClangConfig.cmake
-  ${CLANG_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/cmake/clang/ClangConfig.cmake
+  ${CLANG_BINARY_DIR}/${CLANG_INSTALL_PACKAGE_DIR}/ClangConfig.cmake
   COPYONLY)


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


Re: RFC: Default language standard mode policy

2016-06-29 Thread Sean Silva via cfe-commits
On Wed, Jun 29, 2016 at 12:51 PM, Richard Smith 
wrote:

> On Wed, Jun 29, 2016 at 12:30 PM, Sean Silva 
> wrote:
>
>>
>>
>> On Wed, Jun 29, 2016 at 12:09 PM, Richard Smith via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Hi all!
>>>
>>> I'd like to establish a policy for Clang's default language standard (if
>>> none is specified with -std), as follows:
>>>
>>>   Clang defaults to the most recent published standard for the selected
>>> language that it fully implements.
>>>
>>> The practical impact of this is that clang++ will default to C++14 for
>>> C++ compilations (for version 3.9 onwards) and will default to C++17 once
>>> our implementation support is complete and the standard is published
>>> (whichever happens later).
>>>
>>> I'd suggest that we apply the same policy for clang-cl, but if it's
>>> important that we enable a not-yet-fully-implemented standard for cl
>>> compatibility, that seems reasonable.
>>>
>>> The question of whether the default mode for the GCC-compatible driver
>>> should be -std=gnuXXX or -std=cXXX is separate, but also likely worth
>>> discussing. Enabling GNU keywords by default is a very odd choice, and if
>>> we believe we can change our defaults without breaking the world then this
>>> seems like a good time to do so.
>>>
>>
>> Using cXXX instead of gnuXXX would break the world on PS4. So for sure
>> with `-std=c++latest` we would end up proposing a patch to change this for
>> the PS4 target to gnu++latest (or gnu++11 if gnu++latest is not feasible).
>>
>
> OK. Out of interest, is it the GNU keywords that you need, or some other
> effect of the difference between modes?
>

A quick check of two titles I have at hand shows that at least `typeof` is
in use.

-- Sean Silva


>
>
>> (As I'm sure you're aware, we have pending to upstream a patch that makes
>> -std=gnu++11 the default C++ language mode on PS4 (just blocked on fixing
>> tests to not assume the existing std)).
>>
>> It may be feasible for us to use a "-std=gnu++latest" behavior and not
>> have to have a PS4-specific default; CC'ing Warren and Paul.
>>
>> -- Sean Silva
>>
>>
>>>
>>> I also intend to make explicit in our documentation that our -std=XXX
>>> flag enables the selected standard, *plus all relevant issues in Defect
>>> Report status from the relevant language committee* (it doesn't make sense
>>> to support a language without its bugfixes).
>>>
>>> Thoughts?
>>>
>>> ___
>>> cfe-commits mailing list
>>> cfe-commits@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>>
>>>
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: RFC: Default language standard mode policy

2016-06-29 Thread Sean Silva via cfe-commits
On Wed, Jun 29, 2016 at 1:34 PM, Sean Silva  wrote:

>
>
> On Wed, Jun 29, 2016 at 12:51 PM, Richard Smith 
> wrote:
>
>> On Wed, Jun 29, 2016 at 12:30 PM, Sean Silva 
>> wrote:
>>
>>>
>>>
>>> On Wed, Jun 29, 2016 at 12:09 PM, Richard Smith via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 Hi all!

 I'd like to establish a policy for Clang's default language standard
 (if none is specified with -std), as follows:

   Clang defaults to the most recent published standard for the selected
 language that it fully implements.

 The practical impact of this is that clang++ will default to C++14 for
 C++ compilations (for version 3.9 onwards) and will default to C++17 once
 our implementation support is complete and the standard is published
 (whichever happens later).

 I'd suggest that we apply the same policy for clang-cl, but if it's
 important that we enable a not-yet-fully-implemented standard for cl
 compatibility, that seems reasonable.

 The question of whether the default mode for the GCC-compatible driver
 should be -std=gnuXXX or -std=cXXX is separate, but also likely worth
 discussing. Enabling GNU keywords by default is a very odd choice, and if
 we believe we can change our defaults without breaking the world then this
 seems like a good time to do so.

>>>
>>> Using cXXX instead of gnuXXX would break the world on PS4. So for sure
>>> with `-std=c++latest` we would end up proposing a patch to change this for
>>> the PS4 target to gnu++latest (or gnu++11 if gnu++latest is not feasible).
>>>
>>
>> OK. Out of interest, is it the GNU keywords that you need, or some other
>> effect of the difference between modes?
>>
>
> A quick check of two titles I have at hand shows that at least `typeof` is
> in use.
>

(this check consisted of using -std=c++11 instead of -std=gnu++11 and
seeing what breaks)

-- Sean Silva


>
> -- Sean Silva
>
>
>>
>>
>>> (As I'm sure you're aware, we have pending to upstream a patch that
>>> makes -std=gnu++11 the default C++ language mode on PS4 (just blocked on
>>> fixing tests to not assume the existing std)).
>>>
>>> It may be feasible for us to use a "-std=gnu++latest" behavior and not
>>> have to have a PS4-specific default; CC'ing Warren and Paul.
>>>
>>> -- Sean Silva
>>>
>>>

 I also intend to make explicit in our documentation that our -std=XXX
 flag enables the selected standard, *plus all relevant issues in Defect
 Report status from the relevant language committee* (it doesn't make sense
 to support a language without its bugfixes).

 Thoughts?

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


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


Re: [PATCH] D18035: [GCC] PR23529 Mangler part of attrbute abi_tag support

2016-06-29 Thread Richard Smith via cfe-commits
rsmith accepted this revision.
rsmith added a comment.
This revision is now accepted and ready to land.

LGTM, thank you so much for your patience and hard work on this change!


http://reviews.llvm.org/D18035



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


Re: [PATCH] D21823: [Driver] Add flags for enabling both types of PGO Instrumentation

2016-06-29 Thread Jake VanAdrighem via cfe-commits
jakev updated this revision to Diff 62282.
jakev marked 5 inline comments as done.
jakev added a comment.

Address comments.


Repository:
  rL LLVM

http://reviews.llvm.org/D21823

Files:
  include/clang/Driver/Options.td
  lib/Driver/ToolChain.cpp
  lib/Driver/Tools.cpp
  test/Driver/clang_f_opts.c

Index: test/Driver/clang_f_opts.c
===
--- test/Driver/clang_f_opts.c
+++ test/Driver/clang_f_opts.c
@@ -97,10 +97,20 @@
 // RUN: %clang -### -S -fcoverage-mapping %s 2>&1 | FileCheck -check-prefix=CHECK-COVERAGE-AND-GEN %s
 // RUN: %clang -### -S -fcoverage-mapping -fno-coverage-mapping %s 2>&1 | FileCheck -check-prefix=CHECK-DISABLE-COVERAGE %s
 // RUN: %clang -### -S -fprofile-instr-generate -fcoverage-mapping -fno-coverage-mapping %s 2>&1 | FileCheck -check-prefix=CHECK-DISABLE-COVERAGE %s
+// RUN: %clang -### -S -fpgo-train=source-cfg %s 2>&1 | FileCheck -check-prefix=CHECK-PROFILE-GENERATE %s
+// RUN: %clang -### -S -fpgo-train=optimizer-cfg %s 2>&1 | FileCheck -check-prefix=CHECK-PROFILE-GENERATE-LLVM %s
+// RUN: %clang -### -S -fpgo-train=source-cfg -fcoverage-mapping %s 2>&1 | FileCheck -check-prefix=CHECK-COVERAGE-AND-GEN %s
+// RUN: %clang -### -S -fpgo-train=optimizer-cfg -fcoverage-mapping %s 2>&1 | FileCheck -check-prefix=CHECK-COVERAGE-AND-GEN %s
+// RUN: %clang -### -S -fpgo-train=source-cfg -fprofile-instr-generate %s 2>&1 | FileCheck -check-prefix=CHECK-NO-MIX-TRAIN-GEN %s
+// RUN: %clang -### -S -fpgo-train=optimizer-cfg -fprofile-instr-generate %s 2>&1 | FileCheck -check-prefix=CHECK-NO-MIX-TRAIN-GEN %s
+// RUN: %clang -### -S -fpgo-train=source-cfg -fpgo-apply=file %s 2>&1 | FileCheck -check-prefix=CHECK-PROFILE-GENERATE %s
+// RUN: %clang -### -S -fpgo-train=optimizer-cfg -fpgo-apply=file %s 2>&1 | FileCheck -check-prefix=CHECK-PROFILE-GENERATE-LLVM %s
 // CHECK-PROFILE-GENERATE: "-fprofile-instrument=clang"
+// CHECK-PROFILE-GENERATE-LLVM: "-fprofile-instrument=llvm"
 // CHECK-PROFILE-GENERATE-DIR: "-fprofile-instrument-path=/some/dir{{/|}}default.profraw"
 // CHECK-PROFILE-GENERATE-FILE: "-fprofile-instrument-path=/tmp/somefile.profraw"
 // CHECK-NO-MIX-GEN-USE: '{{[a-z=-]*}}' not allowed with '{{[a-z=-]*}}'
+// CHECK-NO-MIX-TRAIN-GEN: '{{[a-z=-]*}}' not allowed with '{{[a-z=-]*}}'
 // CHECK-DISABLE-GEN-NOT: "-fprofile-instrument=clang"
 // CHECK-DISABLE-USE-NOT: "-fprofile-instr-use"
 // CHECK-COVERAGE-AND-GEN: '-fcoverage-mapping' only allowed with '-fprofile-instr-generate'
@@ -111,9 +121,14 @@
 // RUN: mkdir -p %t.d/some/dir
 // RUN: %clang -### -S -fprofile-use=%t.d/some/dir %s 2>&1 | FileCheck -check-prefix=CHECK-PROFILE-USE-DIR %s
 // RUN: %clang -### -S -fprofile-instr-use=/tmp/somefile.prof %s 2>&1 | FileCheck -check-prefix=CHECK-PROFILE-USE-FILE %s
+// RUN: %clang -### -S -fpgo-apply=/tmp/somefile.prof %s 2>&1 | FileCheck -check-prefix=CHECK-PROFILE-USE-FILE %s
+// RUN: %clang -### -S -fpgo-train=source-cfg -fpgo-apply=/tmp/somefile.prof %s 2>&1 | FileCheck -check-prefix=CHECK-PROFILE-USE-FILE %s
+// RUN: %clang -### -S -fpgo-train=optimizer-cfg  -fpgo-apply=/tmp/somefile.prof %s 2>&1 | FileCheck -check-prefix=CHECK-PROFILE-USE-FILE %s
+// RUN: %clang -### -S -fprofile-instr-use=/tmp/somefile.prof -fpgo-apply=/tmp/somefile.prof %s 2>&1 | FileCheck -check-prefix=CHECK-NO-MIX-APPLY-USE %s
 // CHECK-PROFILE-USE: "-fprofile-instrument-use-path=default.profdata"
 // CHECK-PROFILE-USE-DIR: "-fprofile-instrument-use-path={{.*}}.d/some/dir{{/|}}default.profdata"
 // CHECK-PROFILE-USE-FILE: "-fprofile-instrument-use-path=/tmp/somefile.prof"
+// CHECK-NO-MIX-APPLY-USE: '{{[a-z=-]*}}' not allowed with '{{[a-z=-]*}}'
 
 // RUN: %clang -### -S -fvectorize %s 2>&1 | FileCheck -check-prefix=CHECK-VECTORIZE %s
 // RUN: %clang -### -S -fno-vectorize -fvectorize %s 2>&1 | FileCheck -check-prefix=CHECK-VECTORIZE %s
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -3468,6 +3468,14 @@
 static void addPGOAndCoverageFlags(Compilation &C, const Driver &D,
const InputInfo &Output, const ArgList &Args,
ArgStringList &CmdArgs) {
+
+  auto *PGOTrainArg =
+  Args.getLastArg(options::OPT_fpgo_train_EQ,
+  options::OPT_fno_pgo_train);
+  if (PGOTrainArg &&
+  PGOTrainArg->getOption().matches(options::OPT_fno_pgo_train))
+PGOTrainArg = nullptr;
+
   auto *ProfileGenerateArg = Args.getLastArg(
   options::OPT_fprofile_instr_generate,
   options::OPT_fprofile_instr_generate_EQ, options::OPT_fprofile_generate,
@@ -3478,14 +3486,29 @@
   options::OPT_fno_profile_instr_generate))
 ProfileGenerateArg = nullptr;
 
+  else if (PGOTrainArg && ProfileGenerateArg)
+D.Diag(diag::err_drv_argument_not_allowed_with)
+<< PGOTrainArg->getSpelling()
+<< ProfileGenerateArg->getSpelling();
+
+  auto *PGOApplyArg =
+  

Re: [PATCH] D21823: [Driver] Add flags for enabling both types of PGO Instrumentation

2016-06-29 Thread Rong Xu via cfe-commits
xur added a comment.

Thanks for doing this. I like the patch in general.  Hers are my minor 
feedbacks:
(1) It seems the original options of -fprofile-instr-generate and 
-fprofile-instr-use will be kept. Is so, what is the guideline to use these two 
sets of options. Also, we need some documentations for the new user-visible
options.
(2) One difference b/w -fprofile-instr-generate/-fprofile-instr-use and the new 
options is -fpgo-train={source-cfg | optimizer-cfg} can coexist with 
-fpgo-apply=. I don't think they work as intended in current 
implementation. I would suggest to not allow it.
(3) I would request a driver option to specify the profile name. While  
LLVM_PROFILE_FILE environment variable can do that, a command line option is 
gonna be useful (at least in our setup).

-Rong


Repository:
  rL LLVM

http://reviews.llvm.org/D21823



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


Re: [PATCH] D21705: Include debug info for nested structs and classes

2016-06-29 Thread Adrian McCarthy via cfe-commits
amccarth marked 2 inline comments as done.
amccarth added a comment.

http://reviews.llvm.org/D21705



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


Re: [PATCH] D21705: Include debug info for nested structs and classes

2016-06-29 Thread Adrian McCarthy via cfe-commits
amccarth updated this revision to Diff 62283.
amccarth added a comment.

Applied suggestion from the comments, which eliminates the need to alter the 
ObjectiveC test.


http://reviews.llvm.org/D21705

Files:
  lib/CodeGen/CGDebugInfo.cpp
  lib/CodeGen/CGDebugInfo.h
  test/CodeGenCXX/debug-info-dup-fwd-decl.cpp
  test/CodeGenCXX/debug-info-indirect-field-decl.cpp
  test/CodeGenCXX/debug-info-ms-abi.cpp

Index: test/CodeGenCXX/debug-info-ms-abi.cpp
===
--- test/CodeGenCXX/debug-info-ms-abi.cpp
+++ test/CodeGenCXX/debug-info-ms-abi.cpp
@@ -14,6 +14,9 @@
 // CHECK: ![[Foo:[^ ]*]] = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "Foo",
 // CHECK-SAME: identifier: ".?AUFoo@@"
 
+// CHECK: distinct !DICompositeType(tag: DW_TAG_structure_type, name: "Nested",
+// CHECK-SAME: identifier: ".?AUNested@Foo@@"
+
 // CHECK: !DISubprogram(name: "f",
 // CHECK-SAME: containingType: ![[Foo]], virtuality: DW_VIRTUALITY_virtual, virtualIndex: 0,
 // CHECK-SAME: flags: DIFlagPrototyped | DIFlagIntroducedVirtual,
@@ -25,6 +28,3 @@
 // CHECK: !DISubprogram(name: "h",
 // CHECK-SAME: containingType: ![[Foo]], virtuality: DW_VIRTUALITY_virtual, virtualIndex: 2,
 // CHECK-SAME: flags: DIFlagPrototyped | DIFlagIntroducedVirtual,
-
-// CHECK: distinct !DICompositeType(tag: DW_TAG_structure_type, name: "Nested",
-// CHECK-SAME: identifier: ".?AUNested@Foo@@"
Index: test/CodeGenCXX/debug-info-indirect-field-decl.cpp
===
--- test/CodeGenCXX/debug-info-indirect-field-decl.cpp
+++ test/CodeGenCXX/debug-info-indirect-field-decl.cpp
@@ -8,18 +8,18 @@
 struct Bar {
   int i1;
   // CHECK: ![[INT:[0-9]+]] = !DIBasicType(name: "int"
-  // CHECK: !DIDerivedType(tag: DW_TAG_member, scope:
-  // CHECK-SAME:   line: [[@LINE+4]]
-  // CHECK-SAME:   baseType: ![[UNION:[0-9]+]]
-  // CHECK-SAME:   size: 32, align: 32, offset: 32
-  // CHECK: ![[UNION]] = distinct !DICompositeType(tag: DW_TAG_union_type,{{.*}} identifier: "_ZTSN3BarUt_E")
+  // CHECK: ![[UNION:[0-9]+]] = distinct !DICompositeType(tag: DW_TAG_union_type,{{.*}} identifier: "_ZTSN3BarUt_E")
   union {
 // CHECK: !DIDerivedType(tag: DW_TAG_member, name: "i2",
-// CHECK-SAME:   line: [[@LINE+5]]
+// CHECK-SAME:   line: [[@LINE+9]]
 // CHECK-SAME:   baseType: ![[INT]]
 // CHECK-SAME:   size: 32, align: 32
 // CHECK-NOT:offset:
 // CHECK-SAME:   ){{$}}
+// CHECK: !DIDerivedType(tag: DW_TAG_member, scope:
+// CHECK-SAME:   line: [[@LINE-8]]
+// CHECK-SAME:   baseType: ![[UNION]]
+// CHECK-SAME:   size: 32, align: 32, offset: 32
 int i2;
   };
 };
Index: test/CodeGenCXX/debug-info-dup-fwd-decl.cpp
===
--- test/CodeGenCXX/debug-info-dup-fwd-decl.cpp
+++ test/CodeGenCXX/debug-info-dup-fwd-decl.cpp
@@ -19,6 +19,6 @@
 
 Test t;
 
-// CHECK: !DIDerivedType(tag: DW_TAG_pointer_type
 // CHECK: !DICompositeType(tag: DW_TAG_structure_type, name: "data"
+// CHECK: !DIDerivedType(tag: DW_TAG_pointer_type
 // CHECK-NOT: !DICompositeType(tag: DW_TAG_structure_type, name: "data"
Index: lib/CodeGen/CGDebugInfo.h
===
--- lib/CodeGen/CGDebugInfo.h
+++ lib/CodeGen/CGDebugInfo.h
@@ -249,6 +249,8 @@
 llvm::DIFile *F,
 SmallVectorImpl &E,
 llvm::DIType *RecordTy, const RecordDecl *RD);
+  void CollectRecordNestedRecord(const RecordDecl *RD,
+ SmallVectorImpl &E);
   void CollectRecordFields(const RecordDecl *Decl, llvm::DIFile *F,
SmallVectorImpl &E,
llvm::DICompositeType *RecordTy);
Index: lib/CodeGen/CGDebugInfo.cpp
===
--- lib/CodeGen/CGDebugInfo.cpp
+++ lib/CodeGen/CGDebugInfo.cpp
@@ -1028,6 +1028,13 @@
   elements.push_back(fieldType);
 }
 
+void CGDebugInfo::CollectRecordNestedRecord(
+const RecordDecl *RD, SmallVectorImpl &elements) {
+  QualType Ty = CGM.getContext().getTypeDeclType(RD);
+  llvm::DIType *nestedType = getOrCreateType(Ty, getOrCreateMainFile());
+  elements.push_back(nestedType);
+}
+
 void CGDebugInfo::CollectRecordFields(
 const RecordDecl *record, llvm::DIFile *tunit,
 SmallVectorImpl &elements,
@@ -1064,6 +1071,9 @@
 
 // Bump field number for next field.
 ++fieldNo;
+  } else if (const auto *nestedRec = dyn_cast(I)) {
+if (!nestedRec->isImplicit() && nestedRec->getDeclContext() == record)
+  CollectRecordNestedRecord(nestedRec, elements);
   }
   }
 }
@@ -3562,8 +3572,8 @@
   if (CGM.getCodeGenOpts().getDebugInfo() < codegenoptions::LimitedDebugInfo)
 return;
   const Namespace

r274165 - Switch to an RAII object to revert tentative parsing automatically.

2016-06-29 Thread Richard Smith via cfe-commits
Author: rsmith
Date: Wed Jun 29 16:06:51 2016
New Revision: 274165

URL: http://llvm.org/viewvc/llvm-project?rev=274165&view=rev
Log:
Switch to an RAII object to revert tentative parsing automatically.

Modified:
cfe/trunk/include/clang/Parse/Parser.h
cfe/trunk/lib/Parse/ParseTentative.cpp

Modified: cfe/trunk/include/clang/Parse/Parser.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Parse/Parser.h?rev=274165&r1=274164&r2=274165&view=diff
==
--- cfe/trunk/include/clang/Parse/Parser.h (original)
+++ cfe/trunk/include/clang/Parse/Parser.h Wed Jun 29 16:06:51 2016
@@ -715,6 +715,16 @@ private:
   assert(!isActive && "Forgot to call Commit or Revert!");
 }
   };
+  /// A TentativeParsingAction that automatically reverts in its destructor.
+  /// Useful for disambiguation parses that will always be reverted.
+  class RevertingTentativeParsingAction
+  : private Parser::TentativeParsingAction {
+  public:
+RevertingTentativeParsingAction(Parser &P)
+: Parser::TentativeParsingAction(P) {}
+~RevertingTentativeParsingAction() { Revert(); }
+  };
+
   class UnannotatedTentativeParsingAction;
 
   /// ObjCDeclContextSwitch - An object used to switch context from

Modified: cfe/trunk/lib/Parse/ParseTentative.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseTentative.cpp?rev=274165&r1=274164&r2=274165&view=diff
==
--- cfe/trunk/lib/Parse/ParseTentative.cpp (original)
+++ cfe/trunk/lib/Parse/ParseTentative.cpp Wed Jun 29 16:06:51 2016
@@ -125,10 +125,11 @@ bool Parser::isCXXSimpleDeclaration(bool
   // Ok, we have a simple-type-specifier/typename-specifier followed by a '(',
   // or an identifier which doesn't resolve as anything. We need tentative
   // parsing...
-
-  TentativeParsingAction PA(*this);
-  TPR = TryParseSimpleDeclaration(AllowForRangeDecl);
-  PA.Revert();
+ 
+  {
+RevertingTentativeParsingAction PA(*this);
+TPR = TryParseSimpleDeclaration(AllowForRangeDecl);
+  }
 
   // In case of an error, let the declaration parsing code handle it.
   if (TPR == TPResult::Error)
@@ -354,7 +355,7 @@ bool Parser::isCXXConditionDeclaration()
   // Ok, we have a simple-type-specifier/typename-specifier followed by a '('.
   // We need tentative parsing...
 
-  TentativeParsingAction PA(*this);
+  RevertingTentativeParsingAction PA(*this);
 
   // type-specifier-seq
   TryConsumeDeclarationSpecifier();
@@ -378,8 +379,6 @@ bool Parser::isCXXConditionDeclaration()
   TPR = TPResult::False;
   }
 
-  PA.Revert();
-
   assert(TPR == TPResult::True || TPR == TPResult::False);
   return TPR == TPResult::True;
 }
@@ -423,7 +422,7 @@ bool Parser::isCXXTypeId(TentativeCXXTyp
   // Ok, we have a simple-type-specifier/typename-specifier followed by a '('.
   // We need tentative parsing...
 
-  TentativeParsingAction PA(*this);
+  RevertingTentativeParsingAction PA(*this);
 
   // type-specifier-seq
   TryConsumeDeclarationSpecifier();
@@ -456,8 +455,6 @@ bool Parser::isCXXTypeId(TentativeCXXTyp
   TPR = TPResult::False;
   }
 
-  PA.Revert();
-
   assert(TPR == TPResult::True || TPR == TPResult::False);
   return TPR == TPResult::True;
 }
@@ -508,7 +505,7 @@ Parser::isCXX11AttributeSpecifier(bool D
   if (!Disambiguate && !getLangOpts().ObjC1)
 return CAK_AttributeSpecifier;
 
-  TentativeParsingAction PA(*this);
+  RevertingTentativeParsingAction PA(*this);
 
   // Opening brackets were checked for above.
   ConsumeBracket();
@@ -520,8 +517,6 @@ Parser::isCXX11AttributeSpecifier(bool D
 bool IsAttribute = SkipUntil(tok::r_square);
 IsAttribute &= Tok.is(tok::r_square);
 
-PA.Revert();
-
 return IsAttribute ? CAK_AttributeSpecifier : 
CAK_InvalidAttributeSpecifier;
   }
 
@@ -542,8 +537,6 @@ Parser::isCXX11AttributeSpecifier(bool D
 // A lambda cannot end with ']]', and an attribute must.
 bool IsAttribute = Tok.is(tok::r_square);
 
-PA.Revert();
-
 if (IsAttribute)
   // Case 1: C++11 attribute.
   return CAK_AttributeSpecifier;
@@ -564,7 +557,6 @@ Parser::isCXX11AttributeSpecifier(bool D
   while (Tok.isNot(tok::r_square)) {
 if (Tok.is(tok::comma)) {
   // Case 1: Stray commas can only occur in attributes.
-  PA.Revert();
   return CAK_AttributeSpecifier;
 }
 
@@ -611,8 +603,6 @@ Parser::isCXX11AttributeSpecifier(bool D
 }
   }
 
-  PA.Revert();
-
   if (IsAttribute)
 // Case 1: C++11 statement attribute.
 return CAK_AttributeSpecifier;
@@ -1340,6 +1330,8 @@ Parser::isCXXDeclarationSpecifier(Parser
 *HasMissingTypename = true;
 return TPResult::Ambiguous;
   }
+
+  // FIXME: Fails to either revert or commit the tentative parse!
 } else {
   // Try to resolve the name. If it doesn't exist, assume it was
   // intended to name a type and keep disambi

Re: [cfe-dev] RFC: Default language standard mode policy

2016-06-29 Thread Hal Finkel via cfe-commits
- Original Message -

> From: "Richard Smith" 
> To: "Hal Finkel" 
> Cc: "Clang Dev" , "cfe-commits"
> 
> Sent: Wednesday, June 29, 2016 3:01:46 PM
> Subject: Re: [cfe-dev] RFC: Default language standard mode policy

> On Wed, Jun 29, 2016 at 12:55 PM, Hal Finkel via cfe-dev <
> cfe-...@lists.llvm.org > wrote:

> > > From: "Richard Smith via cfe-commits" <
> > > cfe-commits@lists.llvm.org
> > > >
> > 
> 
> > > To: "cfe-commits" < cfe-commits@lists.llvm.org >, "Clang Dev" <
> > > cfe-...@lists.llvm.org >
> > 
> 
> > > Sent: Wednesday, June 29, 2016 2:09:37 PM
> > 
> 
> > > Subject: RFC: Default language standard mode policy
> > 
> 

> > > Hi all!
> > 
> 

> > > I'd like to establish a policy for Clang's default language
> > > standard
> > > (if none is specified with -std), as follows:
> > 
> 

> > > Clang defaults to the most recent published standard for the
> > > selected
> > > language that it fully implements.
> > 
> 

> > > The practical impact of this is that clang++ will default to
> > > C++14
> > > for C++ compilations (for version 3.9 onwards) and will default
> > > to
> > > C++17 once our implementation support is complete and the
> > > standard
> > > is published (whichever happens later).
> > 
> 
> > I think that we need to include libc++ in this criteria as well. I
> > think we'll also need some CMake flags to adjust the default for
> > builds for systems on which this won't work.
> 
> Right, it doesn't make sense to change our default in a way that
> breaks use of the same version of libc++, or a supported version of
> libstdc++ (and we should establish how old a version of libstdc++ we
> support here).

> However, I don't immediately see that we need to wait for libc++ to
> be feature-complete before we enable the new standard in Clang. If
> that's what you're suggesting, can you expand on why? We already
> have the SD-6 feature test macros to test for implementation of
> specific features.
I think it is completely reasonable for an application to test __cplusplus for 
both language and library features. There are plenty of reasons why this won't 
always work on all systems, but I think we should endeavor to make this 
possible. I think that the SD-6 macros are useful is many circumstances, but I 
think it is unreasonable to expect users to detect all of the features they're 
using separately using SD-6 macros. 

We can't control what libstdc++ and others do, but if we can't even provide a 
complete implementation (including the library), I don't think we should switch 
the default. 

> > > I'd suggest that we apply the same policy for clang-cl, but if
> > > it's
> > > important that we enable a not-yet-fully-implemented standard for
> > > cl
> > > compatibility, that seems reasonable.
> > 
> 

> > > The question of whether the default mode for the GCC-compatible
> > > driver should be -std=gnuXXX or -std=cXXX is separate, but also
> > > likely worth discussing. Enabling GNU keywords by default is a
> > > very
> > > odd choice, and if we believe we can change our defaults without
> > > breaking the world then this seems like a good time to do so.
> > 
> 
> > Unfortunately, on many systems, some standard system headers won't
> > even parse without GNU extensions enabled. I think we'll need to
> > leave the GNU extensions on by default (at least for parsing system
> > headers).
> 
> Can you give an example? -std=c++11 works fine on a broad range of
> systems. Note that this is not about GNU *extensions*, which are
> enabled in both modes; it's about GNU *keywords* (and a small number
> of non-conforming extensions) -- in particular, the 'typeof' GNU
> keyword, and support for the asm keyword in C and the inline keyword
> in C89 (without __decoration__).

I recall having problems with this with fenv.h on various systems. They might 
just be older systems, however. We should check the current state of the world. 

Thanks again, 
Hal 

> > > I also intend to make explicit in our documentation that our
> > > -std=XXX
> > > flag enables the selected standard, *plus all relevant issues in
> > > Defect Report status from the relevant language committee* (it
> > > doesn't make sense to support a language without its bugfixes).
> > 
> 
> > +1
> 

> > -Hal
> 

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

> > --
> 

> > Hal Finkel
> 
> > Assistant Computational Scientist
> 
> > Leadership Computing Facility
> 
> > Argonne National Laboratory
> 

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

-- 

Hal Finkel 
Assistant Computational Scientist 
Leadership Computing Facility 
Argonne National Laboratory 
___
cfe-commits mailing list
cfe-c

r274168 - [ClangConfig] Copy ClangConfig.cmake to ${CMAKE_BINARY_DIR}/${CLANG_INSTALL_PACKAGE_DIR} instead of to ${CLANG_BINARY_DIR}/${CLANG_INSTALL_PACKAGE_DIR}.

2016-06-29 Thread Michael Gottesman via cfe-commits
Author: mgottesman
Date: Wed Jun 29 16:12:38 2016
New Revision: 274168

URL: http://llvm.org/viewvc/llvm-project?rev=274168&view=rev
Log:
[ClangConfig] Copy ClangConfig.cmake to 
${CMAKE_BINARY_DIR}/${CLANG_INSTALL_PACKAGE_DIR} instead of to 
${CLANG_BINARY_DIR}/${CLANG_INSTALL_PACKAGE_DIR}.

This is an obvious bug since ClangConfig.cmake looks for ClangTargets.cmake in
${CMAKE_CURRENT_LIST_DIR}. But ClangTargets.cmake is in
${CMAKE_BINARY_DIR}/${CLANG_INSTALL_PACKAGE_DIR}, so it will always fail with an
in tree build.

In the case where clang is built out of tree, this is still correct since
CMAKE_BINARY_DIR and CLANG_BINARY_DIR will be the same.

Modified:
cfe/trunk/cmake/modules/CMakeLists.txt

Modified: cfe/trunk/cmake/modules/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/modules/CMakeLists.txt?rev=274168&r1=274167&r2=274168&view=diff
==
--- cfe/trunk/cmake/modules/CMakeLists.txt (original)
+++ cfe/trunk/cmake/modules/CMakeLists.txt Wed Jun 29 16:12:38 2016
@@ -18,5 +18,5 @@ install(FILES
 # can build against a build directory of Clang more easily.
 configure_file(
   ${CMAKE_CURRENT_SOURCE_DIR}/ClangConfig.cmake
-  ${CLANG_BINARY_DIR}/${CLANG_INSTALL_PACKAGE_DIR}/ClangConfig.cmake
+  ${clang_cmake_builddir}/ClangConfig.cmake
   COPYONLY)


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


r274167 - Convert another case over to RevertingTentativeParsingAction.

2016-06-29 Thread Richard Smith via cfe-commits
Author: rsmith
Date: Wed Jun 29 16:12:37 2016
New Revision: 274167

URL: http://llvm.org/viewvc/llvm-project?rev=274167&view=rev
Log:
Convert another case over to RevertingTentativeParsingAction.

Modified:
cfe/trunk/lib/Parse/ParseTentative.cpp

Modified: cfe/trunk/lib/Parse/ParseTentative.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseTentative.cpp?rev=274167&r1=274166&r2=274167&view=diff
==
--- cfe/trunk/lib/Parse/ParseTentative.cpp (original)
+++ cfe/trunk/lib/Parse/ParseTentative.cpp Wed Jun 29 16:12:37 2016
@@ -1310,7 +1310,7 @@ Parser::isCXXDeclarationSpecifier(Parser
  Tok.getAnnotationRange(),
  SS);
 if (SS.getScopeRep() && SS.getScopeRep()->isDependent()) {
-  TentativeParsingAction PA(*this);
+  RevertingTentativeParsingAction PA(*this);
   ConsumeToken();
   ConsumeToken();
   bool isIdentifier = Tok.is(tok::identifier);
@@ -1318,7 +1318,6 @@ Parser::isCXXDeclarationSpecifier(Parser
   if (!isIdentifier)
 TPR = isCXXDeclarationSpecifier(BracedCastResult,
 HasMissingTypename);
-  PA.Revert();
 
   if (isIdentifier ||
   TPR == TPResult::True || TPR == TPResult::Error)
@@ -1330,8 +1329,6 @@ Parser::isCXXDeclarationSpecifier(Parser
 *HasMissingTypename = true;
 return TPResult::Ambiguous;
   }
-
-  // FIXME: Fails to either revert or commit the tentative parse!
 } else {
   // Try to resolve the name. If it doesn't exist, assume it was
   // intended to name a type and keep disambiguating.


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


r274169 - P0305R1: Parsing support for init-statements in 'if' and 'switch' statements.

2016-06-29 Thread Richard Smith via cfe-commits
Author: rsmith
Date: Wed Jun 29 16:17:59 2016
New Revision: 274169

URL: http://llvm.org/viewvc/llvm-project?rev=274169&view=rev
Log:
P0305R1: Parsing support for init-statements in 'if' and 'switch' statements.
No semantic analysis yet.

This is a pain to disambiguate correctly, because the parsing rules for the
declaration form of a condition and of an init-statement are quite different --
for a token sequence that looks like a declaration, we frequently need to
disambiguate all the way to the ')' or ';'.

We could do better here in some cases by stopping disambiguation once we've
decided whether we've got an expression or not (rather than keeping going until
we know whether it's an init-statement declaration or a condition declaration),
by unifying our parsing code for the two types of declaration and moving the
syntactic checks into Sema; if this has a measurable impact on parsing
performance, I'll look into that.

Added:
cfe/trunk/test/Parser/cxx1z-init-statement.cpp
Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/include/clang/Parse/Parser.h
cfe/trunk/include/clang/Sema/DeclSpec.h
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/Parse/ParseDecl.cpp
cfe/trunk/lib/Parse/ParseExprCXX.cpp
cfe/trunk/lib/Parse/ParseStmt.cpp
cfe/trunk/lib/Parse/ParseTentative.cpp
cfe/trunk/lib/Sema/SemaStmt.cpp
cfe/trunk/lib/Sema/SemaType.cpp
cfe/trunk/lib/Sema/TreeTransform.h
cfe/trunk/test/Parser/extra-semi.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=274169&r1=274168&r2=274169&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Wed Jun 29 16:17:59 
2016
@@ -7499,6 +7499,9 @@ def warn_empty_switch_body : Warning<
 def note_empty_body_on_separate_line : Note<
   "put the semicolon on a separate line to silence this warning">;
 
+def err_init_stmt_not_supported : Error<
+  "C++1z init-statement not yet supported">;
+
 def err_va_start_used_in_non_variadic_function : Error<
   "'va_start' used in function with fixed args">;
 def err_va_start_used_in_wrong_abi_function : Error<

Modified: cfe/trunk/include/clang/Parse/Parser.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Parse/Parser.h?rev=274169&r1=274168&r2=274169&view=diff
==
--- cfe/trunk/include/clang/Parse/Parser.h (original)
+++ cfe/trunk/include/clang/Parse/Parser.h Wed Jun 29 16:17:59 2016
@@ -1598,7 +1598,8 @@ private:
 
   
//======//
   // C++ if/switch/while condition expression.
-  Sema::ConditionResult ParseCXXCondition(SourceLocation Loc,
+  Sema::ConditionResult ParseCXXCondition(StmtResult *InitStmt,
+  SourceLocation Loc,
   Sema::ConditionKind CK);
 
   
//======//
@@ -1690,7 +1691,8 @@ private:
 unsigned ScopeFlags);
   void ParseCompoundStatementLeadingPragmas();
   StmtResult ParseCompoundStatementBody(bool isStmtExpr = false);
-  bool ParseParenExprOrCondition(Sema::ConditionResult &CondResult,
+  bool ParseParenExprOrCondition(StmtResult *InitStmt,
+ Sema::ConditionResult &CondResult,
  SourceLocation Loc,
  Sema::ConditionKind CK);
   StmtResult ParseIfStatement(SourceLocation *TrailingElseLoc);
@@ -1984,11 +1986,18 @@ private:
   /// the function returns true to let the declaration parsing code handle it.
   bool isCXXFunctionDeclarator(bool *IsAmbiguous = nullptr);
 
-  /// isCXXConditionDeclaration - Disambiguates between a declaration or an
-  /// expression for a condition of a if/switch/while/for statement.
-  /// If during the disambiguation process a parsing error is encountered,
-  /// the function returns true to let the declaration parsing code handle it.
-  bool isCXXConditionDeclaration();
+  struct ConditionDeclarationOrInitStatementState;
+  enum class ConditionOrInitStatement {
+Expression,///< Disambiguated as an expression (either kind).
+ConditionDecl, ///< Disambiguated as the declaration form of condition.
+InitStmtDecl,  ///< Disambiguated as a simple-declaration init-statement.
+Error  ///< Can't be any of the above!
+  };
+  /// \brief Disambiguates between the different kinds of things that can 
happen
+  /// after 'if (' or 'switch ('. This could be one of two different kinds of
+  /// declaration (depending on whether there is a ';' later) or an expression.
+  ConditionOrInitStatement
+  isCXXConditionDec

Re: [PATCH] D21834: Implementing 'If statement with Initializer'

2016-06-29 Thread Richard Smith via cfe-commits
rsmith requested changes to this revision.
rsmith added a comment.
This revision now requires changes to proceed.

The proposal has changed since the pre-meeting mailing, and now covers `switch` 
as well as `if`. You also need to handle the //expression-statement// form of 
//init-statement//.

As it happens, I've also been working on this proposal, and the bit that you're 
getting wrong here (the parsing side) is the part that I've finished. I've 
committed that as r274169; if you rebase your Sema changes on top of that (and 
add support for `switch`), we can get this change committed to finish off the 
implementation.

We'll also need some tests before this can be committed.

Thank you!



Comment at: lib/Parse/ParseStmt.cpp:1062-1075
@@ -1060,1 +1061,16 @@
 
+  if (CK == Sema::ConditionKind::IfWithInit &&
+  isForInitDeclarationWithSemi()) {  // if (int X = 4;
+// Parse declaration, which eats the ';'.
+ParsedAttributesWithRange attrs(AttrFactory);
+MaybeParseCXX11Attributes(attrs);
+
+SourceLocation DeclStart = Tok.getLocation(), DeclEnd;
+DeclGroupPtrTy DG = ParseSimpleDeclaration(
+  Declarator::ForContext, DeclEnd, attrs, false, nullptr);
+StmtResult InitStmt = Actions.ActOnDeclStmt(DG, DeclStart, 
Tok.getLocation());
+if (Init) *Init = InitStmt.get();
+
+ConsumeToken(); // Consume semi
+  }
+

We should try to only walk over the tokens once to identify whether this is a 
//condition// declaration, a //simple-declaration// of an //init-statement//, 
or an //expression//.


Comment at: lib/Parse/ParseTentative.cpp:77-79
@@ +76,5 @@
+  TentativeParsingAction PA(*this);
+  TPResult TPR = TryParseSimpleDeclaration(false);
+  if (Tok.isNot(tok::semi))
+TPR = TPResult::False;
+  PA.Revert();

This is not correct; `TryParseSimpleDeclaration` usually stops long before it 
reaches the end of the //simple-declaration//, so this will give false 
negatives in lots of cases.


http://reviews.llvm.org/D21834



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


Re: [PATCH] D21803: [libcxxabi] Provide a fallback __cxa_thread_atexit() implementation

2016-06-29 Thread Joerg Sonnenberger via cfe-commits
joerg added a subscriber: joerg.
joerg added a comment.

On the topic of __cxa_thread_atexit, was it ever specified how it interacts 
with things like thread cancellation?


http://reviews.llvm.org/D21803



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


Re: [PATCH] D21830: Remove -mrelax-all from Clang -O0

2016-06-29 Thread Joerg Sonnenberger via cfe-commits
On Wed, Jun 29, 2016 at 11:00:26AM -0400, Rafael Espíndola via cfe-commits 
wrote:
> We need to benchmark this to see if it still makes a difference.
> 
> My canonical test is the .s of a lto of clang.

That won't exercise it? Assembler sources are exempt from this.

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


Re: [cfe-dev] RFC: Default language standard mode policy

2016-06-29 Thread Joerg Sonnenberger via cfe-commits
On Wed, Jun 29, 2016 at 12:09:37PM -0700, Richard Smith via cfe-dev wrote:
> Hi all!
> 
> I'd like to establish a policy for Clang's default language standard (if
> none is specified with -std), as follows:
> 
>   Clang defaults to the most recent published standard for the selected
> language that it fully implements.
> 
> The practical impact of this is that clang++ will default to C++14 for C++
> compilations (for version 3.9 onwards) and will default to C++17 once our
> implementation support is complete and the standard is published (whichever
> happens later).

I don't have a problem with the C11 default, because the language impact
is minimal. That's quite different from C++ though and I am very
reluctant to update the default language even to C++11. There is a lot
of code in the wild that doesn't compile anymore due to stupid changes
like user-defined string literals or the narrowing (warning) changes.
Even worse are the nothrow changes for destructors, which silently break
valid C++03 code.

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


r274180 - [ClangConfig] Store all of the targets exported in the variable CLANG_EXPORTED_TARGETS.

2016-06-29 Thread Michael Gottesman via cfe-commits
Author: mgottesman
Date: Wed Jun 29 16:59:23 2016
New Revision: 274180

URL: http://llvm.org/viewvc/llvm-project?rev=274180&view=rev
Log:
[ClangConfig] Store all of the targets exported in the variable 
CLANG_EXPORTED_TARGETS.

Modified:
cfe/trunk/cmake/modules/CMakeLists.txt
cfe/trunk/cmake/modules/ClangConfig.cmake.in

Modified: cfe/trunk/cmake/modules/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/modules/CMakeLists.txt?rev=274180&r1=274179&r2=274180&view=diff
==
--- cfe/trunk/cmake/modules/CMakeLists.txt (original)
+++ cfe/trunk/cmake/modules/CMakeLists.txt Wed Jun 29 16:59:23 2016
@@ -28,7 +28,7 @@ foreach(p ${_count})
   set(CLANG_CONFIG_CODE "${CLANG_CONFIG_CODE}
 get_filename_component(CLANG_INSTALL_PREFIX \"\${CLANG_INSTALL_PREFIX}\" 
PATH)")
 endforeach(p)
-set(CLANG_CONFIG_CMAKE_DIR 
"\${CLANG_INSTALL_PREFIX}/\${CLANG_INSTALL_PACKAGE_DIR}")
+set(CLANG_CONFIG_CMAKE_DIR 
"\${CLANG_INSTALL_PREFIX}/${CLANG_INSTALL_PACKAGE_DIR}")
 set(CLANG_CONFIG_EXPORTS_FILE "\${CLANG_CMAKE_DIR}/ClangTargets.cmake")
 configure_file(
   ${CMAKE_CURRENT_SOURCE_DIR}/ClangConfig.cmake.in

Modified: cfe/trunk/cmake/modules/ClangConfig.cmake.in
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/modules/ClangConfig.cmake.in?rev=274180&r1=274179&r2=274180&view=diff
==
--- cfe/trunk/cmake/modules/ClangConfig.cmake.in (original)
+++ cfe/trunk/cmake/modules/ClangConfig.cmake.in Wed Jun 29 16:59:23 2016
@@ -8,6 +8,7 @@ find_package(LLVM REQUIRED CONFIG)
 
 @CLANG_CONFIG_CODE@
 
+set(CLANG_EXPORTED_TARGETS "@CLANG_EXPORTS@")
 set(CLANG_CMAKE_DIR "@CLANG_CONFIG_CMAKE_DIR@")
 
 # Provide all our library targets to users.


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


r274177 - [ClangConfig] Follow LLVM's example and only install Clang{Config, Target}.cmake when LLVM_INSTALL_TOOLCHAIN_ONLY is disabled.

2016-06-29 Thread Michael Gottesman via cfe-commits
Author: mgottesman
Date: Wed Jun 29 16:59:15 2016
New Revision: 274177

URL: http://llvm.org/viewvc/llvm-project?rev=274177&view=rev
Log:
[ClangConfig] Follow LLVM's example and only install Clang{Config,Target}.cmake 
when LLVM_INSTALL_TOOLCHAIN_ONLY is disabled.

Modified:
cfe/trunk/cmake/modules/CMakeLists.txt

Modified: cfe/trunk/cmake/modules/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/modules/CMakeLists.txt?rev=274177&r1=274176&r2=274177&view=diff
==
--- cfe/trunk/cmake/modules/CMakeLists.txt (original)
+++ cfe/trunk/cmake/modules/CMakeLists.txt Wed Jun 29 16:59:15 2016
@@ -19,8 +19,10 @@ configure_file(
   ${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/ClangConfig.cmake
   @ONLY)
 
-install(EXPORT ClangTargets DESTINATION ${CLANG_INSTALL_PACKAGE_DIR})
+if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY)
+  install(EXPORT ClangTargets DESTINATION ${CLANG_INSTALL_PACKAGE_DIR})
 
-install(FILES
-  ${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/ClangConfig.cmake
-  DESTINATION ${CLANG_INSTALL_PACKAGE_DIR})
+  install(FILES
+${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/ClangConfig.cmake
+DESTINATION ${CLANG_INSTALL_PACKAGE_DIR})
+endif()


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


r274178 - [ClangConfig] Instead of hard coding the ClangTargets location to /ClangTargets.cmake, follow LLVM's example and use a pre-computed cmake variable @CLANG_CONFIG_EXPORTS_FILE@.

2016-06-29 Thread Michael Gottesman via cfe-commits
Author: mgottesman
Date: Wed Jun 29 16:59:19 2016
New Revision: 274178

URL: http://llvm.org/viewvc/llvm-project?rev=274178&view=rev
Log:
[ClangConfig] Instead of hard coding the ClangTargets location to 
/ClangTargets.cmake, follow LLVM's example and use a pre-computed cmake 
variable @CLANG_CONFIG_EXPORTS_FILE@.

This just makes ClangConfig more consistent with LLVMConfig.

Modified:
cfe/trunk/cmake/modules/CMakeLists.txt
cfe/trunk/cmake/modules/ClangConfig.cmake.in

Modified: cfe/trunk/cmake/modules/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/modules/CMakeLists.txt?rev=274178&r1=274177&r2=274178&view=diff
==
--- cfe/trunk/cmake/modules/CMakeLists.txt (original)
+++ cfe/trunk/cmake/modules/CMakeLists.txt Wed Jun 29 16:59:19 2016
@@ -8,12 +8,26 @@ get_property(CLANG_EXPORTS GLOBAL PROPER
 export(TARGETS ${CLANG_EXPORTS} FILE 
${clang_cmake_builddir}/ClangTargets.cmake)
 
 # Generate ClangConfig.cmake for the build tree.
+set(CLANG_CONFIG_CMAKE_DIR "${clang_cmake_builddir}")
+set(CLANG_CONFIG_EXPORTS_FILE "${clang_cmake_builddir}/ClangTargets.cmake")
 configure_file(
   ${CMAKE_CURRENT_SOURCE_DIR}/ClangConfig.cmake.in
   ${clang_cmake_builddir}/ClangConfig.cmake
   @ONLY)
 
 # Generate ClangConfig.cmake for the install tree.
+set(CLANG_CONFIG_CODE "
+# Compute the installation prefix from this LLVMConfig.cmake file location.
+get_filename_component(CLANG_INSTALL_PREFIX \"\${CMAKE_CURRENT_LIST_FILE}\" 
PATH)")
+# Construct the proper number of get_filename_component(... PATH)
+# calls to compute the installation prefix.
+string(REGEX REPLACE "/" ";" _count "${CLANG_INSTALL_PACKAGE_DIR}")
+foreach(p ${_count})
+  set(CLANG_CONFIG_CODE "${CLANG_CONFIG_CODE}
+get_filename_component(CLANG_INSTALL_PREFIX \"\${CLANG_INSTALL_PREFIX}\" 
PATH)")
+endforeach(p)
+set(CLANG_CONFIG_CMAKE_DIR 
"\${CLANG_INSTALL_PREFIX}/\${CLANG_INSTALL_PACKAGE_DIR}")
+set(CLANG_CONFIG_EXPORTS_FILE "\${CLANG_CMAKE_DIR}/ClangTargets.cmake")
 configure_file(
   ${CMAKE_CURRENT_SOURCE_DIR}/ClangConfig.cmake.in
   ${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/ClangConfig.cmake

Modified: cfe/trunk/cmake/modules/ClangConfig.cmake.in
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/modules/ClangConfig.cmake.in?rev=274178&r1=274177&r2=274178&view=diff
==
--- cfe/trunk/cmake/modules/ClangConfig.cmake.in (original)
+++ cfe/trunk/cmake/modules/ClangConfig.cmake.in Wed Jun 29 16:59:19 2016
@@ -6,5 +6,9 @@
 
 find_package(LLVM REQUIRED CONFIG)
 
+@CLANG_CONFIG_CODE@
+
+set(CLANG_CMAKE_DIR "@CLANG_CONFIG_CMAKE_DIR@")
+
 # Provide all our library targets to users.
-include("${CMAKE_CURRENT_LIST_DIR}/ClangTargets.cmake")
+include("@CLANG_CONFIG_EXPORTS_FILE@")


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


r274179 - [ClangConfig] Unset some variables after we are done using them to configure ClangConfig.cmake.in files.

2016-06-29 Thread Michael Gottesman via cfe-commits
Author: mgottesman
Date: Wed Jun 29 16:59:20 2016
New Revision: 274179

URL: http://llvm.org/viewvc/llvm-project?rev=274179&view=rev
Log:
[ClangConfig] Unset some variables after we are done using them to configure 
ClangConfig.cmake.in files.

This ensures that the values do not bleed over in between computations. It may
make sense in the future to just refactor this code into functions to provide
"true scoping".

Modified:
cfe/trunk/cmake/modules/CMakeLists.txt

Modified: cfe/trunk/cmake/modules/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/modules/CMakeLists.txt?rev=274179&r1=274178&r2=274179&view=diff
==
--- cfe/trunk/cmake/modules/CMakeLists.txt (original)
+++ cfe/trunk/cmake/modules/CMakeLists.txt Wed Jun 29 16:59:20 2016
@@ -14,6 +14,8 @@ configure_file(
   ${CMAKE_CURRENT_SOURCE_DIR}/ClangConfig.cmake.in
   ${clang_cmake_builddir}/ClangConfig.cmake
   @ONLY)
+set(CLANG_CONFIG_CMAKE_DIR)
+set(CLANG_CONFIG_EXPORTS_FILE)
 
 # Generate ClangConfig.cmake for the install tree.
 set(CLANG_CONFIG_CODE "
@@ -32,6 +34,9 @@ configure_file(
   ${CMAKE_CURRENT_SOURCE_DIR}/ClangConfig.cmake.in
   ${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/ClangConfig.cmake
   @ONLY)
+set(CLANG_CONFIG_CODE)
+set(CLANG_CONFIG_CMAKE_DIR)
+set(CLANG_CONFIG_EXPORTS_FILE)
 
 if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY)
   install(EXPORT ClangTargets DESTINATION ${CLANG_INSTALL_PACKAGE_DIR})


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


r274176 - [cmake] Instead of just copying ClangConfig.cmake, configure it using ClangConfig.cmake.in.

2016-06-29 Thread Michael Gottesman via cfe-commits
Author: mgottesman
Date: Wed Jun 29 16:59:14 2016
New Revision: 274176

URL: http://llvm.org/viewvc/llvm-project?rev=274176&view=rev
Log:
[cmake] Instead of just copying ClangConfig.cmake, configure it using 
ClangConfig.cmake.in.

This will allow for cmake to expand variables in ClangConfig.cmake for
downstream users.

Added:
cfe/trunk/cmake/modules/ClangConfig.cmake.in
  - copied, changed from r274169, cfe/trunk/cmake/modules/ClangConfig.cmake
Removed:
cfe/trunk/cmake/modules/ClangConfig.cmake
Modified:
cfe/trunk/cmake/modules/CMakeLists.txt

Modified: cfe/trunk/cmake/modules/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/modules/CMakeLists.txt?rev=274176&r1=274175&r2=274176&view=diff
==
--- cfe/trunk/cmake/modules/CMakeLists.txt (original)
+++ cfe/trunk/cmake/modules/CMakeLists.txt Wed Jun 29 16:59:14 2016
@@ -3,20 +3,24 @@
 # the usual CMake convention seems to be ${Project}Targets.cmake.
 set(CLANG_INSTALL_PACKAGE_DIR lib${LLVM_LIBDIR_SUFFIX}/cmake/clang)
 set(clang_cmake_builddir "${CMAKE_BINARY_DIR}/${CLANG_INSTALL_PACKAGE_DIR}")
+
 get_property(CLANG_EXPORTS GLOBAL PROPERTY CLANG_EXPORTS)
 export(TARGETS ${CLANG_EXPORTS} FILE 
${clang_cmake_builddir}/ClangTargets.cmake)
 
-# Install a /lib/cmake/clang/ClangConfig.cmake file so that
-# find_package(Clang) works. Install the target list with it.
+# Generate ClangConfig.cmake for the build tree.
+configure_file(
+  ${CMAKE_CURRENT_SOURCE_DIR}/ClangConfig.cmake.in
+  ${clang_cmake_builddir}/ClangConfig.cmake
+  @ONLY)
+
+# Generate ClangConfig.cmake for the install tree.
+configure_file(
+  ${CMAKE_CURRENT_SOURCE_DIR}/ClangConfig.cmake.in
+  ${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/ClangConfig.cmake
+  @ONLY)
+
 install(EXPORT ClangTargets DESTINATION ${CLANG_INSTALL_PACKAGE_DIR})
 
 install(FILES
-  ${CMAKE_CURRENT_SOURCE_DIR}/ClangConfig.cmake
+  ${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/ClangConfig.cmake
   DESTINATION ${CLANG_INSTALL_PACKAGE_DIR})
-
-# Also copy ClangConfig.cmake to the build directory so that dependent projects
-# can build against a build directory of Clang more easily.
-configure_file(
-  ${CMAKE_CURRENT_SOURCE_DIR}/ClangConfig.cmake
-  ${clang_cmake_builddir}/ClangConfig.cmake
-  COPYONLY)

Removed: cfe/trunk/cmake/modules/ClangConfig.cmake
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/modules/ClangConfig.cmake?rev=274175&view=auto
==
--- cfe/trunk/cmake/modules/ClangConfig.cmake (original)
+++ cfe/trunk/cmake/modules/ClangConfig.cmake (removed)
@@ -1,10 +0,0 @@
-# This file allows users to call find_package(Clang) and pick up our targets.
-
-# Clang doesn't have any CMake configuration settings yet because it mostly
-# uses LLVM's. When it does, we should move this file to ClangConfig.cmake.in
-# and call configure_file() on it.
-
-find_package(LLVM REQUIRED CONFIG)
-
-# Provide all our library targets to users.
-include("${CMAKE_CURRENT_LIST_DIR}/ClangTargets.cmake")

Copied: cfe/trunk/cmake/modules/ClangConfig.cmake.in (from r274169, 
cfe/trunk/cmake/modules/ClangConfig.cmake)
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/modules/ClangConfig.cmake.in?p2=cfe/trunk/cmake/modules/ClangConfig.cmake.in&p1=cfe/trunk/cmake/modules/ClangConfig.cmake&r1=274169&r2=274176&rev=274176&view=diff
==
(empty)


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


Re: [cfe-dev] RFC: Default language standard mode policy

2016-06-29 Thread Hal Finkel via cfe-commits
- Original Message -

> From: "Hal Finkel via cfe-dev" 
> To: "Richard Smith" 
> Cc: "Clang Dev" , "cfe-commits"
> 
> Sent: Wednesday, June 29, 2016 4:17:18 PM
> Subject: Re: [cfe-dev] RFC: Default language standard mode policy

> - Original Message -

> > From: "Richard Smith" 
> 
> > To: "Hal Finkel" 
> 
> > Cc: "Clang Dev" , "cfe-commits"
> > 
> 
> > Sent: Wednesday, June 29, 2016 3:01:46 PM
> 
> > Subject: Re: [cfe-dev] RFC: Default language standard mode policy
> 

> > On Wed, Jun 29, 2016 at 12:55 PM, Hal Finkel via cfe-dev <
> > cfe-...@lists.llvm.org > wrote:
> 

> > > > From: "Richard Smith via cfe-commits" <
> > > > cfe-commits@lists.llvm.org
> > > > >
> > > 
> > 
> 
> > > > To: "cfe-commits" < cfe-commits@lists.llvm.org >, "Clang Dev" <
> > > > cfe-...@lists.llvm.org >
> > > 
> > 
> 
> > > > Sent: Wednesday, June 29, 2016 2:09:37 PM
> > > 
> > 
> 
> > > > Subject: RFC: Default language standard mode policy
> > > 
> > 
> 

> > > > Hi all!
> > > 
> > 
> 

> > > > I'd like to establish a policy for Clang's default language
> > > > standard
> > > > (if none is specified with -std), as follows:
> > > 
> > 
> 

> > > > Clang defaults to the most recent published standard for the
> > > > selected
> > > > language that it fully implements.
> > > 
> > 
> 

> > > > The practical impact of this is that clang++ will default to
> > > > C++14
> > > > for C++ compilations (for version 3.9 onwards) and will default
> > > > to
> > > > C++17 once our implementation support is complete and the
> > > > standard
> > > > is published (whichever happens later).
> > > 
> > 
> 
> > > I think that we need to include libc++ in this criteria as well.
> > > I
> > > think we'll also need some CMake flags to adjust the default for
> > > builds for systems on which this won't work.
> > 
> 
> > Right, it doesn't make sense to change our default in a way that
> > breaks use of the same version of libc++, or a supported version of
> > libstdc++ (and we should establish how old a version of libstdc++
> > we
> > support here).
> 

> > However, I don't immediately see that we need to wait for libc++ to
> > be feature-complete before we enable the new standard in Clang. If
> > that's what you're suggesting, can you expand on why? We already
> > have the SD-6 feature test macros to test for implementation of
> > specific features.
> 
> I think it is completely reasonable for an application to test
> __cplusplus for both language and library features. There are plenty
> of reasons why this won't always work on all systems, but I think we
> should endeavor to make this possible. I think that the SD-6 macros
> are useful is many circumstances, but I think it is unreasonable to
> expect users to detect all of the features they're using separately
> using SD-6 macros.

> We can't control what libstdc++ and others do, but if we can't even
> provide a complete implementation (including the library), I don't
> think we should switch the default.

> > > > I'd suggest that we apply the same policy for clang-cl, but if
> > > > it's
> > > > important that we enable a not-yet-fully-implemented standard
> > > > for
> > > > cl
> > > > compatibility, that seems reasonable.
> > > 
> > 
> 

> > > > The question of whether the default mode for the GCC-compatible
> > > > driver should be -std=gnuXXX or -std=cXXX is separate, but also
> > > > likely worth discussing. Enabling GNU keywords by default is a
> > > > very
> > > > odd choice, and if we believe we can change our defaults
> > > > without
> > > > breaking the world then this seems like a good time to do so.
> > > 
> > 
> 
> > > Unfortunately, on many systems, some standard system headers
> > > won't
> > > even parse without GNU extensions enabled. I think we'll need to
> > > leave the GNU extensions on by default (at least for parsing
> > > system
> > > headers).
> > 
> 
> > Can you give an example? -std=c++11 works fine on a broad range of
> > systems. Note that this is not about GNU *extensions*, which are
> > enabled in both modes; it's about GNU *keywords* (and a small
> > number
> > of non-conforming extensions) -- in particular, the 'typeof' GNU
> > keyword, and support for the asm keyword in C and the inline
> > keyword
> > in C89 (without __decoration__).
> 

> I recall having problems with this with fenv.h on various systems.
> They might just be older systems, however. We should check the
> current state of the world.

A quick data point: 

$ rpm -q --whatprovides /usr/include/aio.h 
glibc-headers-2.12-1.166.el6_7.7.ppc64 
$ clang -fsyntax-only -std=c11 -w /usr/include/aio.h 
/usr/include/aio.h:42:19: error: field has incomplete type 'struct sigevent' 
struct sigevent aio_sigevent; /* Signal number and value. */ 
^ 
/usr/include/aio.h:42:10: note: forward declaration of 'struct sigevent' 
struct sigevent aio_sigevent; /* Signal number and value. */ 
^ 
1 error generated. 
$ clang -fsyntax-only -std=gnu11 -w /usr/include/aio.h 
(works) 

$ rpm -q --whatprovides /usr/includ

Re: [cfe-dev] RFC: Default language standard mode policy

2016-06-29 Thread Richard Smith via cfe-commits
On Wed, Jun 29, 2016 at 2:48 PM, Joerg Sonnenberger via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Wed, Jun 29, 2016 at 12:09:37PM -0700, Richard Smith via cfe-dev wrote:
> > Hi all!
> >
> > I'd like to establish a policy for Clang's default language standard (if
> > none is specified with -std), as follows:
> >
> >   Clang defaults to the most recent published standard for the selected
> > language that it fully implements.
> >
> > The practical impact of this is that clang++ will default to C++14 for
> C++
> > compilations (for version 3.9 onwards) and will default to C++17 once our
> > implementation support is complete and the standard is published
> (whichever
> > happens later).
>
> I don't have a problem with the C11 default, because the language impact
> is minimal. That's quite different from C++ though and I am very
> reluctant to update the default language even to C++11. There is a lot
> of code in the wild that doesn't compile anymore due to stupid changes
> like user-defined string literals or the narrowing (warning) changes.
> Even worse are the nothrow changes for destructors, which silently break
> valid C++03 code.


Yes, those are real problems, but it's not reasonable for us to keep the
default at C++98/03 forever. GCC has already taken the plunge here, so a
lot of open-source code that doesn't work in C++11 onwards already
explicitly specifies an appropriate -std= flag.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


  1   2   >