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

[Keno Fischer via cfe-commits]

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

Address review comments. I had to add a special case to 
checkNewAttributesAfterDef if we want to use attribute merging for explicit 
template instantiations, because the Microsoft ABI allows adding dll attributes 
to the explicit template definition, but not the declaration (which clang 
considers to be the record's definition).


Repository:
  rL LLVM

http://reviews.llvm.org/D13330

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

Index: test/SemaCXX/unique-instantiations.cpp
===
--- /dev/null
+++ test/SemaCXX/unique-instantiations.cpp
@@ -0,0 +1,18 @@
+// RUN: %clang -cc1 -std=c++11 -fsyntax-only -verify %s
+
+template < typename T > struct foo1 { };
+template struct __attribute__((unique_instantiation)) foo1; // expected-error{{requires a previous declaration}}
+
+template < typename T > struct foo2 { };
+extern template struct foo2; // expected-note{{previous explicit instantiation is here}}
+template struct __attribute__((unique_instantiation)) foo2; // expected-error{{must be specified on all declarations}}
+
+template < typename T > struct foo3 { };
+extern template struct __attribute__((unique_instantiation)) foo3; // expected-note{{previous explicit instantiation is here}}
+extern template struct foo3; // expected-error{{must be specified on all declarations}}
+
+template < typename T > struct __attribute__((unique_instantiation)) foo4 { }; // expected-error{{only applies to explicit template declarations or definitions}}
+
+template < typename T > struct foo5 { };
+extern template struct  __attribute__((unique_instantiation)) foo5; // expected-note{{previous explicit instantiation is here}}
+template struct foo5; // expected-error{{must be specified on all declarations}}
Index: test/CodeGenCXX/unique-instantiation.cpp
===
--- /dev/null
+++ test/CodeGenCXX/unique-instantiation.cpp
@@ -0,0 +1,15 @@
+// RUN: %clang -std=c++11 -emit-llvm -O0 -c -S -o - %s | FileCheck %s
+
+template < typename T > struct foo {
+T x;
+T getX() { return x; }
+};
+// CHECK: define i32 @_ZN3fooIiE4getXEv
+// CHECK-NOT: define weak_odr i32 @_ZN3fooIiE4getXEv
+extern template struct __attribute__((unique_instantiation)) foo;
+template struct __attribute__((unique_instantiation)) foo;
+
+int footest() {
+auto var = foo{5};
+return var.getX();
+}
Index: lib/Sema/SemaTemplate.cpp
===
--- lib/Sema/SemaTemplate.cpp
+++ lib/Sema/SemaTemplate.cpp
@@ -7321,20 +7321,22 @@
   Specialization->setExternLoc(ExternLoc);
   Specialization->setTemplateKeywordLoc(TemplateLoc);
   Specialization->setRBraceLoc(SourceLocation());
+  Specialization->setTemplateSpecializationKind(TSK);
 
   if (Attr)
 ProcessDeclAttributeList(S, Specialization, Attr);
 
+  if (PrevDecl)
+mergeDeclAttributes(Specialization, PrevDecl);
+
   // Add the explicit instantiation into its lexical context. However,
   // since explicit instantiations are never found by name lookup, we
   // just put it into the declaration context directly.
   Specialization->setLexicalDeclContext(CurContext);
   CurContext->addDecl(Specialization);
 
   // Syntax is now OK, so return if it has no other effect on semantics.
   if (HasNoEffect) {
-// Set the template specialization kind.
-Specialization->setTemplateSpecializationKind(TSK);
 return Specialization;
   }
 
@@ -7388,14 +7390,7 @@
   }
 }
 
-// Set the template specialization kind. Make sure it is set before
-// instantiating the members which will trigger ASTConsumer callbacks.
-Specialization->setTemplateSpecializationKind(TSK);
 InstantiateClassTemplateSpecializationMembers(TemplateNameLoc, Def, TSK);
-  } else {
-
-// Set the template specialization kind.
-Specialization->setTemplateSpecializationKind(TSK);
   }
 
   return Specialization;
Index: lib/Sema/SemaDeclAttr.cpp
===
--- lib/Sema/SemaDeclAttr.cpp
+++ lib/Sema/SemaDeclAttr.cpp
@@ -4529,6 +4529,29 @@
 Attr.getAttributeSpellingListIndex()));
 }
 
