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

[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=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=249132=249133=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=249132=249133=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] 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

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=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=249128=249129=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

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

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=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=249136=249137=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> ,
@@ -2217,6 +,9 @@ const ToolChain ::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=249136=249137=diff

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=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 @@
   

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] 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

[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=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=249126=249127=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=249126=249127=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=249126=249127=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] 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 ) {
 // 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  = 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  : Parents) {
+  if (!Parent.get())
+return false;
+}
+  }
 
   const ast_type_traits::DynTypedNode  = 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->getSemanticForm());
+  }
+
 

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] 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

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] 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

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

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] 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] 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=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=249129=249130=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=249129=249130=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=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 ) 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=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
+  clangLex
+  clangTidy
+  )

Added: 

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] 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] 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

[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
===
--- 

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;
+// 

[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),
  

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

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] 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

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=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 *,
@@ -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.FiniteMathOnly)

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 ,
+   FullSourceLoc ,
+   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

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 

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=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=249137=249138=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

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

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=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=249139=249140=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=249139=249140=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 *,
@@ -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=249139=249140=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 
   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=249139=249140=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-prefix=CHECK-FASTMATH %s
 // RUN: %clang -target 

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=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=249140=249141=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> ,
@@ -,9 +2217,6 @@ const ToolChain ::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=249140=249141=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=249140=249141=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("+march=mips32r2");
-
-auto MArchMipselR2 = 

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] 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

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=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=249141=249142=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

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