+
+static void handleUniqueInstantiation(Sema &S, Decl *D,
+  const AttributeList &Attr) {
+  if (auto *CTSD = dyn_cast(D)) {
+// If this is an explicit instantiation definition. Check that it was preceeded
+// by an ExplicitInstantiationDeclaration. Note, this
+// requirement encourages a programming style that uses unique explicit
+// instantiation declarations

Re: [PATCH] D13340: Add support for the new mips-mti-linux toolchain.

[Simon Atanasyan via cfe-commits]

atanasyan added inline comments.


Comment at: lib/Driver/Driver.cpp:2225
@@ -2219,1 +2224,3 @@
 TC = new toolchains::HexagonToolChain(*this, Target, Args);
+  else if ((Target.getVendor() == llvm::Triple::MipsTechnologies) &&
+   !Target.hasEnvironment())

Now I try to redesign Codescape toolchain support in the Clang driver. I 
consider to use a separate toolchain class like your `MipsToolChain` and I name 
it `CodeScapeMtiToolChain`. If I be able to join support for both MIT and IMG 
toolchains in the single class, I will rename it to `CodeScapeToolChain`.

Will this non-GNU toolchain have a personal name like CodeScape? If not I am 
okay with `MipsNonGNUToolChain`.


http://reviews.llvm.org/D13340



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

Re: [Patch][OpenCL] Custom atomic Builtin check ignores address space of a non-atomic pointer

[Pekka Jääskeläinen via cfe-commits]

LGTM.

Related to it:
There has been so many getPointerTo() issues with multi-AS in the
past that I wonder if it'd be time to drop the default value from it,
and go through all the places where it's called with the default AS, thus
breaking multi-AS.  Might be a worthwhile job to do at some point.

On 09/30/2015 01:23 PM, Anastasia Stulova via cfe-commits wrote:

Hi all,

Address spaces are not handled in custom semantic checks of atomic Builtins.

If there are two pointers passed to the Builtin, it doesn't allow the second

(non-atomic) one to be qualified with an address space.

This patch removed this restriction by recording the address space of the

passed pointers while checking its type correctness.

Currently, the following code:

_Atomic int __attribute__((address_space(1))) *A;

int __attribute__((address_space(2))) *B;

...

... = __c11_atomic_compare_exchange_strong(A, B, 1, memory_order_seq_cst,
memory_order_seq_cst);

fails to compile with an error:

"passing '__attribute__((address_space(2))) int *' to parameter of type 'int
*' changes address space of pointer".

Please, review the attached fix for it!

Cheers,

Anastasia



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



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

Re: [PATCH] D13349: [OpenCL] Casting boolean to an integer vector in OpenCL should set all bits if boolean is true

[Pekka Jääskeläinen via cfe-commits]

pekka.jaaskelainen added a subscriber: pekka.jaaskelainen.
pekka.jaaskelainen accepted this revision.
pekka.jaaskelainen added a reviewer: pekka.jaaskelainen.
This revision is now accepted and ready to land.


Comment at: lib/CodeGen/CGExprScalar.cpp:820
@@ -809,3 +819,3 @@
 QualType EltTy = DstType->getAs()->getElementType();
-llvm::Value *Elt = EmitScalarConversion(Src, SrcType, EltTy, Loc);
+llvm::Value *Elt = EmitScalarConversion(Src, SrcType, EltTy, Loc, 
CGF.getContext().getLangOpts().OpenCL);
 

Too long line here.


http://reviews.llvm.org/D13349



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

Re: [PATCH] D13340: Add support for the new mips-mti-linux toolchain.

[Vasileios Kalintiris via cfe-commits]

vkalintiris added inline comments.


Comment at: lib/Driver/Driver.cpp:2225
@@ -2219,1 +2224,3 @@
 TC = new toolchains::HexagonToolChain(*this, Target, Args);
+  else if ((Target.getVendor() == llvm::Triple::MipsTechnologies) &&
+   !Target.hasEnvironment())

atanasyan wrote:
> Now I try to redesign Codescape toolchain support in the Clang driver. I 
> consider to use a separate toolchain class like your `MipsToolChain` and I 
> name it `CodeScapeMtiToolChain`. If I be able to join support for both MIT 
> and IMG toolchains in the single class, I will rename it to 
> `CodeScapeToolChain`.
> 
> Will this non-GNU toolchain have a personal name like CodeScape? If not I am 
> okay with `MipsNonGNUToolChain`.
I thought about this and I don't believe that `MipsNonGNUToolChain` is a very 
good name. The main reason is that the last component of the entries under the 
sysroot, contain the name of the C library (or empty for GLIBC). We could 
easily have a toolchain with `mips-r2-hard{,-uClibc}` installed for 
`mips-mti-linux`.

What are your thoughts about the names: `MipsGCCToolChain`, 
`Mips{Clang,LLVM}ToolChain`, or `CodescapeGCCToolChain` and 
`CodescapeLLVMToolChain`?

Personally, I'd prefer the first pair of names. The reason is that with this 
choice we will be consistent in the naming of our classes. Also, it's clear 
that these are MIPS TCs and we have to consider that the Codescape name could 
change in the future (improbable but not impossible).

The `Mips{GCC,Clang/LLVM}Toolchain` name would specify whether we are going to 
use the files generated from a GCC or Clang installation. This way we could 
keep the existing functionality of the `Linux` class for older toolchains that 
will be deprecated/unused over time.


http://reviews.llvm.org/D13340



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

Re: [PATCH] D12854: [SourceManager] Support buffers that are not null-terminated

[Keno Fischer via cfe-commits]

loladiro added a comment.

Bump. Could somebody take a look at this?


Repository:
  rL LLVM

http://reviews.llvm.org/D12854



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

[PATCH] D13381: Handle trailing underscores on modernize-loop-convert variable namer.

[Angel Garcia via cfe-commits]

angelgarcia created this revision.
angelgarcia added a reviewer: klimek.
angelgarcia added subscribers: alexfh, cfe-commits.

https://llvm.org/bugs/show_bug.cgi?id=24961.

http://reviews.llvm.org/D13381

Files:
  clang-tidy/modernize/LoopConvertUtils.cpp
  test/clang-tidy/modernize-loop-convert-lowercase.cpp
  test/clang-tidy/modernize-loop-convert-uppercase.cpp

Index: test/clang-tidy/modernize-loop-convert-uppercase.cpp
===
--- test/clang-tidy/modernize-loop-convert-uppercase.cpp
+++ test/clang-tidy/modernize-loop-convert-uppercase.cpp
@@ -7,6 +7,7 @@
 const int N = 10;
 int ARR[N];
 int NUMS[N];
+int NUMS_[N];
 
 void naming() {
   for (int I = 0; I < N; ++I) {
@@ -23,6 +24,13 @@
   // CHECK-FIXES: for (auto & NUM : NUMS)
   // CHECK-FIXES-NEXT: printf("%d\n", NUM);
 
+  for (int I = 0; I < N; ++I) {
+printf("%d\n", NUMS_[I]);
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based for loop instead
+  // CHECK-FIXES: for (auto & NUM : NUMS_)
+  // CHECK-FIXES-NEXT: printf("%d\n", NUM);
+
   int NUM = 0;
   for (int I = 0; I < N; ++I) {
 printf("%d\n", NUMS[I] + NUM);
Index: test/clang-tidy/modernize-loop-convert-lowercase.cpp
===
--- test/clang-tidy/modernize-loop-convert-lowercase.cpp
+++ test/clang-tidy/modernize-loop-convert-lowercase.cpp
@@ -7,6 +7,7 @@
 const int n = 10;
 int arr[n];
 int nums[n];
+int nums_[n];
 
 void naming() {
   for (int i = 0; i < n; ++i) {
@@ -23,6 +24,13 @@
   // CHECK-FIXES: for (auto & num : nums)
   // CHECK-FIXES-NEXT: printf("%d\n", num);
 
+  for (int i = 0; i < n; ++i) {
+printf("%d\n", nums_[i]);
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based for loop instead
+  // CHECK-FIXES: for (auto & num : nums_)
+  // CHECK-FIXES-NEXT: printf("%d\n", num);
+
   int num = 0;
   for (int i = 0; i < n; ++i) {
 printf("%d\n", nums[i] + num);
Index: clang-tidy/modernize/LoopConvertUtils.cpp
===
--- clang-tidy/modernize/LoopConvertUtils.cpp
+++ clang-tidy/modernize/LoopConvertUtils.cpp
@@ -819,6 +819,14 @@
   size_t Len = ContainerName.size();
   if (Len > 1 && ContainerName.endswith(Style == NS_UpperCase ? "S" : "s")) {
 IteratorName = ContainerName.substr(0, Len - 1);
+// Ej: (auto thing : things)
+if (!declarationExists(IteratorName))
+  return IteratorName;
+  }
+
+  if (Len > 2 && ContainerName.endswith(Style == NS_UpperCase ? "S_" : "s_")) {
+IteratorName = ContainerName.substr(0, Len - 2);
+// Ej: (auto thing : things_)
 if (!declarationExists(IteratorName))
   return IteratorName;
   }
@@ -835,14 +843,17 @@
   case NS_UpperCase:
 Elem = "ELEM";
   }
+  // Ej: (auto elem : container)
   if (!declarationExists(Elem))
 return Elem;
 
   IteratorName = AppendWithStyle(ContainerName, OldIndex->getName());
+  // Ej: (auto container_i : container)
   if (!declarationExists(IteratorName))
 return IteratorName;
 
   IteratorName = AppendWithStyle(ContainerName, Elem);
+  // Ej: (auto container_elem : container)
   if (!declarationExists(IteratorName))
 return IteratorName;
 


Index: test/clang-tidy/modernize-loop-convert-uppercase.cpp
===
--- test/clang-tidy/modernize-loop-convert-uppercase.cpp
+++ test/clang-tidy/modernize-loop-convert-uppercase.cpp
@@ -7,6 +7,7 @@
 const int N = 10;
 int ARR[N];
 int NUMS[N];
+int NUMS_[N];
 
 void naming() {
   for (int I = 0; I < N; ++I) {
@@ -23,6 +24,13 @@
   // CHECK-FIXES: for (auto & NUM : NUMS)
   // CHECK-FIXES-NEXT: printf("%d\n", NUM);
 
+  for (int I = 0; I < N; ++I) {
+printf("%d\n", NUMS_[I]);
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based for loop instead
+  // CHECK-FIXES: for (auto & NUM : NUMS_)
+  // CHECK-FIXES-NEXT: printf("%d\n", NUM);
+
   int NUM = 0;
   for (int I = 0; I < N; ++I) {
 printf("%d\n", NUMS[I] + NUM);
Index: test/clang-tidy/modernize-loop-convert-lowercase.cpp
===
--- test/clang-tidy/modernize-loop-convert-lowercase.cpp
+++ test/clang-tidy/modernize-loop-convert-lowercase.cpp
@@ -7,6 +7,7 @@
 const int n = 10;
 int arr[n];
 int nums[n];
+int nums_[n];
 
 void naming() {
   for (int i = 0; i < n; ++i) {
@@ -23,6 +24,13 @@
   // CHECK-FIXES: for (auto & num : nums)
   // CHECK-FIXES-NEXT: printf("%d\n", num);
 
+  for (int i = 0; i < n; ++i) {
+printf("%d\n", nums_[i]);
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based for loop instead
+  // CHECK-FIXES: for (auto & num : nums_)
+  // CHECK-FIXES-NEXT: printf("%d\n", num);
+
   int num = 0;
   for (int i = 0; i < n; ++i) {
 printf("%d\n", nums[i] + num);
Index: clang-tidy/modernize/LoopConvertUtils.cpp
===
--- clang-tidy/modernize/Loop

Re: [PATCH] D13340: Add support for the new mips-mti-linux toolchain.

[Simon Atanasyan via cfe-commits]

atanasyan added inline comments.


Comment at: lib/Driver/Driver.cpp:2225
@@ -2219,1 +2224,3 @@
 TC = new toolchains::HexagonToolChain(*this, Target, Args);
+  else if ((Target.getVendor() == llvm::Triple::MipsTechnologies) &&
+   !Target.hasEnvironment())

vkalintiris wrote:
> atanasyan wrote:
> > Now I try to redesign Codescape toolchain support in the Clang driver. I 
> > consider to use a separate toolchain class like your `MipsToolChain` and I 
> > name it `CodeScapeMtiToolChain`. If I be able to join support for both MIT 
> > and IMG toolchains in the single class, I will rename it to 
> > `CodeScapeToolChain`.
> > 
> > Will this non-GNU toolchain have a personal name like CodeScape? If not I 
> > am okay with `MipsNonGNUToolChain`.
> I thought about this and I don't believe that `MipsNonGNUToolChain` is a very 
> good name. The main reason is that the last component of the entries under 
> the sysroot, contain the name of the C library (or empty for GLIBC). We could 
> easily have a toolchain with `mips-r2-hard{,-uClibc}` installed for 
> `mips-mti-linux`.
> 
> What are your thoughts about the names: `MipsGCCToolChain`, 
> `Mips{Clang,LLVM}ToolChain`, or `CodescapeGCCToolChain` and 
> `CodescapeLLVMToolChain`?
> 
> Personally, I'd prefer the first pair of names. The reason is that with this 
> choice we will be consistent in the naming of our classes. Also, it's clear 
> that these are MIPS TCs and we have to consider that the Codescape name could 
> change in the future (improbable but not impossible).
> 
> The `Mips{GCC,Clang/LLVM}Toolchain` name would specify whether we are going 
> to use the files generated from a GCC or Clang installation. This way we 
> could keep the existing functionality of the `Linux` class for older 
> toolchains that will be deprecated/unused over time.
It sounds reasonable. Let's use MipsGCCToolChain and MipsLLVMToolChain.


http://reviews.llvm.org/D13340



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

Re: [PATCH] D13340: Add support for the new mips-mti-linux toolchain.

[Vasileios Kalintiris via cfe-commits]

vkalintiris updated this revision to Diff 36344.
vkalintiris added a comment.

1. s/MipsToolChain/MipsLLVMToolChain/
2. Change to the new getCompilerRT() return type
3. clang-format


http://reviews.llvm.org/D13340

Files:
  lib/Driver/Driver.cpp
  lib/Driver/ToolChain.cpp
  lib/Driver/ToolChains.cpp
  lib/Driver/ToolChains.h
  lib/Driver/Tools.cpp
  lib/Driver/Tools.h
  
test/Driver/Inputs/mips_mti_linux/lib/clang/3.8.0/mips-r2-hard-musl/lib/linux/libclang_rt.builtins-mips.a
  
test/Driver/Inputs/mips_mti_linux/lib/clang/3.8.0/mips-r2-hard-musl/lib/linux/libclang_rt.builtins-mips.so
  
test/Driver/Inputs/mips_mti_linux/lib/clang/3.8.0/mipsel-r2-hard-musl/lib/linux/libclang_rt.builtins-mipsel.a
  
test/Driver/Inputs/mips_mti_linux/lib/clang/3.8.0/mipsel-r2-hard-musl/lib/linux/libclang_rt.builtins-mipsel.so
  test/Driver/Inputs/mips_mti_linux/sysroot/mips-r2-hard-musl/usr/lib/crt1.o
  test/Driver/Inputs/mips_mti_linux/sysroot/mips-r2-hard-musl/usr/lib/crti.o
  test/Driver/Inputs/mips_mti_linux/sysroot/mips-r2-hard-musl/usr/lib/crtn.o
  test/Driver/Inputs/mips_mti_linux/sysroot/mipsel-r2-hard-musl/usr/lib/crt1.o
  test/Driver/Inputs/mips_mti_linux/sysroot/mipsel-r2-hard-musl/usr/lib/crti.o
  test/Driver/Inputs/mips_mti_linux/sysroot/mipsel-r2-hard-musl/usr/lib/crtn.o
  test/Driver/mips-mti-linux.c

Index: test/Driver/mips-mti-linux.c
===
--- /dev/null
+++ test/Driver/mips-mti-linux.c
@@ -0,0 +1,42 @@
+// Check frontend and linker invocations on GPL-free MIPS toolchain.
+//
+// FIXME: Using --sysroot with this toolchain/triple isn't supported. We use
+//it here to test that we are producing the correct paths/flags.
+//Ideally, we'd like to have an --llvm-toolchain option similar to
+//the --gcc-toolchain one.
+
+// = Big-endian, mips32r2, hard float
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: --target=mips-mti-linux -mips32r2 -mhard-float \
+// RUN: --sysroot=%S/Inputs/mips_mti_linux/sysroot \
+// RUN:   | FileCheck --check-prefix=CHECK-BE-HF-32R2 %s
+//
+// CHECK-BE-HF-32R2: "{{.*}}clang" {{.*}} "-triple" "mips-mti-linux"
+// CHECK-BE-HF-32R2-SAME: "-fuse-init-array" "-target-cpu" "mips32r2"
+// CHECK-BE-HF-32R2-SAME: "-isysroot" "{{.*}}mips_mti_linux/sysroot"
+// CHECK-BE-HF-32R2: "lld" "-flavor" "gnu" "-target" "mips-mti-linux"
+// CHECK-BE-HF-32R2-SAME: "--sysroot=[[SYSROOT:[^"]+]]" {{.*}} "-dynamic-linker" "/lib/ld-musl-mips.so.1"
+// CHECK-BE-HF-32R2-SAME: "[[SYSROOT]]/mips-r2-hard-musl/usr/lib/crt1.o"
+// CHECK-BE-HF-32R2-SAME: "[[SYSROOT]]/mips-r2-hard-musl/usr/lib/crti.o"
+// CHECK-BE-HF-32R2-SAME: "-L[[SYSROOT]]/mips-r2-hard-musl/usr/lib"
+// CHECK-BE-HF-32R2-SAME: "{{[^"]+}}/mips-r2-hard-musl/lib/linux/libclang_rt.builtins-mips.a"
+// CHECK-BE-HF-32R2-SAME: "-lc"
+// CHECK-BE-HF-32R2-SAME: "[[SYSROOT]]/mips-r2-hard-musl/usr/lib/crtn.o"
+
+// = Little-endian, mips32r2, hard float
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: --target=mips-mti-linux -mips32r2 -EL -mhard-float \
+// RUN: --sysroot=%S/Inputs/mips_mti_linux/sysroot \
+// RUN:   | FileCheck --check-prefix=CHECK-LE-HF-32R2 %s
+//
+// CHECK-LE-HF-32R2: "{{.*}}clang" {{.*}} "-triple" "mipsel-mti-linux"
+// CHECK-LE-HF-32R2-SAME: "-fuse-init-array" "-target-cpu" "mips32r2"
+// CHECK-LE-HF-32R2-SAME: "-isysroot" "{{.*}}mips_mti_linux/sysroot"
+// CHECK-LE-HF-32R2: "lld" "-flavor" "gnu" "-target" "mipsel-mti-linux"
+// CHECK-LE-HF-32R2-SAME: "--sysroot=[[SYSROOT:[^"]+]]" {{.*}} "-dynamic-linker" "/lib/ld-musl-mipsel.so.1"
+// CHECK-LE-HF-32R2-SAME: "[[SYSROOT]]/mipsel-r2-hard-musl/usr/lib/crt1.o"
+// CHECK-LE-HF-32R2-SAME: "[[SYSROOT]]/mipsel-r2-hard-musl/usr/lib/crti.o"
+// CHECK-LE-HF-32R2-SAME: "-L[[SYSROOT]]/mipsel-r2-hard-musl/usr/lib"
+// CHECK-LE-HF-32R2-SAME: "{{[^"]+}}/mipsel-r2-hard-musl/lib/linux/libclang_rt.builtins-mipsel.a"
+// CHECK-LE-HF-32R2-SAME: "-lc"
+// CHECK-LE-HF-32R2-SAME: "[[SYSROOT]]/mipsel-r2-hard-musl/usr/lib/crtn.o"
Index: lib/Driver/Tools.h
===
--- lib/Driver/Tools.h
+++ lib/Driver/Tools.h
@@ -267,6 +267,8 @@
 void getMipsCPUAndABI(const llvm::opt::ArgList &Args,
   const llvm::Triple &Triple, StringRef &CPUName,
   StringRef &ABIName);
+std::string getMipsABILibSuffix(const llvm::opt::ArgList &Args,
+const llvm::Triple &Triple);
 bool hasMipsAbiArg(const llvm::opt::ArgList &Args, const char *Value);
 bool isUCLibc(const llvm::opt::ArgList &Args);
 bool isNaN2008(const llvm::opt::ArgList &Args, const llvm::Triple &Triple);
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -1077,6 +1077,16 @@
   // FIXME: Warn on inconsistent use of -march and -mabi.
 }
 
+std::string mips::getMipsABILibSuffix(const ArgList &Args,
+

Re: [PATCH] D12854: [SourceManager] Support buffers that are not null-terminated

[Manuel Klimek via cfe-commits]

klimek added a subscriber: klimek.
klimek added a comment.

Generally, I thought clang often relies on buffers being null terminated to 
speed up parse times. Usually the MemoryBuffers have an option to guarantee 
null-terminatedness (and copy if necessary)


Repository:
  rL LLVM

http://reviews.llvm.org/D12854



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

[PATCH] D13383: [clang] Add flag to DeclContext to distinguish between qualified and unqualified name lookups

[Eugene Leviant via cfe-commits]

evgeny777 created this revision.
evgeny777 added reviewers: aaron.ballman, klimek.
evgeny777 added subscribers: cfe-commits, dawn, KLapshin.

Hi, all!
Currently lldb evaluation of qualified global variables does not work properly.
I've created a revision addressing the issue, which is here: 
http://reviews.llvm.org/D13350

To fix the issue in lldb one has to distinguish between qualified and 
unqualified identifier lookups. In case of qualified lookup the identifier 
search scope is restricted to DeclContext::DeclKind (Namespace, 
TranslationUnit). For unqualified lookups scopes are being searched from bottom 
to top, until you get the first name match 


http://reviews.llvm.org/D13383

Files:
  clang/include/clang/AST/DeclBase.h
  clang/lib/Sema/SemaLookup.cpp

Index: clang/lib/Sema/SemaLookup.cpp
===
--- clang/lib/Sema/SemaLookup.cpp
+++ clang/lib/Sema/SemaLookup.cpp
@@ -204,6 +204,13 @@

UnqualUsingEntry::Comparator()));
 }
   };
+
+  class Deinitializer {
+std::function Deinit;
+  public:
+Deinitializer(const std::function& d): Deinit(d) {}
+~Deinitializer() { Deinit(); }
+  };
 }
 
 // Retrieve the set of identifier namespaces that correspond to a
@@ -1852,6 +1859,9 @@
  "Declaration context must already be complete!");
 
   // Perform qualified name lookup into the LookupCtx.
+  bool oldval = LookupCtx->setUseQualifiedLookup();
+  Deinitializer deinit([&]() { LookupCtx->setUseQualifiedLookup(oldval); });
+
   if (LookupDirect(*this, R, LookupCtx)) {
 R.resolveKind();
 if (isa(LookupCtx))
Index: clang/include/clang/AST/DeclBase.h
===
--- clang/include/clang/AST/DeclBase.h
+++ clang/include/clang/AST/DeclBase.h
@@ -1142,6 +1142,11 @@
   /// that are missing from the lookup table.
   mutable bool HasLazyExternalLexicalLookups : 1;
 
+  /// \brief If \c true, lookups should only return identifier from
+  /// DeclContext scope (for example TranslationUnit). Used in
+  /// LookupQualifiedName()
+  mutable bool UseQualifiedLookup : 1;
+
   /// \brief Pointer to the data structure used to lookup declarations
   /// within this context (or a DependentStoredDeclsMap if this is a
   /// dependent context). We maintain the invariant that, if the map
@@ -1176,6 +1181,7 @@
 ExternalVisibleStorage(false),
 NeedToReconcileExternalVisibleStorage(false),
 HasLazyLocalLexicalLookups(false), 
HasLazyExternalLexicalLookups(false),
+UseQualifiedLookup(false),
 LookupPtr(nullptr), FirstDecl(nullptr), LastDecl(nullptr) {}
 
 public:
@@ -1756,6 +1762,16 @@
  D == LastDecl);
   }
 
+  bool setUseQualifiedLookup(bool use = true) {
+bool old_value = UseQualifiedLookup;
+UseQualifiedLookup = use;
+return old_value;
+  }
+
+  bool shouldUseQualifiedLookup() const {
+return UseQualifiedLookup;
+  }
+
   static bool classof(const Decl *D);
   static bool classof(const DeclContext *D) { return true; }
 


Index: clang/lib/Sema/SemaLookup.cpp
===
--- clang/lib/Sema/SemaLookup.cpp
+++ clang/lib/Sema/SemaLookup.cpp
@@ -204,6 +204,13 @@
UnqualUsingEntry::Comparator()));
 }
   };
+
+  class Deinitializer {
+std::function Deinit;
+  public:
+Deinitializer(const std::function& d): Deinit(d) {}
+~Deinitializer() { Deinit(); }
+  };
 }
 
 // Retrieve the set of identifier namespaces that correspond to a
@@ -1852,6 +1859,9 @@
  "Declaration context must already be complete!");
 
   // Perform qualified name lookup into the LookupCtx.
+  bool oldval = LookupCtx->setUseQualifiedLookup();
+  Deinitializer deinit([&]() { LookupCtx->setUseQualifiedLookup(oldval); });
+
   if (LookupDirect(*this, R, LookupCtx)) {
 R.resolveKind();
 if (isa(LookupCtx))
Index: clang/include/clang/AST/DeclBase.h
===
--- clang/include/clang/AST/DeclBase.h
+++ clang/include/clang/AST/DeclBase.h
@@ -1142,6 +1142,11 @@
   /// that are missing from the lookup table.
   mutable bool HasLazyExternalLexicalLookups : 1;
 
+  /// \brief If \c true, lookups should only return identifier from
+  /// DeclContext scope (for example TranslationUnit). Used in
+  /// LookupQualifiedName()
+  mutable bool UseQualifiedLookup : 1;
+
   /// \brief Pointer to the data structure used to lookup declarations
   /// within this context (or a DependentStoredDeclsMap if this is a
   /// dependent context). We maintain the invariant that, if the map
@@ -1176,6 +1181,7 @@
 ExternalVisibleStorage(false),
 NeedToReconcileExternalVisibleStorage(false),
 HasLazyLocalLexicalLookups(false), HasLazyExternalLexicalLookups(false),
+UseQualifiedLookup(false),
 LookupPtr(nullptr), FirstDecl

Re: [PATCH] D13349: [OpenCL] Casting boolean to an integer vector in OpenCL should set all bits if boolean is true

[Neil Hickey via cfe-commits]

neil.hickey updated this revision to Diff 36348.
neil.hickey added a comment.

Fixing formatting problems.


http://reviews.llvm.org/D13349

Files:
  lib/CodeGen/CGExprScalar.cpp
  test/CodeGenOpenCL/bool_cast.cl

Index: test/CodeGenOpenCL/bool_cast.cl
===
--- /dev/null
+++ test/CodeGenOpenCL/bool_cast.cl
@@ -0,0 +1,27 @@
+// RUN: %clang_cc1 %s -emit-llvm -o - -O0 | FileCheck %s
+
+typedef unsigned char uchar4 __attribute((ext_vector_type(4)));
+typedef unsigned int int4 __attribute((ext_vector_type(4)));
+
+void kernel ker() {
+  bool t = true;
+  int4 vec4 = (int4)t;
+// CHECK: {{%.*}} = load i8, i8* %t, align 1
+// CHECK: {{%.*}} = trunc i8 {{%.*}} to i1
+// CHECK: {{%.*}} = sext i1 {{%.*}} to i32
+// CHECK: {{%.*}} = insertelement <4 x i32> undef, i32 {{%.*}}, i32 0
+// CHECK: {{%.*}} = shufflevector <4 x i32> {{%.*}}, <4 x i32> undef, <4 x 
i32> zeroinitializer
+// CHECK: store <4 x i32> {{%.*}}, <4 x i32>* %vec4, align 16
+  int i = (int)t;
+// CHECK: {{%.*}} = load i8, i8* %t, align 1
+// CHECK: {{%.*}} = trunc i8 {{%.*}} to i1
+// CHECK: {{%.*}} = zext i1 {{%.*}} to i32
+// CHECK: store i32 {{%.*}}, i32* %i, align 4
+
+  uchar4 vc;
+  vc = (uchar4)true;
+// CHECK: store <4 x i8> , <4 x i8>* %vc, align 4
+  unsigned char c;
+  c = (unsigned char)true;
+// CHECK: store i8 1, i8* %c, align 1
+}
Index: lib/CodeGen/CGExprScalar.cpp
===
--- lib/CodeGen/CGExprScalar.cpp
+++ lib/CodeGen/CGExprScalar.cpp
@@ -151,6 +151,9 @@
   Value *EmitScalarConversion(Value *Src, QualType SrcTy, QualType DstTy,
   SourceLocation Loc);
 
+  Value *EmitScalarConversion(Value *Src, QualType SrcTy, QualType DstTy,
+  SourceLocation Loc, bool TreatBooleanAsSigned);
+
   /// Emit a conversion from the specified complex type to the specified
   /// destination type, where the destination type is an LLVM scalar type.
   Value *EmitComplexToScalarConversion(CodeGenFunction::ComplexPairTy Src,
@@ -733,6 +736,13 @@
 Value *ScalarExprEmitter::EmitScalarConversion(Value *Src, QualType SrcType,
QualType DstType,
SourceLocation Loc) {
+  return EmitScalarConversion(Src, SrcType, DstType, Loc, false);
+}
+
+Value *ScalarExprEmitter::EmitScalarConversion(Value *Src, QualType SrcType,
+   QualType DstType,
+   SourceLocation Loc,
+   bool TreatBooleanAsSigned) {
   SrcType = CGF.getContext().getCanonicalType(SrcType);
   DstType = CGF.getContext().getCanonicalType(DstType);
   if (SrcType == DstType) return Src;
@@ -807,7 +817,8 @@
   if (DstType->isExtVectorType() && !SrcType->isVectorType()) {
 // Cast the scalar to element type
 QualType EltTy = DstType->getAs()->getElementType();
-llvm::Value *Elt = EmitScalarConversion(Src, SrcType, EltTy, Loc);
+llvm::Value *Elt = EmitScalarConversion(
+Src, SrcType, EltTy, Loc, CGF.getContext().getLangOpts().OpenCL);
 
 // Splat the element across to all elements
 unsigned NumElements = cast(DstTy)->getNumElements();
@@ -847,6 +858,9 @@
 
   if (isa(SrcTy)) {
 bool InputSigned = SrcType->isSignedIntegerOrEnumerationType();
+if (SrcType->isBooleanType() && TreatBooleanAsSigned) {
+  InputSigned = true;
+}
 if (isa(DstTy))
   Res = Builder.CreateIntCast(Src, DstTy, InputSigned, "conv");
 else if (InputSigned)
@@ -1531,10 +1545,14 @@
   }
   case CK_VectorSplat: {
 llvm::Type *DstTy = ConvertType(DestTy);
-Value *Elt = Visit(const_cast(E));
-Elt = EmitScalarConversion(Elt, E->getType(),
+// Need an IgnoreImpCasts here as by default a boolean will be promoted to
+// an int, which will not perform the sign extension, so if we know we are
+// going to cast to a vector we have to strip the implicit cast off.
+Value *Elt = Visit(const_cast(E->IgnoreImpCasts()));
+Elt = EmitScalarConversion(Elt, E->IgnoreImpCasts()->getType(),
DestTy->getAs()->getElementType(),
-   CE->getExprLoc());
+   CE->getExprLoc(), 
+   CGF.getContext().getLangOpts().OpenCL);
 
 // Splat the element across to all elements
 unsigned NumElements = cast(DstTy)->getNumElements();


Index: test/CodeGenOpenCL/bool_cast.cl
===
--- /dev/null
+++ test/CodeGenOpenCL/bool_cast.cl
@@ -0,0 +1,27 @@
+// RUN: %clang_cc1 %s -emit-llvm -o - -O0 | FileCheck %s
+
+typedef unsigned char uchar4 __attribute((ext_vector_type(4)));
+typedef unsigned int int4 __attribute((ext_vector_type(4)));
+
+void kernel ker() {
+  bool t = true;
+  int4 vec4 = (int4)t;
+// CHECK: {{%.*}} = l

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

[Aaron Ballman via cfe-commits]

On Fri, Oct 2, 2015 at 1:26 AM, Keno Fischer
 wrote:
> loladiro added inline comments.
>
> 
> Comment at: include/clang/Basic/Attr.td:1462
> @@ +1461,3 @@
> +def UniqueInstantiation : InheritableAttr {
> +  let Spellings = [GCC<"unique_instantiation">];
> +  let Subjects = SubjectList<[CXXRecord]>;
> 
> loladiro wrote:
>> aaron.ballman wrote:
>> > This is not a GCC attribute, so it should not be spelled as such. Since 
>> > this only applies to C++ code, I would recommend a C++11 spelling (in the 
>> > clang namespace). If you think this is something C++03 and earlier code 
>> > would really benefit from, then you could also add a GNU-style spelling.
>> No, this is C++11 only. Will change the spelling.
> It doesn't appear like the grammar allows attributes to be specified on 
> explicit template definitions. I'll change the spelling to GNU:

Ah shoot, that's right. I hadn't noticed  [dcl.attr.grammar]p4.
Specifically, the strangely easily-understandable sentence: No
attribute-specifier-seq shall appertain to an explicit instantiation.

Sorry about that!

~Aaron

>
> ```
> error:
>   an attribute list cannot appear here
> template struct foo [[clang::unique_instantiation]];
>  ^~~
> [[clang::unique_instantiation]]
> error:
>   an attribute list cannot appear here
> template struct [[clang::unique_instantiation]] foo;
> ^~~
> error:
>   an attribute list cannot appear here
> template [[clang::unique_instantiation]] struct foo;
>  ^~~
> error:
>   an attribute list cannot appear here
> [[clang::unique_instantiation]] template struct foo;
> ^~~
> 1 error generated.
> FileCheck error: '-' is empty.
> ```
>
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D13330
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D13313: [clang-tidy] new check cppcoreguidelines-pro-type-reinterpret-cast

[Aaron Ballman via cfe-commits]

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

LGTM with one minor nit. Thank you for working on this!

~Aaron



Comment at: clang-tidy/add_new_check.py:150
@@ -149,2 +149,3 @@
 def adapt_module(module_path, module, check_name, check_name_camel):
-  filename = os.path.join(module_path, module.capitalize() + 'TidyModule.cpp')
+  modulecpp = filter(lambda p: p.lower() == module.lower() + "tidymodule.cpp", 
os.listdir(module_path))[0]
+  filename = os.path.join(module_path, modulecpp)

Thank you for pointing this out, I hadn't realized we had a helper for this, 
let alone that it does the wrong thing for the new module I was working on. :-P


Comment at: clang-tidy/cppcoreguidelines/ProTypeReinterpretCastCheck.cpp:30
@@ +29,3 @@
+  diag(MatchedCast->getOperatorLoc(),
+   "do not use reinterpret_cast (C++ Core Guidelines, rule Type.1)");
+}

I don't think we need the parenthetical any longer because the name of the 
checker will already be displayed to the user with the diagnostic.


http://reviews.llvm.org/D13313



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

Re: [PATCH] D13157: Teach -Wtautological-overlap-compare about enums

[Aaron Ballman via cfe-commits]

On Thu, Oct 1, 2015 at 5:18 PM, Richard Trieu  wrote:
> I'm in favor of keeping the asserts around.  Several times, I've seen Clang
> crashers than languish in the bug tracker with an assert in a generic
> casting function.  And no one fixes it until someone pokes at the backtrace
> to find the source of the bad pointer, at which point it gets fixed quickly.

I think no one fixes it until it becomes a pain point, not because the
backtrace is marginally more complex. I still don't think the
maintenance burden or performance hit from duplicate logic provides a
tangible benefit. That being said, I'm also fine letting it slide -- I
just worry about this becoming a pattern in more parts of the code. If
that happens, we can have a larger discussion about it then.

~Aaron

>
> On Thu, Oct 1, 2015 at 1:01 PM, George Burgess IV
>  wrote:
>>
>> > Next time, add Differential Revision:  to your commit and
>> > Phabricator will close the diff automatically.
>>
>> Ooh, shiny. Thanks for letting me know!
>>
>> > Doubling the expense for assert builds so that we get a slightly better
>> > stack trace in the event our assumptions are wrong doesn't seem like a good
>> > tradeoff
>>
>> I'd think that the optimizer would be able to eliminate the redundant
>> checks for Release+Asserts builds, and that this code wouldn't get hit often
>> enough for it to make a meaningful impact on the execution time of a Debug
>> build of clang. That said, I'm happy to potentially make things a bit faster
>> if that's what we choose to do. :)
>>
>> Richard, do you feel strongly one way or the other? If not, I'll go ahead
>> and take them out.
>>
>> George
>>
>> On Thu, Oct 1, 2015 at 12:03 PM, Aaron Ballman 
>> wrote:
>>>
>>> On Thu, Oct 1, 2015 at 3:01 PM, Richard Trieu  wrote:
>>> > rtrieu added a comment.
>>> >
>>> > Next time, add
>>> >
>>> >> Differential Revision: 
>>> >
>>> >
>>> > to your commit and Phabricator will close the diff automatically.
>>> >
>>> > http://llvm.org/docs/Phabricator.html
>>> >
>>> >
>>> > 
>>> > Comment at: lib/Analysis/CFG.cpp:99-104
>>> > @@ +98,8 @@
>>> > +  // Currently we're only given EnumConstantDecls or IntegerLiterals
>>> > +  auto *C1 = cast(cast(A)->getDecl());
>>> > +  auto *C2 = cast(cast(B)->getDecl());
>>> > +
>>> > +  const TagDecl *E1 =
>>> > TagDecl::castFromDeclContext(C1->getDeclContext());
>>> > +  const TagDecl *E2 =
>>> > TagDecl::castFromDeclContext(C2->getDeclContext());
>>> > +  return E1 == E2;
>>> > +}
>>> > 
>>> > george.burgess.iv wrote:
>>> >> rtrieu wrote:
>>> >> > There's a few extra casts in here, plus some blind conversions
>>> >> > between types.  Add your assumptions for the types in asserts.  Also,
>>> >> > DeclContext should use cast<> to get to Decl types.  I recommend the
>>> >> > following:
>>> >> >
>>> >> > ```
>>> >> >   assert(isa(E1) && isa(E2));
>>> >> >   auto *Decl1 = cast(E1)->getDecl();
>>> >> >   auto *Decl2 = cast(E2)->getDecl();
>>> >> >
>>> >> >   assert(isa(Decl1) &&
>>> >> > isa(Decl2));
>>> >> >   const DeclContext *DC1 = Decl1->getDeclContext();
>>> >> >   const DeclContext *DC2 = Decl2->getDeclContext();
>>> >> >
>>> >> >   assert(isa(DC1) && isa(DC2));
>>> >> >   return DC1 == DC2;
>>> >> >
>>> >> > ```
>>> >> I was under the impression that the `cast(Bar)` asserts
>>> >> `isa(Bar)` for me, so I thought that asserts like those would just 
>>> >> be
>>> >> redundant. Changed to your version anyway :)
>>> > You are correct, 'cast(Bar)' does assert 'isa(Bar)'.
>>> > However, when Bar is not Foo, using the assert here means the crash will
>>> > produce a backtrace will point straight to this function instead of an
>>> > assert that points deep into the casting functions.
>>>
>>> Doubling the expense for assert builds so that we get a slightly
>>> better stack trace in the event our assumptions are wrong doesn't seem
>>> like a good tradeoff. It means everyone running an assert build pays
>>> the price twice to save a few moments of scanning the backtrace in a
>>> situation that's (hopefully) highly unlikely to occur in practice.
>>>
>>> ~Aaron
>>>
>>> >
>>> >
>>> > http://reviews.llvm.org/D13157
>>> >
>>> >
>>> >
>>
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D13381: Handle trailing underscores on modernize-loop-convert variable namer.

[Manuel Klimek via cfe-commits]

klimek added inline comments.


Comment at: clang-tidy/modernize/LoopConvertUtils.cpp:822
@@ -821,1 +821,3 @@
 IteratorName = ContainerName.substr(0, Len - 1);
+// Ej: (auto thing : things)
+if (!declarationExists(IteratorName))

Do you mean: E.g.?


http://reviews.llvm.org/D13381



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

Re: [PATCH] D13381: Handle trailing underscores on modernize-loop-convert variable namer.

[Angel Garcia via cfe-commits]

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

I forgot one.


http://reviews.llvm.org/D13381

Files:
  clang-tidy/modernize/LoopConvertUtils.cpp
  test/clang-tidy/modernize-loop-convert-lowercase.cpp
  test/clang-tidy/modernize-loop-convert-uppercase.cpp

Index: test/clang-tidy/modernize-loop-convert-uppercase.cpp
===
--- test/clang-tidy/modernize-loop-convert-uppercase.cpp
+++ test/clang-tidy/modernize-loop-convert-uppercase.cpp
@@ -7,6 +7,7 @@
 const int N = 10;
 int ARR[N];
 int NUMS[N];
+int NUMS_[N];
 
 void naming() {
   for (int I = 0; I < N; ++I) {
@@ -23,6 +24,13 @@
   // CHECK-FIXES: for (auto & NUM : NUMS)
   // CHECK-FIXES-NEXT: printf("%d\n", NUM);
 
+  for (int I = 0; I < N; ++I) {
+printf("%d\n", NUMS_[I]);
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based for loop instead
+  // CHECK-FIXES: for (auto & NUM : NUMS_)
+  // CHECK-FIXES-NEXT: printf("%d\n", NUM);
+
   int NUM = 0;
   for (int I = 0; I < N; ++I) {
 printf("%d\n", NUMS[I] + NUM);
Index: test/clang-tidy/modernize-loop-convert-lowercase.cpp
===
--- test/clang-tidy/modernize-loop-convert-lowercase.cpp
+++ test/clang-tidy/modernize-loop-convert-lowercase.cpp
@@ -7,6 +7,7 @@
 const int n = 10;
 int arr[n];
 int nums[n];
+int nums_[n];
 
 void naming() {
   for (int i = 0; i < n; ++i) {
@@ -23,6 +24,13 @@
   // CHECK-FIXES: for (auto & num : nums)
   // CHECK-FIXES-NEXT: printf("%d\n", num);
 
+  for (int i = 0; i < n; ++i) {
+printf("%d\n", nums_[i]);
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based for loop instead
+  // CHECK-FIXES: for (auto & num : nums_)
+  // CHECK-FIXES-NEXT: printf("%d\n", num);
+
   int num = 0;
   for (int i = 0; i < n; ++i) {
 printf("%d\n", nums[i] + num);
Index: clang-tidy/modernize/LoopConvertUtils.cpp
===
--- clang-tidy/modernize/LoopConvertUtils.cpp
+++ clang-tidy/modernize/LoopConvertUtils.cpp
@@ -819,6 +819,14 @@
   size_t Len = ContainerName.size();
   if (Len > 1 && ContainerName.endswith(Style == NS_UpperCase ? "S" : "s")) {
 IteratorName = ContainerName.substr(0, Len - 1);
+// E.g.: (auto thing : things)
+if (!declarationExists(IteratorName))
+  return IteratorName;
+  }
+
+  if (Len > 2 && ContainerName.endswith(Style == NS_UpperCase ? "S_" : "s_")) {
+IteratorName = ContainerName.substr(0, Len - 2);
+// E.g.: (auto thing : things_)
 if (!declarationExists(IteratorName))
   return IteratorName;
   }
@@ -835,14 +843,17 @@
   case NS_UpperCase:
 Elem = "ELEM";
   }
+  // E.g.: (auto elem : container)
   if (!declarationExists(Elem))
 return Elem;
 
   IteratorName = AppendWithStyle(ContainerName, OldIndex->getName());
+  // E.g.: (auto container_i : container)
   if (!declarationExists(IteratorName))
 return IteratorName;
 
   IteratorName = AppendWithStyle(ContainerName, Elem);
+  // E.g.: (auto container_elem : container)
   if (!declarationExists(IteratorName))
 return IteratorName;
 


Index: test/clang-tidy/modernize-loop-convert-uppercase.cpp
===
--- test/clang-tidy/modernize-loop-convert-uppercase.cpp
+++ test/clang-tidy/modernize-loop-convert-uppercase.cpp
@@ -7,6 +7,7 @@
 const int N = 10;
 int ARR[N];
 int NUMS[N];
+int NUMS_[N];
 
 void naming() {
   for (int I = 0; I < N; ++I) {
@@ -23,6 +24,13 @@
   // CHECK-FIXES: for (auto & NUM : NUMS)
   // CHECK-FIXES-NEXT: printf("%d\n", NUM);
 
+  for (int I = 0; I < N; ++I) {
+printf("%d\n", NUMS_[I]);
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based for loop instead
+  // CHECK-FIXES: for (auto & NUM : NUMS_)
+  // CHECK-FIXES-NEXT: printf("%d\n", NUM);
+
   int NUM = 0;
   for (int I = 0; I < N; ++I) {
 printf("%d\n", NUMS[I] + NUM);
Index: test/clang-tidy/modernize-loop-convert-lowercase.cpp
===
--- test/clang-tidy/modernize-loop-convert-lowercase.cpp
+++ test/clang-tidy/modernize-loop-convert-lowercase.cpp
@@ -7,6 +7,7 @@
 const int n = 10;
 int arr[n];
 int nums[n];
+int nums_[n];
 
 void naming() {
   for (int i = 0; i < n; ++i) {
@@ -23,6 +24,13 @@
   // CHECK-FIXES: for (auto & num : nums)
   // CHECK-FIXES-NEXT: printf("%d\n", num);
 
+  for (int i = 0; i < n; ++i) {
+printf("%d\n", nums_[i]);
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based for loop instead
+  // CHECK-FIXES: for (auto & num : nums_)
+  // CHECK-FIXES-NEXT: printf("%d\n", num);
+
   int num = 0;
   for (int i = 0; i < n; ++i) {
 printf("%d\n", nums[i] + num);
Index: clang-tidy/modernize/LoopConvertUtils.cpp
===
--- clang-tidy/modernize/LoopConvertUtils.cpp
+++ clang-tidy/modernize/LoopConvertUtils.cpp
@@ -

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

[Manuel Klimek via cfe-commits]

klimek added a subscriber: klimek.
klimek added a comment.

Perhaps "sharded" would fit what it is?


http://reviews.llvm.org/D11908



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

Re: [PATCH] D13381: Handle trailing underscores on modernize-loop-convert variable namer.

[Manuel Klimek via cfe-commits]

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

lg


http://reviews.llvm.org/D13381



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

[clang-tools-extra] r249127 - Handle trailing underscores on modernize-loop-convert variable namer.

[Angel Garcia Gomez via cfe-commits]

Author: angelgarcia
Date: Fri Oct  2 08:20:11 2015
New Revision: 249127

URL: http://llvm.org/viewvc/llvm-project?rev=249127&view=rev
Log:
Handle trailing underscores on modernize-loop-convert variable namer.

Summary: https://llvm.org/bugs/show_bug.cgi?id=24961.

Reviewers: klimek

Subscribers: cfe-commits, alexfh

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

Modified:
clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertUtils.cpp
clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-lowercase.cpp
clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-uppercase.cpp

Modified: clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertUtils.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertUtils.cpp?rev=249127&r1=249126&r2=249127&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertUtils.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/modernize/LoopConvertUtils.cpp Fri Oct  
2 08:20:11 2015
@@ -819,6 +819,14 @@ std::string VariableNamer::createIndexNa
   size_t Len = ContainerName.size();
   if (Len > 1 && ContainerName.endswith(Style == NS_UpperCase ? "S" : "s")) {
 IteratorName = ContainerName.substr(0, Len - 1);
+// E.g.: (auto thing : things)
+if (!declarationExists(IteratorName))
+  return IteratorName;
+  }
+
+  if (Len > 2 && ContainerName.endswith(Style == NS_UpperCase ? "S_" : "s_")) {
+IteratorName = ContainerName.substr(0, Len - 2);
+// E.g.: (auto thing : things_)
 if (!declarationExists(IteratorName))
   return IteratorName;
   }
@@ -835,14 +843,17 @@ std::string VariableNamer::createIndexNa
   case NS_UpperCase:
 Elem = "ELEM";
   }
+  // E.g.: (auto elem : container)
   if (!declarationExists(Elem))
 return Elem;
 
   IteratorName = AppendWithStyle(ContainerName, OldIndex->getName());
+  // E.g.: (auto container_i : container)
   if (!declarationExists(IteratorName))
 return IteratorName;
 
   IteratorName = AppendWithStyle(ContainerName, Elem);
+  // E.g.: (auto container_elem : container)
   if (!declarationExists(IteratorName))
 return IteratorName;
 

Modified: 
clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-lowercase.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-lowercase.cpp?rev=249127&r1=249126&r2=249127&view=diff
==
--- 
clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-lowercase.cpp 
(original)
+++ 
clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-lowercase.cpp 
Fri Oct  2 08:20:11 2015
@@ -7,6 +7,7 @@
 const int n = 10;
 int arr[n];
 int nums[n];
+int nums_[n];
 
 void naming() {
   for (int i = 0; i < n; ++i) {
@@ -23,6 +24,13 @@ void naming() {
   // CHECK-FIXES: for (auto & num : nums)
   // CHECK-FIXES-NEXT: printf("%d\n", num);
 
+  for (int i = 0; i < n; ++i) {
+printf("%d\n", nums_[i]);
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based for loop instead
+  // CHECK-FIXES: for (auto & num : nums_)
+  // CHECK-FIXES-NEXT: printf("%d\n", num);
+
   int num = 0;
   for (int i = 0; i < n; ++i) {
 printf("%d\n", nums[i] + num);

Modified: 
clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-uppercase.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-uppercase.cpp?rev=249127&r1=249126&r2=249127&view=diff
==
--- 
clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-uppercase.cpp 
(original)
+++ 
clang-tools-extra/trunk/test/clang-tidy/modernize-loop-convert-uppercase.cpp 
Fri Oct  2 08:20:11 2015
@@ -7,6 +7,7 @@
 const int N = 10;
 int ARR[N];
 int NUMS[N];
+int NUMS_[N];
 
 void naming() {
   for (int I = 0; I < N; ++I) {
@@ -23,6 +24,13 @@ void naming() {
   // CHECK-FIXES: for (auto & NUM : NUMS)
   // CHECK-FIXES-NEXT: printf("%d\n", NUM);
 
+  for (int I = 0; I < N; ++I) {
+printf("%d\n", NUMS_[I]);
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based for loop instead
+  // CHECK-FIXES: for (auto & NUM : NUMS_)
+  // CHECK-FIXES-NEXT: printf("%d\n", NUM);
+
   int NUM = 0;
   for (int I = 0; I < N; ++I) {
 printf("%d\n", NUMS[I] + NUM);


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

Re: [PATCH] D13381: Handle trailing underscores on modernize-loop-convert variable namer.

[Angel Garcia via cfe-commits]

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

Yes! Sorry.


http://reviews.llvm.org/D13381

Files:
  clang-tidy/modernize/LoopConvertUtils.cpp
  test/clang-tidy/modernize-loop-convert-lowercase.cpp
  test/clang-tidy/modernize-loop-convert-uppercase.cpp

Index: test/clang-tidy/modernize-loop-convert-uppercase.cpp
===
--- test/clang-tidy/modernize-loop-convert-uppercase.cpp
+++ test/clang-tidy/modernize-loop-convert-uppercase.cpp
@@ -7,6 +7,7 @@
 const int N = 10;
 int ARR[N];
 int NUMS[N];
+int NUMS_[N];
 
 void naming() {
   for (int I = 0; I < N; ++I) {
@@ -23,6 +24,13 @@
   // CHECK-FIXES: for (auto & NUM : NUMS)
   // CHECK-FIXES-NEXT: printf("%d\n", NUM);
 
+  for (int I = 0; I < N; ++I) {
+printf("%d\n", NUMS_[I]);
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based for loop instead
+  // CHECK-FIXES: for (auto & NUM : NUMS_)
+  // CHECK-FIXES-NEXT: printf("%d\n", NUM);
+
   int NUM = 0;
   for (int I = 0; I < N; ++I) {
 printf("%d\n", NUMS[I] + NUM);
Index: test/clang-tidy/modernize-loop-convert-lowercase.cpp
===
--- test/clang-tidy/modernize-loop-convert-lowercase.cpp
+++ test/clang-tidy/modernize-loop-convert-lowercase.cpp
@@ -7,6 +7,7 @@
 const int n = 10;
 int arr[n];
 int nums[n];
+int nums_[n];
 
 void naming() {
   for (int i = 0; i < n; ++i) {
@@ -23,6 +24,13 @@
   // CHECK-FIXES: for (auto & num : nums)
   // CHECK-FIXES-NEXT: printf("%d\n", num);
 
+  for (int i = 0; i < n; ++i) {
+printf("%d\n", nums_[i]);
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based for loop instead
+  // CHECK-FIXES: for (auto & num : nums_)
+  // CHECK-FIXES-NEXT: printf("%d\n", num);
+
   int num = 0;
   for (int i = 0; i < n; ++i) {
 printf("%d\n", nums[i] + num);
Index: clang-tidy/modernize/LoopConvertUtils.cpp
===
--- clang-tidy/modernize/LoopConvertUtils.cpp
+++ clang-tidy/modernize/LoopConvertUtils.cpp
@@ -819,6 +819,14 @@
   size_t Len = ContainerName.size();
   if (Len > 1 && ContainerName.endswith(Style == NS_UpperCase ? "S" : "s")) {
 IteratorName = ContainerName.substr(0, Len - 1);
+// Ej: (auto thing : things)
+if (!declarationExists(IteratorName))
+  return IteratorName;
+  }
+
+  if (Len > 2 && ContainerName.endswith(Style == NS_UpperCase ? "S_" : "s_")) {
+IteratorName = ContainerName.substr(0, Len - 2);
+// E.g.: (auto thing : things_)
 if (!declarationExists(IteratorName))
   return IteratorName;
   }
@@ -835,14 +843,17 @@
   case NS_UpperCase:
 Elem = "ELEM";
   }
+  // E.g.: (auto elem : container)
   if (!declarationExists(Elem))
 return Elem;
 
   IteratorName = AppendWithStyle(ContainerName, OldIndex->getName());
+  // E.g.: (auto container_i : container)
   if (!declarationExists(IteratorName))
 return IteratorName;
 
   IteratorName = AppendWithStyle(ContainerName, Elem);
+  // E.g.: (auto container_elem : container)
   if (!declarationExists(IteratorName))
 return IteratorName;
 


Index: test/clang-tidy/modernize-loop-convert-uppercase.cpp
===
--- test/clang-tidy/modernize-loop-convert-uppercase.cpp
+++ test/clang-tidy/modernize-loop-convert-uppercase.cpp
@@ -7,6 +7,7 @@
 const int N = 10;
 int ARR[N];
 int NUMS[N];
+int NUMS_[N];
 
 void naming() {
   for (int I = 0; I < N; ++I) {
@@ -23,6 +24,13 @@
   // CHECK-FIXES: for (auto & NUM : NUMS)
   // CHECK-FIXES-NEXT: printf("%d\n", NUM);
 
+  for (int I = 0; I < N; ++I) {
+printf("%d\n", NUMS_[I]);
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based for loop instead
+  // CHECK-FIXES: for (auto & NUM : NUMS_)
+  // CHECK-FIXES-NEXT: printf("%d\n", NUM);
+
   int NUM = 0;
   for (int I = 0; I < N; ++I) {
 printf("%d\n", NUMS[I] + NUM);
Index: test/clang-tidy/modernize-loop-convert-lowercase.cpp
===
--- test/clang-tidy/modernize-loop-convert-lowercase.cpp
+++ test/clang-tidy/modernize-loop-convert-lowercase.cpp
@@ -7,6 +7,7 @@
 const int n = 10;
 int arr[n];
 int nums[n];
+int nums_[n];
 
 void naming() {
   for (int i = 0; i < n; ++i) {
@@ -23,6 +24,13 @@
   // CHECK-FIXES: for (auto & num : nums)
   // CHECK-FIXES-NEXT: printf("%d\n", num);
 
+  for (int i = 0; i < n; ++i) {
+printf("%d\n", nums_[i]);
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based for loop instead
+  // CHECK-FIXES: for (auto & num : nums_)
+  // CHECK-FIXES-NEXT: printf("%d\n", num);
+
   int num = 0;
   for (int i = 0; i < n; ++i) {
 printf("%d\n", nums[i] + num);
Index: clang-tidy/modernize/LoopConvertUtils.cpp
===
--- clang-tidy/modernize/LoopConvertUtils.cpp
+++ clang-tidy/modernize/LoopConvertUtils.cpp
@@ -819,

Re: [PATCH] D13352: [PATCH] Add a CERT category for clang-tidy checkers

[Manuel Klimek via cfe-commits]

klimek added a subscriber: klimek.
klimek accepted this revision.
klimek added a reviewer: klimek.
klimek added a comment.
This revision is now accepted and ready to land.

lg


http://reviews.llvm.org/D13352



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

r249129 - Divide TraverseInitListExpr to a different function for each form.

[Angel Garcia Gomez via cfe-commits]

Author: angelgarcia
Date: Fri Oct  2 08:25:51 2015
New Revision: 249129

URL: http://llvm.org/viewvc/llvm-project?rev=249129&view=rev
Log:
Divide TraverseInitListExpr to a different function for each form.

Summary: create TraverseSyntacticInitListExpr and TraverseSemanticInitListExpr.

Reviewers: rsmith, klimek

Subscribers: klimek, cfe-commits, alexfh

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

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

Modified: cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/RecursiveASTVisitor.h?rev=249129&r1=249128&r2=249129&view=diff
==
--- cfe/trunk/include/clang/AST/RecursiveASTVisitor.h (original)
+++ cfe/trunk/include/clang/AST/RecursiveASTVisitor.h Fri Oct  2 08:25:51 2015
@@ -255,6 +255,12 @@ public:
   /// \returns false if the visitation was terminated early, true otherwise.
   bool TraverseLambdaBody(LambdaExpr *LE);
 
+  /// \brief Recursively visit the syntactic or semantic form of an
+  /// initialization list.
+  ///
+  /// \returns false if the visitation was terminated early, true otherwise.
+  bool TraverseSynOrSemInitListExpr(InitListExpr *S);
+
   //  Methods on Attrs 
 
   // \brief Visit an attribute.
@@ -2056,31 +2062,33 @@ DEF_TRAVERSE_STMT(CXXStaticCastExpr, {
   TRY_TO(TraverseTypeLoc(S->getTypeInfoAsWritten()->getTypeLoc()));
 })
 
-// InitListExpr is a tricky one, because we want to do all our work on
-// the syntactic form of the listexpr, but this method takes the
-// semantic form by default.  We can't use the macro helper because it
-// calls WalkUp*() on the semantic form, before our code can convert
-// to the syntactic form.
 template 
-bool RecursiveASTVisitor::TraverseInitListExpr(InitListExpr *S) {
-  InitListExpr *Syn = S->isSemanticForm() ? S->getSyntacticForm() : S;
-  if (Syn) {
-TRY_TO(WalkUpFromInitListExpr(Syn));
+bool RecursiveASTVisitor::TraverseSynOrSemInitListExpr(InitListExpr 
*S) {
+  if (S) {
+TRY_TO(WalkUpFromInitListExpr(S));
 // All we need are the default actions.  FIXME: use a helper function.
-for (Stmt *SubStmt : Syn->children()) {
-  TRY_TO(TraverseStmt(SubStmt));
-}
-  }
-  InitListExpr *Sem = S->isSemanticForm() ? S : S->getSemanticForm();
-  if (Sem) {
-TRY_TO(WalkUpFromInitListExpr(Sem));
-for (Stmt *SubStmt : Sem->children()) {
+for (Stmt *SubStmt : S->children()) {
   TRY_TO(TraverseStmt(SubStmt));
 }
   }
   return true;
 }
 
+// This method is called once for each pair of syntactic and semantic
+// InitListExpr, and it traverses the subtrees defined by the two forms. This
+// may cause some of the children to be visited twice, if they appear both in
+// the syntactic and the semantic form.
+//
+// There is no guarantee about which form \p S takes when this method is 
called.
+template 
+bool RecursiveASTVisitor::TraverseInitListExpr(InitListExpr *S) {
+  TRY_TO(TraverseSynOrSemInitListExpr(
+  S->isSemanticForm() ? S->getSyntacticForm() : S));
+  TRY_TO(TraverseSynOrSemInitListExpr(
+  S->isSemanticForm() ? S : S->getSemanticForm()));
+  return true;
+}
+
 // GenericSelectionExpr is a special case because the types and expressions
 // are interleaved.  We also need to watch out for null types (default
 // generic associations).


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

[clang-tools-extra] r249130 - Adding a new clang-tidy module to house CERT-specific checkers, and map existing checkers to CERT secure coding rules and recommendations for both C (https://www.secureco

[Aaron Ballman via cfe-commits]

Author: aaronballman
Date: Fri Oct  2 08:27:19 2015
New Revision: 249130

URL: http://llvm.org/viewvc/llvm-project?rev=249130&view=rev
Log:
Adding a new clang-tidy module to house CERT-specific checkers, and map 
existing checkers to CERT secure coding rules and recommendations for both C 
(https://www.securecoding.cert.org/confluence/display/c/SEI+CERT+C+Coding+Standard)
 and C++ 
(https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=637).

Added:
clang-tools-extra/trunk/clang-tidy/cert/
clang-tools-extra/trunk/clang-tidy/cert/CERTTidyModule.cpp
clang-tools-extra/trunk/clang-tidy/cert/CMakeLists.txt
clang-tools-extra/trunk/clang-tidy/cert/Makefile
Modified:
clang-tools-extra/trunk/clang-tidy/CMakeLists.txt
clang-tools-extra/trunk/clang-tidy/Makefile
clang-tools-extra/trunk/clang-tidy/tool/CMakeLists.txt
clang-tools-extra/trunk/clang-tidy/tool/ClangTidyMain.cpp
clang-tools-extra/trunk/clang-tidy/tool/Makefile

Modified: clang-tools-extra/trunk/clang-tidy/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/CMakeLists.txt?rev=249130&r1=249129&r2=249130&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clang-tidy/CMakeLists.txt Fri Oct  2 08:27:19 2015
@@ -26,6 +26,7 @@ add_clang_library(clangTidy
   )
 
 add_subdirectory(tool)
+add_subdirectory(cert)
 add_subdirectory(llvm)
 add_subdirectory(google)
 add_subdirectory(misc)

Modified: clang-tools-extra/trunk/clang-tidy/Makefile
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/Makefile?rev=249130&r1=249129&r2=249130&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/Makefile (original)
+++ clang-tools-extra/trunk/clang-tidy/Makefile Fri Oct  2 08:27:19 2015
@@ -11,6 +11,6 @@ CLANG_LEVEL := ../../..
 LIBRARYNAME := clangTidy
 include $(CLANG_LEVEL)/../../Makefile.config
 
-DIRS = utils readability llvm google misc modernize tool
+DIRS = utils cert readability llvm google misc modernize tool
 
 include $(CLANG_LEVEL)/Makefile

Added: clang-tools-extra/trunk/clang-tidy/cert/CERTTidyModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/cert/CERTTidyModule.cpp?rev=249130&view=auto
==
--- clang-tools-extra/trunk/clang-tidy/cert/CERTTidyModule.cpp (added)
+++ clang-tools-extra/trunk/clang-tidy/cert/CERTTidyModule.cpp Fri Oct  2 
08:27:19 2015
@@ -0,0 +1,59 @@
+//===--- CERTTidyModule.cpp - clang-tidy 
--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "../ClangTidy.h"
+#include "../ClangTidyModule.h"
+#include "../ClangTidyModuleRegistry.h"
+#include "../google/UnnamedNamespaceInHeaderCheck.h"
+#include "../misc/MoveConstructorInitCheck.h"
+#include "../misc/NewDeleteOverloadsCheck.h"
+#include "../misc/NonCopyableObjects.h"
+#include "../misc/StaticAssertCheck.h"
+
+namespace clang {
+namespace tidy {
+namespace CERT {
+
+class CERTModule : public ClangTidyModule {
+public:
+  void addCheckFactories(ClangTidyCheckFactories &CheckFactories) override {
+// C++ checkers
+// DCL
+CheckFactories.registerCheck(
+"cert-dcl54-cpp");
+CheckFactories.registerCheck(
+"cert-dcl59-cpp");
+// OOP
+CheckFactories.registerCheck(
+"cert-oop11-cpp");
+
+// C checkers
+// DCL
+CheckFactories.registerCheck(
+"cert-dcl03-c");
+
+// FIO
+CheckFactories.registerCheck(
+"cert-fio38-c");
+  }
+};
+
+} // namespace misc
+
+// Register the MiscTidyModule using this statically initialized variable.
+static ClangTidyModuleRegistry::Add
+X("cert-module",
+  "Adds lint checks corresponding to CERT secure coding guidelines.");
+
+// This anchor is used to force the linker to link in the generated object file
+// and thus register the CERTModule.
+volatile int CERTModuleAnchorSource = 0;
+
+} // namespace tidy
+} // namespace clang

Added: clang-tools-extra/trunk/clang-tidy/cert/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/cert/CMakeLists.txt?rev=249130&view=auto
==
--- clang-tools-extra/trunk/clang-tidy/cert/CMakeLists.txt (added)
+++ clang-tools-extra/trunk/clang-tidy/cert/CMakeLists.txt Fri Oct  2 08:27:19 
2015
@@ -0,0 +1,12 @@
+set(LLVM_LINK_COMPONENTS support)
+
+add_clang_library(clangTidyCERTModule
+  CERTTidyModule.cpp
+
+  LINK_LIBS
+  clangAST
+  clangASTMatchers
+  clangBasic
+  clangL

Re: [PATCH] D13351: [Power PC] add soft float support for ppc32

[Joerg Sonnenberger via cfe-commits]

On Thu, Oct 01, 2015 at 09:00:46PM +, Alex Rosenberg via cfe-commits wrote:
> alexr added a subscriber: alexr.
> alexr added a comment.
> 
> PowerPC has floating point hardware by definition. Is this some new variant?

e500MC for example only has SPE, not "normal" FPU.

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

Re: [PATCH] D13349: [OpenCL] Casting boolean to an integer vector in OpenCL should set all bits if boolean is true

[Pekka Jääskeläinen via cfe-commits]

pekka.jaaskelainen added a comment.

OK now.


http://reviews.llvm.org/D13349



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

Re: [PATCH] D13352: [PATCH] Add a CERT category for clang-tidy checkers

[Aaron Ballman via cfe-commits]

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

Thanks! I've commit in r249130.

Do we want to have code owners for this sort of thing, or is that too 
fine-grained of a concept? If we do want them, I am (obviously) happy to be the 
code owner for anything in the CERT directory.

~Aaron


http://reviews.llvm.org/D13352



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

Re: [PATCH] D13246: Fix bug in modernize-use-nullptr.

[Angel Garcia via cfe-commits]

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

Update this patch to the change in RecursiveASTVisitor.


http://reviews.llvm.org/D13246

Files:
  clang-tidy/modernize/UseNullptrCheck.cpp
  test/clang-tidy/modernize-use-nullptr.cpp

Index: test/clang-tidy/modernize-use-nullptr.cpp
===
--- test/clang-tidy/modernize-use-nullptr.cpp
+++ test/clang-tidy/modernize-use-nullptr.cpp
@@ -174,4 +174,13 @@
 #define CALL(X) X
   OPTIONAL_CODE(NOT_NULL);
   CALL(NOT_NULL);
+
+#define ENTRY(X) {X}
+  struct A {
+int *Ptr;
+  } a[2] = {ENTRY(0), {0}};
+  // CHECK-MESSAGES: :[[@LINE-1]]:19: warning: use nullptr
+  // CHECK-MESSAGES: :[[@LINE-2]]:24: warning: use nullptr
+  // CHECK-FIXES: a[2] = {ENTRY(nullptr), {nullptr}};
+#undef ENTRY
 }
Index: clang-tidy/modernize/UseNullptrCheck.cpp
===
--- clang-tidy/modernize/UseNullptrCheck.cpp
+++ clang-tidy/modernize/UseNullptrCheck.cpp
@@ -150,6 +150,16 @@
 return true;
   }
 
+  bool TraverseInitListExpr(InitListExpr *S) {
+// Only go through the semantic form of the InitListExpr, because
+// ImplicitCast might not appear in the syntactic form, and this results in
+// finding usages of the macro argument that don't have a ImplicitCast as 
an
+// ancestor (thus invalidating the replacement) when they actually have.
+return RecursiveASTVisitor::
+TraverseSynOrSemInitListExpr(
+S->isSemanticForm() ? S : S->getSemanticForm());
+  }
+
   bool foundInvalid() const { return InvalidFound; }
 
 private:
@@ -273,7 +283,7 @@
 // Visit children of this containing parent looking for the least-descended
 // nodes of the containing parent which are macro arg expansions that 
expand
 // from the given arg location.
-// Visitor needs: arg loc
+// Visitor needs: arg loc.
 MacroArgUsageVisitor ArgUsageVisitor(SM.getFileLoc(CastLoc), SM);
 if (const auto *D = ContainingAncestor.get())
   ArgUsageVisitor.TraverseDecl(const_cast(D));
@@ -345,8 +355,8 @@
   /// also handled.
   ///
   /// False means either:
-  /// - TestLoc is not from a macro expansion
-  /// - TestLoc is from a different macro expansion
+  /// - TestLoc is not from a macro expansion.
+  /// - TestLoc is from a different macro expansion.
   bool expandsFrom(SourceLocation TestLoc, SourceLocation TestMacroLoc) {
 if (TestLoc.isFileID()) {
   return false;
@@ -399,17 +409,24 @@
   ast_type_traits::DynTypedNode &Result) {
 // Below we're only following the first parent back up the AST. This should
 // be fine since for the statements we care about there should only be one
-// parent as far up as we care. If this assumption doesn't hold, need to
-// revisit what to do here.
+// parent, except for the case specified below.
 
 assert(MacroLoc.isFileID());
 
 while (true) {
   const auto &Parents = Context.getParents(Start);
   if (Parents.empty())
 return false;
-  assert(Parents.size() == 1 &&
- "Found an ancestor with more than one parent!");
+  if (Parents.size() > 1) {
+// If there are more than one parents, don't do the replacement unless
+// they are InitListsExpr (semantic and syntactic form). In this case 
we
+// can choose any one here, and the ASTVisitor will take care of
+// traversing the right one.
+for (const auto &Parent : Parents) {
+  if (!Parent.get())
+return false;
+}
+  }
 
   const ast_type_traits::DynTypedNode &Parent = Parents[0];
 


Index: test/clang-tidy/modernize-use-nullptr.cpp
===
--- test/clang-tidy/modernize-use-nullptr.cpp
+++ test/clang-tidy/modernize-use-nullptr.cpp
@@ -174,4 +174,13 @@
 #define CALL(X) X
   OPTIONAL_CODE(NOT_NULL);
   CALL(NOT_NULL);
+
+#define ENTRY(X) {X}
+  struct A {
+int *Ptr;
+  } a[2] = {ENTRY(0), {0}};
+  // CHECK-MESSAGES: :[[@LINE-1]]:19: warning: use nullptr
+  // CHECK-MESSAGES: :[[@LINE-2]]:24: warning: use nullptr
+  // CHECK-FIXES: a[2] = {ENTRY(nullptr), {nullptr}};
+#undef ENTRY
 }
Index: clang-tidy/modernize/UseNullptrCheck.cpp
===
--- clang-tidy/modernize/UseNullptrCheck.cpp
+++ clang-tidy/modernize/UseNullptrCheck.cpp
@@ -150,6 +150,16 @@
 return true;
   }
 
+  bool TraverseInitListExpr(InitListExpr *S) {
+// Only go through the semantic form of the InitListExpr, because
+// ImplicitCast might not appear in the syntactic form, and this results in
+// finding usages of the macro argument that don't have a ImplicitCast as an
+// ancestor (thus invalidating the replacement) when they actually have.
+return RecursiveASTVisitor::
+TraverseSynOrSemInitListExpr(
+S->isSemanticForm() ? S : S-

Re: [PATCH] D13351: [Power PC] add soft float support for ppc32

[Konstantin Tokarev via cfe-commits]

02.10.2015, 00:00, "Alex Rosenberg via cfe-commits" 
:
> alexr added a subscriber: alexr.
> alexr added a comment.
>
> PowerPC has floating point hardware by definition. Is this some new variant?

Some cores from ppc400 series do not have hardware FP (for example, ppc 405)

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

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

[Teresa Johnson via cfe-commits]

tejohnson added a subscriber: tejohnson.
tejohnson added a comment.

Added echristo, rafael, pcc officially as subscribers as Duncan's cc
of them via email didn't stick.


http://reviews.llvm.org/D11908



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

Re: [PATCH] D13340: Add support for the new mips-mti-linux toolchain.

[Simon Atanasyan via cfe-commits]

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

LGTM


http://reviews.llvm.org/D13340



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

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

[Teresa Johnson via cfe-commits]

tejohnson added a comment.

Sorry for the duplicate - my previous response didn't go to Duncan or Mehdi for 
some reason. Trying again...

In http://reviews.llvm.org/D11908#258540, @klimek wrote:

> Perhaps "sharded" would fit what it is?


You could have a sharded mode for full FDO (like gcc's partitioned LTO). And we 
aren't really making any explicit sharding decisions, since the backends do 
importing on demand.

As David mentioned, "inlineonly" is much too restrictive for what is possible. 
I prefer to stick with "thin" since it refers to this new model of keeping the 
whole program part very thin.

Does anyone have an opinion on "full" vs "monolithic" vs something else for the 
traditional full/monolithic LTO?


http://reviews.llvm.org/D11908



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

Re: [PATCH] D13352: [PATCH] Add a CERT category for clang-tidy checkers

[Manuel Klimek via cfe-commits]

I dont think we need finer grained code owners, but I also don't have real
objections.

On Fri, Oct 2, 2015, 3:31 PM Aaron Ballman  wrote:

> aaron.ballman closed this revision.
> aaron.ballman added a comment.
>
> Thanks! I've commit in r249130.
>
> Do we want to have code owners for this sort of thing, or is that too
> fine-grained of a concept? If we do want them, I am (obviously) happy to be
> the code owner for anything in the CERT directory.
>
> ~Aaron
>
>
> http://reviews.llvm.org/D13352
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] r249133 - Hopefully rectifying a build bot issue with:

[Aaron Ballman via cfe-commits]

Author: aaronballman
Date: Fri Oct  2 09:01:55 2015
New Revision: 249133

URL: http://llvm.org/viewvc/llvm-project?rev=249133&view=rev
Log:
Hopefully rectifying a build bot issue with:

http://bb.pgr.jp/builders/i686-mingw32-RA-on-linux/builds/2833/steps/build_llvmclang/logs/stdio

Also, drive-by comment fix in a makefile.

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

Modified: clang-tools-extra/trunk/clang-tidy/cert/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/cert/CMakeLists.txt?rev=249133&r1=249132&r2=249133&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/cert/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clang-tidy/cert/CMakeLists.txt Fri Oct  2 09:01:55 
2015
@@ -9,4 +9,6 @@ add_clang_library(clangTidyCERTModule
   clangBasic
   clangLex
   clangTidy
+  clangTidyGoogleModule
+  clangTidyMiscModule
   )

Modified: clang-tools-extra/trunk/clang-tidy/cert/Makefile
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/cert/Makefile?rev=249133&r1=249132&r2=249133&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/cert/Makefile (original)
+++ clang-tools-extra/trunk/clang-tidy/cert/Makefile Fri Oct  2 09:01:55 2015
@@ -1,4 +1,4 @@
-##===- clang-tidy/misc/Makefile *- Makefile 
-*-===##
+##===- clang-tidy/cert/Makefile *- Makefile 
-*-===##
 #
 # The LLVM Compiler Infrastructure
 #


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

Re: [PATCH] D13352: [PATCH] Add a CERT category for clang-tidy checkers

[Aaron Ballman via cfe-commits]

On Fri, Oct 2, 2015 at 9:59 AM, Manuel Klimek  wrote:
> I dont think we need finer grained code owners, but I also don't have real
> objections.

Then we can leave well enough alone. :-)

~Aaron

>
>
> On Fri, Oct 2, 2015, 3:31 PM Aaron Ballman  wrote:
>>
>> aaron.ballman closed this revision.
>> aaron.ballman added a comment.
>>
>> Thanks! I've commit in r249130.
>>
>> Do we want to have code owners for this sort of thing, or is that too
>> fine-grained of a concept? If we do want them, I am (obviously) happy to be
>> the code owner for anything in the CERT directory.
>>
>> ~Aaron
>>
>>
>> http://reviews.llvm.org/D13352
>>
>>
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D12633: Implement ACLE 2.0 macros of chapters 6.6 and 6.7 for [ARM] and [Aarch64] targets

[Richard Barton via cfe-commits]

richard.barton.arm added a comment.

What do you think about this Renato? Although Alexandros has added a LangOption 
which is strictly speaking to do with CodeGen rather than Lang, I think this is 
the only pragmatica way to do this without needing re-engineering work to 
expose the codegen options to this phase in clang.

Are you and I able to make the call to let Alexandros commit, or do you think 
we ought to seek guidance from elsewhere? Do you have an idea who we could go 
to?


http://reviews.llvm.org/D12633



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

Re: [PATCH] D12633: Implement ACLE 2.0 macros of chapters 6.6 and 6.7 for [ARM] and [Aarch64] targets

[Renato Golin via cfe-commits]

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

Sorry, I've been redirected elsewhere for a few days.

I agree that this is the best option, since that's the meaning of the flag, 
anyway.

LGTM.

--renato


http://reviews.llvm.org/D12633



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

[clang-tools-extra] r249136 - Taking a stab at fixing failing build bots that use make. Unfortunately, the build logs do not point to much useful information for tracking this down, such as:

[Aaron Ballman via cfe-commits]

Author: aaronballman
Date: Fri Oct  2 09:28:44 2015
New Revision: 249136

URL: http://llvm.org/viewvc/llvm-project?rev=249136&view=rev
Log:
Taking a stab at fixing failing build bots that use make. Unfortunately, the 
build logs do not point to much useful information for tracking this down, such 
as:

http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/31782/steps/compile/logs/stdio

Modified:
clang-tools-extra/trunk/clang-tidy/tool/Makefile

Modified: clang-tools-extra/trunk/clang-tidy/tool/Makefile
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/tool/Makefile?rev=249136&r1=249135&r2=249136&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/tool/Makefile (original)
+++ clang-tools-extra/trunk/clang-tidy/tool/Makefile Fri Oct  2 09:28:44 2015
@@ -16,10 +16,9 @@ TOOL_NO_EXPORTS = 1
 
 include $(CLANG_LEVEL)/../../Makefile.config
 LINK_COMPONENTS := $(TARGETS_TO_BUILD) asmparser bitreader support mc option
-USEDLIBS = clangTidy.a clangTidyCERTModule.a clangTidyLLVMModule.a \
-   clangTidyGoogleModule.a \ clangTidyMiscModule.a \
-   clangTidyModernizeModule.a clangTidyReadability.a \
-  clangTidyUtils.a clangStaticAnalyzerFrontend.a \
+USEDLIBS = clangTidy.a clangTidyLLVMModule.a clangTidyGoogleModule.a \
+   clangTidyMiscModule.a clangTidyModernizeModule.a 
clangTidyReadability.a \
+  clangTidyUtils.a clangTidyCERTModule.a clangStaticAnalyzerFrontend.a 
\
   clangStaticAnalyzerCheckers.a clangStaticAnalyzerCore.a \
   clangFormat.a clangASTMatchers.a clangTooling.a clangToolingCore.a \
   clangFrontend.a clangSerialization.a clangDriver.a clangParse.a \


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

Re: [PATCH] D10305: [Clang Static Analyzer] Bug identification

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

xazax.hun marked 9 inline comments as done.


Comment at: lib/StaticAnalyzer/Core/BugId.cpp:29
@@ +28,3 @@
+
+static std::string GetSignature(const FunctionDecl *Target) {
+  if (!Target)

zaks.anna wrote:
> Can/Should we use some existing machinery for this? For example, mangleName().
Generating mangled names requires ASTContext which is not available during the 
error reporting. BugReporter does have the ASTContext, so it would not be a big 
change to add it to the DiagnosticConsumers though. And I think the mangled 
name might contain too much redundant information. The only relevant 
information here is the fully qualified name and the parts of the signature 
that can be ocerloaded on e.g.: constness. Using this method might also be 
easier to debug, since the IssueString is more readable.


Comment at: lib/StaticAnalyzer/Core/BugId.cpp:38
@@ +37,3 @@
+
+  switch (Target->getStorageClass()) {
+  case SC_Extern:

zaks.anna wrote:
> Why are these necessary? 
You are right, it is not possible to overload on these properties, so it is 
safe (and even beneficial) to remove them from the hash. 


Comment at: lib/StaticAnalyzer/Core/BugId.cpp:52
@@ +51,3 @@
+
+  if (Target->isInlineSpecified())
+Signature.append("inline ");

zaks.anna wrote:
> Why do we need these in the hash?
We do not need these information (see my previous comment). I removed them from 
the hash.


Comment at: lib/StaticAnalyzer/Core/BugId.cpp:198
@@ +197,3 @@
+std::string clang::GetIssueString(const SourceManager &SM, FullSourceLoc &L,
+  StringRef CheckerName, StringRef HashField,
+  const Decl *D) {

zaks.anna wrote:
> Including the checker name here is not perfect because checker name can 
> easily change from one release of clang to another. For example, when a 
> checker moves to another package.
> 
> I think the best approach here would be to give checkers some unique 
> identifiers and using those here. We can discuss the more if you are 
> interested in solving this problem.
I definitely agree. It would be great to have a unique identifier for checkers 
that is independent from the name/package. It is not a trivial problem however, 
since we probably want to support plugins too. I can think of a similar 
solution like git commit ids, but I think this problem might be out of the 
scope of this patch. But I am happy to start a discussion on the mailing list 
and create a new patch to solve this. 


Comment at: lib/StaticAnalyzer/Core/PlistDiagnostics.cpp:20
@@ -19,2 +19,3 @@
 #include "clang/Lex/Preprocessor.h"
+#include "clang/StaticAnalyzer/Core/AnalyzerOptions.h"
 #include "clang/StaticAnalyzer/Core/BugReporter/PathDiagnostic.h"

zaks.anna wrote:
> Is this needed?
Removed.


Comment at: test/Analysis/model-file.cpp:43
@@ -42,7 +42,3 @@
 // CHECK-NEXT:  
-// CHECK-NEXT:  
-// CHECK-NEXT:   path
-// CHECK-NEXT:   
-// CHECK-NEXT:
-// CHECK-NEXT: kindcontrol
-// CHECK-NEXT: edges
+// CHECK-NEXT:   
+// CHECK-NEXT:path

zaks.anna wrote:
> Extra space in the whole file.
Whatever I do it looks like the whitespaces are not alligned well for this 
file. My guess s that this plist might be generated with an old version of the 
static analyzer. I think it is better to actually update it to the old 
formatting than doing a diff by hand, or writing a script to do just that.


http://reviews.llvm.org/D10305



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

r249137 - Add support for the new mips-mti-linux toolchain.

[Vasileios Kalintiris via cfe-commits]

Author: vkalintiris
Date: Fri Oct  2 09:38:23 2015
New Revision: 249137

URL: http://llvm.org/viewvc/llvm-project?rev=249137&view=rev
Log:
Add support for the new mips-mti-linux toolchain.

Summary:
This new toolchain uses primarily LLVM-based tools, eg. compiler-rt, lld,
libcxx, etc. Because of this, it doesn't require neither an existing GCC
installation nor a GNU environment. Ideally, in a follow-up patch we
would like to add a new --{llvm|clang}-toolchain option (similar to
--gcc-toolchain) in order to allow the use of this toolchain with
independent Clang builds. For the time being, we use the --sysroot
option just to test the correctness of the paths generated by the
driver.

Reviewers: atanasyan, dsanders, rsmith

Subscribers: jfb, tberghammer, danalbert, srhines, dschuff, cfe-commits

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

Added:
cfe/trunk/test/Driver/Inputs/mips_mti_linux/
cfe/trunk/test/Driver/Inputs/mips_mti_linux/lib/
cfe/trunk/test/Driver/Inputs/mips_mti_linux/lib/clang/
cfe/trunk/test/Driver/Inputs/mips_mti_linux/lib/clang/3.8.0/

cfe/trunk/test/Driver/Inputs/mips_mti_linux/lib/clang/3.8.0/mips-r2-hard-musl/

cfe/trunk/test/Driver/Inputs/mips_mti_linux/lib/clang/3.8.0/mips-r2-hard-musl/lib/

cfe/trunk/test/Driver/Inputs/mips_mti_linux/lib/clang/3.8.0/mips-r2-hard-musl/lib/linux/

cfe/trunk/test/Driver/Inputs/mips_mti_linux/lib/clang/3.8.0/mips-r2-hard-musl/lib/linux/libclang_rt.builtins-mips.a

cfe/trunk/test/Driver/Inputs/mips_mti_linux/lib/clang/3.8.0/mips-r2-hard-musl/lib/linux/libclang_rt.builtins-mips.so

cfe/trunk/test/Driver/Inputs/mips_mti_linux/lib/clang/3.8.0/mipsel-r2-hard-musl/

cfe/trunk/test/Driver/Inputs/mips_mti_linux/lib/clang/3.8.0/mipsel-r2-hard-musl/lib/

cfe/trunk/test/Driver/Inputs/mips_mti_linux/lib/clang/3.8.0/mipsel-r2-hard-musl/lib/linux/

cfe/trunk/test/Driver/Inputs/mips_mti_linux/lib/clang/3.8.0/mipsel-r2-hard-musl/lib/linux/libclang_rt.builtins-mipsel.a

cfe/trunk/test/Driver/Inputs/mips_mti_linux/lib/clang/3.8.0/mipsel-r2-hard-musl/lib/linux/libclang_rt.builtins-mipsel.so
cfe/trunk/test/Driver/Inputs/mips_mti_linux/sysroot/
cfe/trunk/test/Driver/Inputs/mips_mti_linux/sysroot/mips-r2-hard-musl/
cfe/trunk/test/Driver/Inputs/mips_mti_linux/sysroot/mips-r2-hard-musl/usr/

cfe/trunk/test/Driver/Inputs/mips_mti_linux/sysroot/mips-r2-hard-musl/usr/lib/

cfe/trunk/test/Driver/Inputs/mips_mti_linux/sysroot/mips-r2-hard-musl/usr/lib/crt1.o

cfe/trunk/test/Driver/Inputs/mips_mti_linux/sysroot/mips-r2-hard-musl/usr/lib/crti.o

cfe/trunk/test/Driver/Inputs/mips_mti_linux/sysroot/mips-r2-hard-musl/usr/lib/crtn.o
cfe/trunk/test/Driver/Inputs/mips_mti_linux/sysroot/mipsel-r2-hard-musl/
cfe/trunk/test/Driver/Inputs/mips_mti_linux/sysroot/mipsel-r2-hard-musl/usr/

cfe/trunk/test/Driver/Inputs/mips_mti_linux/sysroot/mipsel-r2-hard-musl/usr/lib/

cfe/trunk/test/Driver/Inputs/mips_mti_linux/sysroot/mipsel-r2-hard-musl/usr/lib/crt1.o

cfe/trunk/test/Driver/Inputs/mips_mti_linux/sysroot/mipsel-r2-hard-musl/usr/lib/crti.o

cfe/trunk/test/Driver/Inputs/mips_mti_linux/sysroot/mipsel-r2-hard-musl/usr/lib/crtn.o
cfe/trunk/test/Driver/mips-mti-linux.c
Modified:
cfe/trunk/lib/Driver/Driver.cpp
cfe/trunk/lib/Driver/ToolChain.cpp
cfe/trunk/lib/Driver/ToolChains.cpp
cfe/trunk/lib/Driver/ToolChains.h
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/lib/Driver/Tools.h

Modified: cfe/trunk/lib/Driver/Driver.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Driver.cpp?rev=249137&r1=249136&r2=249137&view=diff
==
--- cfe/trunk/lib/Driver/Driver.cpp (original)
+++ cfe/trunk/lib/Driver/Driver.cpp Fri Oct  2 09:38:23 2015
@@ -2122,6 +2122,11 @@ void Driver::generatePrefixedToolNames(
   // FIXME: Needs a better variable than DefaultTargetTriple
   Names.emplace_back(DefaultTargetTriple + "-" + Tool);
   Names.emplace_back(Tool);
+
+  // Allow the discovery of tools prefixed with LLVM's default target triple.
+  std::string LLVMDefaultTargetTriple = llvm::sys::getDefaultTargetTriple();
+  if (LLVMDefaultTargetTriple != DefaultTargetTriple)
+Names.emplace_back(LLVMDefaultTargetTriple + "-" + Tool);
 }
 
 static bool ScanDirForExecutable(SmallString<128> &Dir,
@@ -2217,6 +,9 @@ const ToolChain &Driver::getToolChain(co
 case llvm::Triple::Linux:
   if (Target.getArch() == llvm::Triple::hexagon)
 TC = new toolchains::HexagonToolChain(*this, Target, Args);
+  else if ((Target.getVendor() == llvm::Triple::MipsTechnologies) &&
+   !Target.hasEnvironment())
+TC = new toolchains::MipsLLVMToolChain(*this, Target, Args);
   else
 TC = new toolchains::Linux(*this, Target, Args);
   break;

Modified: cfe/trunk/lib/Driver/ToolChain.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChain.cpp?rev=249137&

Re: [PATCH] D13340: Add support for the new mips-mti-linux toolchain.

[Vasileios Kalintiris via cfe-commits]

This revision was automatically updated to reflect the committed changes.
vkalintiris marked an inline comment as done.
Closed by commit rL249137: Add support for the new mips-mti-linux toolchain. 
(authored by vkalintiris).

Changed prior to commit:
  http://reviews.llvm.org/D13340?vs=36344&id=36365#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D13340

Files:
  cfe/trunk/lib/Driver/Driver.cpp
  cfe/trunk/lib/Driver/ToolChain.cpp
  cfe/trunk/lib/Driver/ToolChains.cpp
  cfe/trunk/lib/Driver/ToolChains.h
  cfe/trunk/lib/Driver/Tools.cpp
  cfe/trunk/lib/Driver/Tools.h
  
cfe/trunk/test/Driver/Inputs/mips_mti_linux/lib/clang/3.8.0/mips-r2-hard-musl/lib/linux/libclang_rt.builtins-mips.a
  
cfe/trunk/test/Driver/Inputs/mips_mti_linux/lib/clang/3.8.0/mips-r2-hard-musl/lib/linux/libclang_rt.builtins-mips.so
  
cfe/trunk/test/Driver/Inputs/mips_mti_linux/lib/clang/3.8.0/mipsel-r2-hard-musl/lib/linux/libclang_rt.builtins-mipsel.a
  
cfe/trunk/test/Driver/Inputs/mips_mti_linux/lib/clang/3.8.0/mipsel-r2-hard-musl/lib/linux/libclang_rt.builtins-mipsel.so
  
cfe/trunk/test/Driver/Inputs/mips_mti_linux/sysroot/mips-r2-hard-musl/usr/lib/crt1.o
  
cfe/trunk/test/Driver/Inputs/mips_mti_linux/sysroot/mips-r2-hard-musl/usr/lib/crti.o
  
cfe/trunk/test/Driver/Inputs/mips_mti_linux/sysroot/mips-r2-hard-musl/usr/lib/crtn.o
  
cfe/trunk/test/Driver/Inputs/mips_mti_linux/sysroot/mipsel-r2-hard-musl/usr/lib/crt1.o
  
cfe/trunk/test/Driver/Inputs/mips_mti_linux/sysroot/mipsel-r2-hard-musl/usr/lib/crti.o
  
cfe/trunk/test/Driver/Inputs/mips_mti_linux/sysroot/mipsel-r2-hard-musl/usr/lib/crtn.o
  cfe/trunk/test/Driver/mips-mti-linux.c

Index: cfe/trunk/test/Driver/mips-mti-linux.c
===
--- cfe/trunk/test/Driver/mips-mti-linux.c
+++ cfe/trunk/test/Driver/mips-mti-linux.c
@@ -0,0 +1,42 @@
+// Check frontend and linker invocations on GPL-free MIPS toolchain.
+//
+// FIXME: Using --sysroot with this toolchain/triple isn't supported. We use
+//it here to test that we are producing the correct paths/flags.
+//Ideally, we'd like to have an --llvm-toolchain option similar to
+//the --gcc-toolchain one.
+
+// = Big-endian, mips32r2, hard float
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: --target=mips-mti-linux -mips32r2 -mhard-float \
+// RUN: --sysroot=%S/Inputs/mips_mti_linux/sysroot \
+// RUN:   | FileCheck --check-prefix=CHECK-BE-HF-32R2 %s
+//
+// CHECK-BE-HF-32R2: "{{.*}}clang" {{.*}} "-triple" "mips-mti-linux"
+// CHECK-BE-HF-32R2-SAME: "-fuse-init-array" "-target-cpu" "mips32r2"
+// CHECK-BE-HF-32R2-SAME: "-isysroot" "{{.*}}mips_mti_linux/sysroot"
+// CHECK-BE-HF-32R2: "lld" "-flavor" "gnu" "-target" "mips-mti-linux"
+// CHECK-BE-HF-32R2-SAME: "--sysroot=[[SYSROOT:[^"]+]]" {{.*}} "-dynamic-linker" "/lib/ld-musl-mips.so.1"
+// CHECK-BE-HF-32R2-SAME: "[[SYSROOT]]/mips-r2-hard-musl/usr/lib/crt1.o"
+// CHECK-BE-HF-32R2-SAME: "[[SYSROOT]]/mips-r2-hard-musl/usr/lib/crti.o"
+// CHECK-BE-HF-32R2-SAME: "-L[[SYSROOT]]/mips-r2-hard-musl/usr/lib"
+// CHECK-BE-HF-32R2-SAME: "{{[^"]+}}/mips-r2-hard-musl/lib/linux/libclang_rt.builtins-mips.a"
+// CHECK-BE-HF-32R2-SAME: "-lc"
+// CHECK-BE-HF-32R2-SAME: "[[SYSROOT]]/mips-r2-hard-musl/usr/lib/crtn.o"
+
+// = Little-endian, mips32r2, hard float
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: --target=mips-mti-linux -mips32r2 -EL -mhard-float \
+// RUN: --sysroot=%S/Inputs/mips_mti_linux/sysroot \
+// RUN:   | FileCheck --check-prefix=CHECK-LE-HF-32R2 %s
+//
+// CHECK-LE-HF-32R2: "{{.*}}clang" {{.*}} "-triple" "mipsel-mti-linux"
+// CHECK-LE-HF-32R2-SAME: "-fuse-init-array" "-target-cpu" "mips32r2"
+// CHECK-LE-HF-32R2-SAME: "-isysroot" "{{.*}}mips_mti_linux/sysroot"
+// CHECK-LE-HF-32R2: "lld" "-flavor" "gnu" "-target" "mipsel-mti-linux"
+// CHECK-LE-HF-32R2-SAME: "--sysroot=[[SYSROOT:[^"]+]]" {{.*}} "-dynamic-linker" "/lib/ld-musl-mipsel.so.1"
+// CHECK-LE-HF-32R2-SAME: "[[SYSROOT]]/mipsel-r2-hard-musl/usr/lib/crt1.o"
+// CHECK-LE-HF-32R2-SAME: "[[SYSROOT]]/mipsel-r2-hard-musl/usr/lib/crti.o"
+// CHECK-LE-HF-32R2-SAME: "-L[[SYSROOT]]/mipsel-r2-hard-musl/usr/lib"
+// CHECK-LE-HF-32R2-SAME: "{{[^"]+}}/mipsel-r2-hard-musl/lib/linux/libclang_rt.builtins-mipsel.a"
+// CHECK-LE-HF-32R2-SAME: "-lc"
+// CHECK-LE-HF-32R2-SAME: "[[SYSROOT]]/mipsel-r2-hard-musl/usr/lib/crtn.o"
Index: cfe/trunk/lib/Driver/ToolChain.cpp
===
--- cfe/trunk/lib/Driver/ToolChain.cpp
+++ cfe/trunk/lib/Driver/ToolChain.cpp
@@ -315,7 +315,6 @@
 
 std::string ToolChain::GetFilePath(const char *Name) const {
   return D.GetFilePath(Name, *this);
-
 }
 
 std::string ToolChain::GetProgramPath(const char *Name) const {
Index: cfe/trunk/lib/Driver/ToolChains.h
===
--- cfe/trunk/lib/Driver/ToolChains.h
+++ cfe/trunk/lib/Driver/ToolChains.h
@@ -724,6 +724,7 @@
  

r249138 - Fix bogus comment.

[Douglas Katzman via cfe-commits]

Author: dougk
Date: Fri Oct  2 09:41:38 2015
New Revision: 249138

URL: http://llvm.org/viewvc/llvm-project?rev=249138&view=rev
Log:
Fix bogus comment.

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

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=249138&r1=249137&r2=249138&view=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Fri Oct  2 09:41:38 2015
@@ -402,7 +402,7 @@ void Clang::AddPreprocessingOptions(Comp
   {options::OPT_D, options::OPT_U, options::OPT_I_Group,
options::OPT_F, options::OPT_index_header_map});
 
-  // Add -Wp, and -Xassembler if using the preprocessor.
+  // Add -Wp, and -Xpreprocessor if using the preprocessor.
 
   // FIXME: There is a very unfortunate problem here, some troubled
   // souls abuse -Wp, to pass preprocessor options in gcc syntax. To


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

r249140 - Implement ACLE 2.0 macros of chapters 6.6 and 6.7 for [ARM] and [Aarch64] targets.

[Alexandros Lamprineas via cfe-commits]

Author: alelab01
Date: Fri Oct  2 09:56:37 2015
New Revision: 249140

URL: http://llvm.org/viewvc/llvm-project?rev=249140&view=rev
Log:
Implement ACLE 2.0 macros of chapters 6.6 and 6.7 for [ARM] and [Aarch64] 
targets.

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

Modified:
cfe/trunk/include/clang/Basic/LangOptions.def
cfe/trunk/lib/Basic/Targets.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/test/Preprocessor/aarch64-target-features.c
cfe/trunk/test/Preprocessor/arm-target-features.c

Modified: cfe/trunk/include/clang/Basic/LangOptions.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/LangOptions.def?rev=249140&r1=249139&r2=249140&view=diff
==
--- cfe/trunk/include/clang/Basic/LangOptions.def (original)
+++ cfe/trunk/include/clang/Basic/LangOptions.def Fri Oct  2 09:56:37 2015
@@ -146,6 +146,7 @@ COMPATIBLE_LANGOPT(NoInlineDefine, 1
 COMPATIBLE_LANGOPT(Deprecated, 1, 0, "__DEPRECATED predefined macro")
 LANGOPT(FastMath  , 1, 0, "__FAST_MATH__ predefined macro")
 LANGOPT(FiniteMathOnly, 1, 0, "__FINITE_MATH_ONLY__ predefined macro")
+LANGOPT(UnsafeFPMath  , 1, 0, "Unsafe Floating Point Math")
 
 BENIGN_LANGOPT(ObjCGCBitmapPrint , 1, 0, "printing of GC's bitmap layout for 
__weak/__strong ivars")
 

Modified: cfe/trunk/lib/Basic/Targets.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=249140&r1=249139&r2=249140&view=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Fri Oct  2 09:56:37 2015
@@ -4751,6 +4751,9 @@ public:
 // ACLE 6.4.6 Q (saturation) flag
 if (DSP || SAT)
   Builder.defineMacro("__ARM_FEATURE_QBIT", "1");
+
+if (Opts.UnsafeFPMath)
+  Builder.defineMacro("__ARM_FP_FAST", "1");
   }
 
   void getTargetBuiltins(const Builtin::Info *&Records,
@@ -5204,7 +5207,7 @@ public:
 Builder.defineMacro("__ARM_ARCH_PROFILE", "'A'");
 
 Builder.defineMacro("__ARM_64BIT_STATE", "1");
-Builder.defineMacro("__ARM_PCS_AAPCS64");
+Builder.defineMacro("__ARM_PCS_AAPCS64", "1");
 Builder.defineMacro("__ARM_ARCH_ISA_A64", "1");
 
 Builder.defineMacro("__ARM_FEATURE_CLZ", "1");
@@ -5225,11 +5228,8 @@ public:
 Builder.defineMacro("__ARM_FP16_FORMAT_IEEE", "1");
 Builder.defineMacro("__ARM_FP16_ARGS", "1");
 
-if (Opts.FastMath || Opts.FiniteMathOnly)
-  Builder.defineMacro("__ARM_FP_FAST");
-
-if (Opts.C99 && !Opts.Freestanding)
-  Builder.defineMacro("__ARM_FP_FENV_ROUNDING");
+if (Opts.UnsafeFPMath)
+  Builder.defineMacro("__ARM_FP_FAST", "1");
 
 Builder.defineMacro("__ARM_SIZEOF_WCHAR_T", Opts.ShortWChar ? "2" : "4");
 

Modified: cfe/trunk/lib/Frontend/CompilerInvocation.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/CompilerInvocation.cpp?rev=249140&r1=249139&r2=249140&view=diff
==
--- cfe/trunk/lib/Frontend/CompilerInvocation.cpp (original)
+++ cfe/trunk/lib/Frontend/CompilerInvocation.cpp Fri Oct  2 09:56:37 2015
@@ -1708,6 +1708,9 @@ static void ParseLangArgs(LangOptions &O
   Opts.FiniteMathOnly = Args.hasArg(OPT_ffinite_math_only) ||
   Args.hasArg(OPT_cl_finite_math_only) ||
   Args.hasArg(OPT_cl_fast_relaxed_math);
+  Opts.UnsafeFPMath = Args.hasArg(OPT_menable_unsafe_fp_math) ||
+  Args.hasArg(OPT_cl_unsafe_math_optimizations) ||
+  Args.hasArg(OPT_cl_fast_relaxed_math);
 
   Opts.RetainCommentsFromSystemHeaders =
   Args.hasArg(OPT_fretain_comments_from_system_headers);

Modified: cfe/trunk/test/Preprocessor/aarch64-target-features.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Preprocessor/aarch64-target-features.c?rev=249140&r1=249139&r2=249140&view=diff
==
--- cfe/trunk/test/Preprocessor/aarch64-target-features.c (original)
+++ cfe/trunk/test/Preprocessor/aarch64-target-features.c Fri Oct  2 09:56:37 
2015
@@ -30,10 +30,11 @@
 // CHECK: __ARM_FP16_ARGS 1
 // CHECK: __ARM_FP16_FORMAT_IEEE 1
 // CHECK-NOT: __ARM_FP_FAST 1
-// CHECK: __ARM_FP_FENV_ROUNDING 1
 // CHECK: __ARM_NEON 1
 // CHECK: __ARM_NEON_FP 0xE
 // CHECK: __ARM_PCS_AAPCS64 1
+// CHECK-NOT: __ARM_PCS 1
+// CHECK-NOT: __ARM_PCS_VFP 1
 // CHECK-NOT: __ARM_SIZEOF_MINIMAL_ENUM 1
 // CHECK-NOT: __ARM_SIZEOF_WCHAR_T 2
 
@@ -50,6 +51,9 @@
 // RUN: %clang -target arm64-none-linux-gnu -march=armv8-a+crc -x c -E -dM %s 
-o - | FileCheck --check-prefix=CHECK-CRC32 %s
 // CHECK-CRC32: __ARM_FEATURE_CRC32 1
 
+// RUN: %clang -target aarch64-none-linux-gnu -fno-math-errno 
-fno-signed-zeros\
+// RUN:-fno-trapping-math -fassociative-math -freciprocal-math\
+// RUN:-x c -E -dM %s -o - | FileCheck --check-pre

Re: [PATCH] D12633: Implement ACLE 2.0 macros of chapters 6.6 and 6.7 for [ARM] and [Aarch64] targets

[Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL249140: Implement ACLE 2.0 macros of chapters 6.6 and 6.7 
for [ARM] and [Aarch64]… (authored by alelab01).

Changed prior to commit:
  http://reviews.llvm.org/D12633?vs=35628&id=36367#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D12633

Files:
  cfe/trunk/include/clang/Basic/LangOptions.def
  cfe/trunk/lib/Basic/Targets.cpp
  cfe/trunk/lib/Frontend/CompilerInvocation.cpp
  cfe/trunk/test/Preprocessor/aarch64-target-features.c
  cfe/trunk/test/Preprocessor/arm-target-features.c

Index: cfe/trunk/include/clang/Basic/LangOptions.def
===
--- cfe/trunk/include/clang/Basic/LangOptions.def
+++ cfe/trunk/include/clang/Basic/LangOptions.def
@@ -146,6 +146,7 @@
 COMPATIBLE_LANGOPT(Deprecated, 1, 0, "__DEPRECATED predefined macro")
 LANGOPT(FastMath  , 1, 0, "__FAST_MATH__ predefined macro")
 LANGOPT(FiniteMathOnly, 1, 0, "__FINITE_MATH_ONLY__ predefined macro")
+LANGOPT(UnsafeFPMath  , 1, 0, "Unsafe Floating Point Math")
 
 BENIGN_LANGOPT(ObjCGCBitmapPrint , 1, 0, "printing of GC's bitmap layout for __weak/__strong ivars")
 
Index: cfe/trunk/test/Preprocessor/arm-target-features.c
===
--- cfe/trunk/test/Preprocessor/arm-target-features.c
+++ cfe/trunk/test/Preprocessor/arm-target-features.c
@@ -32,6 +32,7 @@
 // CHECK-V8-BAREHF: __ARM_FEATURE_DIRECTED_ROUNDING 1
 // CHECK-V8-BAREHF: __ARM_FEATURE_NUMERIC_MAXMIN 1
 // CHECK-V8-BAREHF: __ARM_NEON__ 1
+// CHECK-V8-BAREHF: __ARM_PCS_VFP 1
 // CHECK-V8-BAREHF: __VFP_FP__ 1
 
 // RUN: %clang -target armv8a -mfloat-abi=hard -mfpu=fp-armv8 -x c -E -dM %s | FileCheck --check-prefix=CHECK-V8-BAREHF-FP %s
@@ -85,9 +86,17 @@
 // THUMBV8A-EABI:#define __ARM_ARCH_EXT_IDIV__ 1
 
 // RUN: %clang -target arm-none-linux-gnu -x c -E -dM %s -o - | FileCheck --check-prefix=CHECK-DEFS %s
+// CHECK-DEFS:#define __ARM_PCS 1
 // CHECK-DEFS:#define __ARM_SIZEOF_MINIMAL_ENUM 4
 // CHECK-DEFS:#define __ARM_SIZEOF_WCHAR_T 4
 
+// RUN: %clang -target arm-none-linux-gnu -fno-math-errno -fno-signed-zeros\
+// RUN:-fno-trapping-math -fassociative-math -freciprocal-math\
+// RUN:-x c -E -dM %s -o - | FileCheck --check-prefix=CHECK-FASTMATH %s
+// RUN: %clang -target arm-none-linux-gnu -ffast-math -x c -E -dM %s -o -\
+// RUN:| FileCheck --check-prefix=CHECK-FASTMATH %s
+// CHECK-FASTMATH: __ARM_FP_FAST 1
+
 // RUN: %clang -target arm-none-linux-gnu -fshort-wchar -x c -E -dM %s -o - | FileCheck --check-prefix=CHECK-SHORTWCHAR %s
 // CHECK-SHORTWCHAR:#define __ARM_SIZEOF_WCHAR_T 2
 
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
@@ -30,10 +30,11 @@
 // CHECK: __ARM_FP16_ARGS 1
 // CHECK: __ARM_FP16_FORMAT_IEEE 1
 // CHECK-NOT: __ARM_FP_FAST 1
-// CHECK: __ARM_FP_FENV_ROUNDING 1
 // CHECK: __ARM_NEON 1
 // CHECK: __ARM_NEON_FP 0xE
 // CHECK: __ARM_PCS_AAPCS64 1
+// CHECK-NOT: __ARM_PCS 1
+// CHECK-NOT: __ARM_PCS_VFP 1
 // CHECK-NOT: __ARM_SIZEOF_MINIMAL_ENUM 1
 // CHECK-NOT: __ARM_SIZEOF_WCHAR_T 2
 
@@ -50,6 +51,9 @@
 // RUN: %clang -target arm64-none-linux-gnu -march=armv8-a+crc -x c -E -dM %s -o - | FileCheck --check-prefix=CHECK-CRC32 %s
 // CHECK-CRC32: __ARM_FEATURE_CRC32 1
 
+// RUN: %clang -target aarch64-none-linux-gnu -fno-math-errno -fno-signed-zeros\
+// RUN:-fno-trapping-math -fassociative-math -freciprocal-math\
+// RUN:-x c -E -dM %s -o - | FileCheck --check-prefix=CHECK-FASTMATH %s
 // RUN: %clang -target aarch64-none-linux-gnu -ffast-math -x c -E -dM %s -o - | FileCheck --check-prefix=CHECK-FASTMATH %s
 // RUN: %clang -target arm64-none-linux-gnu -ffast-math -x c -E -dM %s -o - | FileCheck --check-prefix=CHECK-FASTMATH %s
 // CHECK-FASTMATH: __ARM_FP_FAST 1
Index: cfe/trunk/lib/Basic/Targets.cpp
===
--- cfe/trunk/lib/Basic/Targets.cpp
+++ cfe/trunk/lib/Basic/Targets.cpp
@@ -4751,6 +4751,9 @@
 // ACLE 6.4.6 Q (saturation) flag
 if (DSP || SAT)
   Builder.defineMacro("__ARM_FEATURE_QBIT", "1");
+
+if (Opts.UnsafeFPMath)
+  Builder.defineMacro("__ARM_FP_FAST", "1");
   }
 
   void getTargetBuiltins(const Builtin::Info *&Records,
@@ -5204,7 +5207,7 @@
 Builder.defineMacro("__ARM_ARCH_PROFILE", "'A'");
 
 Builder.defineMacro("__ARM_64BIT_STATE", "1");
-Builder.defineMacro("__ARM_PCS_AAPCS64");
+Builder.defineMacro("__ARM_PCS_AAPCS64", "1");
 Builder.defineMacro("__ARM_ARCH_ISA_A64", "1");
 
 Builder.defineMacro("__ARM_FEATURE_CLZ", "1");
@@ -5225,11 +5228,8 @@
 Builder.defineMacro("__ARM_FP16_FORMAT_IEEE", "1");
 Builder.defineMacro("__ARM_FP16_ARGS", "1");
 
-if (Opts.FastMath || Opts.Finite

r249141 - Revert "Add support for the new mips-mti-linux toolchain."

[Vasileios Kalintiris via cfe-commits]

Author: vkalintiris
Date: Fri Oct  2 10:00:55 2015
New Revision: 249141

URL: http://llvm.org/viewvc/llvm-project?rev=249141&view=rev
Log:
Revert "Add support for the new mips-mti-linux toolchain."

This reverts commit r249137 because it broke the Windows buildbots and
a Linux buildbot for LLD.

Removed:

cfe/trunk/test/Driver/Inputs/mips_mti_linux/lib/clang/3.8.0/mips-r2-hard-musl/lib/linux/libclang_rt.builtins-mips.a

cfe/trunk/test/Driver/Inputs/mips_mti_linux/lib/clang/3.8.0/mips-r2-hard-musl/lib/linux/libclang_rt.builtins-mips.so

cfe/trunk/test/Driver/Inputs/mips_mti_linux/lib/clang/3.8.0/mipsel-r2-hard-musl/lib/linux/libclang_rt.builtins-mipsel.a

cfe/trunk/test/Driver/Inputs/mips_mti_linux/lib/clang/3.8.0/mipsel-r2-hard-musl/lib/linux/libclang_rt.builtins-mipsel.so

cfe/trunk/test/Driver/Inputs/mips_mti_linux/sysroot/mips-r2-hard-musl/usr/lib/crt1.o

cfe/trunk/test/Driver/Inputs/mips_mti_linux/sysroot/mips-r2-hard-musl/usr/lib/crti.o

cfe/trunk/test/Driver/Inputs/mips_mti_linux/sysroot/mips-r2-hard-musl/usr/lib/crtn.o

cfe/trunk/test/Driver/Inputs/mips_mti_linux/sysroot/mipsel-r2-hard-musl/usr/lib/crt1.o

cfe/trunk/test/Driver/Inputs/mips_mti_linux/sysroot/mipsel-r2-hard-musl/usr/lib/crti.o

cfe/trunk/test/Driver/Inputs/mips_mti_linux/sysroot/mipsel-r2-hard-musl/usr/lib/crtn.o
cfe/trunk/test/Driver/mips-mti-linux.c
Modified:
cfe/trunk/lib/Driver/Driver.cpp
cfe/trunk/lib/Driver/ToolChain.cpp
cfe/trunk/lib/Driver/ToolChains.cpp
cfe/trunk/lib/Driver/ToolChains.h
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/lib/Driver/Tools.h

Modified: cfe/trunk/lib/Driver/Driver.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Driver.cpp?rev=249141&r1=249140&r2=249141&view=diff
==
--- cfe/trunk/lib/Driver/Driver.cpp (original)
+++ cfe/trunk/lib/Driver/Driver.cpp Fri Oct  2 10:00:55 2015
@@ -2122,11 +2122,6 @@ void Driver::generatePrefixedToolNames(
   // FIXME: Needs a better variable than DefaultTargetTriple
   Names.emplace_back(DefaultTargetTriple + "-" + Tool);
   Names.emplace_back(Tool);
-
-  // Allow the discovery of tools prefixed with LLVM's default target triple.
-  std::string LLVMDefaultTargetTriple = llvm::sys::getDefaultTargetTriple();
-  if (LLVMDefaultTargetTriple != DefaultTargetTriple)
-Names.emplace_back(LLVMDefaultTargetTriple + "-" + Tool);
 }
 
 static bool ScanDirForExecutable(SmallString<128> &Dir,
@@ -,9 +2217,6 @@ const ToolChain &Driver::getToolChain(co
 case llvm::Triple::Linux:
   if (Target.getArch() == llvm::Triple::hexagon)
 TC = new toolchains::HexagonToolChain(*this, Target, Args);
-  else if ((Target.getVendor() == llvm::Triple::MipsTechnologies) &&
-   !Target.hasEnvironment())
-TC = new toolchains::MipsLLVMToolChain(*this, Target, Args);
   else
 TC = new toolchains::Linux(*this, Target, Args);
   break;

Modified: cfe/trunk/lib/Driver/ToolChain.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChain.cpp?rev=249141&r1=249140&r2=249141&view=diff
==
--- cfe/trunk/lib/Driver/ToolChain.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChain.cpp Fri Oct  2 10:00:55 2015
@@ -315,6 +315,7 @@ Tool *ToolChain::SelectTool(const JobAct
 
 std::string ToolChain::GetFilePath(const char *Name) const {
   return D.GetFilePath(Name, *this);
+
 }
 
 std::string ToolChain::GetProgramPath(const char *Name) const {

Modified: cfe/trunk/lib/Driver/ToolChains.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains.cpp?rev=249141&r1=249140&r2=249141&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains.cpp Fri Oct  2 10:00:55 2015
@@ -1301,9 +1301,8 @@ bool Generic_GCC::GCCInstallationDetecto
   "i586-linux-gnu"};
 
   static const char *const MIPSLibDirs[] = {"/lib"};
-  static const char *const MIPSTriples[] = {"mips-linux-gnu", "mips-mti-linux",
-"mips-mti-linux-gnu",
-"mips-img-linux-gnu"};
+  static const char *const MIPSTriples[] = {
+  "mips-linux-gnu", "mips-mti-linux-gnu", "mips-img-linux-gnu"};
   static const char *const MIPSELLibDirs[] = {"/lib"};
   static const char *const MIPSELTriples[] = {
   "mipsel-linux-gnu", "mipsel-linux-android", "mips-img-linux-gnu"};
@@ -1692,32 +1691,6 @@ static bool findMIPSMultilibs(const llvm
 });
   }
 
-  // Check for Musl toolchain multilibs
-  MultilibSet MuslMipsMultilibs;
-  {
-auto MArchMipsR2 = makeMultilib("")
-   .osSuffix("/mips-r2-hard-musl")
-   .flag("+EB")
-   .flag("-EL")
-   .flag("+ma

[PATCH] D13386: PR24115: Don't instantiate constexpr function templates in decltype

[Stephan Bergmann via cfe-commits]

sberg created this revision.
sberg added reviewers: cfe-commits, rsmith.

As discussed in [[ https://llvm.org/bugs/show_bug.cgi?id=24115 | "llvm-nm fails 
to build with gcc 5.1's libstdc++," ]] both llvm-nm and LibreOffice fail to 
build against GCC 5.1 libstdc++, due to Clang trying (and failing) to 
instantiate constexpr function templates referenced from within a decltype.
See [[ 
https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/6udLpHDvShU 
| "Implicit instantiation of constexpr function template specialization called 
in decltype expression?" ]] for a stripped-down test case and a discussion why 
the Clang behaviour is considered wrong.
There is a comment in test/SemaTemplate/constexpr-instantiate.cpp claiming this 
behaviour is in line with g++, but I cannot reproduce that neither with some 
GCC 5.1.1 nor with a recent GCC trunk build.  The comment also says "FIXME: 
None of this is required by the C++ standard. The rules in this area are poorly 
specified, so this is subject to change.", and from the above build breakage I 
think it would be best to change the behaviour to not instantiate constexpr 
function templates merely because they are referenced from within a decltype.  
(Doing so of course breaks the test corresponding to that comment, so turn that 
test around to check the changed behaviour now.)

http://reviews.llvm.org/D13386

Files:
  lib/Sema/SemaExpr.cpp
  test/SemaTemplate/constexpr-instantiate.cpp

Index: test/SemaTemplate/constexpr-instantiate.cpp
===
--- test/SemaTemplate/constexpr-instantiate.cpp
+++ test/SemaTemplate/constexpr-instantiate.cpp
@@ -77,37 +77,23 @@
 }
 
 namespace Unevaluated {
-  // We follow g++ in treating any reference to a constexpr function template
-  // specialization as requiring an instantiation, even if it occurs in an
-  // unevaluated context.
-  //
-  // We go slightly further than g++, and also trigger the implicit definition
-  // of a defaulted special member in the same circumstances. This seems scary,
-  // since a lot of classes have constexpr special members in C++11, but the
-  // only observable impact should be the implicit instantiation of constexpr
-  // special member templates (defaulted special members should only be
-  // generated if they are well-formed, and non-constexpr special members in a
-  // base or member cause the class's special member to not be constexpr).
-  //
-  // FIXME: None of this is required by the C++ standard. The rules in this
-  //area are poorly specified, so this is subject to change.
   namespace NotConstexpr {
 template struct S {
   S() : n(0) {}
   S(const S&) : n(T::error) {}
   int n;
 };
 struct U : S {};
-decltype(U(U())) u; // ok, don't instantiate S::S() because it wasn't 
declared constexpr
+decltype(U(U())) u; // ok, don't instantiate S::S()
   }
   namespace Constexpr {
 template struct S {
   constexpr S() : n(0) {}
-  constexpr S(const S&) : n(T::error) {} // expected-error {{has no 
members}}
+  constexpr S(const S&) : n(T::error) {}
   int n;
 };
-struct U : S {}; // expected-note {{instantiation}}
-decltype(U(U())) u; // expected-note {{here}}
+struct U : S {};
+decltype(U(U())) u; // ok, don't instantiate S::S()
   }
 
   namespace PR11851_Comment0 {
Index: lib/Sema/SemaExpr.cpp
===
--- lib/Sema/SemaExpr.cpp
+++ lib/Sema/SemaExpr.cpp
@@ -12414,7 +12414,8 @@
 // However, they cannot be referenced if they are deleted, and they are
 // deleted whenever the implicit definition of the special member would
 // fail.
-if (!Func->isConstexpr() || Func->getBody())
+if (!Func->isConstexpr() || Func->getBody() ||
+ExprEvalContexts.back().IsDecltype)
   return;
 CXXMethodDecl *MD = dyn_cast(Func);
 if (!Func->isImplicitlyInstantiable() && (!MD || MD->isUserProvided()))


Index: test/SemaTemplate/constexpr-instantiate.cpp
===
--- test/SemaTemplate/constexpr-instantiate.cpp
+++ test/SemaTemplate/constexpr-instantiate.cpp
@@ -77,37 +77,23 @@
 }
 
 namespace Unevaluated {
-  // We follow g++ in treating any reference to a constexpr function template
-  // specialization as requiring an instantiation, even if it occurs in an
-  // unevaluated context.
-  //
-  // We go slightly further than g++, and also trigger the implicit definition
-  // of a defaulted special member in the same circumstances. This seems scary,
-  // since a lot of classes have constexpr special members in C++11, but the
-  // only observable impact should be the implicit instantiation of constexpr
-  // special member templates (defaulted special members should only be
-  // generated if they are well-formed, and non-constexpr special members in a
-  // base or member cause the class's special member to not be c

r249142 - Make test more resilient to FastIsel changes. NFC.

[Andrea Di Biagio via cfe-commits]

Author: adibiagio
Date: Fri Oct  2 10:10:22 2015
New Revision: 249142

URL: http://llvm.org/viewvc/llvm-project?rev=249142&view=rev
Log:
Make test more resilient to FastIsel changes. NFC.

Currently FastISel doesn't know how to select vector bitcasts.
During instruction selection, fast-isel always falls back to SelectionDAG 
every time it encounters a vector bitcast.
As a consequence of this, all the 'packed vector shift by immedate count'
test cases in avx2-builtins.c are optimized by the DAGCombiner.
In particular, the DAGCombiner would always fold trivial stack loads of
constant shift counts into the operands of packed shift builtins.

This behavior would start changing as soon as I reapply revision 249121.
That revision would teach x86 fast-isel how to select bitcasts between vector
types of the same size.

As a consequence of that change, fast-isel would less often fall back to
SelectionDAG. More importantly, DAGCombiner would no longer be able to 
simplify the code by folding the stack reload of a constant.

No functional change.

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

Modified: cfe/trunk/test/CodeGen/avx2-builtins.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/avx2-builtins.c?rev=249142&r1=249141&r2=249142&view=diff
==
--- cfe/trunk/test/CodeGen/avx2-builtins.c (original)
+++ cfe/trunk/test/CodeGen/avx2-builtins.c Fri Oct  2 10:10:22 2015
@@ -574,7 +574,7 @@ __m256i test_mm256_bslli_epi128(__m256i
 
 __m256i test_mm256_slli_epi16(__m256i a) {
   // CHECK: @llvm.x86.avx2.pslli.w
-  // CHECK-ASM: vpsllw $3, %ymm{{.*}}, %ymm{{.*}}
+  // CHECK-ASM: vpsllw {{\$3|%xmm[0-9]+}}, %ymm{{.*}}, %ymm{{.*}}
   return _mm256_slli_epi16(a, 3);
 }
 
@@ -586,7 +586,7 @@ __m256i test_mm256_sll_epi16(__m256i a,
 
 __m256i test_mm256_slli_epi32(__m256i a) {
   // CHECK: @llvm.x86.avx2.pslli.d
-  // CHECK-ASM: vpslld $3, %ymm{{.*}}, %ymm{{.*}}
+  // CHECK-ASM: vpslld {{\$3|%xmm[0-9]+}}, %ymm{{.*}}, %ymm{{.*}}
   return _mm256_slli_epi32(a, 3);
 }
 
@@ -610,7 +610,7 @@ __m256i test_mm256_sll_epi64(__m256i a,
 
 __m256i test_mm256_srai_epi16(__m256i a) {
   // CHECK: @llvm.x86.avx2.psrai.w
-  // CHECK-ASM: vpsraw $3, %ymm{{.*}}, %ymm{{.*}}
+  // CHECK-ASM: vpsraw {{\$3|%xmm[0-9]+}}, %ymm{{.*}}, %ymm{{.*}}
   return _mm256_srai_epi16(a, 3);
 }
 
@@ -622,7 +622,7 @@ __m256i test_mm256_sra_epi16(__m256i a,
 
 __m256i test_mm256_srai_epi32(__m256i a) {
   // CHECK: @llvm.x86.avx2.psrai.d
-  // CHECK-ASM: vpsrad $3, %ymm{{.*}}, %ymm{{.*}}
+  // CHECK-ASM: vpsrad {{\$3|%xmm[0-9]+}}, %ymm{{.*}}, %ymm{{.*}}
   return _mm256_srai_epi32(a, 3);
 }
 
@@ -646,7 +646,7 @@ __m256i test_mm256_bsrli_epi128(__m256i
 
 __m256i test_mm256_srli_epi16(__m256i a) {
   // CHECK: @llvm.x86.avx2.psrli.w
-  // CHECK-ASM: vpsrlw $3, %ymm{{.*}}, %ymm{{.*}}
+  // CHECK-ASM: vpsrlw {{\$3|%xmm[0-9]+}}, %ymm{{.*}}, %ymm{{.*}}
   return _mm256_srli_epi16(a, 3);
 }
 
@@ -658,7 +658,7 @@ __m256i test_mm256_srl_epi16(__m256i a,
 
 __m256i test_mm256_srli_epi32(__m256i a) {
   // CHECK: @llvm.x86.avx2.psrli.d
-  // CHECK-ASM: vpsrld $3, %ymm{{.*}}, %ymm{{.*}}
+  // CHECK-ASM: vpsrld {{\$3|%xmm[0-9]+}}, %ymm{{.*}}, %ymm{{.*}}
   return _mm256_srli_epi32(a, 3);
 }
 


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

r249143 - [DarwinDriver] Reapply: Use -lto_library to specify the path for libLTO.dylib

[Bruno Cardoso Lopes via cfe-commits]

Author: bruno
Date: Fri Oct  2 10:10:33 2015
New Revision: 249143

URL: http://llvm.org/viewvc/llvm-project?rev=249143&view=rev
Log:
[DarwinDriver] Reapply: Use -lto_library to specify the path for libLTO.dylib

Reapply r248935.

Usually, when using LTO with a clang installation newer than the
system's one, there's a libLTO.dylib version mismatch and LTO fails. One
solution to this is to make ld point to the right libLTO.dylib by
changing DYLD_LIBRARY_PATH.

However, ld64 supports specifying the complete path to the desired
libLTO.dylib through the -lto_library option. This commit adds support
for the clang driver to use this option whenever it's capable of finding
a libLTO.dylib in clang's installed library directory. This way, we
don't need to rely on DYLD_LIBRARY_PATH nor get caught by version
mismatches.

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

rdar://problem/7363476

Added:
cfe/trunk/test/Driver/darwin-ld-lto.c
Modified:
cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
cfe/trunk/include/clang/Basic/DiagnosticGroups.td
cfe/trunk/lib/Driver/Tools.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td?rev=249143&r1=249142&r2=249143&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td Fri Oct  2 10:10:33 
2015
@@ -117,6 +117,8 @@ def err_drv_optimization_remark_pattern
 def err_drv_no_neon_modifier : Error<"[no]neon is not accepted as modifier, 
please use [no]simd instead">;
 
 def warn_O4_is_O3 : Warning<"-O4 is equivalent to -O3">, InGroup;
+def warn_drv_lto_libpath : Warning<"libLTO.dylib relative to clang installed 
dir not found; using 'ld' default search path instead">,
+  InGroup;
 def warn_drv_optimization_value : Warning<"optimization level '%0' is not 
supported; using '%1%2' instead">,
   InGroup;
 def warn_ignored_gcc_optimization : Warning<"optimization flag '%0' is not 
supported">,

Modified: cfe/trunk/include/clang/Basic/DiagnosticGroups.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticGroups.td?rev=249143&r1=249142&r2=249143&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticGroups.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticGroups.td Fri Oct  2 10:10:33 2015
@@ -96,6 +96,7 @@ def Deprecated : DiagGroup<"deprecated",
   DeprecatedWritableStr]>,
  DiagCategory<"Deprecations">;
 
+def LibLTO : DiagGroup<"liblto">;
 def : DiagGroup<"disabled-optimization">;
 def : DiagGroup<"discard-qual">;
 def : DiagGroup<"div-by-zero">;

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=249143&r1=249142&r2=249143&view=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Fri Oct  2 10:10:33 2015
@@ -6502,15 +6502,34 @@ void darwin::Linker::AddLinkArgs(Compila
options::OPT_fno_application_extension, false))
 CmdArgs.push_back("-application_extension");
 
-  // If we are using LTO, then automatically create a temporary file path for
-  // the linker to use, so that it's lifetime will extend past a possible
-  // dsymutil step.
-  if (Version[0] >= 116 && D.IsUsingLTO(Args) && NeedsTempPath(Inputs)) {
-const char *TmpPath = C.getArgs().MakeArgString(
-D.GetTemporaryPath("cc", types::getTypeTempSuffix(types::TY_Object)));
-C.addTempFile(TmpPath);
-CmdArgs.push_back("-object_path_lto");
-CmdArgs.push_back(TmpPath);
+  if (D.IsUsingLTO(Args)) {
+// If we are using LTO, then automatically create a temporary file path for
+// the linker to use, so that it's lifetime will extend past a possible
+// dsymutil step.
+if (Version[0] >= 116 && NeedsTempPath(Inputs)) {
+  const char *TmpPath = C.getArgs().MakeArgString(
+  D.GetTemporaryPath("cc", 
types::getTypeTempSuffix(types::TY_Object)));
+  C.addTempFile(TmpPath);
+  CmdArgs.push_back("-object_path_lto");
+  CmdArgs.push_back(TmpPath);
+}
+
+// Use -lto_library option to specify the libLTO.dylib path. Try to find
+// it in clang installed libraries. If not found, the option is not used
+// and 'ld' will use its default mechanism to search for libLTO.dylib.
+if (Version[0] >= 133) {
+  // Search for libLTO in /../lib/libLTO.dylib
+  StringRef P = llvm::sys::path::parent_path(D.getInstalledDir());
+  SmallString<128> LibLTOPath(P);
+  llvm::sys::path::append(LibLTOPath, "lib");
+  llvm::sys::path::append(LibLTOPath, "libLTO.dylib");
+  if (llvm::sys::fs::exists(LibLTO

Re: [PATCH] D13368: [clang-tidy] add check cppcoreguidelines-pro-type-static-cast-downcast

[Samuel Benzaquen via cfe-commits]

sbenza added inline comments.


Comment at: 
test/clang-tidy/cppcoreguidelines-pro-type-static-cast-downcast.cpp:19
@@ +18,3 @@
+  // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: do not use static_cast to cast 
from base to derived. Use dynamic_cast instead. (C++ Core Guidelines, rule 
Type.2) [cppcoreguidelines-pro-type-static-cast-downcast]
+  // CHECK-FIXES: auto B0 = dynamic_cast(new Base());
+

This is not a valid dynamic_cast<> because Base is not polymorphic.



Comment at: 
test/clang-tidy/cppcoreguidelines-pro-type-static-cast-downcast.cpp:47
@@ +46,3 @@
+  auto B0 = static_cast(new D());
+  // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: do not use static_cast to cast 
from base to derived. Use dynamic_cast instead. (C++ Core Guidelines, rule 
Type.2) [cppcoreguidelines-pro-type-static-cast-downcast]
+  // CHECK-FIXES: auto B0 = dynamic_cast(new D());

I don't think we should warn here.
Whether it is a downcast or whether dynamic_cast<> is correct will depend on 
the specific instantiation.
A fix like this can break valid code.


http://reviews.llvm.org/D13368



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

Re: [PATCH] D13311: [clang-tidy] Add check cppcoreguidelines-pro-bounds-pointer-arithmetic

[Samuel Benzaquen via cfe-commits]

sbenza added inline comments.


Comment at: clang-tidy/cppcoreguidelines/ProBoundsPointerArithmeticCheck.cpp:38
@@ +37,3 @@
+  Finder->addMatcher(
+  arraySubscriptExpr(hasBase(implicitCastExpr(hasSourceExpression(
+ hasType(pointerType()).bind("expr"),

What is that implicitCastExpr() matching?
Did you mean to use ignoringImpCasts() instead?


Comment at: 
test/clang-tidy/cppcoreguidelines-pro-bounds-pointer-arithmetic.cpp:17
@@ +16,3 @@
+  q = p - 1;
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: do not use pointer arithmetic 
(C++ Core Guidelines, rule Bounds.1) 
[cppcoreguidelines-pro-bounds-pointer-arithmetic]
+  p += 4;

You don't need to specify the whole message on each hit.
Use the first hit to verify the whole message.
Strip the tail of the rest to let them fit in a single line.


Comment at: 
test/clang-tidy/cppcoreguidelines-pro-bounds-pointer-arithmetic.cpp:24
@@ +23,3 @@
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: do not use pointer arithmetic 
(C++ Core Guidelines, rule Bounds.1) 
[cppcoreguidelines-pro-bounds-pointer-arithmetic]
+  p = q + ENUM_LITERAL;
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: do not use pointer arithmetic 
(C++ Core Guidelines, rule Bounds.1) 
[cppcoreguidelines-pro-bounds-pointer-arithmetic]

Why just literals/enums? Maybe one of these should use i/j to make sure 
variables also work.


http://reviews.llvm.org/D13311



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

Re: [PATCH] D12901: [Static Analyzer] Intersecting ranges and 64 bit to 32 bit truncations causing "System is over constrained." assertions.

[pierre gousseau via cfe-commits]

pgousseau added a comment.

Ping !


http://reviews.llvm.org/D12901



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

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

[Manuel Klimek via cfe-commits]

klimek added a comment.

In http://reviews.llvm.org/D11908#258570, @tejohnson wrote:

> Sorry for the duplicate - my previous response didn't go to Duncan or Mehdi 
> for some reason. Trying again...
>
> In http://reviews.llvm.org/D11908#258540, @klimek wrote:
>
> > Perhaps "sharded" would fit what it is?
>
>
> You could have a sharded mode for full FDO (like gcc's partitioned LTO). And 
> we aren't really making any explicit sharding decisions, since the backends 
> do importing on demand.
>
> As David mentioned, "inlineonly" is much too restrictive for what is 
> possible. I prefer to stick with "thin" since it refers to this new model of 
> keeping the whole program part very thin.
>
> Does anyone have an opinion on "full" vs "monolithic" vs something else for 
> the traditional full/monolithic LTO?


If "sharded" is not the right term, than "monolithic" doesn't seem like the 
right term, either, right?

If "thin" basically refers to how much information is given to the lto steps 
(for which "thin" seems to be a good name actually), then "full" seems to be a 
good term for the, well, full information.


http://reviews.llvm.org/D11908



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

Re: [PATCH] D13368: [clang-tidy] add check cppcoreguidelines-pro-type-static-cast-downcast

[Aaron Ballman via cfe-commits]

aaron.ballman added inline comments.


Comment at: clang-tidy/cppcoreguidelines/ProTypeStaticCastDowncastCheck.cpp:33
@@ +32,3 @@
+
+  SubExpr = SubExpr->IgnoreParens();
+  QualType SourceType = SubExpr->getType();

Will the type dependence check also look through parens, or should this move up 
a few lines?


Comment at: clang-tidy/cppcoreguidelines/ProTypeStaticCastDowncastCheck.cpp:42
@@ +41,3 @@
+  const CXXRecordDecl* SourceDecl;
+  if (SourceType->isPointerType())
+SourceDecl = SourceType->getPointeeCXXRecordDecl();

No need for this or the check above -- getPointeeCXXRecordDecl() already does 
the right thing for references. You should be able to do:

```
if (auto *DestDecl = DestType->getPointeeCXXRecordDecl()) {
  // etc
}
```
Also note  that auto DestDecl isn't a good idea as it hides the fact that 
DestDecl is a pointer from anyone reading the code.


Comment at: clang-tidy/cppcoreguidelines/ProTypeStaticCastDowncastCheck.cpp:51
@@ +50,3 @@
+  if (DestDecl->isDerivedFrom(SourceDecl)) {
+diag(MatchedCast->getOperatorLoc(), "do not use static_cast to cast from 
base to derived. Use "
+  "dynamic_cast instead. (C++ Core "

Formatting looks off on this; also, I don't think you need the parenthetical as 
that information is part of the checker name itself.


http://reviews.llvm.org/D13368



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

Re: [PATCH] D13246: Fix bug in modernize-use-nullptr.

[Manuel Klimek via cfe-commits]

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

lg


http://reviews.llvm.org/D13246



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

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

[Diego Novillo via cfe-commits]

On Fri, Oct 2, 2015 at 9:44 AM, Teresa Johnson via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

As David mentioned, "inlineonly" is much too restrictive for what is
> possible. I prefer to stick with "thin" since it refers to this new model
> of keeping the whole program part very thin.
>

Agreed.  "inlineonly" is too restrictive.


> Does anyone have an opinion on "full" vs "monolithic" vs something else
> for the traditional full/monolithic LTO?
>


I prefer Full LTO for the traditional mechanism (or even Traditional LTO).
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Teresa Johnson via cfe-commits]

On Fri, Oct 2, 2015 at 8:53 AM, Manuel Klimek  wrote:
> klimek added a comment.
>
> In http://reviews.llvm.org/D11908#258570, @tejohnson wrote:
>
>> Sorry for the duplicate - my previous response didn't go to Duncan or Mehdi 
>> for some reason. Trying again...
>>
>> In http://reviews.llvm.org/D11908#258540, @klimek wrote:
>>
>> > Perhaps "sharded" would fit what it is?
>>
>>
>> You could have a sharded mode for full FDO (like gcc's partitioned LTO). And 
>> we aren't really making any explicit sharding decisions, since the backends 
>> do importing on demand.
>>
>> As David mentioned, "inlineonly" is much too restrictive for what is 
>> possible. I prefer to stick with "thin" since it refers to this new model of 
>> keeping the whole program part very thin.
>>
>> Does anyone have an opinion on "full" vs "monolithic" vs something else for 
>> the traditional full/monolithic LTO?
>
>
> If "sharded" is not the right term, than "monolithic" doesn't seem like the 
> right term, either, right?

Right, LLVM's "full" LTO could move to a partitioned/sharded model as
well. That is more of an implementation issue, not related to the
model.

>
> If "thin" basically refers to how much information is given to the lto steps 
> (for which "thin" seems to be a good name actually), then "full" seems to be 
> a good term for the, well, full information.

Ok, thanks. That echos my thinking.

Teresa

>
>
> http://reviews.llvm.org/D11908
>
>
>



-- 
Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D10305: [Clang Static Analyzer] Bug identification

[Anna Zaks via cfe-commits]

zaks.anna added a comment.

> Generating mangled names requires ASTContext which is not available during 
> the error reporting. BugReporter does have the ASTContext, so it would not 

>  be a big change to add it to the DiagnosticConsumers though. And I think the 
> mangled name might contain too much redundant information. The only 

>  relevant information here is the fully qualified name and the parts of the 
> signature that can be ocerloaded on e.g.: constness. Using this method might 
> also 

>  be easier to debug, since the IssueString is more readable.


I think it'd be fine to pass ASTContext to the DiagnosticConsumers. It would be 
useful to find out exactly what extra information the mangled names have that 
we do not want to see in the issue_hash.

One issue that I see with the current approach is that we do not differentiate 
methods from different classes/namespaces. Is this by design?

> I definitely agree. It would be great to have a unique identifier for 
> checkers that is independent from the name/package. It is not a trivial 
> problem however,

>  since we probably want to support plugins too. I can think of a similar 
> solution like git commit ids, but I think this problem might be out of the 
> scope of this

>  patch. But I am happy to start a discussion on the mailing list and create a 
> new patch to solve this.


Sounds good to me. I agree that this is out of scope for this patch.



Comment at: include/clang/StaticAnalyzer/Core/IssueHash.h:32
@@ +31,3 @@
+llvm::SmallString<32> GetIssueHash(const SourceManager &SM,
+   FullSourceLoc &UniqueLoc,
+   llvm::StringRef CheckerName,

UniqueLoc -> IssueLoc ?


Comment at: utils/analyzer/CmpRuns.py:74
@@ -73,3 +73,3 @@
 if 'issue_hash' in self._data :
-  id += str(self._data['issue_hash'])
+  id += str(self._data['issue_hash_function_offset'])
 return id

We should use the new hash here.


http://reviews.llvm.org/D10305



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

[PATCH] D13388: Add support for querying the visibility of a cursor

[Michael Wu via cfe-commits]

michaelwu created this revision.
michaelwu added a subscriber: cfe-commits.

This patch implements clang_getCursorVisibility which provides access to 
NamedDecl::getVisibility. It's been very useful for me when generating bindings.

http://reviews.llvm.org/D13388

Files:
  include/clang-c/Index.h
  test/Index/symbol-visibility.c
  tools/c-index-test/c-index-test.c
  tools/libclang/CIndex.cpp
  tools/libclang/libclang.exports

Index: tools/libclang/libclang.exports
===
--- tools/libclang/libclang.exports
+++ tools/libclang/libclang.exports
@@ -173,6 +173,7 @@
 clang_getCursorSpelling
 clang_getCursorType
 clang_getCursorUSR
+clang_getCursorVisibility
 clang_getDeclObjCTypeEncoding
 clang_getDefinitionSpellingAndExtent
 clang_getDiagnostic
Index: tools/libclang/CIndex.cpp
===
--- tools/libclang/CIndex.cpp
+++ tools/libclang/CIndex.cpp
@@ -6351,6 +6351,27 @@
 } // end: extern "C"
 
 //===--===//
+// Operations for querying visibility of a cursor.
+//===--===//
+
+extern "C" {
+CXVisibilityKind clang_getCursorVisibility(CXCursor cursor) {
+  if (!clang_isDeclaration(cursor.kind))
+return CXVisibility_Invalid;
+
+  const Decl *D = cxcursor::getCursorDecl(cursor);
+  if (const NamedDecl *ND = dyn_cast_or_null(D))
+switch (ND->getVisibility()) {
+  case HiddenVisibility: return CXVisibility_Hidden;
+  case ProtectedVisibility: return CXVisibility_Protected;
+  case DefaultVisibility: return CXVisibility_Default;
+};
+
+  return CXVisibility_Invalid;
+}
+} // end: extern "C"
+
+//===--===//
 // Operations for querying language of a cursor.
 //===--===//
 
Index: tools/c-index-test/c-index-test.c
===
--- tools/c-index-test/c-index-test.c
+++ tools/c-index-test/c-index-test.c
@@ -1246,6 +1246,32 @@
 }
 
 /**/
+/* Visibility testing.*/
+/**/
+
+static enum CXChildVisitResult PrintVisibility(CXCursor cursor, CXCursor p,
+   CXClientData d) {
+  const char *visibility = 0;
+
+  if (clang_isInvalid(clang_getCursorKind(cursor)))
+return CXChildVisit_Recurse;
+
+  switch (clang_getCursorVisibility(cursor)) {
+case CXVisibility_Invalid: break;
+case CXVisibility_Hidden: visibility = "Hidden"; break;
+case CXVisibility_Protected: visibility = "Protected"; break;
+case CXVisibility_Default: visibility = "Default"; break;
+  }
+
+  if (visibility) {
+PrintCursor(cursor, NULL);
+printf("visibility=%s\n", visibility);
+  }
+
+  return CXChildVisit_Recurse;
+}
+
+/**/
 /* Typekind testing.  */
 /**/
 
@@ -4061,6 +4087,7 @@
 "   c-index-test -test-inclusion-stack-tu \n");
   fprintf(stderr,
 "   c-index-test -test-print-linkage-source {}*\n"
+"   c-index-test -test-print-visibility {}*\n"
 "   c-index-test -test-print-type {}*\n"
 "   c-index-test -test-print-type-size {}*\n"
 "   c-index-test -test-print-bitwidth {}*\n"
@@ -4148,6 +4175,9 @@
   else if (argc > 2 && strcmp(argv[1], "-test-print-linkage-source") == 0)
 return perform_test_load_source(argc - 2, argv + 2, "all", PrintLinkage,
 NULL);
+  else if (argc > 2 && strcmp(argv[1], "-test-print-visibility") == 0)
+return perform_test_load_source(argc - 2, argv + 2, "all", PrintVisibility,
+NULL);
   else if (argc > 2 && strcmp(argv[1], "-test-print-type") == 0)
 return perform_test_load_source(argc - 2, argv + 2, "all",
 PrintType, 0);
Index: test/Index/symbol-visibility.c
===
--- /dev/null
+++ test/Index/symbol-visibility.c
@@ -0,0 +1,9 @@
+// RUN: c-index-test -test-print-visibility %s | FileCheck %s
+
+__attribute__ ((visibility ("default"))) void foo1();
+__attribute__ ((visibility ("protected"))) void foo2();
+__attribute__ ((visibility ("hidden"))) void foo3();
+
+// CHECK: FunctionDecl=foo1:3:47visibility=Default
+// CHECK: FunctionDecl=foo2:4:49visibility=Protected
+// CHECK: FunctionDecl=foo3:5:46visibility=Hidden
Index: include/clang-c/Index.h
=

Re: [PATCH] D13311: [clang-tidy] Add check cppcoreguidelines-pro-bounds-pointer-arithmetic

[Aaron Ballman via cfe-commits]

aaron.ballman added inline comments.


Comment at: clang-tidy/cppcoreguidelines/ProBoundsPointerArithmeticCheck.cpp:48
@@ +47,3 @@
+  diag(MatchedExpr->getExprLoc(),
+   "do not use pointer arithmetic (C++ Core Guidelines, rule Bounds.1)");
+}

Can elide the parenthetical.


Comment at: clang-tidy/cppcoreguidelines/ProBoundsPointerArithmeticCheck.h:18
@@ +17,3 @@
+
+/// Flags all kinds of pointer arithmetic
+///

This could be a bit more usefully descriptive. ;-)


Comment at: 
test/clang-tidy/cppcoreguidelines-pro-bounds-pointer-arithmetic.cpp:36
@@ +35,3 @@
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: do not use pointer arithmetic 
(C++ Core Guidelines, rule Bounds.1) 
[cppcoreguidelines-pro-bounds-pointer-arithmetic]
+}
+

How does this check handle code like:
```
struct S {
  operator int() const;  
};

void f(S &s) {
  int *i;
  i = i + s;
}
```


Comment at: 
test/clang-tidy/cppcoreguidelines-pro-bounds-pointer-arithmetic.cpp:38
@@ +37,3 @@
+
+void okey() {
+  int a[3];

s/okey/okay

;-)


http://reviews.llvm.org/D13311



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

r249148 - [OpenMP] Target directive host codegen.

[Samuel Antao via cfe-commits]

Author: sfantao
Date: Fri Oct  2 11:14:20 2015
New Revision: 249148

URL: http://llvm.org/viewvc/llvm-project?rev=249148&view=rev
Log:
[OpenMP] Target directive host codegen.

This patch implements the outlining for offloading functions for code 
annotated with the OpenMP target directive. It uses a temporary naming 
of the outlined functions that will have to be updated later on once 
target side codegen and registration of offloading libraries is 
implemented - the naming needs to be made unique in the produced 
library.


Added:
cfe/trunk/test/OpenMP/target_codegen.cpp
Modified:
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h
cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.h

Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp?rev=249148&r1=249147&r2=249148&view=diff
==
--- cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp Fri Oct  2 11:14:20 2015
@@ -41,6 +41,8 @@ public:
 /// \brief Region for constructs that do not require function outlining,
 /// like 'for', 'sections', 'atomic' etc. directives.
 InlinedRegion,
+/// \brief Region with outlined function for standalone 'target' directive.
+TargetRegion,
   };
 
   CGOpenMPRegionInfo(const CapturedStmt &CS,
@@ -211,6 +213,29 @@ private:
   CGOpenMPRegionInfo *OuterRegionInfo;
 };
 
+/// \brief API for captured statement code generation in OpenMP target
+/// constructs. For this captures, implicit parameters are used instead of the
+/// captured fields.
+class CGOpenMPTargetRegionInfo : public CGOpenMPRegionInfo {
+public:
+  CGOpenMPTargetRegionInfo(const CapturedStmt &CS,
+   const RegionCodeGenTy &CodeGen)
+  : CGOpenMPRegionInfo(CS, TargetRegion, CodeGen, OMPD_target,
+   /*HasCancel = */ false) {}
+
+  /// \brief This is unused for target regions because each starts executing
+  /// with a single thread.
+  const VarDecl *getThreadIDVariable() const override { return nullptr; }
+
+  /// \brief Get the name of the capture helper.
+  StringRef getHelperName() const override { return ".omp_offloading."; }
+
+  static bool classof(const CGCapturedStmtInfo *Info) {
+return CGOpenMPRegionInfo::classof(Info) &&
+   cast(Info)->getRegionKind() == TargetRegion;
+  }
+};
+
 /// \brief RAII for emitting code of OpenMP constructs.
 class InlinedOpenMPRegionRAII {
   CodeGenFunction &CGF;
@@ -877,6 +902,22 @@ CGOpenMPRuntime::createRuntimeFunction(O
 RTLFn = CGM.CreateRuntimeFunction(FnTy, "__kmpc_cancel");
 break;
   }
+  case OMPRTL__tgt_target: {
+// Build int32_t __tgt_target(int32_t device_id, void *host_ptr, int32_t
+// arg_num, void** args_base, void **args, size_t *arg_sizes, int32_t
+// *arg_types);
+llvm::Type *TypeParams[] = {CGM.Int32Ty,
+CGM.VoidPtrTy,
+CGM.Int32Ty,
+CGM.VoidPtrPtrTy,
+CGM.VoidPtrPtrTy,
+CGM.SizeTy->getPointerTo(),
+CGM.Int32Ty->getPointerTo()};
+llvm::FunctionType *FnTy =
+llvm::FunctionType::get(CGM.Int32Ty, TypeParams, /*isVarArg*/ false);
+RTLFn = CGM.CreateRuntimeFunction(FnTy, "__tgt_target");
+break;
+  }
   }
   return RTLFn;
 }
@@ -2952,3 +2993,265 @@ void CGOpenMPRuntime::emitCancelCall(Cod
   ThenGen(CGF);
   }
 }
+
+llvm::Value *
+CGOpenMPRuntime::emitTargetOutlinedFunction(const OMPExecutableDirective &D,
+const RegionCodeGenTy &CodeGen) {
+  const CapturedStmt &CS = *cast(D.getAssociatedStmt());
+
+  CodeGenFunction CGF(CGM, true);
+  CGOpenMPTargetRegionInfo CGInfo(CS, CodeGen);
+  CodeGenFunction::CGCapturedStmtRAII CapInfoRAII(CGF, &CGInfo);
+  return CGF.GenerateOpenMPCapturedStmtFunction(CS, 
/*UseOnlyReferences=*/true);
+}
+
+void CGOpenMPRuntime::emitTargetCall(CodeGenFunction &CGF,
+ const OMPExecutableDirective &D,
+ llvm::Value *OutlinedFn,
+ const Expr *IfCond, const Expr *Device,
+ ArrayRef CapturedVars) {
+  /// \brief Values for bit flags used to specify the mapping type for
+  /// offloading.
+  enum OpenMPOffloadMappingFlags {
+/// \brief Allocate memory on the device and move data from host to device.
+OMP_MAP_TO = 0x01,
+/// \brief Allocate memory on the device and move data from device to host.
+OMP_MAP_FROM = 0x02,
+  };
+
+  enum OpenMPOffloadingReservedDeviceIDs {
+/// \brief Device ID if the device was not defined, runtime should get it
+/// from environment variables in the spec.
+ 

Re: [PATCH] D12871: [OpenMP] Target directive host codegen - rebased

[Samuel Antao via cfe-commits]

sfantao closed this revision.
sfantao added a comment.

Committed in r249148!

Thanks,
Samuel


http://reviews.llvm.org/D12871



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

Re: [PATCH] D13313: [clang-tidy] new check cppcoreguidelines-pro-type-reinterpret-cast

[Matthias Gehre via cfe-commits]

mgehre updated this revision to Diff 36371.
mgehre added a comment.

Rebased
Removed "(C++ Core Guidelines, rule Type.1)" from diagnostic

Can someone please commit this?


http://reviews.llvm.org/D13313

Files:
  clang-tidy/CMakeLists.txt
  clang-tidy/Makefile
  clang-tidy/add_new_check.py
  clang-tidy/cppcoreguidelines/CMakeLists.txt
  clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
  clang-tidy/cppcoreguidelines/Makefile
  clang-tidy/cppcoreguidelines/ProTypeReinterpretCastCheck.cpp
  clang-tidy/cppcoreguidelines/ProTypeReinterpretCastCheck.h
  clang-tidy/tool/CMakeLists.txt
  clang-tidy/tool/ClangTidyMain.cpp
  clang-tidy/tool/Makefile
  docs/clang-tidy/checks/cppcoreguidelines-pro-type-reinterpret-cast.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/cppcoreguidelines-pro-type-reinterpret-cast.cpp

Index: test/clang-tidy/cppcoreguidelines-pro-type-reinterpret-cast.cpp
===
--- /dev/null
+++ test/clang-tidy/cppcoreguidelines-pro-type-reinterpret-cast.cpp
@@ -0,0 +1,6 @@
+// RUN: %python %S/check_clang_tidy.py %s cppcoreguidelines-pro-type-reinterpret-cast %t
+
+int i = 0;
+void* j;
+void f() { j = reinterpret_cast(i); }
+// CHECK-MESSAGES: :[[@LINE-1]]:16: warning: do not use reinterpret_cast (C++ Core Guidelines, rule Type.1) [cppcoreguidelines-pro-type-reinterpret-cast]
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -2,6 +2,7 @@
 =
 
 .. toctree::
+   cppcoreguidelines-pro-type-reinterpret-cast
google-build-explicit-make-pair
google-build-namespaces
google-build-using-namespace
Index: docs/clang-tidy/checks/cppcoreguidelines-pro-type-reinterpret-cast.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/cppcoreguidelines-pro-type-reinterpret-cast.rst
@@ -0,0 +1,9 @@
+cppcoreguidelines-pro-type-reinterpret-cast
+===
+
+This check flags all uses of reinterpret_cast in C++ code.
+
+Use of these casts can violate type safety and cause the program to access a variable that is actually of type X to be accessed as if it were of an unrelated type Z.
+
+This rule is part of the "Type safety" profile of the C++ Core Guidelines, see
+https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#-type1-dont-use-reinterpret_cast.
Index: clang-tidy/tool/Makefile
===
--- clang-tidy/tool/Makefile
+++ clang-tidy/tool/Makefile
@@ -19,6 +19,7 @@
 USEDLIBS = clangTidy.a clangTidyLLVMModule.a clangTidyGoogleModule.a \
clangTidyMiscModule.a clangTidyModernizeModule.a clangTidyReadability.a \
 	   clangTidyUtils.a clangTidyCERTModule.a clangStaticAnalyzerFrontend.a \
+	   clangTidyCppCoreGuidelinesModule.a \
 	   clangStaticAnalyzerCheckers.a clangStaticAnalyzerCore.a \
 	   clangFormat.a clangASTMatchers.a clangTooling.a clangToolingCore.a \
 	   clangFrontend.a clangSerialization.a clangDriver.a clangParse.a \
Index: clang-tidy/tool/ClangTidyMain.cpp
===
--- clang-tidy/tool/ClangTidyMain.cpp
+++ clang-tidy/tool/ClangTidyMain.cpp
@@ -357,6 +357,11 @@
 static int LLVM_ATTRIBUTE_UNUSED LLVMModuleAnchorDestination =
 LLVMModuleAnchorSource;
 
+// This anchor is used to force the linker to link the CppCoreGuidelinesModule.
+extern volatile int CppCoreGuidelinesModuleAnchorSource;
+static int LLVM_ATTRIBUTE_UNUSED CppCoreGuidelinesModuleAnchorDestination =
+CppCoreGuidelinesModuleAnchorSource;
+
 // This anchor is used to force the linker to link the GoogleModule.
 extern volatile int GoogleModuleAnchorSource;
 static int LLVM_ATTRIBUTE_UNUSED GoogleModuleAnchorDestination =
Index: clang-tidy/tool/CMakeLists.txt
===
--- clang-tidy/tool/CMakeLists.txt
+++ clang-tidy/tool/CMakeLists.txt
@@ -11,6 +11,7 @@
   clangBasic
   clangTidy
   clangTidyCERTModule
+  clangTidyCppCoreGuidelinesModule
   clangTidyGoogleModule
   clangTidyLLVMModule
   clangTidyMiscModule
Index: clang-tidy/cppcoreguidelines/ProTypeReinterpretCastCheck.h
===
--- /dev/null
+++ clang-tidy/cppcoreguidelines/ProTypeReinterpretCastCheck.h
@@ -0,0 +1,33 @@
+//===--- ProTypeReinterpretCast.h - clang-tidy--*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_CPPCOREGUIDELINES_PRO_TYPE_REINTERPRETCAST_CHECK_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_

Re: [PATCH] D13313: [clang-tidy] new check cppcoreguidelines-pro-type-reinterpret-cast

[Matthias Gehre via cfe-commits]

mgehre updated this revision to Diff 36372.
mgehre added a comment.

Shot to fast, fixed test.

Now it's ready


http://reviews.llvm.org/D13313

Files:
  clang-tidy/CMakeLists.txt
  clang-tidy/Makefile
  clang-tidy/add_new_check.py
  clang-tidy/cppcoreguidelines/CMakeLists.txt
  clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
  clang-tidy/cppcoreguidelines/Makefile
  clang-tidy/cppcoreguidelines/ProTypeReinterpretCastCheck.cpp
  clang-tidy/cppcoreguidelines/ProTypeReinterpretCastCheck.h
  clang-tidy/tool/CMakeLists.txt
  clang-tidy/tool/ClangTidyMain.cpp
  clang-tidy/tool/Makefile
  docs/clang-tidy/checks/cppcoreguidelines-pro-type-reinterpret-cast.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/cppcoreguidelines-pro-type-reinterpret-cast.cpp

Index: test/clang-tidy/cppcoreguidelines-pro-type-reinterpret-cast.cpp
===
--- /dev/null
+++ test/clang-tidy/cppcoreguidelines-pro-type-reinterpret-cast.cpp
@@ -0,0 +1,6 @@
+// RUN: %python %S/check_clang_tidy.py %s cppcoreguidelines-pro-type-reinterpret-cast %t
+
+int i = 0;
+void* j;
+void f() { j = reinterpret_cast(i); }
+// CHECK-MESSAGES: :[[@LINE-1]]:16: warning: do not use reinterpret_cast [cppcoreguidelines-pro-type-reinterpret-cast]
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -2,6 +2,7 @@
 =
 
 .. toctree::
+   cppcoreguidelines-pro-type-reinterpret-cast
google-build-explicit-make-pair
google-build-namespaces
google-build-using-namespace
Index: docs/clang-tidy/checks/cppcoreguidelines-pro-type-reinterpret-cast.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/cppcoreguidelines-pro-type-reinterpret-cast.rst
@@ -0,0 +1,9 @@
+cppcoreguidelines-pro-type-reinterpret-cast
+===
+
+This check flags all uses of reinterpret_cast in C++ code.
+
+Use of these casts can violate type safety and cause the program to access a variable that is actually of type X to be accessed as if it were of an unrelated type Z.
+
+This rule is part of the "Type safety" profile of the C++ Core Guidelines, see
+https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#-type1-dont-use-reinterpret_cast.
Index: clang-tidy/tool/Makefile
===
--- clang-tidy/tool/Makefile
+++ clang-tidy/tool/Makefile
@@ -19,6 +19,7 @@
 USEDLIBS = clangTidy.a clangTidyLLVMModule.a clangTidyGoogleModule.a \
clangTidyMiscModule.a clangTidyModernizeModule.a clangTidyReadability.a \
 	   clangTidyUtils.a clangTidyCERTModule.a clangStaticAnalyzerFrontend.a \
+	   clangTidyCppCoreGuidelinesModule.a \
 	   clangStaticAnalyzerCheckers.a clangStaticAnalyzerCore.a \
 	   clangFormat.a clangASTMatchers.a clangTooling.a clangToolingCore.a \
 	   clangFrontend.a clangSerialization.a clangDriver.a clangParse.a \
Index: clang-tidy/tool/ClangTidyMain.cpp
===
--- clang-tidy/tool/ClangTidyMain.cpp
+++ clang-tidy/tool/ClangTidyMain.cpp
@@ -357,6 +357,11 @@
 static int LLVM_ATTRIBUTE_UNUSED LLVMModuleAnchorDestination =
 LLVMModuleAnchorSource;
 
+// This anchor is used to force the linker to link the CppCoreGuidelinesModule.
+extern volatile int CppCoreGuidelinesModuleAnchorSource;
+static int LLVM_ATTRIBUTE_UNUSED CppCoreGuidelinesModuleAnchorDestination =
+CppCoreGuidelinesModuleAnchorSource;
+
 // This anchor is used to force the linker to link the GoogleModule.
 extern volatile int GoogleModuleAnchorSource;
 static int LLVM_ATTRIBUTE_UNUSED GoogleModuleAnchorDestination =
Index: clang-tidy/tool/CMakeLists.txt
===
--- clang-tidy/tool/CMakeLists.txt
+++ clang-tidy/tool/CMakeLists.txt
@@ -11,6 +11,7 @@
   clangBasic
   clangTidy
   clangTidyCERTModule
+  clangTidyCppCoreGuidelinesModule
   clangTidyGoogleModule
   clangTidyLLVMModule
   clangTidyMiscModule
Index: clang-tidy/cppcoreguidelines/ProTypeReinterpretCastCheck.h
===
--- /dev/null
+++ clang-tidy/cppcoreguidelines/ProTypeReinterpretCastCheck.h
@@ -0,0 +1,33 @@
+//===--- ProTypeReinterpretCast.h - clang-tidy--*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_CPPCOREGUIDELINES_PRO_TYPE_REINTERPRETCAST_CHECK_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_CPPCOREGUIDELINES_PRO_TYPE_REINTERPRETCAST_CHECK_H
+
+#include "../ClangTidy.h"
+
+namespace cl

Re: [PATCH] D13313: [clang-tidy] new check cppcoreguidelines-pro-type-reinterpret-cast

[Aaron Ballman via cfe-commits]

aaron.ballman added a comment.

Does not apply cleanly to ToT; can you rebase?

~Aaron


http://reviews.llvm.org/D13313



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

r249152 - constify ClassTemplatePartialSpecializationDecl::getInstantiatedFromMember and VarTemplatePartialSpecializationDecl::getInstantiatedFromMember.

[Yaron Keren via cfe-commits]

Author: yrnkrn
Date: Fri Oct  2 11:40:48 2015
New Revision: 249152

URL: http://llvm.org/viewvc/llvm-project?rev=249152&view=rev
Log:
constify ClassTemplatePartialSpecializationDecl::getInstantiatedFromMember and 
VarTemplatePartialSpecializationDecl::getInstantiatedFromMember.


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

Modified: cfe/trunk/include/clang/AST/DeclTemplate.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclTemplate.h?rev=249152&r1=249151&r2=249152&view=diff
==
--- cfe/trunk/include/clang/AST/DeclTemplate.h (original)
+++ cfe/trunk/include/clang/AST/DeclTemplate.h Fri Oct  2 11:40:48 2015
@@ -1853,8 +1853,8 @@ public:
   /// template partial specialization \c Outer::Inner. Given
   /// \c Outer::Inner, this function would return
   /// \c Outer::Inner.
-  ClassTemplatePartialSpecializationDecl *getInstantiatedFromMember() {
-ClassTemplatePartialSpecializationDecl *First =
+  ClassTemplatePartialSpecializationDecl *getInstantiatedFromMember() const {
+const ClassTemplatePartialSpecializationDecl *First =
 cast(getFirstDecl());
 return First->InstantiatedFromMember.getPointer();
   }
@@ -2702,8 +2702,8 @@ public:
   /// variable template partial specialization \c Outer::Inner. Given
   /// \c Outer::Inner, this function would return
   /// \c Outer::Inner.
-  VarTemplatePartialSpecializationDecl *getInstantiatedFromMember() {
-VarTemplatePartialSpecializationDecl *First =
+  VarTemplatePartialSpecializationDecl *getInstantiatedFromMember() const {
+const VarTemplatePartialSpecializationDecl *First =
 cast(getFirstDecl());
 return First->InstantiatedFromMember.getPointer();
   }


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

Re: r249141 - Revert "Add support for the new mips-mti-linux toolchain."

[Yaron Keren via cfe-commits]

The regular expression should match match clang.exe on Windows.



2015-10-02 18:00 GMT+03:00 Vasileios Kalintiris via cfe-commits <
cfe-commits@lists.llvm.org>:

> Author: vkalintiris
> Date: Fri Oct  2 10:00:55 2015
> New Revision: 249141
>
> URL: http://llvm.org/viewvc/llvm-project?rev=249141&view=rev
> Log:
> Revert "Add support for the new mips-mti-linux toolchain."
>
> This reverts commit r249137 because it broke the Windows buildbots and
> a Linux buildbot for LLD.
>
> Removed:
>
> cfe/trunk/test/Driver/Inputs/mips_mti_linux/lib/clang/3.8.0/mips-r2-hard-musl/lib/linux/libclang_rt.builtins-mips.a
>
> cfe/trunk/test/Driver/Inputs/mips_mti_linux/lib/clang/3.8.0/mips-r2-hard-musl/lib/linux/
> libclang_rt.builtins-mips.so
>
> cfe/trunk/test/Driver/Inputs/mips_mti_linux/lib/clang/3.8.0/mipsel-r2-hard-musl/lib/linux/libclang_rt.builtins-mipsel.a
>
> cfe/trunk/test/Driver/Inputs/mips_mti_linux/lib/clang/3.8.0/mipsel-r2-hard-musl/lib/linux/
> libclang_rt.builtins-mipsel.so
>
> cfe/trunk/test/Driver/Inputs/mips_mti_linux/sysroot/mips-r2-hard-musl/usr/lib/crt1.o
>
> cfe/trunk/test/Driver/Inputs/mips_mti_linux/sysroot/mips-r2-hard-musl/usr/lib/crti.o
>
> cfe/trunk/test/Driver/Inputs/mips_mti_linux/sysroot/mips-r2-hard-musl/usr/lib/crtn.o
>
> cfe/trunk/test/Driver/Inputs/mips_mti_linux/sysroot/mipsel-r2-hard-musl/usr/lib/crt1.o
>
> cfe/trunk/test/Driver/Inputs/mips_mti_linux/sysroot/mipsel-r2-hard-musl/usr/lib/crti.o
>
> cfe/trunk/test/Driver/Inputs/mips_mti_linux/sysroot/mipsel-r2-hard-musl/usr/lib/crtn.o
> cfe/trunk/test/Driver/mips-mti-linux.c
> Modified:
> cfe/trunk/lib/Driver/Driver.cpp
> cfe/trunk/lib/Driver/ToolChain.cpp
> cfe/trunk/lib/Driver/ToolChains.cpp
> cfe/trunk/lib/Driver/ToolChains.h
> cfe/trunk/lib/Driver/Tools.cpp
> cfe/trunk/lib/Driver/Tools.h
>
> Modified: cfe/trunk/lib/Driver/Driver.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Driver.cpp?rev=249141&r1=249140&r2=249141&view=diff
>
> ==
> --- cfe/trunk/lib/Driver/Driver.cpp (original)
> +++ cfe/trunk/lib/Driver/Driver.cpp Fri Oct  2 10:00:55 2015
> @@ -2122,11 +2122,6 @@ void Driver::generatePrefixedToolNames(
>// FIXME: Needs a better variable than DefaultTargetTriple
>Names.emplace_back(DefaultTargetTriple + "-" + Tool);
>Names.emplace_back(Tool);
> -
> -  // Allow the discovery of tools prefixed with LLVM's default target
> triple.
> -  std::string LLVMDefaultTargetTriple =
> llvm::sys::getDefaultTargetTriple();
> -  if (LLVMDefaultTargetTriple != DefaultTargetTriple)
> -Names.emplace_back(LLVMDefaultTargetTriple + "-" + Tool);
>  }
>
>  static bool ScanDirForExecutable(SmallString<128> &Dir,
> @@ -,9 +2217,6 @@ const ToolChain &Driver::getToolChain(co
>  case llvm::Triple::Linux:
>if (Target.getArch() == llvm::Triple::hexagon)
>  TC = new toolchains::HexagonToolChain(*this, Target, Args);
> -  else if ((Target.getVendor() == llvm::Triple::MipsTechnologies) &&
> -   !Target.hasEnvironment())
> -TC = new toolchains::MipsLLVMToolChain(*this, Target, Args);
>else
>  TC = new toolchains::Linux(*this, Target, Args);
>break;
>
> Modified: cfe/trunk/lib/Driver/ToolChain.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChain.cpp?rev=249141&r1=249140&r2=249141&view=diff
>
> ==
> --- cfe/trunk/lib/Driver/ToolChain.cpp (original)
> +++ cfe/trunk/lib/Driver/ToolChain.cpp Fri Oct  2 10:00:55 2015
> @@ -315,6 +315,7 @@ Tool *ToolChain::SelectTool(const JobAct
>
>  std::string ToolChain::GetFilePath(const char *Name) const {
>return D.GetFilePath(Name, *this);
> +
>  }
>
>  std::string ToolChain::GetProgramPath(const char *Name) const {
>
> Modified: cfe/trunk/lib/Driver/ToolChains.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains.cpp?rev=249141&r1=249140&r2=249141&view=diff
>
> ==
> --- cfe/trunk/lib/Driver/ToolChains.cpp (original)
> +++ cfe/trunk/lib/Driver/ToolChains.cpp Fri Oct  2 10:00:55 2015
> @@ -1301,9 +1301,8 @@ bool Generic_GCC::GCCInstallationDetecto
>"i586-linux-gnu"};
>
>static const char *const MIPSLibDirs[] = {"/lib"};
> -  static const char *const MIPSTriples[] = {"mips-linux-gnu",
> "mips-mti-linux",
> -"mips-mti-linux-gnu",
> -"mips-img-linux-gnu"};
> +  static const char *const MIPSTriples[] = {
> +  "mips-linux-gnu", "mips-mti-linux-gnu", "mips-img-linux-gnu"};
>static const char *const MIPSELLibDirs[] = {"/lib"};
>static const char *const MIPSELTriples[] = {
>"mipsel-linux-gnu", "mipsel-linux-android", "mips-img-linux-gnu"};
> @@ -1692,32 +1691,6 @@ static bool findMIPSMultilibs(const llvm
>  

RE: r249141 - Revert "Add support for the new mips-mti-linux toolchain."

[Vasileios Kalintiris via cfe-commits]

Thanks Yaron. I'll to figure out what's going wrong with
the Linux buildbot and I'll re-commit the fixed patch tomorrow.

- Vasileios


From: Yaron Keren [yaron.ke...@gmail.com]
Sent: 02 October 2015 17:46
To: Vasileios Kalintiris
Cc: cfe-commits
Subject: Re: r249141 - Revert "Add support for the new mips-mti-linux 
toolchain."

The regular expression should match match clang.exe on Windows.



2015-10-02 18:00 GMT+03:00 Vasileios Kalintiris via cfe-commits 
mailto:cfe-commits@lists.llvm.org>>:
Author: vkalintiris
Date: Fri Oct  2 10:00:55 2015
New Revision: 249141

URL: http://llvm.org/viewvc/llvm-project?rev=249141&view=rev
Log:
Revert "Add support for the new mips-mti-linux toolchain."

This reverts commit r249137 because it broke the Windows buildbots and
a Linux buildbot for LLD.

Removed:

cfe/trunk/test/Driver/Inputs/mips_mti_linux/lib/clang/3.8.0/mips-r2-hard-musl/lib/linux/libclang_rt.builtins-mips.a

cfe/trunk/test/Driver/Inputs/mips_mti_linux/lib/clang/3.8.0/mips-r2-hard-musl/lib/linux/libclang_rt.builtins-mips.so

cfe/trunk/test/Driver/Inputs/mips_mti_linux/lib/clang/3.8.0/mipsel-r2-hard-musl/lib/linux/libclang_rt.builtins-mipsel.a

cfe/trunk/test/Driver/Inputs/mips_mti_linux/lib/clang/3.8.0/mipsel-r2-hard-musl/lib/linux/libclang_rt.builtins-mipsel.so

cfe/trunk/test/Driver/Inputs/mips_mti_linux/sysroot/mips-r2-hard-musl/usr/lib/crt1.o

cfe/trunk/test/Driver/Inputs/mips_mti_linux/sysroot/mips-r2-hard-musl/usr/lib/crti.o

cfe/trunk/test/Driver/Inputs/mips_mti_linux/sysroot/mips-r2-hard-musl/usr/lib/crtn.o

cfe/trunk/test/Driver/Inputs/mips_mti_linux/sysroot/mipsel-r2-hard-musl/usr/lib/crt1.o

cfe/trunk/test/Driver/Inputs/mips_mti_linux/sysroot/mipsel-r2-hard-musl/usr/lib/crti.o

cfe/trunk/test/Driver/Inputs/mips_mti_linux/sysroot/mipsel-r2-hard-musl/usr/lib/crtn.o
cfe/trunk/test/Driver/mips-mti-linux.c
Modified:
cfe/trunk/lib/Driver/Driver.cpp
cfe/trunk/lib/Driver/ToolChain.cpp
cfe/trunk/lib/Driver/ToolChains.cpp
cfe/trunk/lib/Driver/ToolChains.h
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/lib/Driver/Tools.h

Modified: cfe/trunk/lib/Driver/Driver.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Driver.cpp?rev=249141&r1=249140&r2=249141&view=diff
==
--- cfe/trunk/lib/Driver/Driver.cpp (original)
+++ cfe/trunk/lib/Driver/Driver.cpp Fri Oct  2 10:00:55 2015
@@ -2122,11 +2122,6 @@ void Driver::generatePrefixedToolNames(
   // FIXME: Needs a better variable than DefaultTargetTriple
   Names.emplace_back(DefaultTargetTriple + "-" + Tool);
   Names.emplace_back(Tool);
-
-  // Allow the discovery of tools prefixed with LLVM's default target triple.
-  std::string LLVMDefaultTargetTriple = llvm::sys::getDefaultTargetTriple();
-  if (LLVMDefaultTargetTriple != DefaultTargetTriple)
-Names.emplace_back(LLVMDefaultTargetTriple + "-" + Tool);
 }

 static bool ScanDirForExecutable(SmallString<128> &Dir,
@@ -,9 +2217,6 @@ const ToolChain &Driver::getToolChain(co
 case llvm::Triple::Linux:
   if (Target.getArch() == llvm::Triple::hexagon)
 TC = new toolchains::HexagonToolChain(*this, Target, Args);
-  else if ((Target.getVendor() == llvm::Triple::MipsTechnologies) &&
-   !Target.hasEnvironment())
-TC = new toolchains::MipsLLVMToolChain(*this, Target, Args);
   else
 TC = new toolchains::Linux(*this, Target, Args);
   break;

Modified: cfe/trunk/lib/Driver/ToolChain.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChain.cpp?rev=249141&r1=249140&r2=249141&view=diff
==
--- cfe/trunk/lib/Driver/ToolChain.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChain.cpp Fri Oct  2 10:00:55 2015
@@ -315,6 +315,7 @@ Tool *ToolChain::SelectTool(const JobAct

 std::string ToolChain::GetFilePath(const char *Name) const {
   return D.GetFilePath(Name, *this);
+
 }

 std::string ToolChain::GetProgramPath(const char *Name) const {

Modified: cfe/trunk/lib/Driver/ToolChains.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains.cpp?rev=249141&r1=249140&r2=249141&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains.cpp Fri Oct  2 10:00:55 2015
@@ -1301,9 +1301,8 @@ bool Generic_GCC::GCCInstallationDetecto
   "i586-linux-gnu"};

   static const char *const MIPSLibDirs[] = {"/lib"};
-  static const char *const MIPSTriples[] = {"mips-linux-gnu", "mips-mti-linux",
-"mips-mti-linux-gnu",
-"mips-img-linux-gnu"};
+  static const char *const MIPSTriples[] = {
+  "mips-linux-gnu", "mips-mt

r249154 - [OpenMP] Capture global variables in target regions.

[Samuel Antao via cfe-commits]

Author: sfantao
Date: Fri Oct  2 12:14:03 2015
New Revision: 249154

URL: http://llvm.org/viewvc/llvm-project?rev=249154&view=rev
Log:
[OpenMP] Capture global variables in target regions.

All global variables that are not enclosed in a declare target region 
must be captured in the target region as local variables do. Currently, 
there is no support for declare target, so this patch adds support for 
capturing all the global variables used in a the target region.


Added:
cfe/trunk/test/OpenMP/target_codegen_global_capture.cpp
Modified:
cfe/trunk/include/clang/Basic/OpenMPKinds.h
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/Basic/OpenMPKinds.cpp
cfe/trunk/lib/Sema/SemaExpr.cpp
cfe/trunk/lib/Sema/SemaOpenMP.cpp

Modified: cfe/trunk/include/clang/Basic/OpenMPKinds.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/OpenMPKinds.h?rev=249154&r1=249153&r2=249154&view=diff
==
--- cfe/trunk/include/clang/Basic/OpenMPKinds.h (original)
+++ cfe/trunk/include/clang/Basic/OpenMPKinds.h Fri Oct  2 12:14:03 2015
@@ -109,6 +109,12 @@ bool isOpenMPWorksharingDirective(OpenMP
 /// parallel', otherwise - false.
 bool isOpenMPParallelDirective(OpenMPDirectiveKind DKind);
 
+/// \brief Checks if the specified directive is a target-kind directive.
+/// \param DKind Specified directive.
+/// \return true - the directive is a target-like directive like 'omp target',
+/// otherwise - false.
+bool isOpenMPTargetDirective(OpenMPDirectiveKind DKind);
+
 /// \brief Checks if the specified directive is a teams-kind directive.
 /// \param DKind Specified directive.
 /// \return true - the directive is a teams-like directive like 'omp teams',

Modified: cfe/trunk/include/clang/Sema/Sema.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=249154&r1=249153&r2=249154&view=diff
==
--- cfe/trunk/include/clang/Sema/Sema.h (original)
+++ cfe/trunk/include/clang/Sema/Sema.h Fri Oct  2 12:14:03 2015
@@ -7728,6 +7728,11 @@ public:
   /// is performed.
   bool isOpenMPPrivateVar(VarDecl *VD, unsigned Level);
 
+  /// \brief Check if the specified variable is captured  by 'target' 
directive.
+  /// \param Level Relative level of nested OpenMP construct for that the check
+  /// is performed.
+  bool isOpenMPTargetCapturedVar(VarDecl *VD, unsigned Level);
+
   ExprResult PerformOpenMPImplicitIntegerConversion(SourceLocation OpLoc,
 Expr *Op);
   /// \brief Called on start of new data sharing attribute block.

Modified: cfe/trunk/lib/Basic/OpenMPKinds.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/OpenMPKinds.cpp?rev=249154&r1=249153&r2=249154&view=diff
==
--- cfe/trunk/lib/Basic/OpenMPKinds.cpp (original)
+++ cfe/trunk/lib/Basic/OpenMPKinds.cpp Fri Oct  2 12:14:03 2015
@@ -424,6 +424,10 @@ bool clang::isOpenMPParallelDirective(Op
  DKind == OMPD_parallel_sections; // TODO add next directives.
 }
 
+bool clang::isOpenMPTargetDirective(OpenMPDirectiveKind DKind) {
+  return DKind == OMPD_target; // TODO add next directives.
+}
+
 bool clang::isOpenMPTeamsDirective(OpenMPDirectiveKind DKind) {
   return DKind == OMPD_teams; // TODO add next directives.
 }

Modified: cfe/trunk/lib/Sema/SemaExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExpr.cpp?rev=249154&r1=249153&r2=249154&view=diff
==
--- cfe/trunk/lib/Sema/SemaExpr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExpr.cpp Fri Oct  2 12:14:03 2015
@@ -13183,10 +13183,18 @@ bool Sema::tryCaptureVariable(
 if (getLangOpts().OpenMP) {
   if (auto *RSI = dyn_cast(CSI)) {
 // OpenMP private variables should not be captured in outer scope, so
-// just break here.
+// just break here. Similarly, global variables that are captured in a
+// target region should not be captured outside the scope of the 
region.
 if (RSI->CapRegionKind == CR_OpenMP) {
-  if (isOpenMPPrivateVar(Var, OpenMPLevel)) {
-Nested = true;
+  auto isTargetCap = isOpenMPTargetCapturedVar(Var, OpenMPLevel);
+  // When we detect target captures we are looking from inside the
+  // target region, therefore we need to propagate the capture from the
+  // enclosing region. Therefore, the capture is not initially nested.
+  if (isTargetCap)
+FunctionScopesIndex--;
+
+  if (isTargetCap || isOpenMPPrivateVar(Var, OpenMPLevel)) {
+Nested = !isTargetCap;
 DeclRefType = DeclRefType.getUnqualifiedType();
 CaptureType = Context.getLValueReferenceType(DeclRefType);
 break;

Modified: cfe/trunk/lib/Se

Re: [PATCH] D12262: [OpenMP] Capture global variables in target regions.

[Samuel Antao via cfe-commits]

sfantao closed this revision.
sfantao added a comment.

Committed in r249154.

Thanks!
Samuel


http://reviews.llvm.org/D12262



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

Re: [PATCH] D13322: Add -f[no-]declspec to control recognition of __declspec as a keyword

[Warren Ristow via cfe-commits]

wristow updated this revision to Diff 36373.
wristow added a comment.

Added 4 new tests, the verify the last -fdeclspec/-fno-declspec wins, both in 
the context of -fms-extensions and without -fms-extensions.


http://reviews.llvm.org/D13322

Files:
  include/clang/Basic/LangOptions.def
  include/clang/Basic/TokenKinds.def
  include/clang/Driver/Options.td
  include/clang/Parse/Parser.h
  lib/Basic/IdentifierTable.cpp
  lib/Driver/Tools.cpp
  lib/Frontend/CompilerInvocation.cpp
  lib/Parse/ParseDecl.cpp
  test/Lexer/keywords_test.c
  test/Lexer/keywords_test.cpp

Index: test/Lexer/keywords_test.cpp
===
--- test/Lexer/keywords_test.cpp
+++ test/Lexer/keywords_test.cpp
@@ -1,6 +1,19 @@
 // RUN: %clang_cc1 -std=c++03 -fsyntax-only %s
 // RUN: %clang_cc1 -std=c++11 -DCXX11 -fsyntax-only %s
 // RUN: %clang_cc1 -std=c++14 -fconcepts-ts -DCXX11 -DCONCEPTS -fsyntax-only %s
+// RUN: %clang_cc1 -std=c++03 -fdeclspec -DDECLSPEC -fsyntax-only %s
+// RUN: %clang_cc1 -std=c++03 -fms-extensions -DDECLSPEC -fsyntax-only %s
+// RUN: %clang_cc1 -std=c++03 -fborland-extensions -DDECLSPEC -fsyntax-only %s
+// RUN: %clang_cc1 -std=c++03 -fms-extensions -fno-declspec -fsyntax-only %s
+// RUN: %clang_cc1 -std=c++03 -fborland-extensions -fno-declspec -fsyntax-only %s
+// RUN: %clang_cc1 -std=c++03 -fno-declspec -fdeclspec -DDECLSPEC -fsyntax-only %s
+// RUN: %clang_cc1 -std=c++03 -fdeclspec -fno-declspec -fsyntax-only %s
+// RUN: %clang_cc1 -std=c++03 -fms-extensions -fno-declspec -fdeclspec -DDECLSPEC -fsyntax-only %s
+// RUN: %clang_cc1 -std=c++03 -fms-extensions -fdeclspec -fno-declspec -fsyntax-only %s
+// RUN: %clang -std=c++03 -target i686-windows-msvc -DDECLSPEC -fsyntax-only %s
+// RUN: %clang -std=c++03 -target x86_64-scei-ps4 -DDECLSPEC -fsyntax-only %s
+// RUN: %clang -std=c++03 -target i686-windows-msvc -fno-declspec -fsyntax-only %s
+// RUN: %clang -std=c++03 -target x86_64-scei-ps4 -fno-declspec -fsyntax-only %s
 
 #define IS_KEYWORD(NAME) _Static_assert(!__is_identifier(NAME), #NAME)
 #define NOT_KEYWORD(NAME) _Static_assert(__is_identifier(NAME), #NAME)
@@ -12,6 +25,12 @@
 #define CONCEPTS_KEYWORD(NAME)  NOT_KEYWORD(NAME)
 #endif
 
+#ifdef DECLSPEC
+#define DECLSPEC_KEYWORD(NAME)  IS_KEYWORD(NAME)
+#else
+#define DECLSPEC_KEYWORD(NAME)  NOT_KEYWORD(NAME)
+#endif
+
 #ifdef CXX11
 #define CXX11_KEYWORD(NAME)  IS_KEYWORD(NAME)
 #define CXX11_TYPE(NAME) IS_TYPE(NAME)
@@ -38,6 +57,9 @@
 CONCEPTS_KEYWORD(concept);
 CONCEPTS_KEYWORD(requires);
 
+// __declspec extension
+DECLSPEC_KEYWORD(__declspec);
+
 // Clang extension
 IS_KEYWORD(__char16_t);
 IS_TYPE(__char16_t);
Index: test/Lexer/keywords_test.c
===
--- test/Lexer/keywords_test.c
+++ test/Lexer/keywords_test.c
@@ -9,6 +9,10 @@
 
 // RUN: %clang_cc1 -std=c99 -fms-extensions -E %s -o - \
 // RUN: | FileCheck --check-prefix=CHECK-MS-KEYWORDS %s
+// RUN: %clang_cc1 -std=c99 -fdeclspec -E %s -o - \
+// RUN: | FileCheck --check-prefix=CHECK-DECLSPEC-KEYWORD %s
+// RUN: %clang_cc1 -std=c99 -fms-extensions -fno-declspec -E %s -o - \
+// RUN: | FileCheck --check-prefix=CHECK-MS-KEYWORDS-WITHOUT-DECLSPEC %s
 
 void f() {
 // CHECK-NONE: int asm
@@ -22,8 +26,19 @@
 
 // CHECK-NONE: no_ms_wchar
 // CHECK-MS-KEYWORDS: has_ms_wchar
+// CHECK-MS-KEYWORDS-WITHOUT-DECLSPEC: has_ms_wchar
 #if __is_identifier(__wchar_t)
 void no_ms_wchar();
 #else
 void has_ms_wchar();
 #endif
+
+// CHECK-NONE: no_declspec
+// CHECK-MS-KEYWORDS: has_declspec
+// CHECK-MS-KEYWORDS-WITHOUT-DECLSPEC: no_declspec
+// CHECK-DECLSPEC-KEYWORD: has_declspec
+#if __is_identifier(__declspec)
+void no_declspec();
+#else
+void has_declspec();
+#endif
Index: lib/Parse/ParseDecl.cpp
===
--- lib/Parse/ParseDecl.cpp
+++ lib/Parse/ParseDecl.cpp
@@ -532,9 +532,7 @@
 /// extended-decl-modifier extended-decl-modifier-seq
 void Parser::ParseMicrosoftDeclSpecs(ParsedAttributes &Attrs,
  SourceLocation *End) {
-  assert((getLangOpts().MicrosoftExt || getLangOpts().Borland ||
-  getLangOpts().CUDA) &&
- "Incorrect language options for parsing __declspec");
+  assert(getLangOpts().DeclSpecKeyword && "__declspec keyword is not enabled");
   assert(Tok.is(tok::kw___declspec) && "Not a declspec!");
 
   while (Tok.is(tok::kw___declspec)) {
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -1630,6 +1630,17 @@
   Opts.HalfArgsAndReturns = Args.hasArg(OPT_fallow_half_arguments_and_returns);
   Opts.GNUAsm = !Args.hasArg(OPT_fno_gnu_inline_asm);
 
+  // __declspec is enabled by default for the PS4 by the driver, and also
+  // enabled for Microsoft Extensions or Borland Extensions, here.
+  //
+  // FIXME: __declspec is al

Re: [PATCH] D13322: Add -f[no-]declspec to control recognition of __declspec as a keyword

[Warren Ristow via cfe-commits]

wristow added inline comments.


Comment at: lib/Driver/Tools.cpp:4663
@@ +4662,3 @@
+  else if (Args.hasArg(options::OPT_fno_declspec))
+CmdArgs.push_back("-fno-declspec"); // Explicitly disabling __declspec.
+

But in the '-fno-declspec -fdeclspec' case, the 'if' clause "wins", and we 
never even reach the test of the 'else if' clause.  As I said at the end of my 
previous comment, if -fno-declspec isn't the last one, we don't get to that 
line.  That said, given the interaction with "implicit enabling" of declspec 
(via Microsoft, Borland, CUDA), it's a bit different than vanilla 
switch-handling.  So I've updated the tests to explicitly have some checks for 
'-fno-declspec -fdeclspec' case (and the reverse, and for with and without 
-fms-extensions interacting).


http://reviews.llvm.org/D13322



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

LLVM buildnaster will be restarted tonight

[Galina Kistanova via cfe-commits]

Hello everyone,

LLVM buildmaster will be restarted after 6 PM Pacific time today.
Sorry for the noise.

Thanks

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

r249156 - Break long lines for readability.

[Adrian Prantl via cfe-commits]

Author: adrian
Date: Fri Oct  2 12:36:10 2015
New Revision: 249156

URL: http://llvm.org/viewvc/llvm-project?rev=249156&view=rev
Log:
Break long lines for readability.

Modified:
cfe/trunk/test/Modules/ModuleDebugInfo.m

Modified: cfe/trunk/test/Modules/ModuleDebugInfo.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/ModuleDebugInfo.m?rev=249156&r1=249155&r2=249156&view=diff
==
--- cfe/trunk/test/Modules/ModuleDebugInfo.m (original)
+++ cfe/trunk/test/Modules/ModuleDebugInfo.m Fri Oct  2 12:36:10 2015
@@ -5,12 +5,17 @@
 
 // Modules:
 // RUN: rm -rf %t
-// RUN: %clang_cc1 -x objective-c -fmodules -fmodule-format=obj 
-fimplicit-module-maps -DMODULES -fmodules-cache-path=%t %s -I %S/Inputs -I %t 
-emit-llvm -o %t.ll -mllvm -debug-only=pchcontainer &>%t-mod.ll
+// RUN: %clang_cc1 -x objective-c -fmodules -fmodule-format=obj \
+// RUN:   -fimplicit-module-maps -DMODULES -fmodules-cache-path=%t %s \
+// RUN:   -I %S/Inputs -I %t -emit-llvm -o %t.ll \
+// RUN:   -mllvm -debug-only=pchcontainer &>%t-mod.ll
 // RUN: cat %t-mod.ll | FileCheck %s
 // RUN: cat %t-mod.ll | FileCheck %s --check-prefix=MODULE-CHECK
 
 // PCH:
-// RUN: %clang_cc1 -x objective-c -emit-pch -fmodule-format=obj -I %S/Inputs 
-o %t.pch %S/Inputs/DebugObjC.h -mllvm -debug-only=pchcontainer &>%t-pch.ll
+// RUN: %clang_cc1 -x objective-c -emit-pch -fmodule-format=obj -I %S/Inputs \
+// RUN:   -o %t.pch %S/Inputs/DebugObjC.h \
+// RUN:   -mllvm -debug-only=pchcontainer &>%t-pch.ll
 // RUN: cat %t-pch.ll | FileCheck %s
 
 #ifdef MODULES


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

r249155 - Remove unused variable.

[Adrian Prantl via cfe-commits]

Author: adrian
Date: Fri Oct  2 12:36:03 2015
New Revision: 249155

URL: http://llvm.org/viewvc/llvm-project?rev=249155&view=rev
Log:
Remove unused variable.

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

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=249155&r1=249154&r2=249155&view=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Fri Oct  2 12:36:03 2015
@@ -2172,7 +2172,6 @@ ObjCInterfaceDecl *CGDebugInfo::getObjCI
 }
 
 llvm::DIModule *CGDebugInfo::getParentModuleOrNull(const Decl *D) {
-  ExternalASTSource::ASTSourceDescriptor Info;
   if (DebugTypeExtRefs && D->isFromASTFile()) {
 // Record a reference to an imported clang module or precompiled header.
 auto *Reader = CGM.getContext().getExternalSource();


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

r249157 - Module debugging: Don't emit forward declarations in module scopes.

[Adrian Prantl via cfe-commits]

Author: adrian
Date: Fri Oct  2 12:36:14 2015
New Revision: 249157

URL: http://llvm.org/viewvc/llvm-project?rev=249157&view=rev
Log:
Module debugging: Don't emit forward declarations in module scopes.
A forward declaration inside a module header does not belong to the module.

Modified:
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/test/Modules/Inputs/DebugObjC.h
cfe/trunk/test/Modules/ModuleDebugInfo.m

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=249157&r1=249156&r2=249157&view=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Fri Oct  2 12:36:14 2015
@@ -2172,6 +2172,9 @@ ObjCInterfaceDecl *CGDebugInfo::getObjCI
 }
 
 llvm::DIModule *CGDebugInfo::getParentModuleOrNull(const Decl *D) {
+  // A forward declaration inside a module header does not belong to the 
module.
+  if (isa(D) && !cast(D)->getDefinition())
+return nullptr;
   if (DebugTypeExtRefs && D->isFromASTFile()) {
 // Record a reference to an imported clang module or precompiled header.
 auto *Reader = CGM.getContext().getExternalSource();

Modified: cfe/trunk/test/Modules/Inputs/DebugObjC.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/DebugObjC.h?rev=249157&r1=249156&r2=249157&view=diff
==
--- cfe/trunk/test/Modules/Inputs/DebugObjC.h (original)
+++ cfe/trunk/test/Modules/Inputs/DebugObjC.h Fri Oct  2 12:36:14 2015
@@ -5,6 +5,7 @@
 }
 + classMethod;
 - instanceMethodWithInt:(int)i;
+- (struct OpaqueData*) getSomethingOpaque;
 @property int property;
 @end
 

Modified: cfe/trunk/test/Modules/ModuleDebugInfo.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/ModuleDebugInfo.m?rev=249157&r1=249156&r2=249157&view=diff
==
--- cfe/trunk/test/Modules/ModuleDebugInfo.m (original)
+++ cfe/trunk/test/Modules/ModuleDebugInfo.m Fri Oct  2 12:36:14 2015
@@ -41,3 +41,6 @@
 // MODULE-CHECK: !DICompositeType(tag: DW_TAG_structure_type,
 // MODULE-CHECK-SAME: name: "ObjCClass",
 // MODULE-CHECK-SAME: scope: ![[MODULE]],
+
+// The forward declaration should not be in the module scope.
+// MODULE-CHECK: !DICompositeType(tag: DW_TAG_structure_type, name: 
"OpaqueData", file


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

r249159 - constify four getInstantiatedFromMemberTemplate() in DeclTemplate.h.

[Yaron Keren via cfe-commits]

Author: yrnkrn
Date: Fri Oct  2 12:38:57 2015
New Revision: 249159

URL: http://llvm.org/viewvc/llvm-project?rev=249159&view=rev
Log:
constify four getInstantiatedFromMemberTemplate() in DeclTemplate.h.


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

Modified: cfe/trunk/include/clang/AST/DeclTemplate.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclTemplate.h?rev=249159&r1=249158&r2=249159&view=diff
==
--- cfe/trunk/include/clang/AST/DeclTemplate.h (original)
+++ cfe/trunk/include/clang/AST/DeclTemplate.h Fri Oct  2 12:38:57 2015
@@ -946,7 +946,7 @@ public:
 return const_cast(this)->getMostRecentDecl();
   }
 
-  FunctionTemplateDecl *getInstantiatedFromMemberTemplate() {
+  FunctionTemplateDecl *getInstantiatedFromMemberTemplate() const {
 return cast_or_null(
  RedeclarableTemplateDecl::getInstantiatedFromMemberTemplate());
   }
@@ -2034,7 +2034,7 @@ public:
 return const_cast(this)->getMostRecentDecl();
   }
 
-  ClassTemplateDecl *getInstantiatedFromMemberTemplate() {
+  ClassTemplateDecl *getInstantiatedFromMemberTemplate() const {
 return cast_or_null(
  RedeclarableTemplateDecl::getInstantiatedFromMemberTemplate());
   }
@@ -2264,7 +2264,7 @@ public:
this)->getPreviousDecl());
   }
 
-  TypeAliasTemplateDecl *getInstantiatedFromMemberTemplate() {
+  TypeAliasTemplateDecl *getInstantiatedFromMemberTemplate() const {
 return cast_or_null(
  RedeclarableTemplateDecl::getInstantiatedFromMemberTemplate());
   }
@@ -2867,7 +2867,7 @@ public:
 return const_cast(this)->getMostRecentDecl();
   }
 
-  VarTemplateDecl *getInstantiatedFromMemberTemplate() {
+  VarTemplateDecl *getInstantiatedFromMemberTemplate() const {
 return cast_or_null(
 RedeclarableTemplateDecl::getInstantiatedFromMemberTemplate());
   }


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

Re: [PATCH] D13217: [ARM] The Driver does not set the +strict-align flag when targeting armv6m + netbsd

[Renato Golin via cfe-commits]

rengolin added inline comments.


Comment at: lib/Basic/Targets.cpp:4456
@@ -4455,3 +4455,1 @@
 
-if (ArchVersion < 6  || 
-   (ArchVersion == 6 && ArchProfile == llvm::ARM::PK_M))

Why is this not necessary any more?


http://reviews.llvm.org/D13217



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

Re: [PATCH] D13373: Emiting invariant.group.barrier for ctors bugfix

[Piotr Padlewski via cfe-commits]

Prazek updated the summary for this revision.
Prazek updated this revision to Diff 36382.
Prazek marked an inline comment as done.

http://reviews.llvm.org/D13373

Files:
  lib/CodeGen/CGClass.cpp
  test/CodeGenCXX/invariant.group-for-vptrs.cpp
  test/CodeGenCXX/strict-vtable-pointers.cpp

Index: test/CodeGenCXX/strict-vtable-pointers.cpp
===
--- test/CodeGenCXX/strict-vtable-pointers.cpp
+++ test/CodeGenCXX/strict-vtable-pointers.cpp
@@ -136,26 +136,43 @@
 
 
 struct DynamicDerived;
+
 // CHECK-CTORS-LABEL: define linkonce_odr void @_ZN14DynamicDerivedC2Ev(
-// CHECK-CTORS: call void @_ZN12DynamicBase1C2Ev(
-// CHECK-CTORS: %[[THIS1:.*]] = bitcast %[[DynamicDerived:.*]]* %[[THIS0:.*]] to i8*
+// CHECK-CTORS: %[[THIS0:.*]] = load %[[DynamicDerived:.*]]*, %[[DynamicDerived]]** {{.*}}
+// CHECK-CTORS: %[[THIS1:.*]] = bitcast %[[DynamicDerived:.*]]* %[[THIS0]] to i8*
 // CHECK-CTORS: %[[THIS2:.*]] = call i8* @llvm.invariant.group.barrier(i8* %[[THIS1:.*]])
-// CHECK-CTORS: %[[THIS3:.*]] = bitcast i8* %[[THIS2:.*]] to %[[DynamicDerived]]*
-// CHECK-CTORS: %[[THIS4:.*]] = bitcast %struct.DynamicDerived* %[[THIS3:.*]] to i32 (...)***
-// CHECK-CTORS: store {{.*}} %[[THIS4:.*]]
+// CHECK-CTORS: %[[THIS3:.*]] = bitcast i8* %[[THIS2]] to %[[DynamicDerived]]*
+// CHECK-CTORS: %[[THIS4:.*]] = bitcast %[[DynamicDerived]]* %2 to %[[DynamicBase:.*]]*
+// CHECK-CTORS: call void @_ZN12DynamicBase1C2Ev(%[[DynamicBase]]* %[[THIS4]])
+
+// CHECK-CTORS: %[[THIS5:.*]] = bitcast %struct.DynamicDerived* %[[THIS0]] to i32 (...)***
+// CHECK-CTORS: store {{.*}} %[[THIS5]]
 // CHECK-CTORS-LABEL: }
 
 struct DynamicDerivedMultiple;
-// CHECK-CTORS-LABEL: define linkonce_odr void @_ZN22DynamicDerivedMultipleC2Ev
-// CHECK-CTORS: call void @_ZN12DynamicBase1C2Ev(
+// CHECK-CTORS-LABEL: define linkonce_odr void @_ZN22DynamicDerivedMultipleC2Ev(
+
+// CHECK-CTORS: %[[THIS0:.*]] = load %[[CLASS:.*]]*, %[[CLASS]]** {{.*}}
+// CHECK-CTORS: %[[THIS1:.*]] = bitcast %[[CLASS:.*]]* %[[THIS0]] to i8*
+// CHECK-CTORS: %[[THIS2:.*]] = call i8* @llvm.invariant.group.barrier(i8* %[[THIS1]])
+// CHECK-CTORS: %[[THIS3:.*]] = bitcast i8* %[[THIS2]] to %[[CLASS]]*
+// CHECK-CTORS: %[[THIS4:.*]] = bitcast %[[CLASS]]* %[[THIS3]] to %[[BASE_CLASS:.*]]*
+// CHECK-CTORS: call void @_ZN12DynamicBase1C2Ev(%[[BASE_CLASS]]* %[[THIS4]])
+
+// CHECK-CTORS: call i8* @llvm.invariant.group.barrier(
+
+// CHECK-CTORS: call void @_ZN12DynamicBase2C2Ev(
 // CHECK-CTORS-NOT: @llvm.invariant.group.barrier
-// CHECK-CTORS-LABEL: call void @_ZN12DynamicBase2C2Ev(
-// CHECK-CTORS: %[[THIS1:.*]] = bitcast %[[CLASS:.*]]* %[[THIS0:.*]] to i8*
-// CHECK-CTORS: %[[THIS2:.*]] = call i8* @llvm.invariant.group.barrier(i8* %[[THIS1:.*]])
-// CHECK-CTORS: %[[THIS3:.*]] = bitcast i8* %[[THIS2:.*]] to %[[CLASS]]*
-// CHECK-CTORS-NOT: invariant.group.barrier
-// CHECK-CTORS: store {{.*}} @_ZTV22DynamicDerivedMultiple, i64 0, i64 2)
-// CHECK-CTORS: store {{.*}} @_ZTV22DynamicDerivedMultiple, i64 0, i64 6)
+
+
+// CHECK-CTORS: %[[THIS10:.*]] = bitcast %struct.DynamicDerivedMultiple* %[[THIS0]] to i32 (...)***
+// CHECK-CTORS: store {{.*}} @_ZTV22DynamicDerivedMultiple, i64 0, i64 2) {{.*}} %[[THIS10]]
+// CHECK-CTORS: %[[THIS11:.*]] = bitcast %struct.DynamicDerivedMultiple* %[[THIS0]] to i8*
+// CHECK-CTORS: %[[THIS_ADD:.*]] = getelementptr inbounds i8, i8* %[[THIS11]], i64 16
+// CHECK-CTORS: %[[THIS12:.*]]  = bitcast i8* %[[THIS_ADD]] to i32 (...)***
+
+
+// CHECK-CTORS: store {{.*}} @_ZTV22DynamicDerivedMultiple, i64 0, i64 6) {{.*}} %[[THIS12]]
 // CHECK-CTORS-LABEL: }
 
 struct DynamicFromStatic;
Index: test/CodeGenCXX/invariant.group-for-vptrs.cpp
===
--- test/CodeGenCXX/invariant.group-for-vptrs.cpp
+++ test/CodeGenCXX/invariant.group-for-vptrs.cpp
@@ -56,9 +56,8 @@
 
 // Checking D::D()
 // CHECK-LABEL: define linkonce_odr void @_ZN1DC2Ev(
-
-// CHECK:  call void @_ZN1AC2Ev(%struct.A*
 // CHECK:  = call i8* @llvm.invariant.group.barrier(i8*
+// CHECK:  call void @_ZN1AC2Ev(%struct.A*
 // CHECK: store {{.*}} !invariant.group ![[D_MD]]
 
 // Checking B::B()
Index: lib/CodeGen/CGClass.cpp
===
--- lib/CodeGen/CGClass.cpp
+++ lib/CodeGen/CGClass.cpp
@@ -1375,13 +1375,14 @@
 assert(BaseCtorContinueBB);
   }
 
-  bool BaseVPtrsInitialized = false;
+  llvm::Value *const OldThis = CXXThisValue;
   // Virtual base initializers first.
   for (; B != E && (*B)->isBaseInitializer() && (*B)->isBaseVirtual(); B++) {
-CXXCtorInitializer *BaseInit = *B;
+if (CGM.getCodeGenOpts().StrictVTablePointers &&
+CGM.getCodeGenOpts().OptimizationLevel > 0 &&
+isInitializerOfDynamicClass(*B))
+  CXXThisValue = Builder.CreateInvariantGroupBarrier(LoadCXXThis());
 EmitBaseInitializer(*this, ClassDecl, *B, CtorType);
-BaseVPtrsInitialized |= BaseInitializerUsesThis(getContext(),
-  

Re: [PATCH] D13373: Emiting invariant.group.barrier for ctors bugfix

[Richard Smith via cfe-commits]

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

LGTM, but your commit message should be more descriptive than your current 
summary. Something like:

Ensure that the vptr store in the most-derived constructor is not behind an 
invariant group barrier. Previously, the base-most vptr store would be the one 
behind no barrier, and that could result in the creator of the object thinking 
it had the base-most vtable.


http://reviews.llvm.org/D13373



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

r249166 - [Myriad]: Accept '-nostdlib' option

[Douglas Katzman via cfe-commits]

Author: dougk
Date: Fri Oct  2 13:39:08 2015
New Revision: 249166

URL: http://llvm.org/viewvc/llvm-project?rev=249166&view=rev
Log:
[Myriad]: Accept '-nostdlib' option

Modified:
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/test/Driver/myriad-toolchain.c

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=249166&r1=249165&r2=249166&view=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Fri Oct  2 13:39:08 2015
@@ -9760,6 +9760,8 @@ void tools::Myriad::Linker::ConstructJob
   const llvm::Triple &T = TC.getTriple();
   ArgStringList CmdArgs;
   bool UseStartfiles = !Args.hasArg(options::OPT_nostartfiles);
+  bool UseDefaultLibs = !Args.hasArg(options::OPT_nostdlib) &&
+!Args.hasArg(options::OPT_nodefaultlibs);
 
   std::string StartFilesDir, BuiltinLibDir;
   TC.getCompilerSupportDir(StartFilesDir);
@@ -9796,27 +9798,31 @@ void tools::Myriad::Linker::ConstructJob
 options::OPT_e, options::OPT_s, options::OPT_t,
 options::OPT_Z_Flag, options::OPT_r});
 
-  // The linker doesn't use these builtin paths unless directed to,
-  // because it was not compiled for support with sysroots, nor does
-  // it have a default of little-endian with FPU.
-  CmdArgs.push_back(Args.MakeArgString("-L" + BuiltinLibDir));
-  CmdArgs.push_back(Args.MakeArgString("-L" + StartFilesDir));
+  if (UseDefaultLibs) {
+// The linker doesn't use these builtin paths unless directed to,
+// because it was not compiled for support with sysroots, nor does
+// it have a default of little-endian with FPU.
+CmdArgs.push_back(Args.MakeArgString("-L" + BuiltinLibDir));
+CmdArgs.push_back(Args.MakeArgString("-L" + StartFilesDir));
+  }
 
   AddLinkerInputs(getToolChain(), Inputs, Args, CmdArgs);
 
-  if (T.getOS() == llvm::Triple::RTEMS) {
-CmdArgs.push_back("--start-group");
-CmdArgs.push_back("-lc");
-// You must provide your own "-L" option to enable finding these.
-CmdArgs.push_back("-lrtemscpu");
-CmdArgs.push_back("-lrtemsbsp");
-CmdArgs.push_back("--end-group");
-  } else {
-CmdArgs.push_back("-lc");
+  if (UseDefaultLibs) {
+if (T.getOS() == llvm::Triple::RTEMS) {
+  CmdArgs.push_back("--start-group");
+  CmdArgs.push_back("-lc");
+  // You must provide your own "-L" option to enable finding these.
+  CmdArgs.push_back("-lrtemscpu");
+  CmdArgs.push_back("-lrtemsbsp");
+  CmdArgs.push_back("--end-group");
+} else {
+  CmdArgs.push_back("-lc");
+}
+if (C.getDriver().CCCIsCXX())
+  CmdArgs.push_back("-lstdc++");
+CmdArgs.push_back("-lgcc");
   }
-  if (C.getDriver().CCCIsCXX())
-CmdArgs.push_back("-lstdc++");
-  CmdArgs.push_back("-lgcc");
   if (UseStartfiles) {
 CmdArgs.push_back(Args.MakeArgString(StartFilesDir + "/crtend.o"));
 CmdArgs.push_back(Args.MakeArgString(StartFilesDir + "/crtn.o"));

Modified: cfe/trunk/test/Driver/myriad-toolchain.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/myriad-toolchain.c?rev=249166&r1=249165&r2=249166&view=diff
==
--- cfe/trunk/test/Driver/myriad-toolchain.c (original)
+++ cfe/trunk/test/Driver/myriad-toolchain.c Fri Oct  2 13:39:08 2015
@@ -53,3 +53,7 @@
 // RUN: %clang -target shave-myriad -c %s -o foo.o -### -MD -MF dep.d 2>&1 \
 // RUN:   | FileCheck %s -check-prefix=MDMF
 // MDMF: "-S" "-MD" "-MF" "dep.d" "-MT" "foo.o"
+
+// RUN: %clang -target sparc-myriad -### -nostdlib %s 2>&1 | FileCheck %s 
--check-prefix=NOSTDLIB
+//
+// NOSTDLIB-NOT: "-lc"


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

Re: [PATCH] D12508: [libcxx] Make it drastically simpler to link libc++.

[Eric Fiselier via cfe-commits]

EricWF added a comment.

@mclow.lists ping. Do you think this is the right approach to fix linking the 
ABI library?
@rsmith: I think you asked for this functionality a while ago. Any thoughts?


http://reviews.llvm.org/D12508



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

Question about FunctionDecl::isVariadic()

[Aaron Ballman via cfe-commits]

Given the following two function declarations:

void f1(...);
void f2();

It makes sense to me that isVariadic() returns true for f1 in both C
and C++. It makes sense to me that isVariadic() returns false for f2
in C++. I am confused as to why it returns false instead of true for
C, however.

In C11, 6.7.6.3p9 states: If the list terminates with an ellipsis (,
...), no information about the number or types of the parameters after
the comma is supplied.

p14 states, in part: "The empty list in a function declarator that is
not part of a definition of that function specifies that no
information about the number or types of the parameters is supplied."

It seems to me that for function *declarations* (not definitions),
isVariadic() should return true for f2 in C. Is there a reason it
doesn't currently behave that way, or is this a bug?

I ask because I was writing an AST matcher for isVariadic() for an
in-progress checker, but the checker was failing to catch that f2 was
a variadic function. I am not certain whether
FunctionDecl::isVariadic() should be changed, whether the AST matcher
isVariadic() should be smarter about C code, or whether the checker
itself needs to be smarter about this particular behavior in C code.
My gut reaction is that FunctionDecl::isVariadic() has a bug, but from
looking at code elsewhere, everything seems to assume isVariadic()
implies the ellipsis, which makes me think I just need to make my
checker smarter.

Thanks!

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

r249176 - [WebAssembly] Add a __builtin_wasm_memory_size() intrinsic.

[Dan Gohman via cfe-commits]

Author: djg
Date: Fri Oct  2 14:38:47 2015
New Revision: 249176

URL: http://llvm.org/viewvc/llvm-project?rev=249176&view=rev
Log:
[WebAssembly] Add a __builtin_wasm_memory_size() intrinsic.

Modified:
cfe/trunk/include/clang/Basic/BuiltinsWebAssembly.def
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/test/CodeGen/builtins-wasm.c

Modified: cfe/trunk/include/clang/Basic/BuiltinsWebAssembly.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsWebAssembly.def?rev=249176&r1=249175&r2=249176&view=diff
==
--- cfe/trunk/include/clang/Basic/BuiltinsWebAssembly.def (original)
+++ cfe/trunk/include/clang/Basic/BuiltinsWebAssembly.def Fri Oct  2 14:38:47 
2015
@@ -17,5 +17,6 @@
 // The format of this database matches clang/Basic/Builtins.def.
 
 BUILTIN(__builtin_wasm_page_size, "z", "nc")
+BUILTIN(__builtin_wasm_memory_size, "z", "nc")
 
 #undef BUILTIN

Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=249176&r1=249175&r2=249176&view=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Fri Oct  2 14:38:47 2015
@@ -7048,6 +7048,11 @@ Value *CodeGenFunction::EmitWebAssemblyB
 Value *Callee = CGM.getIntrinsic(Intrinsic::wasm_page_size, ResultType);
 return Builder.CreateCall(Callee);
   }
+  case WebAssembly::BI__builtin_wasm_memory_size: {
+llvm::Type *ResultType = ConvertType(E->getType());
+Value *Callee = CGM.getIntrinsic(Intrinsic::wasm_memory_size, ResultType);
+return Builder.CreateCall(Callee);
+  }
 
   default:
 return nullptr;

Modified: cfe/trunk/test/CodeGen/builtins-wasm.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/builtins-wasm.c?rev=249176&r1=249175&r2=249176&view=diff
==
--- cfe/trunk/test/CodeGen/builtins-wasm.c (original)
+++ cfe/trunk/test/CodeGen/builtins-wasm.c Fri Oct  2 14:38:47 2015
@@ -8,3 +8,9 @@ __SIZE_TYPE__ f0(void) {
 // WEBASSEMBLY32: call {{i.*}} @llvm.wasm.page.size.i32()
 // WEBASSEMBLY64: call {{i.*}} @llvm.wasm.page.size.i64()
 }
+
+__SIZE_TYPE__ f1(void) {
+  return __builtin_wasm_memory_size();
+// WEBASSEMBLY32: call {{i.*}} @llvm.wasm.memory.size.i32()
+// WEBASSEMBLY64: call {{i.*}} @llvm.wasm.memory.size.i64()
+}


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

Re: Question about FunctionDecl::isVariadic()

[mats petersson via cfe-commits]

Since "varargs" often involve some kind of special passing mechanisms [I've
seen implementations that build data block and pass a pointer to that,
rather than passing on the stack, for example], or additional code in the
recipient function, I would say that `f2()` does not mean `f2(...)`.

--
Mats

On 2 October 2015 at 20:16, Aaron Ballman via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Given the following two function declarations:
>
> void f1(...);
> void f2();
>
> It makes sense to me that isVariadic() returns true for f1 in both C
> and C++. It makes sense to me that isVariadic() returns false for f2
> in C++. I am confused as to why it returns false instead of true for
> C, however.
>
> In C11, 6.7.6.3p9 states: If the list terminates with an ellipsis (,
> ...), no information about the number or types of the parameters after
> the comma is supplied.
>
> p14 states, in part: "The empty list in a function declarator that is
> not part of a definition of that function specifies that no
> information about the number or types of the parameters is supplied."
>
> It seems to me that for function *declarations* (not definitions),
> isVariadic() should return true for f2 in C. Is there a reason it
> doesn't currently behave that way, or is this a bug?
>
> I ask because I was writing an AST matcher for isVariadic() for an
> in-progress checker, but the checker was failing to catch that f2 was
> a variadic function. I am not certain whether
> FunctionDecl::isVariadic() should be changed, whether the AST matcher
> isVariadic() should be smarter about C code, or whether the checker
> itself needs to be smarter about this particular behavior in C code.
> My gut reaction is that FunctionDecl::isVariadic() has a bug, but from
> looking at code elsewhere, everything seems to assume isVariadic()
> implies the ellipsis, which makes me think I just need to make my
> checker smarter.
>
> Thanks!
>
> ~Aaron
> ___
> 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

r249179 - [WebAssembly] Add a __builtin_wasm_resize_memory() intrinsic.

[Dan Gohman via cfe-commits]

Author: djg
Date: Fri Oct  2 15:20:01 2015
New Revision: 249179

URL: http://llvm.org/viewvc/llvm-project?rev=249179&view=rev
Log:
[WebAssembly] Add a __builtin_wasm_resize_memory() intrinsic.

Modified:
cfe/trunk/include/clang/Basic/BuiltinsWebAssembly.def
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/test/CodeGen/builtins-wasm.c

Modified: cfe/trunk/include/clang/Basic/BuiltinsWebAssembly.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsWebAssembly.def?rev=249179&r1=249178&r2=249179&view=diff
==
--- cfe/trunk/include/clang/Basic/BuiltinsWebAssembly.def (original)
+++ cfe/trunk/include/clang/Basic/BuiltinsWebAssembly.def Fri Oct  2 15:20:01 
2015
@@ -18,5 +18,6 @@
 
 BUILTIN(__builtin_wasm_page_size, "z", "nc")
 BUILTIN(__builtin_wasm_memory_size, "z", "nc")
+BUILTIN(__builtin_wasm_resize_memory, "vz", "n")
 
 #undef BUILTIN

Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=249179&r1=249178&r2=249179&view=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Fri Oct  2 15:20:01 2015
@@ -7053,6 +7053,11 @@ Value *CodeGenFunction::EmitWebAssemblyB
 Value *Callee = CGM.getIntrinsic(Intrinsic::wasm_memory_size, ResultType);
 return Builder.CreateCall(Callee);
   }
+  case WebAssembly::BI__builtin_wasm_resize_memory: {
+Value *X = EmitScalarExpr(E->getArg(0));
+Value *Callee = CGM.getIntrinsic(Intrinsic::wasm_resize_memory, 
X->getType());
+return Builder.CreateCall(Callee, X);
+  }
 
   default:
 return nullptr;

Modified: cfe/trunk/test/CodeGen/builtins-wasm.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/builtins-wasm.c?rev=249179&r1=249178&r2=249179&view=diff
==
--- cfe/trunk/test/CodeGen/builtins-wasm.c (original)
+++ cfe/trunk/test/CodeGen/builtins-wasm.c Fri Oct  2 15:20:01 2015
@@ -14,3 +14,9 @@ __SIZE_TYPE__ f1(void) {
 // WEBASSEMBLY32: call {{i.*}} @llvm.wasm.memory.size.i32()
 // WEBASSEMBLY64: call {{i.*}} @llvm.wasm.memory.size.i64()
 }
+
+void f2(long delta) {
+  __builtin_wasm_resize_memory(delta);
+// WEBASSEMBLY32: call void @llvm.wasm.resize.memory.i32(i32 %{{.*}})
+// WEBASSEMBLY64: call void @llvm.wasm.resize.memory.i64(i64 %{{.*}})
+}


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

Re: [PATCH] D10370: clang-format: Implement AlwaysBreakAfterDeclarationReturnType.

[Dawn Perchik via cfe-commits]

dawn added a subscriber: dawn.
dawn added a comment.

Can someone please accept and commit this patch so we can use this feature?  
Thanks.


http://reviews.llvm.org/D10370



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

Re: [libcxx] r248313 - Add placeholder __libcpp_relaxed_store() for when atomic builtins are not available.

[Eric Fiselier via cfe-commits]

Hi Tom,

I would like this patch merged into 3.7.1.
Marshall can you please approve this?

/Eric

On Tue, Sep 22, 2015 at 12:55 PM, Dimitry Andric via cfe-commits
 wrote:
> Author: dim
> Date: Tue Sep 22 13:55:37 2015
> New Revision: 248313
>
> URL: http://llvm.org/viewvc/llvm-project?rev=248313&view=rev
> Log:
> Add placeholder __libcpp_relaxed_store() for when atomic builtins are not 
> available.
>
> Summary:
> In rL241532, atomic_support.h was added, which provides handling of
> atomic operations for libc++.  When atomic builtins are not available,
> it emits a warning about being unsupported, but it still provides a
> number of stubs for the required functions.
>
> However, it misses a stub for `__libcpp_relaxed_store()`.  Add it, by
> using the same implementation as for `__libcpp_atomic_store()`.
>
> (Note that I encountered this on arm-freebsd, which still defaults to
> armv4, and does not have the runtime libcalls to support atomic
> builtins.  For now, I have simply disabled using them.)
>
> Reviewers: mclow.lists, EricWF
>
> Subscribers: theraven, cfe-commits, jroelofs, majnemer, aemerson
>
> Differential Revision: http://reviews.llvm.org/D13051
>
> Modified:
> libcxx/trunk/src/include/atomic_support.h
>
> Modified: libcxx/trunk/src/include/atomic_support.h
> URL: 
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/src/include/atomic_support.h?rev=248313&r1=248312&r2=248313&view=diff
> ==
> --- libcxx/trunk/src/include/atomic_support.h (original)
> +++ libcxx/trunk/src/include/atomic_support.h Tue Sep 22 13:55:37 2015
> @@ -103,6 +103,13 @@ void __libcpp_atomic_store(_ValueType* _
>  *__dest = __val;
>  }
>
> +template 
> +inline _LIBCPP_INLINE_VISIBILITY
> +void __libcpp_relaxed_store(_ValueType* __dest, _FromType __val)
> +{
> +*__dest = __val;
> +}
> +
>  template 
>  inline _LIBCPP_INLINE_VISIBILITY
>  _ValueType __libcpp_atomic_load(_ValueType const* __val,
>
>
> ___
> 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: Question about FunctionDecl::isVariadic()

[Aaron Ballman via cfe-commits]

On Fri, Oct 2, 2015 at 4:01 PM, mats petersson  wrote:
> Since "varargs" often involve some kind of special passing mechanisms [I've
> seen implementations that build data block and pass a pointer to that,
> rather than passing on the stack, for example], or additional code in the
> recipient function, I would say that `f2()` does not mean `f2(...)`.

I kind of wondered if that was the case. If that's reality, perhaps we
may want to consider naming it FunctionDecl::hasVarArgs() or something
that specifies the difference is in whether we need to care about
packaging up the argument list so it can be used with va_start() and
friends?

~Aaron

>
> --
> Mats
>
> On 2 October 2015 at 20:16, Aaron Ballman via cfe-commits
>  wrote:
>>
>> Given the following two function declarations:
>>
>> void f1(...);
>> void f2();
>>
>> It makes sense to me that isVariadic() returns true for f1 in both C
>> and C++. It makes sense to me that isVariadic() returns false for f2
>> in C++. I am confused as to why it returns false instead of true for
>> C, however.
>>
>> In C11, 6.7.6.3p9 states: If the list terminates with an ellipsis (,
>> ...), no information about the number or types of the parameters after
>> the comma is supplied.
>>
>> p14 states, in part: "The empty list in a function declarator that is
>> not part of a definition of that function specifies that no
>> information about the number or types of the parameters is supplied."
>>
>> It seems to me that for function *declarations* (not definitions),
>> isVariadic() should return true for f2 in C. Is there a reason it
>> doesn't currently behave that way, or is this a bug?
>>
>> I ask because I was writing an AST matcher for isVariadic() for an
>> in-progress checker, but the checker was failing to catch that f2 was
>> a variadic function. I am not certain whether
>> FunctionDecl::isVariadic() should be changed, whether the AST matcher
>> isVariadic() should be smarter about C code, or whether the checker
>> itself needs to be smarter about this particular behavior in C code.
>> My gut reaction is that FunctionDecl::isVariadic() has a bug, but from
>> looking at code elsewhere, everything seems to assume isVariadic()
>> implies the ellipsis, which makes me think I just need to make my
>> checker smarter.
>>
>> Thanks!
>>
>> ~Aaron
>> ___
>> 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] D13157: Teach -Wtautological-overlap-compare about enums

[David Blaikie via cfe-commits]

On Fri, Oct 2, 2015 at 6:10 AM, Aaron Ballman via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Thu, Oct 1, 2015 at 5:18 PM, Richard Trieu  wrote:
> > I'm in favor of keeping the asserts around.  Several times, I've seen
> Clang
> > crashers than languish in the bug tracker with an assert in a generic
> > casting function.  And no one fixes it until someone pokes at the
> backtrace
> > to find the source of the bad pointer, at which point it gets fixed
> quickly.
>
> I think no one fixes it until it becomes a pain point, not because the
> backtrace is marginally more complex. I still don't think the
> maintenance burden or performance hit from duplicate logic provides a
> tangible benefit. That being said, I'm also fine letting it slide -- I
> just worry about this becoming a pattern in more parts of the code. If
> that happens, we can have a larger discussion about it then.
>

I feel about the same here & generally discourage explicit asserts when the
intent is already expressed by a cast or similar.


>
> ~Aaron
>
> >
> > On Thu, Oct 1, 2015 at 1:01 PM, George Burgess IV
> >  wrote:
> >>
> >> > Next time, add Differential Revision:  to your commit and
> >> > Phabricator will close the diff automatically.
> >>
> >> Ooh, shiny. Thanks for letting me know!
> >>
> >> > Doubling the expense for assert builds so that we get a slightly
> better
> >> > stack trace in the event our assumptions are wrong doesn't seem like
> a good
> >> > tradeoff
> >>
> >> I'd think that the optimizer would be able to eliminate the redundant
> >> checks for Release+Asserts builds, and that this code wouldn't get hit
> often
> >> enough for it to make a meaningful impact on the execution time of a
> Debug
> >> build of clang. That said, I'm happy to potentially make things a bit
> faster
> >> if that's what we choose to do. :)
> >>
> >> Richard, do you feel strongly one way or the other? If not, I'll go
> ahead
> >> and take them out.
> >>
> >> George
> >>
> >> On Thu, Oct 1, 2015 at 12:03 PM, Aaron Ballman  >
> >> wrote:
> >>>
> >>> On Thu, Oct 1, 2015 at 3:01 PM, Richard Trieu 
> wrote:
> >>> > rtrieu added a comment.
> >>> >
> >>> > Next time, add
> >>> >
> >>> >> Differential Revision: 
> >>> >
> >>> >
> >>> > to your commit and Phabricator will close the diff automatically.
> >>> >
> >>> > http://llvm.org/docs/Phabricator.html
> >>> >
> >>> >
> >>> > 
> >>> > Comment at: lib/Analysis/CFG.cpp:99-104
> >>> > @@ +98,8 @@
> >>> > +  // Currently we're only given EnumConstantDecls or IntegerLiterals
> >>> > +  auto *C1 =
> cast(cast(A)->getDecl());
> >>> > +  auto *C2 =
> cast(cast(B)->getDecl());
> >>> > +
> >>> > +  const TagDecl *E1 =
> >>> > TagDecl::castFromDeclContext(C1->getDeclContext());
> >>> > +  const TagDecl *E2 =
> >>> > TagDecl::castFromDeclContext(C2->getDeclContext());
> >>> > +  return E1 == E2;
> >>> > +}
> >>> > 
> >>> > george.burgess.iv wrote:
> >>> >> rtrieu wrote:
> >>> >> > There's a few extra casts in here, plus some blind conversions
> >>> >> > between types.  Add your assumptions for the types in asserts.
> Also,
> >>> >> > DeclContext should use cast<> to get to Decl types.  I recommend
> the
> >>> >> > following:
> >>> >> >
> >>> >> > ```
> >>> >> >   assert(isa(E1) && isa(E2));
> >>> >> >   auto *Decl1 = cast(E1)->getDecl();
> >>> >> >   auto *Decl2 = cast(E2)->getDecl();
> >>> >> >
> >>> >> >   assert(isa(Decl1) &&
> >>> >> > isa(Decl2));
> >>> >> >   const DeclContext *DC1 = Decl1->getDeclContext();
> >>> >> >   const DeclContext *DC2 = Decl2->getDeclContext();
> >>> >> >
> >>> >> >   assert(isa(DC1) && isa(DC2));
> >>> >> >   return DC1 == DC2;
> >>> >> >
> >>> >> > ```
> >>> >> I was under the impression that the `cast(Bar)` asserts
> >>> >> `isa(Bar)` for me, so I thought that asserts like those would
> just be
> >>> >> redundant. Changed to your version anyway :)
> >>> > You are correct, 'cast(Bar)' does assert 'isa(Bar)'.
> >>> > However, when Bar is not Foo, using the assert here means the crash
> will
> >>> > produce a backtrace will point straight to this function instead of
> an
> >>> > assert that points deep into the casting functions.
> >>>
> >>> Doubling the expense for assert builds so that we get a slightly
> >>> better stack trace in the event our assumptions are wrong doesn't seem
> >>> like a good tradeoff. It means everyone running an assert build pays
> >>> the price twice to save a few moments of scanning the backtrace in a
> >>> situation that's (hopefully) highly unlikely to occur in practice.
> >>>
> >>> ~Aaron
> >>>
> >>> >
> >>> >
> >>> > http://reviews.llvm.org/D13157
> >>> >
> >>> >
> >>> >
> >>
> >>
> >
> ___
> 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] D13337: [libcxx] Attempt to fix __throw_future_error in C++03

[Marshall Clow via cfe-commits]

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

LGTM.
I can't reproduce the error that I was getting.


http://reviews.llvm.org/D13337



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

Re: r249157 - Module debugging: Don't emit forward declarations in module scopes.

[David Blaikie via cfe-commits]

This seems a little curious, so you'll have code like this:

  decl foo
  module
def bar
   member foo pointer (references the declaration of foo outside the
module, in the CU?)

Why is that preferable to DWARF that looks more like the AST where the
declaration of foo appears in the first module that references it, rather
than, in a curiously circular situation, in the CU that references the
module?


On Fri, Oct 2, 2015 at 10:36 AM, Adrian Prantl via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: adrian
> Date: Fri Oct  2 12:36:14 2015
> New Revision: 249157
>
> URL: http://llvm.org/viewvc/llvm-project?rev=249157&view=rev
> Log:
> Module debugging: Don't emit forward declarations in module scopes.
> A forward declaration inside a module header does not belong to the module.
>
> Modified:
> cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> cfe/trunk/test/Modules/Inputs/DebugObjC.h
> cfe/trunk/test/Modules/ModuleDebugInfo.m
>
> Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=249157&r1=249156&r2=249157&view=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Fri Oct  2 12:36:14 2015
> @@ -2172,6 +2172,9 @@ ObjCInterfaceDecl *CGDebugInfo::getObjCI
>  }
>
>  llvm::DIModule *CGDebugInfo::getParentModuleOrNull(const Decl *D) {
> +  // A forward declaration inside a module header does not belong to the
> module.
> +  if (isa(D) && !cast(D)->getDefinition())
> +return nullptr;
>if (DebugTypeExtRefs && D->isFromASTFile()) {
>  // Record a reference to an imported clang module or precompiled
> header.
>  auto *Reader = CGM.getContext().getExternalSource();
>
> Modified: cfe/trunk/test/Modules/Inputs/DebugObjC.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/DebugObjC.h?rev=249157&r1=249156&r2=249157&view=diff
>
> ==
> --- cfe/trunk/test/Modules/Inputs/DebugObjC.h (original)
> +++ cfe/trunk/test/Modules/Inputs/DebugObjC.h Fri Oct  2 12:36:14 2015
> @@ -5,6 +5,7 @@
>  }
>  + classMethod;
>  - instanceMethodWithInt:(int)i;
> +- (struct OpaqueData*) getSomethingOpaque;
>  @property int property;
>  @end
>
>
> Modified: cfe/trunk/test/Modules/ModuleDebugInfo.m
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/ModuleDebugInfo.m?rev=249157&r1=249156&r2=249157&view=diff
>
> ==
> --- cfe/trunk/test/Modules/ModuleDebugInfo.m (original)
> +++ cfe/trunk/test/Modules/ModuleDebugInfo.m Fri Oct  2 12:36:14 2015
> @@ -41,3 +41,6 @@
>  // MODULE-CHECK: !DICompositeType(tag: DW_TAG_structure_type,
>  // MODULE-CHECK-SAME: name: "ObjCClass",
>  // MODULE-CHECK-SAME: scope: ![[MODULE]],
> +
> +// The forward declaration should not be in the module scope.
> +// MODULE-CHECK: !DICompositeType(tag: DW_TAG_structure_type, name:
> "OpaqueData", file
>
>
> ___
> 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: Question about FunctionDecl::isVariadic()

[mats petersson via cfe-commits]

On 2 October 2015 at 22:07, Aaron Ballman  wrote:

> On Fri, Oct 2, 2015 at 4:01 PM, mats petersson 
> wrote:
> > Since "varargs" often involve some kind of special passing mechanisms
> [I've
> > seen implementations that build data block and pass a pointer to that,
> > rather than passing on the stack, for example], or additional code in the
> > recipient function, I would say that `f2()` does not mean `f2(...)`.
>
> I kind of wondered if that was the case. If that's reality, perhaps we
> may want to consider naming it FunctionDecl::hasVarArgs() or something
> that specifies the difference is in whether we need to care about
> packaging up the argument list so it can be used with va_start() and
> friends?
>

My understanding of the meaning of `isVariadic` is indeed "needs to use
va_* to get arguments".

I believe it's technically valid to do something like:

void f2();


f2(42);


voif f2(int x)
{
... use x ...
}

and no special code should be required. Of course, the results of changing
`f2(42);` int `f2(4.2);` or `f2("foo");` and retaining the `int x`
parameter will lead to undefined behaviour, and compiler can do anything it
likes with that... :)

--
Mats

>
> ~Aaron
>
> >
> > --
> > Mats
> >
> > On 2 October 2015 at 20:16, Aaron Ballman via cfe-commits
> >  wrote:
> >>
> >> Given the following two function declarations:
> >>
> >> void f1(...);
> >> void f2();
> >>
> >> It makes sense to me that isVariadic() returns true for f1 in both C
> >> and C++. It makes sense to me that isVariadic() returns false for f2
> >> in C++. I am confused as to why it returns false instead of true for
> >> C, however.
> >>
> >> In C11, 6.7.6.3p9 states: If the list terminates with an ellipsis (,
> >> ...), no information about the number or types of the parameters after
> >> the comma is supplied.
> >>
> >> p14 states, in part: "The empty list in a function declarator that is
> >> not part of a definition of that function specifies that no
> >> information about the number or types of the parameters is supplied."
> >>
> >> It seems to me that for function *declarations* (not definitions),
> >> isVariadic() should return true for f2 in C. Is there a reason it
> >> doesn't currently behave that way, or is this a bug?
> >>
> >> I ask because I was writing an AST matcher for isVariadic() for an
> >> in-progress checker, but the checker was failing to catch that f2 was
> >> a variadic function. I am not certain whether
> >> FunctionDecl::isVariadic() should be changed, whether the AST matcher
> >> isVariadic() should be smarter about C code, or whether the checker
> >> itself needs to be smarter about this particular behavior in C code.
> >> My gut reaction is that FunctionDecl::isVariadic() has a bug, but from
> >> looking at code elsewhere, everything seems to assume isVariadic()
> >> implies the ellipsis, which makes me think I just need to make my
> >> checker smarter.
> >>
> >> Thanks!
> >>
> >> ~Aaron
> >> ___
> >> 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] D13313: [clang-tidy] new check cppcoreguidelines-pro-type-reinterpret-cast

[Matthias Gehre via cfe-commits]

mgehre updated this revision to Diff 36399.
mgehre added a comment.

rebased


http://reviews.llvm.org/D13313

Files:
  clang-tidy/CMakeLists.txt
  clang-tidy/Makefile
  clang-tidy/add_new_check.py
  clang-tidy/cppcoreguidelines/CMakeLists.txt
  clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
  clang-tidy/cppcoreguidelines/Makefile
  clang-tidy/cppcoreguidelines/ProTypeReinterpretCastCheck.cpp
  clang-tidy/cppcoreguidelines/ProTypeReinterpretCastCheck.h
  clang-tidy/tool/CMakeLists.txt
  clang-tidy/tool/ClangTidyMain.cpp
  clang-tidy/tool/Makefile
  docs/clang-tidy/checks/cppcoreguidelines-pro-type-reinterpret-cast.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/cppcoreguidelines-pro-type-reinterpret-cast.cpp

Index: test/clang-tidy/cppcoreguidelines-pro-type-reinterpret-cast.cpp
===
--- /dev/null
+++ test/clang-tidy/cppcoreguidelines-pro-type-reinterpret-cast.cpp
@@ -0,0 +1,6 @@
+// RUN: %python %S/check_clang_tidy.py %s cppcoreguidelines-pro-type-reinterpret-cast %t
+
+int i = 0;
+void* j;
+void f() { j = reinterpret_cast(i); }
+// CHECK-MESSAGES: :[[@LINE-1]]:16: warning: do not use reinterpret_cast [cppcoreguidelines-pro-type-reinterpret-cast]
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -2,6 +2,7 @@
 =
 
 .. toctree::
+   cppcoreguidelines-pro-type-reinterpret-cast
google-build-explicit-make-pair
google-build-namespaces
google-build-using-namespace
Index: docs/clang-tidy/checks/cppcoreguidelines-pro-type-reinterpret-cast.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/cppcoreguidelines-pro-type-reinterpret-cast.rst
@@ -0,0 +1,9 @@
+cppcoreguidelines-pro-type-reinterpret-cast
+===
+
+This check flags all uses of reinterpret_cast in C++ code.
+
+Use of these casts can violate type safety and cause the program to access a variable that is actually of type X to be accessed as if it were of an unrelated type Z.
+
+This rule is part of the "Type safety" profile of the C++ Core Guidelines, see
+https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#-type1-dont-use-reinterpret_cast.
Index: clang-tidy/tool/Makefile
===
--- clang-tidy/tool/Makefile
+++ clang-tidy/tool/Makefile
@@ -19,6 +19,7 @@
 USEDLIBS = clangTidy.a clangTidyLLVMModule.a clangTidyGoogleModule.a \
clangTidyMiscModule.a clangTidyModernizeModule.a clangTidyReadability.a \
 	   clangTidyUtils.a clangTidyCERTModule.a clangStaticAnalyzerFrontend.a \
+	   clangTidyCppCoreGuidelinesModule.a \
 	   clangStaticAnalyzerCheckers.a clangStaticAnalyzerCore.a \
 	   clangFormat.a clangASTMatchers.a clangTooling.a clangToolingCore.a \
 	   clangFrontend.a clangSerialization.a clangDriver.a clangParse.a \
Index: clang-tidy/tool/ClangTidyMain.cpp
===
--- clang-tidy/tool/ClangTidyMain.cpp
+++ clang-tidy/tool/ClangTidyMain.cpp
@@ -357,6 +357,11 @@
 static int LLVM_ATTRIBUTE_UNUSED LLVMModuleAnchorDestination =
 LLVMModuleAnchorSource;
 
+// This anchor is used to force the linker to link the CppCoreGuidelinesModule.
+extern volatile int CppCoreGuidelinesModuleAnchorSource;
+static int LLVM_ATTRIBUTE_UNUSED CppCoreGuidelinesModuleAnchorDestination =
+CppCoreGuidelinesModuleAnchorSource;
+
 // This anchor is used to force the linker to link the GoogleModule.
 extern volatile int GoogleModuleAnchorSource;
 static int LLVM_ATTRIBUTE_UNUSED GoogleModuleAnchorDestination =
Index: clang-tidy/tool/CMakeLists.txt
===
--- clang-tidy/tool/CMakeLists.txt
+++ clang-tidy/tool/CMakeLists.txt
@@ -11,6 +11,7 @@
   clangBasic
   clangTidy
   clangTidyCERTModule
+  clangTidyCppCoreGuidelinesModule
   clangTidyGoogleModule
   clangTidyLLVMModule
   clangTidyMiscModule
Index: clang-tidy/cppcoreguidelines/ProTypeReinterpretCastCheck.h
===
--- /dev/null
+++ clang-tidy/cppcoreguidelines/ProTypeReinterpretCastCheck.h
@@ -0,0 +1,33 @@
+//===--- ProTypeReinterpretCast.h - clang-tidy--*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_CPPCOREGUIDELINES_PRO_TYPE_REINTERPRETCAST_CHECK_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_CPPCOREGUIDELINES_PRO_TYPE_REINTERPRETCAST_CHECK_H
+
+#include "../ClangTidy.h"
+
+namespace clang {
+namespace tidy {
+
+/// Fla

Re: [PATCH] D13313: [clang-tidy] new check cppcoreguidelines-pro-type-reinterpret-cast

[Matthias Gehre via cfe-commits]

mgehre added a comment.

I'm not sure what you mean by ToT. I rebased this against master @ 
http://llvm.org/git/clang-tools-extra.git


http://reviews.llvm.org/D13313



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

[libcxx] r249192 - [libcxx] Attempt to fix __throw_future_error in C++03

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Fri Oct  2 16:25:15 2015
New Revision: 249192

URL: http://llvm.org/viewvc/llvm-project?rev=249192&view=rev
Log:
[libcxx] Attempt to fix __throw_future_error in C++03 

Summary:
Hi Marshall,

Could you please test this patch and see if you run into the same linker errors 
we talked about?
I can't reproduce on linux or OS X.

Hopefully you can't find any problems and we can fix the C++03 bot.

Reviewers: mclow.lists

Subscribers: cfe-commits

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

Modified:
libcxx/trunk/include/future

Modified: libcxx/trunk/include/future
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/future?rev=249192&r1=249191&r2=249192&view=diff
==
--- libcxx/trunk/include/future (original)
+++ libcxx/trunk/include/future Fri Oct  2 16:25:15 2015
@@ -512,9 +512,8 @@ public:
 virtual ~future_error() _NOEXCEPT;
 };
 
-template 
-_LIBCPP_ALWAYS_INLINE
-void __throw_future_error()
+inline _LIBCPP_ALWAYS_INLINE
+void __throw_future_error(future_errc _Ev)
 {
 #ifndef _LIBCPP_NO_EXCEPTIONS
 throw future_error(make_error_code(_Ev));
@@ -657,7 +656,7 @@ __assoc_state<_Rp>::set_value(_Arg& __ar
 {
 unique_lock __lk(this->__mut_);
 if (this->__has_value())
-__throw_future_error();
+__throw_future_error(future_errc::promise_already_satisfied);
 ::new(&__value_) _Rp(_VSTD::forward<_Arg>(__arg));
 this->__state_ |= base::__constructed | base::ready;
 __cv_.notify_all();
@@ -674,7 +673,7 @@ __assoc_state<_Rp>::set_value_at_thread_
 {
 unique_lock __lk(this->__mut_);
 if (this->__has_value())
-__throw_future_error();
+__throw_future_error(future_errc::promise_already_satisfied);
 ::new(&__value_) _Rp(_VSTD::forward<_Arg>(__arg));
 this->__state_ |= base::__constructed;
 __thread_local_data()->__make_ready_at_thread_exit(this);
@@ -733,7 +732,7 @@ __assoc_state<_Rp&>::set_value(_Rp& __ar
 {
 unique_lock __lk(this->__mut_);
 if (this->__has_value())
-__throw_future_error();
+__throw_future_error(future_errc::promise_already_satisfied);
 __value_ = _VSTD::addressof(__arg);
 this->__state_ |= base::__constructed | base::ready;
 __cv_.notify_all();
@@ -745,7 +744,7 @@ __assoc_state<_Rp&>::set_value_at_thread
 {
 unique_lock __lk(this->__mut_);
 if (this->__has_value())
-__throw_future_error();
+__throw_future_error(future_errc::promise_already_satisfied);
 __value_ = _VSTD::addressof(__arg);
 this->__state_ |= base::__constructed;
 __thread_local_data()->__make_ready_at_thread_exit(this);
@@ -1142,7 +1141,7 @@ future<_Rp>::future(__assoc_state<_Rp>*
 : __state_(__state)
 {
 if (__state_->__has_future_attached())
-__throw_future_error();
+__throw_future_error(future_errc::future_already_retrieved);
 __state_->__add_shared();
 __state_->__set_future_attached();
 }
@@ -1244,7 +1243,7 @@ future<_Rp&>::future(__assoc_state<_Rp&>
 : __state_(__state)
 {
 if (__state_->__has_future_attached())
-__throw_future_error();
+__throw_future_error(future_errc::future_already_retrieved);
 __state_->__add_shared();
 __state_->__set_future_attached();
 }
@@ -1445,7 +1444,7 @@ future<_Rp>
 promise<_Rp>::get_future()
 {
 if (__state_ == nullptr)
-__throw_future_error();
+__throw_future_error(future_errc::no_state);
 return future<_Rp>(__state_);
 }
 
@@ -1454,7 +1453,7 @@ void
 promise<_Rp>::set_value(const _Rp& __r)
 {
 if (__state_ == nullptr)
-__throw_future_error();
+__throw_future_error(future_errc::no_state);
 __state_->set_value(__r);
 }
 
@@ -1465,7 +1464,7 @@ void
 promise<_Rp>::set_value(_Rp&& __r)
 {
 if (__state_ == nullptr)
-__throw_future_error();
+__throw_future_error(future_errc::no_state);
 __state_->set_value(_VSTD::move(__r));
 }
 
@@ -1476,7 +1475,7 @@ void
 promise<_Rp>::set_exception(exception_ptr __p)
 {
 if (__state_ == nullptr)
-__throw_future_error();
+__throw_future_error(future_errc::no_state);
 __state_->set_exception(__p);
 }
 
@@ -1485,7 +1484,7 @@ void
 promise<_Rp>::set_value_at_thread_exit(const _Rp& __r)
 {
 if (__state_ == nullptr)
-__throw_future_error();
+__throw_future_error(future_errc::no_state);
 __state_->set_value_at_thread_exit(__r);
 }
 
@@ -1496,7 +1495,7 @@ void
 promise<_Rp>::set_value_at_thread_exit(_Rp&& __r)
 {
 if (__state_ == nullptr)
-__throw_future_error();
+__throw_future_error(future_errc::no_state);
 __state_->set_value_at_thread_exit(_VSTD::move(__r));
 }
 
@@ -1507,7 +1506,7 @@ void
 promise<_Rp>::set_exception_at_thread_exit(exception_ptr __p)
 {
 if (__state_ == nullptr)
-__throw_future_error();
+__throw_future_error(future_errc::no_state);
 __state_->set_exception_at_thread

Re: Question about FunctionDecl::isVariadic()

[Aaron Ballman via cfe-commits]

On Fri, Oct 2, 2015 at 5:22 PM, mats petersson  wrote:
>
>
> On 2 October 2015 at 22:07, Aaron Ballman  wrote:
>>
>> On Fri, Oct 2, 2015 at 4:01 PM, mats petersson 
>> wrote:
>> > Since "varargs" often involve some kind of special passing mechanisms
>> > [I've
>> > seen implementations that build data block and pass a pointer to that,
>> > rather than passing on the stack, for example], or additional code in
>> > the
>> > recipient function, I would say that `f2()` does not mean `f2(...)`.
>>
>> I kind of wondered if that was the case. If that's reality, perhaps we
>> may want to consider naming it FunctionDecl::hasVarArgs() or something
>> that specifies the difference is in whether we need to care about
>> packaging up the argument list so it can be used with va_start() and
>> friends?
>
>
> My understanding of the meaning of `isVariadic` is indeed "needs to use va_*
> to get arguments".
>
> I believe it's technically valid to do something like:
>
> void f2();
>
> 
> f2(42);
> 
>
> voif f2(int x)
> {
> ... use x ...
> }
>
> and no special code should be required. Of course, the results of changing
> `f2(42);` int `f2(4.2);` or `f2("foo");` and retaining the `int x` parameter
> will lead to undefined behaviour, and compiler can do anything it likes with
> that... :)

That is correct, and why I was originally surprised that isVaridic()
was returning false for such a declaration. However, what you can't do
with an empty parameter declaration list, but can do with a trailing
varargs, is get a va_list out of the final parameter. AFAIK, you
cannot do this:

void f2();

void f2(int x, ...) {
  va_list va;
  va_start(va, x);
  va_end(va);
}

int main(void) {
  f2(12, 1.2, "this is one reason why I hate C");
}

~Aaron

>
> --
> Mats
>>
>>
>> ~Aaron
>>
>> >
>> > --
>> > Mats
>> >
>> > On 2 October 2015 at 20:16, Aaron Ballman via cfe-commits
>> >  wrote:
>> >>
>> >> Given the following two function declarations:
>> >>
>> >> void f1(...);
>> >> void f2();
>> >>
>> >> It makes sense to me that isVariadic() returns true for f1 in both C
>> >> and C++. It makes sense to me that isVariadic() returns false for f2
>> >> in C++. I am confused as to why it returns false instead of true for
>> >> C, however.
>> >>
>> >> In C11, 6.7.6.3p9 states: If the list terminates with an ellipsis (,
>> >> ...), no information about the number or types of the parameters after
>> >> the comma is supplied.
>> >>
>> >> p14 states, in part: "The empty list in a function declarator that is
>> >> not part of a definition of that function specifies that no
>> >> information about the number or types of the parameters is supplied."
>> >>
>> >> It seems to me that for function *declarations* (not definitions),
>> >> isVariadic() should return true for f2 in C. Is there a reason it
>> >> doesn't currently behave that way, or is this a bug?
>> >>
>> >> I ask because I was writing an AST matcher for isVariadic() for an
>> >> in-progress checker, but the checker was failing to catch that f2 was
>> >> a variadic function. I am not certain whether
>> >> FunctionDecl::isVariadic() should be changed, whether the AST matcher
>> >> isVariadic() should be smarter about C code, or whether the checker
>> >> itself needs to be smarter about this particular behavior in C code.
>> >> My gut reaction is that FunctionDecl::isVariadic() has a bug, but from
>> >> looking at code elsewhere, everything seems to assume isVariadic()
>> >> implies the ellipsis, which makes me think I just need to make my
>> >> checker smarter.
>> >>
>> >> Thanks!
>> >>
>> >> ~Aaron
>> >> ___
>> >> 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: r249157 - Module debugging: Don't emit forward declarations in module scopes.

[Adrian Prantl via cfe-commits]

> On Oct 2, 2015, at 2:18 PM, David Blaikie  wrote:
> 
> This seems a little curious, so you'll have code like this:
> 
>   decl foo
>   module
> def bar
>member foo pointer (references the declaration of foo outside the 
> module, in the CU?)
> 

Right.

> Why is that preferable to DWARF that looks more like the AST where the 
> declaration of foo appears in the first module that references it, rather 
> than, in a curiously circular situation, in the CU that references the module?

The problem I had with this was that a forward declaration would end up in a 
DeclContext that is not the DeclContext of the definition. Looking at this 
through the dsymutil goggles, the different DeclContexts effectively prevent 
the forward declaration from being uniqued with the type's definition.

-- adrian

> On Fri, Oct 2, 2015 at 10:36 AM, Adrian Prantl via cfe-commits 
> mailto:cfe-commits@lists.llvm.org>> wrote:
> Author: adrian
> Date: Fri Oct  2 12:36:14 2015
> New Revision: 249157
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=249157&view=rev 
> 
> Log:
> Module debugging: Don't emit forward declarations in module scopes.
> A forward declaration inside a module header does not belong to the module.
> 
> Modified:
> cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> cfe/trunk/test/Modules/Inputs/DebugObjC.h
> cfe/trunk/test/Modules/ModuleDebugInfo.m
> 
> Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=249157&r1=249156&r2=249157&view=diff
>  
> 
> ==
> --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Fri Oct  2 12:36:14 2015
> @@ -2172,6 +2172,9 @@ ObjCInterfaceDecl *CGDebugInfo::getObjCI
>  }
> 
>  llvm::DIModule *CGDebugInfo::getParentModuleOrNull(const Decl *D) {
> +  // A forward declaration inside a module header does not belong to the 
> module.
> +  if (isa(D) && !cast(D)->getDefinition())
> +return nullptr;
>if (DebugTypeExtRefs && D->isFromASTFile()) {
>  // Record a reference to an imported clang module or precompiled header.
>  auto *Reader = CGM.getContext().getExternalSource();
> 
> Modified: cfe/trunk/test/Modules/Inputs/DebugObjC.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/DebugObjC.h?rev=249157&r1=249156&r2=249157&view=diff
>  
> 
> ==
> --- cfe/trunk/test/Modules/Inputs/DebugObjC.h (original)
> +++ cfe/trunk/test/Modules/Inputs/DebugObjC.h Fri Oct  2 12:36:14 2015
> @@ -5,6 +5,7 @@
>  }
>  + classMethod;
>  - instanceMethodWithInt:(int)i;
> +- (struct OpaqueData*) getSomethingOpaque;
>  @property int property;
>  @end
> 
> 
> Modified: cfe/trunk/test/Modules/ModuleDebugInfo.m
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/ModuleDebugInfo.m?rev=249157&r1=249156&r2=249157&view=diff
>  
> 
> ==
> --- cfe/trunk/test/Modules/ModuleDebugInfo.m (original)
> +++ cfe/trunk/test/Modules/ModuleDebugInfo.m Fri Oct  2 12:36:14 2015
> @@ -41,3 +41,6 @@
>  // MODULE-CHECK: !DICompositeType(tag: DW_TAG_structure_type,
>  // MODULE-CHECK-SAME: name: "ObjCClass",
>  // MODULE-CHECK-SAME: scope: ![[MODULE]],
> +
> +// The forward declaration should not be in the module scope.
> +// MODULE-CHECK: !DICompositeType(tag: DW_TAG_structure_type, name: 
> "OpaqueData", file
> 
> 
> ___
> 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] D13313: [clang-tidy] new check cppcoreguidelines-pro-type-reinterpret-cast

[Aaron Ballman via cfe-commits]

On Fri, Oct 2, 2015 at 5:27 PM, Matthias Gehre  wrote:
> mgehre added a comment.
>
> I'm not sure what you mean by ToT. I rebased this against master @ 
> http://llvm.org/git/clang-tools-extra.git

Top of Tree from the svn repository. I'm not certain how quickly the
git mirror updates, but when I download your latest revision, I still
get a merge conflict with: clang-tidy/cppcoreguidelines/Makefile

I don't think that Makefile diff in your patch is correct because it
shows lines being removed, but there's no existing content for that
file (it should have all additions, no deletions).

~Aaron

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

Re: r249157 - Module debugging: Don't emit forward declarations in module scopes.

[David Blaikie via cfe-commits]

On Fri, Oct 2, 2015 at 2:40 PM, Adrian Prantl  wrote:

>
> On Oct 2, 2015, at 2:18 PM, David Blaikie  wrote:
>
> This seems a little curious, so you'll have code like this:
>
>   decl foo
>   module
> def bar
>member foo pointer (references the declaration of foo outside the
> module, in the CU?)
>
>
> Right.
>
> Why is that preferable to DWARF that looks more like the AST where the
> declaration of foo appears in the first module that references it, rather
> than, in a curiously circular situation, in the CU that references the
> module?
>
>
> The problem I had with this was that a forward declaration would end up in
> a DeclContext that is not the DeclContext of the definition. Looking at
> this through the dsymutil goggles, the different DeclContexts effectively
> prevent the forward declaration from being uniqued with the type's
> definition.
>

Putting it in the CU doesn't seem to make the decl context match either,
does it? In that case the decl context may still be "some other compile
unit" (as with most declarations)

Shouldn't dsymutil be treating modules more like CUs as "another top level
scope"?


>
> -- adrian
>
> On Fri, Oct 2, 2015 at 10:36 AM, Adrian Prantl via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: adrian
>> Date: Fri Oct  2 12:36:14 2015
>> New Revision: 249157
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=249157&view=rev
>> Log:
>> Module debugging: Don't emit forward declarations in module scopes.
>> A forward declaration inside a module header does not belong to the
>> module.
>>
>> Modified:
>> cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
>> cfe/trunk/test/Modules/Inputs/DebugObjC.h
>> cfe/trunk/test/Modules/ModuleDebugInfo.m
>>
>> Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=249157&r1=249156&r2=249157&view=diff
>>
>> ==
>> --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
>> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Fri Oct  2 12:36:14 2015
>> @@ -2172,6 +2172,9 @@ ObjCInterfaceDecl *CGDebugInfo::getObjCI
>>  }
>>
>>  llvm::DIModule *CGDebugInfo::getParentModuleOrNull(const Decl *D) {
>> +  // A forward declaration inside a module header does not belong to the
>> module.
>> +  if (isa(D) && !cast(D)->getDefinition())
>> +return nullptr;
>>if (DebugTypeExtRefs && D->isFromASTFile()) {
>>  // Record a reference to an imported clang module or precompiled
>> header.
>>  auto *Reader = CGM.getContext().getExternalSource();
>>
>> Modified: cfe/trunk/test/Modules/Inputs/DebugObjC.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/DebugObjC.h?rev=249157&r1=249156&r2=249157&view=diff
>>
>> ==
>> --- cfe/trunk/test/Modules/Inputs/DebugObjC.h (original)
>> +++ cfe/trunk/test/Modules/Inputs/DebugObjC.h Fri Oct  2 12:36:14 2015
>> @@ -5,6 +5,7 @@
>>  }
>>  + classMethod;
>>  - instanceMethodWithInt:(int)i;
>> +- (struct OpaqueData*) getSomethingOpaque;
>>  @property int property;
>>  @end
>>
>>
>> Modified: cfe/trunk/test/Modules/ModuleDebugInfo.m
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/ModuleDebugInfo.m?rev=249157&r1=249156&r2=249157&view=diff
>>
>> ==
>> --- cfe/trunk/test/Modules/ModuleDebugInfo.m (original)
>> +++ cfe/trunk/test/Modules/ModuleDebugInfo.m Fri Oct  2 12:36:14 2015
>> @@ -41,3 +41,6 @@
>>  // MODULE-CHECK: !DICompositeType(tag: DW_TAG_structure_type,
>>  // MODULE-CHECK-SAME: name: "ObjCClass",
>>  // MODULE-CHECK-SAME: scope: ![[MODULE]],
>> +
>> +// The forward declaration should not be in the module scope.
>> +// MODULE-CHECK: !DICompositeType(tag: DW_TAG_structure_type, name:
>> "OpaqueData", file
>>
>>
>> ___
>> 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: r249157 - Module debugging: Don't emit forward declarations in module scopes.

[Adrian Prantl via cfe-commits]

> On Oct 2, 2015, at 2:58 PM, David Blaikie  wrote:
> 
> 
> 
> On Fri, Oct 2, 2015 at 2:40 PM, Adrian Prantl  > wrote:
> 
>> On Oct 2, 2015, at 2:18 PM, David Blaikie > > wrote:
>> 
>> This seems a little curious, so you'll have code like this:
>> 
>>   decl foo
>>   module
>> def bar
>>member foo pointer (references the declaration of foo outside the 
>> module, in the CU?)
>> 
> 
> Right.
> 
>> Why is that preferable to DWARF that looks more like the AST where the 
>> declaration of foo appears in the first module that references it, rather 
>> than, in a curiously circular situation, in the CU that references the 
>> module?
> 
> The problem I had with this was that a forward declaration would end up in a 
> DeclContext that is not the DeclContext of the definition. Looking at this 
> through the dsymutil goggles, the different DeclContexts effectively prevent 
> the forward declaration from being uniqued with the type's definition.
> 
> Putting it in the CU doesn't seem to make the decl context match either, does 
> it? In that case the decl context may still be "some other compile unit" (as 
> with most declarations)
> 
> Shouldn't dsymutil be treating modules more like CUs as "another top level 
> scope”?

The CU is not part of the DeclContext (for dsymutil’s interpretation of a 
DeclContext). Otherwise cross-CU type uniquing would never work.

-- adrian

>  
> 
> -- adrian
> 
>> On Fri, Oct 2, 2015 at 10:36 AM, Adrian Prantl via cfe-commits 
>> mailto:cfe-commits@lists.llvm.org>> wrote:
>> Author: adrian
>> Date: Fri Oct  2 12:36:14 2015
>> New Revision: 249157
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=249157&view=rev 
>> 
>> Log:
>> Module debugging: Don't emit forward declarations in module scopes.
>> A forward declaration inside a module header does not belong to the module.
>> 
>> Modified:
>> cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
>> cfe/trunk/test/Modules/Inputs/DebugObjC.h
>> cfe/trunk/test/Modules/ModuleDebugInfo.m
>> 
>> Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=249157&r1=249156&r2=249157&view=diff
>>  
>> 
>> ==
>> --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
>> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Fri Oct  2 12:36:14 2015
>> @@ -2172,6 +2172,9 @@ ObjCInterfaceDecl *CGDebugInfo::getObjCI
>>  }
>> 
>>  llvm::DIModule *CGDebugInfo::getParentModuleOrNull(const Decl *D) {
>> +  // A forward declaration inside a module header does not belong to the 
>> module.
>> +  if (isa(D) && !cast(D)->getDefinition())
>> +return nullptr;
>>if (DebugTypeExtRefs && D->isFromASTFile()) {
>>  // Record a reference to an imported clang module or precompiled header.
>>  auto *Reader = CGM.getContext().getExternalSource();
>> 
>> Modified: cfe/trunk/test/Modules/Inputs/DebugObjC.h
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/DebugObjC.h?rev=249157&r1=249156&r2=249157&view=diff
>>  
>> 
>> ==
>> --- cfe/trunk/test/Modules/Inputs/DebugObjC.h (original)
>> +++ cfe/trunk/test/Modules/Inputs/DebugObjC.h Fri Oct  2 12:36:14 2015
>> @@ -5,6 +5,7 @@
>>  }
>>  + classMethod;
>>  - instanceMethodWithInt:(int)i;
>> +- (struct OpaqueData*) getSomethingOpaque;
>>  @property int property;
>>  @end
>> 
>> 
>> Modified: cfe/trunk/test/Modules/ModuleDebugInfo.m
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/ModuleDebugInfo.m?rev=249157&r1=249156&r2=249157&view=diff
>>  
>> 
>> ==
>> --- cfe/trunk/test/Modules/ModuleDebugInfo.m (original)
>> +++ cfe/trunk/test/Modules/ModuleDebugInfo.m Fri Oct  2 12:36:14 2015
>> @@ -41,3 +41,6 @@
>>  // MODULE-CHECK: !DICompositeType(tag: DW_TAG_structure_type,
>>  // MODULE-CHECK-SAME: name: "ObjCClass",
>>  // MODULE-CHECK-SAME: scope: ![[MODULE]],
>> +
>> +// The forward declaration should not be in the module scope.
>> +// MODULE-CHECK: !DICompositeType(tag: DW_TAG_structure_type, name: 
>> "OpaqueData", file
>> 
>> 
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org 
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits 
>>