[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 

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=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=249142=249143=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=249142=249143=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=249142=249143=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(LibLTOPath)) {
+

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 ) {
  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

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

[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] 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"
+

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=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=249140=249141=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> ,
> @@ -,9 +2217,6 @@ const ToolChain ::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=249140=249141=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=249140=249141=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 

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

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

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

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 ,
  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 also 

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=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=249153=249154=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=249153=249154=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=249153=249154=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=249153=249154=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/Sema/SemaOpenMP.cpp
URL: 

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

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=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=249155=249156=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=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=249154=249155=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=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=249156=249157=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=249156=249157=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=249156=249157=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

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(),
-  

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=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=249165=249166=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  = 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=249165=249166=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

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=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=249151=249152=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

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=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=249158=249159=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: 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 
>:
Author: vkalintiris
Date: Fri Oct  2 10:00:55 2015
New Revision: 249141

URL: http://llvm.org/viewvc/llvm-project?rev=249141=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=249140=249141=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> ,
@@ -,9 +2217,6 @@ const ToolChain ::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=249140=249141=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=249140=249141=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", 

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

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=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=249175=249176=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=249175=249176=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=249175=249176=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

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: [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 {
+

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 
> > wrote:
> Author: adrian
> Date: Fri Oct  2 12:36:14 2015
> New Revision: 249157
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=249157=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=249156=249157=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=249156=249157=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=249156=249157=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] D13311: [clang-tidy] Add check cppcoreguidelines-pro-bounds-pointer-arithmetic

[Matthias Gehre via cfe-commits]

mgehre updated this revision to Diff 36403.
mgehre marked 7 inline comments as done.
mgehre added a comment.

Incorporated comments
Simplied matcher: Instead of checking argument types, just check that the 
result of the arithmetic operation is a pointer


http://reviews.llvm.org/D13311

Files:
  clang-tidy/cppcoreguidelines/CMakeLists.txt
  clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
  clang-tidy/cppcoreguidelines/ProBoundsPointerArithmeticCheck.cpp
  clang-tidy/cppcoreguidelines/ProBoundsPointerArithmeticCheck.h
  docs/clang-tidy/checks/cppcoreguidelines-pro-bounds-pointer-arithmetic.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/cppcoreguidelines-pro-bounds-pointer-arithmetic.cpp

Index: test/clang-tidy/cppcoreguidelines-pro-bounds-pointer-arithmetic.cpp
===
--- /dev/null
+++ test/clang-tidy/cppcoreguidelines-pro-bounds-pointer-arithmetic.cpp
@@ -0,0 +1,83 @@
+// RUN: %python %S/check_clang_tidy.py %s cppcoreguidelines-pro-bounds-pointer-arithmetic %t
+
+
+enum E {
+  ENUM_LITERAL = 1
+};
+
+int i = 4;
+int j = 1;
+int* p = 0;
+int* q = 0;
+
+void fail() {
+  q = p + 4;
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: do not use pointer arithmetic [cppcoreguidelines-pro-bounds-pointer-arithmetic]
+  p = q + i;
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: do not use pointer arithmetic
+  p = q + ENUM_LITERAL;
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: do not use pointer arithmetic
+
+  q = p - 1;
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: do not use pointer arithmetic
+  p = q - i;
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: do not use pointer arithmetic
+  p = q - ENUM_LITERAL;
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: do not use pointer arithmetic
+
+  p += 4;
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: do not use pointer arithmetic
+  p += i;
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: do not use pointer arithmetic
+  p += ENUM_LITERAL;
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: do not use pointer arithmetic
+
+  q -= 1;
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: do not use pointer arithmetic
+  q -= i;
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: do not use pointer arithmetic
+  q -= ENUM_LITERAL;
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: do not use pointer arithmetic
+
+  p++;
+  // CHECK-MESSAGES: :[[@LINE-1]]:4: warning: do not use pointer arithmetic
+  ++p;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: do not use pointer arithmetic
+
+  p--;
+  // CHECK-MESSAGES: :[[@LINE-1]]:4: warning: do not use pointer arithmetic
+  --p;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: do not use pointer arithmetic
+
+  i = p[1];
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: do not use pointer arithmetic
+}
+
+struct S {
+  operator int() const;
+};
+
+void f(S ) {
+  int *i;
+  i = i + s;
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: do not use pointer arithmetic
+}
+
+void okay() {
+  int a[3];
+  i = a[2]; //OK, access to array
+
+  p = q;
+  p = 
+
+  i++;
+  ++i;
+  i--;
+  --i;
+  i += 1;
+  i -= 1;
+  i = j + 1;
+  i = j - 1;
+
+  auto diff = p - q; //OK, result is arithmetic
+}
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-bounds-pointer-arithmetic
cppcoreguidelines-pro-type-reinterpret-cast
google-build-explicit-make-pair
google-build-namespaces
Index: docs/clang-tidy/checks/cppcoreguidelines-pro-bounds-pointer-arithmetic.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/cppcoreguidelines-pro-bounds-pointer-arithmetic.rst
@@ -0,0 +1,10 @@
+cppcoreguidelines-pro-bounds-pointer-arithmetic
+===
+
+This check flags all usage of pointer arithmetic, because it could lead to an invalid pointer.
+Subtraction of two pointers is not flagged by this check.
+
+Pointers should only refer to single objects, and pointer arithmetic is fragile and easy to get wrong. array_view is a bounds-checked, safe type for accessing arrays of data.
+
+This rule is part of the "Bounds safety" profile of the C++ Core Guidelines, see
+https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#-bounds1-dont-use-pointer-arithmetic-use-array_view-instead
Index: clang-tidy/cppcoreguidelines/ProBoundsPointerArithmeticCheck.h
===
--- /dev/null
+++ clang-tidy/cppcoreguidelines/ProBoundsPointerArithmeticCheck.h
@@ -0,0 +1,35 @@
+//===--- ProBoundsPointerArithmeticCheck.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.
+//

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

[Matthias Gehre via cfe-commits]

mgehre added a comment.

Thank you for the review comments!



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

sbenza wrote:
> What is that implicitCastExpr() matching?
> Did you mean to use ignoringImpCasts() instead?
The AST for

```
int* p = 0;
int i;
i = p[1];

```
is

```
-BinaryOperator 0x22dd770  'int' lvalue '='
   |-DeclRefExpr 0x22dd6a8  'int' lvalue Var 0x227fca0 'i' 'int'
   `-ImplicitCastExpr 0x22dd758  'int' 
 `-ArraySubscriptExpr 0x22dd730  'int' lvalue
   |-ImplicitCastExpr 0x22dd718  'int *' 
   | `-DeclRefExpr 0x22dd6d0  'int *' lvalue Var 0x227fdf0 'p' 'int 
*'
   `-IntegerLiteral 0x22dd6f8  'int' 1

```
I guess you are right about ignoringImpCasts(), though.


http://reviews.llvm.org/D13311



___
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=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=249191=249192=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_exit(__p);
 }
 

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

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 
>> > wrote:
>> Author: adrian
>> Date: Fri Oct  2 12:36:14 2015
>> New Revision: 249157
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=249157=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=249156=249157=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=249156=249157=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=249156=249157=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 
>> 

Re: [PATCH] D13331: [libcxx] Use newest supported language dialect when running the test suite.

[Dan Albert via cfe-commits]

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

LGTM.


http://reviews.llvm.org/D13331



___
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: 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=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=249156=249157=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=249156=249157=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=249156=249157=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: r249157 - Module debugging: Don't emit forward declarations in module scopes.

[David Blaikie via cfe-commits]

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

>
> 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.
>

perhaps the module shouldn't be either, then?


>
> -- adrian
>
>
>
>>
>> -- 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=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=249156=249157=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=249156=249157=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=249156=249157=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 3:01 PM, David Blaikie  wrote:
> 
> 
> 
> On Fri, Oct 2, 2015 at 3:00 PM, Adrian Prantl  > wrote:
> 
>> 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.
> 
> perhaps the module shouldn't be either, then?

The module has to be, for correctness. (None of this applies to C++. 
Oversimplified: because of the ODR we can omit the parent DW_TAG_module from 
all CXXRecordDecls).
For C and ObjC it is perfectly legal to have two modules with conflicting 
definitions for a type, so we need the DW_TAG_module as part of the DeclContext 
to differentiate them if we want to be able to resolve forward declarations to 
the correct definition.

-- adrian
>  
> 
> -- adrian
> 
>>  
>> 
>> -- adrian
>> 
>>> On Fri, Oct 2, 2015 at 10:36 AM, Adrian Prantl via cfe-commits 
>>> > wrote:
>>> Author: adrian
>>> Date: Fri Oct  2 12:36:14 2015
>>> New Revision: 249157
>>> 
>>> URL: http://llvm.org/viewvc/llvm-project?rev=249157=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=249156=249157=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=249156=249157=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=249156=249157=diff
>>>  
>>> 
>>> 

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

[David Blaikie via cfe-commits]

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

>
> On Oct 2, 2015, at 3:01 PM, David Blaikie  wrote:
>
>
>
> On Fri, Oct 2, 2015 at 3:00 PM, Adrian Prantl  wrote:
>
>>
>> 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.
>>
>
> perhaps the module shouldn't be either, then?
>
>
> The module has to be, for correctness. (None of this applies to C++.
> Oversimplified: because of the ODR we can omit the parent DW_TAG_module
> from all CXXRecordDecls).
> For C and ObjC it is perfectly legal to have two modules with conflicting
> definitions for a type, so we need the DW_TAG_module as part of the
> DeclContext to differentiate them if we want to be able to resolve forward
> declarations to the correct definition.
>

But you have to do the same thing for the things in the CU as well, right?
So you can't ignore the CU in the same way you can't ignore the module, yes?


>
> -- adrian
>
>
>
>>
>> -- adrian
>>
>>
>>
>>>
>>> -- 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=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=249156=249157=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=249156=249157=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=249156=249157=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 @@
  // 

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 

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

[PATCH] D13398: [clang-tidy] add check cppcoreguidelines-pro-type-const-cast

[Matthias Gehre via cfe-commits]

mgehre created this revision.
mgehre added reviewers: alexfh, sbenza, bkramer, aaron.ballman.
mgehre added a subscriber: cfe-commits.
mgehre added a dependency: D13313: [clang-tidy] new check 
cppcoreguidelines-pro-type-reinterpret-cast.

This check flags all uses of const_cast in C++ code.

Modifying a variable that was declared const is undefined behavior, even
with const_cast.

This rule is part of the "Type safety" profile of the C++ Core
Guidelines, see
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#-type3-dont-use-const_cast-to-cast-away-const-ie-at-all.

Depends on D13313

http://reviews.llvm.org/D13398

Files:
  clang-tidy/cppcoreguidelines/CMakeLists.txt
  clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
  clang-tidy/cppcoreguidelines/ProTypeConstCastCheck.cpp
  clang-tidy/cppcoreguidelines/ProTypeConstCastCheck.h
  docs/clang-tidy/checks/cppcoreguidelines-pro-type-const-cast.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/cppcoreguidelines-pro-type-const-cast.cpp

Index: test/clang-tidy/cppcoreguidelines-pro-type-const-cast.cpp
===
--- /dev/null
+++ test/clang-tidy/cppcoreguidelines-pro-type-const-cast.cpp
@@ -0,0 +1,6 @@
+// RUN: %python %S/check_clang_tidy.py %s cppcoreguidelines-pro-type-const-cast %t
+
+const int* i;
+int* j;
+void f() { j = const_cast(i); }
+// CHECK-MESSAGES: :[[@LINE-1]]:16: warning: do not use const_cast [cppcoreguidelines-pro-type-const-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-const-cast
cppcoreguidelines-pro-type-reinterpret-cast
google-build-explicit-make-pair
google-build-namespaces
Index: docs/clang-tidy/checks/cppcoreguidelines-pro-type-const-cast.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/cppcoreguidelines-pro-type-const-cast.rst
@@ -0,0 +1,9 @@
+cppcoreguidelines-pro-type-const-cast
+=
+
+This check flags all uses of const_cast in C++ code.
+
+Modifying a variable that was declared const is undefined behavior, even with const_cast.
+
+This rule is part of the "Type safety" profile of the C++ Core Guidelines, see
+https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#-type3-dont-use-const_cast-to-cast-away-const-ie-at-all.
Index: clang-tidy/cppcoreguidelines/ProTypeConstCastCheck.h
===
--- /dev/null
+++ clang-tidy/cppcoreguidelines/ProTypeConstCastCheck.h
@@ -0,0 +1,34 @@
+//===--- ProTypeConstCastCheck.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_CONST_CAST_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_CPPCOREGUIDELINES_PRO_TYPE_CONST_CAST_H
+
+#include "../ClangTidy.h"
+
+namespace clang {
+namespace tidy {
+
+/// This check flags all instances of const_cast
+///
+/// For the user-facing documentation see:
+/// http://clang.llvm.org/extra/clang-tidy/checks/cppcoreguidelines-pro-type-const-cast.html
+class ProTypeConstCastCheck : public ClangTidyCheck {
+public:
+  ProTypeConstCastCheck(StringRef Name, ClangTidyContext *Context)
+  : ClangTidyCheck(Name, Context) {}
+  void registerMatchers(ast_matchers::MatchFinder *Finder) override;
+  void check(const ast_matchers::MatchFinder::MatchResult ) override;
+};
+
+} // namespace tidy
+} // namespace clang
+
+#endif // LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_CPPCOREGUIDELINES_PRO_TYPE_CONST_CAST_H
+
Index: clang-tidy/cppcoreguidelines/ProTypeConstCastCheck.cpp
===
--- /dev/null
+++ clang-tidy/cppcoreguidelines/ProTypeConstCastCheck.cpp
@@ -0,0 +1,33 @@
+//===--- ProTypeConstCastCheck.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 "ProTypeConstCastCheck.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang {
+namespace tidy {
+
+void ProTypeConstCastCheck::registerMatchers(MatchFinder *Finder) {
+  if(!getLangOpts().CPlusPlus)
+return;
+
+  Finder->addMatcher(cxxConstCastExpr().bind("cast"), this);
+}
+

r249213 - [Headers][X86] Fix stream_load (movntdqa) to accept const*.

[Ahmed Bougacha via cfe-commits]

Author: ab
Date: Fri Oct  2 18:29:26 2015
New Revision: 249213

URL: http://llvm.org/viewvc/llvm-project?rev=249213=rev
Log:
[Headers][X86] Fix stream_load (movntdqa) to accept const*.

Per Intel intrinsics guide:
- _mm256_stream_load_si256 takes `__m256i const *'
- _mm_stream_load_si128 takes `__m128i *', for no good reason.

Let's accept const* for both.

Modified:
cfe/trunk/include/clang/Basic/BuiltinsX86.def
cfe/trunk/lib/Headers/avx2intrin.h
cfe/trunk/lib/Headers/smmintrin.h
cfe/trunk/test/CodeGen/avx2-builtins.c
cfe/trunk/test/CodeGen/sse41-builtins.c

Modified: cfe/trunk/include/clang/Basic/BuiltinsX86.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsX86.def?rev=249213=249212=249213=diff
==
--- cfe/trunk/include/clang/Basic/BuiltinsX86.def (original)
+++ cfe/trunk/include/clang/Basic/BuiltinsX86.def Fri Oct  2 18:29:26 2015
@@ -390,7 +390,7 @@ TARGET_BUILTIN(__builtin_ia32_roundsd, "
 TARGET_BUILTIN(__builtin_ia32_roundpd, "V2dV2di", "", "sse4.1")
 TARGET_BUILTIN(__builtin_ia32_dpps, "V4fV4fV4fIc", "", "sse4.1")
 TARGET_BUILTIN(__builtin_ia32_dppd, "V2dV2dV2dIc", "", "sse4.1")
-TARGET_BUILTIN(__builtin_ia32_movntdqa, "V2LLiV2LLi*", "", "sse4.1")
+TARGET_BUILTIN(__builtin_ia32_movntdqa, "V2LLiV2LLiC*", "", "sse4.1")
 TARGET_BUILTIN(__builtin_ia32_ptestz128, "iV2LLiV2LLi", "", "sse4.1")
 TARGET_BUILTIN(__builtin_ia32_ptestc128, "iV2LLiV2LLi", "", "sse4.1")
 TARGET_BUILTIN(__builtin_ia32_ptestnzc128, "iV2LLiV2LLi", "", "sse4.1")
@@ -594,7 +594,7 @@ TARGET_BUILTIN(__builtin_ia32_psrldi256,
 TARGET_BUILTIN(__builtin_ia32_psrld256, "V8iV8iV4i", "", "avx2")
 TARGET_BUILTIN(__builtin_ia32_psrlqi256, "V4LLiV4LLii", "", "avx2")
 TARGET_BUILTIN(__builtin_ia32_psrlq256, "V4LLiV4LLiV2LLi", "", "avx2")
-TARGET_BUILTIN(__builtin_ia32_movntdqa256, "V4LLiV4LLi*", "", "avx2")
+TARGET_BUILTIN(__builtin_ia32_movntdqa256, "V4LLiV4LLiC*", "", "avx2")
 TARGET_BUILTIN(__builtin_ia32_permvarsi256, "V8iV8iV8i", "", "avx2")
 TARGET_BUILTIN(__builtin_ia32_permvarsf256, "V8fV8fV8f", "", "avx2")
 TARGET_BUILTIN(__builtin_ia32_permti256, "V4LLiV4LLiV4LLiIc", "", "avx2")

Modified: cfe/trunk/lib/Headers/avx2intrin.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/avx2intrin.h?rev=249213=249212=249213=diff
==
--- cfe/trunk/lib/Headers/avx2intrin.h (original)
+++ cfe/trunk/lib/Headers/avx2intrin.h Fri Oct  2 18:29:26 2015
@@ -754,9 +754,9 @@ _mm256_xor_si256(__m256i __a, __m256i __
 }
 
 static __inline__ __m256i __DEFAULT_FN_ATTRS
-_mm256_stream_load_si256(__m256i *__V)
+_mm256_stream_load_si256(__m256i const *__V)
 {
-  return (__m256i)__builtin_ia32_movntdqa256((__v4di *)__V);
+  return (__m256i)__builtin_ia32_movntdqa256((const __v4di *)__V);
 }
 
 static __inline__ __m128 __DEFAULT_FN_ATTRS

Modified: cfe/trunk/lib/Headers/smmintrin.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/smmintrin.h?rev=249213=249212=249213=diff
==
--- cfe/trunk/lib/Headers/smmintrin.h (original)
+++ cfe/trunk/lib/Headers/smmintrin.h Fri Oct  2 18:29:26 2015
@@ -151,9 +151,9 @@ _mm_mul_epi32 (__m128i __V1, __m128i __V
 
 /* SSE4 Streaming Load Hint Instruction.  */
 static __inline__  __m128i __DEFAULT_FN_ATTRS
-_mm_stream_load_si128 (__m128i *__V)
+_mm_stream_load_si128 (__m128i const *__V)
 {
-  return (__m128i) __builtin_ia32_movntdqa ((__v2di *) __V);
+  return (__m128i) __builtin_ia32_movntdqa ((const __v2di *) __V);
 }
 
 /* SSE4 Packed Integer Min/Max Instructions.  */

Modified: cfe/trunk/test/CodeGen/avx2-builtins.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/avx2-builtins.c?rev=249213=249212=249213=diff
==
--- cfe/trunk/test/CodeGen/avx2-builtins.c (original)
+++ cfe/trunk/test/CodeGen/avx2-builtins.c Fri Oct  2 18:29:26 2015
@@ -728,7 +728,7 @@ __m256i test_mm256_unpacklo_epi64(__m256
   return _mm256_unpacklo_epi64(a, b);
 }
 
-__m256i test_mm256_stream_load_si256(__m256i *a) {
+__m256i test_mm256_stream_load_si256(__m256i const *a) {
   // CHECK: @llvm.x86.avx2.movntdqa
   // CHECK-ASM: vmovntdqa (%rdi), %ymm{{.*}}
   return _mm256_stream_load_si256(a);

Modified: cfe/trunk/test/CodeGen/sse41-builtins.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/sse41-builtins.c?rev=249213=249212=249213=diff
==
--- cfe/trunk/test/CodeGen/sse41-builtins.c (original)
+++ cfe/trunk/test/CodeGen/sse41-builtins.c Fri Oct  2 18:29:26 2015
@@ -385,7 +385,7 @@ __m128 test_mm_round_ss(__m128 x, __m128
   return _mm_round_ss(x, y, 2);
 }
 
-__m128i test_mm_stream_load_si128(__m128i *a) {
+__m128i test_mm_stream_load_si128(__m128i const *a) {
   // CHECK-LABEL: 

Re: [PATCH] D13221: Make CompilerInvocation's use of the debug options more understandable.

[Douglas Katzman via cfe-commits]

dougk added a comment.

A few more remarks:

- The code which emits line-tables-only seems to understand dwarf2 versus 
dwarf4, but due solely to the way that arguments were parsed, the dwarf version 
did not propagate through to the compiler invocation if you also specified 
line-tables-only.  The new pair of arguments does not have that issue.

So as mentioned on cfe-dev, this is another case of "yeah, I fixed that but 
wasn't really the intent".  [All I want is MyriadToolchain to default to dwarf 
2. That's it!]

- It was suggested to me that it ought to have been possible to pull out all of 
the g group argument processing so that ClangAs::ConstructJob can share a 
little bit more code with Clang::ConstructJob but I'd really prefer not to do 
that in this change. It's possible that another small cleanup can be done, but 
the governing factor is that somehow or another you also have to deal with the 
case where the integrated-as tool has to parse '-gdwarf-N' flags (because 
people can pass those with -Xassembler,-gdwarf-). So you've got to be able to 
parse plain old StringRefs, as opposed to "Arg", which, absent that 
requirement, you'd just do with getOption().matches(). As it is, I think the 
code is well factored for this purpose.


http://reviews.llvm.org/D13221



___
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

[Matthias Gehre via cfe-commits]

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

Fix typo


http://reviews.llvm.org/D13311

Files:
  clang-tidy/cppcoreguidelines/CMakeLists.txt
  clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
  clang-tidy/cppcoreguidelines/ProBoundsPointerArithmeticCheck.cpp
  clang-tidy/cppcoreguidelines/ProBoundsPointerArithmeticCheck.h
  docs/clang-tidy/checks/cppcoreguidelines-pro-bounds-pointer-arithmetic.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/cppcoreguidelines-pro-bounds-pointer-arithmetic.cpp

Index: test/clang-tidy/cppcoreguidelines-pro-bounds-pointer-arithmetic.cpp
===
--- /dev/null
+++ test/clang-tidy/cppcoreguidelines-pro-bounds-pointer-arithmetic.cpp
@@ -0,0 +1,83 @@
+// RUN: %python %S/check_clang_tidy.py %s cppcoreguidelines-pro-bounds-pointer-arithmetic %t
+
+
+enum E {
+  ENUM_LITERAL = 1
+};
+
+int i = 4;
+int j = 1;
+int* p = 0;
+int* q = 0;
+
+void fail() {
+  q = p + 4;
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: do not use pointer arithmetic [cppcoreguidelines-pro-bounds-pointer-arithmetic]
+  p = q + i;
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: do not use pointer arithmetic
+  p = q + ENUM_LITERAL;
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: do not use pointer arithmetic
+
+  q = p - 1;
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: do not use pointer arithmetic
+  p = q - i;
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: do not use pointer arithmetic
+  p = q - ENUM_LITERAL;
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: do not use pointer arithmetic
+
+  p += 4;
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: do not use pointer arithmetic
+  p += i;
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: do not use pointer arithmetic
+  p += ENUM_LITERAL;
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: do not use pointer arithmetic
+
+  q -= 1;
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: do not use pointer arithmetic
+  q -= i;
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: do not use pointer arithmetic
+  q -= ENUM_LITERAL;
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: do not use pointer arithmetic
+
+  p++;
+  // CHECK-MESSAGES: :[[@LINE-1]]:4: warning: do not use pointer arithmetic
+  ++p;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: do not use pointer arithmetic
+
+  p--;
+  // CHECK-MESSAGES: :[[@LINE-1]]:4: warning: do not use pointer arithmetic
+  --p;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: do not use pointer arithmetic
+
+  i = p[1];
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: do not use pointer arithmetic
+}
+
+struct S {
+  operator int() const;
+};
+
+void f(S ) {
+  int *i;
+  i = i + s;
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: do not use pointer arithmetic
+}
+
+void okay() {
+  int a[3];
+  i = a[2]; //OK, access to array
+
+  p = q;
+  p = 
+
+  i++;
+  ++i;
+  i--;
+  --i;
+  i += 1;
+  i -= 1;
+  i = j + 1;
+  i = j - 1;
+
+  auto diff = p - q; //OK, result is arithmetic
+}
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-bounds-pointer-arithmetic
cppcoreguidelines-pro-type-reinterpret-cast
google-build-explicit-make-pair
google-build-namespaces
Index: docs/clang-tidy/checks/cppcoreguidelines-pro-bounds-pointer-arithmetic.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/cppcoreguidelines-pro-bounds-pointer-arithmetic.rst
@@ -0,0 +1,10 @@
+cppcoreguidelines-pro-bounds-pointer-arithmetic
+===
+
+This check flags all usage of pointer arithmetic, because it could lead to an invalid pointer.
+Subtraction of two pointers is not flagged by this check.
+
+Pointers should only refer to single objects, and pointer arithmetic is fragile and easy to get wrong. array_view is a bounds-checked, safe type for accessing arrays of data.
+
+This rule is part of the "Bounds safety" profile of the C++ Core Guidelines, see
+https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#-bounds1-dont-use-pointer-arithmetic-use-array_view-instead
Index: clang-tidy/cppcoreguidelines/ProBoundsPointerArithmeticCheck.h
===
--- /dev/null
+++ clang-tidy/cppcoreguidelines/ProBoundsPointerArithmeticCheck.h
@@ -0,0 +1,35 @@
+//===--- ProBoundsPointerArithmeticCheck.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_BOUNDS_POINTER_ARITHMETIC_H
+#define 

r249223 - Fix clang/test/CodeGenCXX/strict-vtable-pointers.cpp for -Asserts. It missed something. :)

[NAKAMURA Takumi via cfe-commits]

Author: chapuni
Date: Fri Oct  2 19:50:12 2015
New Revision: 249223

URL: http://llvm.org/viewvc/llvm-project?rev=249223=rev
Log:
Fix clang/test/CodeGenCXX/strict-vtable-pointers.cpp for -Asserts. It missed 
something. :)

Modified:
cfe/trunk/test/CodeGenCXX/strict-vtable-pointers.cpp

Modified: cfe/trunk/test/CodeGenCXX/strict-vtable-pointers.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/strict-vtable-pointers.cpp?rev=249223=249222=249223=diff
==
--- cfe/trunk/test/CodeGenCXX/strict-vtable-pointers.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/strict-vtable-pointers.cpp Fri Oct  2 19:50:12 
2015
@@ -142,7 +142,7 @@ struct 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 %[[DynamicDerived]]* %2 to 
%[[DynamicBase:.*]]*
+// CHECK-CTORS: %[[THIS4:.*]] = bitcast %[[DynamicDerived]]* %[[THIS3]] to 
%[[DynamicBase:.*]]*
 // CHECK-CTORS: call void @_ZN12DynamicBase1C2Ev(%[[DynamicBase]]* %[[THIS4]])
 
 // CHECK-CTORS: %[[THIS5:.*]] = bitcast %struct.DynamicDerived* %[[THIS0]] to 
i32 (...)***


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

r249205 - Don't nil check non-nil class receiver of AArch64 stret calls.

[Ahmed Bougacha via cfe-commits]

Author: ab
Date: Fri Oct  2 17:41:59 2015
New Revision: 249205

URL: http://llvm.org/viewvc/llvm-project?rev=249205=rev
Log:
Don't nil check non-nil class receiver of AArch64 stret calls.

I randomly came across this difference between AArch64 and other targets:
on the latter, we don't emit nil checks for known non-nil class method
calls thanks to r247350, but we still do for AArch64 stret calls.

They use different code paths, because those are special, as they go
through the regular msgSend, not the msgSend*_stret variants.

Modified:
cfe/trunk/lib/CodeGen/CGObjCMac.cpp
cfe/trunk/test/CodeGenObjC/stret-1.m

Modified: cfe/trunk/lib/CodeGen/CGObjCMac.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGObjCMac.cpp?rev=249205=249204=249205=diff
==
--- cfe/trunk/lib/CodeGen/CGObjCMac.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGObjCMac.cpp Fri Oct  2 17:41:59 2015
@@ -1931,7 +1931,7 @@ CGObjCCommonMac::EmitMessageSend(CodeGen
   } else {
 // arm64 uses objc_msgSend for stret methods and yet null receiver check
 // must be made for it.
-if (!IsSuper && CGM.ReturnTypeUsesSRet(MSI.CallInfo))
+if (ReceiverCanBeNull && CGM.ReturnTypeUsesSRet(MSI.CallInfo))
   nullReturn.init(CGF, Arg0);
 Fn = (ObjCABI == 2) ? ObjCTypes.getSendFn2(IsSuper)
   : ObjCTypes.getSendFn(IsSuper);

Modified: cfe/trunk/test/CodeGenObjC/stret-1.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenObjC/stret-1.m?rev=249205=249204=249205=diff
==
--- cfe/trunk/test/CodeGenObjC/stret-1.m (original)
+++ cfe/trunk/test/CodeGenObjC/stret-1.m Fri Oct  2 17:41:59 2015
@@ -1,8 +1,7 @@
-// RUN: %clang_cc1 -fblocks -triple arm64-apple-darwin %s -emit-llvm -o - | 
FileCheck %s -check-prefix=CHECK-ARM64
+// RUN: %clang_cc1 -fblocks -triple arm64-apple-darwin %s -emit-llvm -o - | 
FileCheck %s
 // rdar://12416433
 
 struct stret { int x[100]; };
-struct stret zero;
 struct stret one = {{1}};
 
 @interface Test  @end
@@ -13,8 +12,12 @@ struct stret one = {{1}};
 
 int main(int argc, const char **argv)
 {
-struct stret st2 = one;
-if (argc) st2 = [(id)(argc&~255) method];
-}
+[(id)(argc&~255) method];
+// CHECK: call void bitcast (i8* (i8*, i8*, ...)* @objc_msgSend to void 
(%struct.stret*, i8*, i8*)*)(%struct.stret* sret [[T0:%[^,]+]]
+// CHECK: [[T0P:%.*]] = bitcast %struct.stret* [[T0]] to i8*
+// CHECK: call void @llvm.memset.p0i8.i64(i8* [[T0P]], i8 0, i64 400, i32 
4, i1 false)
 
-// CHECK-ARM64: call void @llvm.memset.p0i8.i64(i8* [[T0:%.*]], i8 0, i64 400, 
i32 4, i1 false)
+[Test method];
+// CHECK: call void bitcast (i8* (i8*, i8*, ...)* @objc_msgSend to void 
(%struct.stret*, i8*, i8*)*)(%struct.stret* sret [[T1:%[^,]+]]
+// CHECK-NOT: call void @llvm.memset.p0i8.i64(
+}


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

Re: [PATCH] D7297: [clang][Headers] _mm_stream_load_si128 should accept const arguments.

[Ahmed Bougacha via cfe-commits]

ab closed this revision.
ab added a comment.

Stumbled upon this while looking for the intel guide! Fixed in r249213.


http://reviews.llvm.org/D7297



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

Re: [PATCH] D12614: [OpenMP] Offloading descriptor registration and device codegen.

[Samuel Antao via cfe-commits]

sfantao updated this revision to Diff 36410.
sfantao added a comment.

Fix bug for when no offloading triples are specified.


http://reviews.llvm.org/D12614

Files:
  include/clang/Basic/DiagnosticDriverKinds.td
  include/clang/Basic/LangOptions.def
  include/clang/Basic/LangOptions.h
  include/clang/Driver/CC1Options.td
  include/clang/Driver/Options.td
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntime.h
  lib/CodeGen/CGStmtOpenMP.cpp
  lib/CodeGen/CodeGenModule.cpp
  lib/Frontend/CompilerInvocation.cpp
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTWriter.cpp
  test/OpenMP/target_codegen.cpp
  test/OpenMP/target_codegen_global_capture.cpp
  test/OpenMP/target_codegen_registration.cpp
  test/OpenMP/target_messages.cpp

Index: test/OpenMP/target_messages.cpp
===
--- test/OpenMP/target_messages.cpp
+++ test/OpenMP/target_messages.cpp
@@ -1,4 +1,6 @@
 // RUN: %clang_cc1 -verify -fopenmp -std=c++11 -o - %s
+// RUN: not %clang_cc1 -fopenmp -std=c++11 -omptargets=aaa-bbb-ccc-ddd -o - %s 2>&1 | FileCheck %s
+// CHECK: error: OpenMP target is invalid: 'aaa-bbb-ccc-ddd'
 
 void foo() {
 }
Index: test/OpenMP/target_codegen_registration.cpp
===
--- /dev/null
+++ test/OpenMP/target_codegen_registration.cpp
@@ -0,0 +1,437 @@
+// Test host codegen.
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown -omptargets=powerpc64le-ibm-linux-gnu -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -fopenmp -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -omptargets=powerpc64le-ibm-linux-gnu -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -x c++ -triple powerpc64le-unknown-unknown -omptargets=powerpc64le-ibm-linux-gnu -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple i386-unknown-unknown -omptargets=i386-pc-linux-gnu -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -fopenmp -x c++ -std=c++11 -triple i386-unknown-unknown -omptargets=i386-pc-linux-gnu -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -x c++ -triple i386-unknown-unknown -omptargets=i386-pc-linux-gnu -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s
+
+// Test target codegen - host bc file has to be created first.
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown -omptargets=powerpc64le-ibm-linux-gnu -emit-llvm-bc %s -o %t-ppc-host.bc
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown -omptargets=powerpc64le-ibm-linux-gnu -emit-llvm %s -fopenmp-is-device -omp-host-ir-file-path %t-ppc-host.bc -o - | FileCheck %s -check-prefix=TCHECK
+// RUN: %clang_cc1 -fopenmp -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -omptargets=powerpc64le-ibm-linux-gnu -emit-pch -fopenmp-is-device -omp-host-ir-file-path %t-ppc-host.bc -o %t %s
+// RUN: %clang_cc1 -fopenmp -x c++ -triple powerpc64le-unknown-unknown -omptargets=powerpc64le-ibm-linux-gnu -std=c++11 -fopenmp-is-device -omp-host-ir-file-path %t-ppc-host.bc -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s -check-prefix=TCHECK
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple i386-unknown-unknown -omptargets=i386-pc-linux-gnu -emit-llvm-bc %s -o %t-x86-host.bc
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple i386-unknown-unknown -omptargets=i386-pc-linux-gnu -emit-llvm %s -fopenmp-is-device -omp-host-ir-file-path %t-x86-host.bc -o - | FileCheck %s -check-prefix=TCHECK
+// RUN: %clang_cc1 -fopenmp -x c++ -std=c++11 -triple i386-unknown-unknown -omptargets=i386-pc-linux-gnu -emit-pch -fopenmp-is-device -omp-host-ir-file-path %t-x86-host.bc -o %t %s
+// RUN: %clang_cc1 -fopenmp -x c++ -triple i386-unknown-unknown -omptargets=i386-pc-linux-gnu -std=c++11 -fopenmp-is-device -omp-host-ir-file-path %t-x86-host.bc -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s -check-prefix=TCHECK
+
+// Check that no target code is emmitted if no omptests flag was provided.
+// RxUN: %clang_cc1 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK-NTARGET
+
+// expected-no-diagnostics
+#ifndef HEADER
+#define HEADER
+
+// CHECK-DAG: [[SA:%.+]] = type { [4 x i32] }
+// CHECK-DAG: [[SB:%.+]] = type { [8 x i32] }
+// CHECK-DAG: [[SC:%.+]] = type { [16 x i32] }
+// CHECK-DAG: [[SD:%.+]] = type { [32 x i32] }
+// CHECK-DAG: [[SE:%.+]] = type { [64 x i32] }
+// CHECK-DAG: [[ST1:%.+]] = type { [228 x i32] }
+// CHECK-DAG: [[ST2:%.+]] = type { [1128 x i32] }
+// CHECK-DAG: [[ENTTY:%.+]] = type { i8*, i8*, i[[SZ:32|64]] }
+// CHECK-DAG: [[DEVTY:%.+]] = type { i8*, i8*, [[ENTTY]]*, [[ENTTY]]* }
+// CHECK-DAG: [[DSCTY:%.+]] = type { i32, [[DEVTY]]*, [[ENTTY]]*, [[ENTTY]]* }
+
+// TCHECK:[[ENTTY:%.+]] = type { i8*, i8*, i[[SZ:32|64]] }
+
+// CHECK-DAG: [[A1:@.+]] = internal global [[SA]]
+// CHECK-DAG: [[A2:@.+]] = global [[SA]]
+// 

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

[NAKAMURA Takumi via cfe-commits]

chapuni added a subscriber: chapuni.


Comment at: test/CodeGenCXX/strict-vtable-pointers.cpp:145
@@ +144,3 @@
+// CHECK-CTORS: %[[THIS3:.*]] = bitcast i8* %[[THIS2]] to %[[DynamicDerived]]*
+// CHECK-CTORS: %[[THIS4:.*]] = bitcast %[[DynamicDerived]]* %2 to 
%[[DynamicBase:.*]]*
+// CHECK-CTORS: call void @_ZN12DynamicBase1C2Ev(%[[DynamicBase]]* %[[THIS4]])

You missed "%2" (should be THIS3). Fixed in r249223.


http://reviews.llvm.org/D13373



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

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

[Keno Fischer via cfe-commits]

loladiro 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 , Decl *D,
+  const AttributeList ) {
+  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 

r249228 - Replace double-negated !SourceLocation.isInvalid() with SourceLocation.isValid().

[Yaron Keren via cfe-commits]

Author: yrnkrn
Date: Sat Oct  3 00:15:57 2015
New Revision: 249228

URL: http://llvm.org/viewvc/llvm-project?rev=249228=rev
Log:
Replace double-negated !SourceLocation.isInvalid() with 
SourceLocation.isValid().


Modified:
cfe/trunk/lib/ARCMigrate/ObjCMT.cpp
cfe/trunk/lib/AST/TypeLoc.cpp
cfe/trunk/lib/Analysis/ThreadSafety.cpp
cfe/trunk/lib/Basic/SanitizerBlacklist.cpp
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/lib/CodeGen/CoverageMappingGen.cpp
cfe/trunk/lib/Frontend/DiagnosticRenderer.cpp
cfe/trunk/lib/Frontend/Rewrite/InclusionRewriter.cpp
cfe/trunk/lib/Frontend/TextDiagnostic.cpp
cfe/trunk/lib/Sema/DeclSpec.cpp

Modified: cfe/trunk/lib/ARCMigrate/ObjCMT.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/ARCMigrate/ObjCMT.cpp?rev=249228=249227=249228=diff
==
--- cfe/trunk/lib/ARCMigrate/ObjCMT.cpp (original)
+++ cfe/trunk/lib/ARCMigrate/ObjCMT.cpp Sat Oct  3 00:15:57 2015
@@ -736,7 +736,7 @@ static bool rewriteToNSEnumDecl(const En
   SourceLocation EndOfEnumDclLoc = EnumDcl->getLocEnd();
   EndOfEnumDclLoc = trans::findSemiAfterLocation(EndOfEnumDclLoc,
  NS.getASTContext(), 
/*IsDecl*/true);
-  if (!EndOfEnumDclLoc.isInvalid()) {
+  if (EndOfEnumDclLoc.isValid()) {
 SourceRange EnumDclRange(EnumDcl->getLocStart(), EndOfEnumDclLoc);
 commit.insertFromRange(TypedefDcl->getLocStart(), EnumDclRange);
   }
@@ -746,7 +746,7 @@ static bool rewriteToNSEnumDecl(const En
   SourceLocation EndTypedefDclLoc = TypedefDcl->getLocEnd();
   EndTypedefDclLoc = trans::findSemiAfterLocation(EndTypedefDclLoc,
  NS.getASTContext(), 
/*IsDecl*/true);
-  if (!EndTypedefDclLoc.isInvalid()) {
+  if (EndTypedefDclLoc.isValid()) {
 SourceRange TDRange(TypedefDcl->getLocStart(), EndTypedefDclLoc);
 commit.remove(TDRange);
   }
@@ -755,7 +755,7 @@ static bool rewriteToNSEnumDecl(const En
 
   EndOfEnumDclLoc = trans::findLocationAfterSemi(EnumDcl->getLocEnd(), 
NS.getASTContext(),
  /*IsDecl*/true);
-  if (!EndOfEnumDclLoc.isInvalid()) {
+  if (EndOfEnumDclLoc.isValid()) {
 SourceLocation BeginOfEnumDclLoc = EnumDcl->getLocStart();
 // FIXME. This assumes that enum decl; is immediately preceded by eoln.
 // It is trying to remove the enum decl. lines entirely.

Modified: cfe/trunk/lib/AST/TypeLoc.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/TypeLoc.cpp?rev=249228=249227=249228=diff
==
--- cfe/trunk/lib/AST/TypeLoc.cpp (original)
+++ cfe/trunk/lib/AST/TypeLoc.cpp Sat Oct  3 00:15:57 2015
@@ -192,7 +192,7 @@ SourceLocation TypeLoc::getBeginLoc() co
   Cur = Cur.getNextTypeLoc();
   continue;
 default:
-  if (!Cur.getLocalSourceRange().getBegin().isInvalid())
+  if (Cur.getLocalSourceRange().getBegin().isValid())
 LeftMost = Cur;
   Cur = Cur.getNextTypeLoc();
   if (Cur.isNull())

Modified: cfe/trunk/lib/Analysis/ThreadSafety.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Analysis/ThreadSafety.cpp?rev=249228=249227=249228=diff
==
--- cfe/trunk/lib/Analysis/ThreadSafety.cpp (original)
+++ cfe/trunk/lib/Analysis/ThreadSafety.cpp Sat Oct  3 00:15:57 2015
@@ -787,7 +787,7 @@ static void findBlockLocations(CFG *CFGr
   }
 }
 
-if (!CurrBlockInfo->ExitLoc.isInvalid()) {
+if (CurrBlockInfo->ExitLoc.isValid()) {
   // This block contains at least one statement. Find the source location
   // of the first statement in the block.
   for (CFGBlock::const_iterator BI = CurrBlock->begin(),

Modified: cfe/trunk/lib/Basic/SanitizerBlacklist.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/SanitizerBlacklist.cpp?rev=249228=249227=249228=diff
==
--- cfe/trunk/lib/Basic/SanitizerBlacklist.cpp (original)
+++ cfe/trunk/lib/Basic/SanitizerBlacklist.cpp Sat Oct  3 00:15:57 2015
@@ -40,7 +40,7 @@ bool SanitizerBlacklist::isBlacklistedFi
 
 bool SanitizerBlacklist::isBlacklistedLocation(SourceLocation Loc,
StringRef Category) const {
-  return !Loc.isInvalid() &&
+  return Loc.isValid() &&
  isBlacklistedFile(SM.getFilename(SM.getFileLoc(Loc)), Category);
 }
 

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=249228=249227=249228=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Sat Oct  3 00:15:57 2015
@@ -1281,7 +1281,7 @@ bool 

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

[Keno Fischer via cfe-commits]

loladiro added a comment.

Hmm, you're right. And I am actually constructing it in such a way that it's 
supposed to have it, so I wonder why it ran off the rails here. Will take 
another look.


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

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

[Keno Fischer via cfe-commits]

loladiro abandoned this revision.
loladiro added a comment.

Oh, I see it checks for the null terminator past the end of the given memory 
block on construction, but if the memory after changes later this just keeps 
running. Well, that's quite a trap, but I guess that's what you get for not 
understanding the API ;).


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

Re: [PATCH] D13221: Make CompilerInvocation's use of the debug options more understandable.

[James Y Knight via cfe-commits]

jyknight added a comment.

This certainly seems a big improvement.

However, I don't think that you actually fixed specifying both 
-gline-tables-only and a Dwarf version, because that requires actually handling 
multiple options from g_group, instead of just the last one. E.g. "-gdwarf-2 
-g1" should cause the dwarf level to be set to 2, and enable line-tables. I 
expect the correct thing for Driver to do is to process *all* the args and 
apply them one at a time to the state variables, rather than just take the last 
arg.

(Not that I'm recommending that you fix that also in this commit, just not to 
claim it now works unless it does)



Comment at: include/clang/Driver/CC1Options.td:135
@@ -134,1 +134,3 @@
 
+def debug_info_kind_EQ : Joined<["-"], "di-kind=">;
+def dwarf_version_EQ : Joined<["-"], "dwarf-version=">;

I'd suggest to keep the name of thevar and the string the same for easy 
searching.


Comment at: lib/Driver/Tools.cpp:2353
@@ +2352,3 @@
+  }
+  switch (DwarfVersion) {
+  case 2:

How about:
  if (DwarfVersion > 0) CmdArgs.push_back("-dwarf-version=" + DwarfVersion);


http://reviews.llvm.org/D13221



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