r259769 - Add -nocudainc option to CUDA preprocessor test.

[Samuel Antao via cfe-commits]

Author: sfantao
Date: Thu Feb  4 02:13:16 2016
New Revision: 259769

URL: http://llvm.org/viewvc/llvm-project?rev=259769&view=rev
Log:
Add -nocudainc option to CUDA preprocessor test.

If include files are used in the CUDA preprocessor tests it will cause a 
failure due to a missing header file in hosts that do not match the triple
in the test. E.g. powerpc64le have CUDA support but the include files
cannot be used for an x86 target.


Modified:
cfe/trunk/test/Preprocessor/cuda-preprocess.cu

Modified: cfe/trunk/test/Preprocessor/cuda-preprocess.cu
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Preprocessor/cuda-preprocess.cu?rev=259769&r1=259768&r2=259769&view=diff
==
--- cfe/trunk/test/Preprocessor/cuda-preprocess.cu (original)
+++ cfe/trunk/test/Preprocessor/cuda-preprocess.cu Thu Feb  4 02:13:16 2016
@@ -13,20 +13,20 @@ clang_unittest_cuda_arch __CUDA_ARCH__
 
 // CHECK-NOT: PREPROCESSED_AWAY
 
-// RUN: %clang -E -target x86_64-linux-gnu --cuda-gpu-arch=sm_20 %s 2>&1 \
+// RUN: %clang -E -target x86_64-linux-gnu --cuda-gpu-arch=sm_20 -nocudainc %s 
2>&1 \
 // RUN:   | FileCheck -check-prefix NOARCH %s
-// RUN: %clang -E -target x86_64-linux-gnu --cuda-gpu-arch=sm_20 
--cuda-host-only %s 2>&1 \
+// RUN: %clang -E -target x86_64-linux-gnu --cuda-gpu-arch=sm_20 
--cuda-host-only -nocudainc %s 2>&1 \
 // RUN:   | FileCheck -check-prefix NOARCH %s
 // NOARCH: clang_unittest_no_arch
 
-// RUN: %clang -E -target x86_64-linux-gnu --cuda-gpu-arch=sm_20 
--cuda-device-only %s 2>&1 \
+// RUN: %clang -E -target x86_64-linux-gnu --cuda-gpu-arch=sm_20 
--cuda-device-only -nocudainc %s 2>&1 \
 // RUN:   | FileCheck -check-prefix SM20 %s
 // SM20: clang_unittest_cuda_arch 200
 
-// RUN: %clang -E -target x86_64-linux-gnu --cuda-gpu-arch=sm_30 
--cuda-device-only %s 2>&1 \
+// RUN: %clang -E -target x86_64-linux-gnu --cuda-gpu-arch=sm_30 
--cuda-device-only -nocudainc %s 2>&1 \
 // RUN:   | FileCheck -check-prefix SM30 %s
 // SM30: clang_unittest_cuda_arch 300
 
 // RUN: %clang -E -target x86_64-linux-gnu --cuda-gpu-arch=sm_20 
--cuda-gpu-arch=sm_30 \
-// RUN:   --cuda-device-only %s 2>&1 \
+// RUN:   --cuda-device-only -nocudainc %s 2>&1 \
 // RUN:   | FileCheck -check-prefix SM20 -check-prefix SM30 %s


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

Re: [PATCH] Install cmake files to lib/cmake/clang

[Niels Ole Salscheider via cfe-commits]

Ping.

Am Monday 21 December 2015, 00:10:10 schrieb Niels Ole Salscheider:
> This is the right location for platform-specific files.
> 
> Also, search for LLVM's CMake files in this directory.
> ---
>  CMakeLists.txt | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index 2c54e75..e4a839d 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -72,7 +72,7 @@ if( CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR )
>find_program(LLVM_TABLEGEN_EXE "llvm-tblgen" ${LLVM_TOOLS_BINARY_DIR}
>  NO_DEFAULT_PATH)
> 
> -  set(LLVM_CMAKE_PATH "${LLVM_BINARY_DIR}/share/llvm/cmake")
> +  set(LLVM_CMAKE_PATH
> "${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/cmake/llvm")
> set(LLVMCONFIG_FILE "${LLVM_CMAKE_PATH}/LLVMConfig.cmake")
>if(EXISTS ${LLVMCONFIG_FILE})
>  list(APPEND CMAKE_MODULE_PATH "${LLVM_CMAKE_PATH}")
> @@ -587,24 +587,24 @@ if (CLANG_BUILT_STANDALONE OR CMAKE_VERSION
> VERSION_EQUAL 3 OR # Generate a list of CMake library targets so that other
> CMake projects can # link against them. LLVM calls its version of this file
> LLVMExports.cmake, but # the usual CMake convention seems to be
> ${Project}Targets.cmake. -  set(CLANG_INSTALL_PACKAGE_DIR
> share/clang/cmake)
> +  set(CLANG_INSTALL_PACKAGE_DIR lib${LLVM_LIBDIR_SUFFIX}/cmake/clang)
>set(clang_cmake_builddir
> "${CMAKE_BINARY_DIR}/${CLANG_INSTALL_PACKAGE_DIR}")
> get_property(CLANG_EXPORTS GLOBAL PROPERTY CLANG_EXPORTS)
>export(TARGETS ${CLANG_EXPORTS} FILE
> ${clang_cmake_builddir}/ClangTargets.cmake)
> 
> -  # Install a /share/clang/cmake/ClangConfig.cmake file so that
> +  # Install a /lib/cmake/clang/ClangConfig.cmake file so that
># find_package(Clang) works. Install the target list with it.
>install(EXPORT ClangTargets DESTINATION ${CLANG_INSTALL_PACKAGE_DIR})
> 
>install(FILES
>  ${CMAKE_CURRENT_SOURCE_DIR}/cmake/modules/ClangConfig.cmake
> -DESTINATION share/clang/cmake)
> +DESTINATION lib${LLVM_LIBDIR_SUFFIX}/cmake/clang)
> 
># Also copy ClangConfig.cmake to the build directory so that dependent
> projects # can build against a build directory of Clang more easily.
>configure_file(
>  ${CMAKE_CURRENT_SOURCE_DIR}/cmake/modules/ClangConfig.cmake
> -${CLANG_BINARY_DIR}/share/clang/cmake/ClangConfig.cmake
> +   
> ${CLANG_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/cmake/clang/ClangConfig.cmake
> COPYONLY)
>  endif ()

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

[PATCH] D16876: [OpenCL] Refine pipe builtin support

[Xiuli PAN via cfe-commits]

pxli168 created this revision.
pxli168 added reviewers: Anastasia, pekka.jaaskelainen, yaxunl.
pxli168 added a subscriber: cfe-commits.

Refine the type builtin support as the request with
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20160201/148637.html

http://reviews.llvm.org/D16876

Files:
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/Sema/SemaChecking.cpp
  test/SemaOpenCL/invalid-pipe-builtin-cl2.0.cl

Index: test/SemaOpenCL/invalid-pipe-builtin-cl2.0.cl
===
--- test/SemaOpenCL/invalid-pipe-builtin-cl2.0.cl
+++ test/SemaOpenCL/invalid-pipe-builtin-cl2.0.cl
@@ -5,51 +5,51 @@
   reserve_id_t rid;
 
   // read/write_pipe
-  read_pipe(tmp, p);// expected-error {{first argument to read_pipe must be a pipe type}}
-  read_pipe(p);   // expected-error {{invalid number of arguments to function: read_pipe}}
-  read_pipe(p, tmp, tmp, ptr);   // expected-error {{invalid argument type to function read_pipe (expecting 'reserve_id_t')}}
-  read_pipe(p, rid, rid, ptr);   // expected-error {{invalid argument type to function read_pipe (expecting 'unsigned int')}}
-  read_pipe(p, tmp);   // expected-error {{invalid argument type to function read_pipe (expecting 'int *')}}
+  read_pipe(tmp, p);// expected-error {{first argument to 'read_pipe' must be a pipe type}}
+  read_pipe(p);   // expected-error {{invalid number of arguments to function: 'read_pipe'}}
+  read_pipe(p, tmp, tmp, ptr);   // expected-error {{invalid argument type to function 'read_pipe' (expecting 'reserve_id_t')}}
+  read_pipe(p, rid, rid, ptr);   // expected-error {{invalid argument type to function 'read_pipe' (expecting 'unsigned int')}}
+  read_pipe(p, tmp);   // expected-error {{invalid argument type to function 'read_pipe' (expecting 'int *')}}
   write_pipe(p, ptr);// expected-error {{invalid pipe access modifier (expecting write_only)}}
   write_pipe(p, rid, tmp, ptr);// expected-error {{invalid pipe access modifier (expecting write_only)}}
 
   // reserve_read/write_pipe
-  reserve_read_pipe(p, ptr);// expected-error{{invalid argument type to function reserve_read_pipe (expecting 'unsigned int')}}
-  work_group_reserve_read_pipe(tmp, tmp);// expected-error{{first argument to work_group_reserve_read_pipe must be a pipe type}}
+  reserve_read_pipe(p, ptr);// expected-error{{invalid argument type to function 'reserve_read_pipe' (expecting 'unsigned int')}}
+  work_group_reserve_read_pipe(tmp, tmp);// expected-error{{first argument to 'work_group_reserve_read_pipe' must be a pipe type}}
   sub_group_reserve_write_pipe(p, tmp);// expected-error{{invalid pipe access modifier (expecting write_only)}}
 
   // commit_read/write_pipe
-  commit_read_pipe(tmp, rid);// expected-error{{first argument to commit_read_pipe must be a pipe type}}
-  work_group_commit_read_pipe(p, tmp);// expected-error{{invalid argument type to function work_group_commit_read_pipe (expecting 'reserve_id_t')}}
+  commit_read_pipe(tmp, rid);// expected-error{{first argument to 'commit_read_pipe' must be a pipe type}}
+  work_group_commit_read_pipe(p, tmp);// expected-error{{invalid argument type to function 'work_group_commit_read_pipe' (expecting 'reserve_id_t')}}
   sub_group_commit_write_pipe(p, tmp);// expected-error{{nvalid pipe access modifier (expecting write_only)}}
 }
 
 void test2(write_only pipe int p, global int* ptr){
   int tmp;
   reserve_id_t rid;
 
   // read/write_pipe
-  write_pipe(tmp, p);// expected-error {{first argument to write_pipe must be a pipe type}}
-  write_pipe(p);   // expected-error {{invalid number of arguments to function: write_pipe}}
-  write_pipe(p, tmp, tmp, ptr);   // expected-error {{invalid argument type to function write_pipe (expecting 'reserve_id_t')}}
-  write_pipe(p, rid, rid, ptr);   // expected-error {{invalid argument type to function write_pipe (expecting 'unsigned int')}}
-  write_pipe(p, tmp);   // expected-error {{invalid argument type to function write_pipe (expecting 'int *')}}
+  write_pipe(tmp, p);// expected-error {{first argument to 'write_pipe' must be a pipe type}}
+  write_pipe(p);   // expected-error {{invalid number of arguments to function: 'write_pipe'}}
+  write_pipe(p, tmp, tmp, ptr);   // expected-error {{invalid argument type to function 'write_pipe' (expecting 'reserve_id_t')}}
+  write_pipe(p, rid, rid, ptr);   // expected-error {{invalid argument type to function 'write_pipe' (expecting 'unsigned int')}}
+  write_pipe(p, tmp);   // expected-error {{invalid argument type to function 'write_pipe' (expecting 'int *')}}
   read_pipe(p, ptr);// expected-error {{invalid pipe access modifier (expecting read_only)}}
   read_pipe(p, rid, tmp, ptr);// expected-error {{invalid pipe access modifier (expecting read_only)}}
 
   // reserve_read/write_pipe
-  reserve_write_pipe(p, ptr);// expected-error{{invalid argument type to function reserve_write_pipe (expecting 

RE: r258782 - Recommit: R258773 [OpenCL] Pipe builtin functions

[xiuli pan via cfe-commits]

The refined patch is in http://reviews.llvm.org/D16876

-Original Message-
From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of 
xiuli pan via cfe-commits
Sent: Tuesday, February 2, 2016 10:53 AM
To: 'Richard Smith' 
Cc: 'cfe-commits' 
Subject: RE: r258782 - Recommit: R258773 [OpenCL] Pipe builtin functions

Thank you for you advise, I will make these fixed in some later commit.

-Original Message-
From: meta...@gmail.com [mailto:meta...@gmail.com] On Behalf Of Richard Smith
Sent: Tuesday, February 2, 2016 5:53 AM
To: Xiuli Pan 
Cc: cfe-commits 
Subject: Re: r258782 - Recommit: R258773 [OpenCL] Pipe builtin functions

On Mon, Jan 25, 2016 at 8:03 PM, Xiuli Pan via cfe-commits 
 wrote:
> Author: pxl
> Date: Mon Jan 25 22:03:48 2016
> New Revision: 258782
>
> URL: http://llvm.org/viewvc/llvm-project?rev=258782&view=rev
> Log:
> Recommit: R258773 [OpenCL] Pipe builtin functions Fix arc patch fuzz 
> error.
> Summary:
> Support for the pipe built-in functions for OpenCL 2.0.
> The pipe builtin functions may have infinite kinds of element types, 
> one approach would be to just generate calls that would always use generic 
> types such as void*.
> This patch is based on bader's opencl support patch on SPIR-V branch.
>
> Reviewers: Anastasia, pekka.jaaskelainen
>
> Subscribers: keryell, bader, cfe-commits
>
> Differential Revision: http://reviews.llvm.org/D15914
>
> Added:
> cfe/trunk/test/CodeGenOpenCL/pipe_builtin.cl
> cfe/trunk/test/SemaOpenCL/invalid-pipe-builtin-cl2.0.cl
> Modified:
> cfe/trunk/include/clang/Basic/Builtins.def
> cfe/trunk/include/clang/Basic/Builtins.h
> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> cfe/trunk/lib/Basic/Builtins.cpp
> cfe/trunk/lib/CodeGen/CGBuiltin.cpp
> cfe/trunk/lib/Sema/SemaChecking.cpp
>
> Modified: cfe/trunk/include/clang/Basic/Builtins.def
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Buil
> tins.def?rev=258782&r1=258781&r2=258782&view=diff
> ==
> 
> --- cfe/trunk/include/clang/Basic/Builtins.def (original)
> +++ cfe/trunk/include/clang/Basic/Builtins.def Mon Jan 25 22:03:48
> +++ 2016
> @@ -1252,6 +1252,32 @@ BUILTIN(__builtin___get_unsafe_stack_ptr
>  BUILTIN(__builtin_nontemporal_store, "v.", "t") 
> BUILTIN(__builtin_nontemporal_load, "v.", "t")
>
> +// OpenCL v2.0 s6.13.16, s9.17.3.5 - Pipe functions.
> +// We need the generic prototype, since the packet type could be anything.
> +LANGBUILTIN(read_pipe, "i.", "tn", OCLC_LANG) LANGBUILTIN(write_pipe, 
> +"i.", "tn", OCLC_LANG)
> +
> +LANGBUILTIN(reserve_read_pipe, "i.", "tn", OCLC_LANG) 
> +LANGBUILTIN(reserve_write_pipe, "i.", "tn", OCLC_LANG)
> +
> +LANGBUILTIN(commit_write_pipe, "v.", "tn", OCLC_LANG) 
> +LANGBUILTIN(commit_read_pipe, "v.", "tn", OCLC_LANG)
> +
> +LANGBUILTIN(sub_group_reserve_read_pipe, "i.", "tn", OCLC_LANG) 
> +LANGBUILTIN(sub_group_reserve_write_pipe, "i.", "tn", OCLC_LANG)
> +
> +LANGBUILTIN(sub_group_commit_read_pipe, "v.", "tn", OCLC_LANG) 
> +LANGBUILTIN(sub_group_commit_write_pipe, "v.", "tn", OCLC_LANG)
> +
> +LANGBUILTIN(work_group_reserve_read_pipe, "i.", "tn", OCLC_LANG) 
> +LANGBUILTIN(work_group_reserve_write_pipe, "i.", "tn", OCLC_LANG)
> +
> +LANGBUILTIN(work_group_commit_read_pipe, "v.", "tn", OCLC_LANG) 
> +LANGBUILTIN(work_group_commit_write_pipe, "v.", "tn", OCLC_LANG)
> +
> +LANGBUILTIN(get_pipe_num_packets, "Ui.", "tn", OCLC_LANG) 
> +LANGBUILTIN(get_pipe_max_packets, "Ui.", "tn", OCLC_LANG)
> +
>  #undef BUILTIN
>  #undef LIBBUILTIN
>  #undef LANGBUILTIN
>
> Modified: cfe/trunk/include/clang/Basic/Builtins.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Buil
> tins.h?rev=258782&r1=258781&r2=258782&view=diff
> ==
> 
> --- cfe/trunk/include/clang/Basic/Builtins.h (original)
> +++ cfe/trunk/include/clang/Basic/Builtins.h Mon Jan 25 22:03:48 2016
> @@ -36,6 +36,7 @@ enum LanguageID {
>CXX_LANG = 0x4,  // builtin for cplusplus only.
>OBJC_LANG = 0x8, // builtin for objective-c and objective-c++
>MS_LANG = 0x10,  // builtin requires MS mode.
> +  OCLC_LANG = 0x20,// builtin for OpenCL C only.

Missing space after comma.

Xiuli: I did not add one because the // will be aligned this way.

>ALL_LANGUAGES = C_LANG | CXX_LANG | OBJC_LANG, // builtin for all 
> languages.
>ALL_GNU_LANGUAGES = ALL_LANGUAGES | GNU_LANG,  // builtin requires GNU 
> mode.
>ALL_MS_LANGUAGES = ALL_LANGUAGES | MS_LANG // builtin requires MS mode.
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Diag
> nosticSemaKinds.td?rev=258782&r1=258781&r2=258782&view=diff
> ==
> 
> --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td 

Re: [PATCH] D16183: Added CheckName field to YAML report

[Ilia Gromov via cfe-commits]

Elijah_Th updated this revision to Diff 46883.
Elijah_Th added a comment.

Now the class that is serialized is Diagnostics.
I've moved ClangTidyError and ClangTidyMessage to the upper level, and renamed 
to Diagnostics and DiagnosticsMessage. Now any tool can use this classes, they 
contain more information than than Replacement. I think Diagnostics is a good 
class to add some more information later.

Please, review the fix, if it's ok I'll run clang-format on the changed code 
and provide the documentation. Thanks!


http://reviews.llvm.org/D16183

Files:
  
/media/SSD_/code/LLVM-code/LLVM-trunk_256412/llvm/tools/clang/include/clang/Tooling/Core/Diagnostics.h
  
/media/SSD_/code/LLVM-code/LLVM-trunk_256412/llvm/tools/clang/include/clang/Tooling/DiagnosticsYaml.h
  
/media/SSD_/code/LLVM-code/LLVM-trunk_256412/llvm/tools/clang/lib/Tooling/Core/CMakeLists.txt
  
/media/SSD_/code/LLVM-code/LLVM-trunk_256412/llvm/tools/clang/lib/Tooling/Core/Diagnostics.cpp
  
/media/SSD_/code/LLVM-code/LLVM-trunk_256412/llvm/tools/clang/tools/extra/clang-tidy/ClangTidy.cpp
  
/media/SSD_/code/LLVM-code/LLVM-trunk_256412/llvm/tools/clang/tools/extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp
  
/media/SSD_/code/LLVM-code/LLVM-trunk_256412/llvm/tools/clang/tools/extra/clang-tidy/ClangTidyDiagnosticConsumer.h

Index: /media/SSD_/code/LLVM-code/LLVM-trunk_256412/llvm/tools/clang/include/clang/Tooling/DiagnosticsYaml.h
===
--- /media/SSD_/code/LLVM-code/LLVM-trunk_256412/llvm/tools/clang/include/clang/Tooling/DiagnosticsYaml.h
+++ /media/SSD_/code/LLVM-code/LLVM-trunk_256412/llvm/tools/clang/include/clang/Tooling/DiagnosticsYaml.h
@@ -0,0 +1,42 @@
+//===-- ReplacementsYaml.h -- Serialiazation for Replacements ---*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+///
+/// \file
+/// \brief This file defines the structure of a YAML document for serializing
+/// ClangTidy errors.
+///
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLING_DIAGNOSTICSYAML_H
+#define LLVM_CLANG_TOOLING_DIAGNOSTICSYAML_H
+
+#include "clang/Tooling/Refactoring.h"
+#include "clang/Tooling/Core/Diagnostics.h"
+#include "llvm/Support/YAMLTraits.h"
+#include 
+#include 
+
+LLVM_YAML_IS_SEQUENCE_VECTOR(clang::tooling::Diagnostics)
+
+namespace llvm {
+namespace yaml {
+
+template <> struct MappingTraits {
+  static void mapping(IO &Io,
+  clang::tooling::Diagnostics &D) {
+std::vector fixes(D.Fix.begin(), D.Fix.end());
+Io.mapRequired("CheckName", D.CheckName);
+Io.mapRequired("Replacements", fixes);
+  }
+};
+} // end namespace yaml
+} // end namespace llvm
+
+#endif /* LLVM_CLANG_TOOLING_DIAGNOSTICSYAML_H */
+
Index: /media/SSD_/code/LLVM-code/LLVM-trunk_256412/llvm/tools/clang/include/clang/Tooling/Core/Diagnostics.h
===
--- /media/SSD_/code/LLVM-code/LLVM-trunk_256412/llvm/tools/clang/include/clang/Tooling/Core/Diagnostics.h
+++ /media/SSD_/code/LLVM-code/LLVM-trunk_256412/llvm/tools/clang/include/clang/Tooling/Core/Diagnostics.h
@@ -0,0 +1,62 @@
+//===--- Replacement.h - Framework for clang refactoring tools --*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+//
+//  Classes supporting refactorings that span multiple translation units.
+//  While single translation unit refactorings are supported via the Rewriter,
+//  when refactoring multiple translation units changes must be stored in a
+//  SourceManager independent form, duplicate changes need to be removed, and
+//  all changes must be applied at once at the end of the refactoring so that
+//  the code is always parseable.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLING_CORE_DIAGNOSTICS_H
+#define LLVM_CLANG_TOOLING_CORE_DIAGNOSTICS_H
+
+#include "clang/Basic/Diagnostic.h"
+#include "llvm/ADT/SmallVector.h"
+#include "Replacement.h"
+#include 
+
+namespace clang {
+namespace tooling {
+
+struct DiagnosticsMessage {
+DiagnosticsMessage(StringRef Message = "");
+DiagnosticsMessage(StringRef Message, const SourceManager &Sources,
+SourceLocation Loc);
+std::string Message;
+std::string FilePath;
+unsigned FileOffset;
+};
+
+struct Diagnostics {
+
+enum Level {
+Ignored = DiagnosticsEngine::Ignored,
+Warning =

RE: r258782 - Recommit: R258773 [OpenCL] Pipe builtin functions

[Anastasia Stulova via cfe-commits]

Thanks for clarifications and feedback. I think there is enough time to improve 
the patch before the release date.

But I believe Hans has more experience to evaluate potential issues here. I 
think I am fine to complete this work for the next release instead.

I hope Xiuli and others agree too.

Anastasia

-Original Message-
From: Hans Wennborg [mailto:hwennb...@google.com] 
Sent: 03 February 2016 21:42
To: Richard Smith
Cc: Anastasia Stulova; cfe-commits; xiuli pan; Pekka Jääskeläinen; nd
Subject: Re: r258782 - Recommit: R258773 [OpenCL] Pipe builtin functions

On Wed, Feb 3, 2016 at 1:00 PM, Richard Smith  wrote:
> On Wed, Feb 3, 2016 at 11:08 AM, Anastasia Stulova 
>  wrote:
>>
>> I think the main reason is that we have committed pipe type before 
>> the release branch was taken. It appears to have no use without the 
>> pipe builtin functions.
>>
>> Are there any risks of adding this now?
>
>
> Based on my post-commit review of the patch, I don't think this is yet 
> mature enough for 3.8 (in particular, it improperly handles type 
> sugar, and should be performing argument conversions in SemaChecking 
> rather than in CGBuiltin). If you're confident that this can be 
> cleaned up in time, and Hans is prepared to take those cleanup patches 
> onto the branch too, then I think this is fine to go into 3.8 to finish off 
> the OpenCL pipe work.

I wouldn't be keen on taking those patches. We've already tagged RC2, and I 
want bugfixes only going forward. I think the reality is that this landed a 
little too late to make it into the release, and will have to wait until 3.9.

 - Hans


>> -Original Message-
>> From: meta...@gmail.com [mailto:meta...@gmail.com] On Behalf Of 
>> Richard Smith
>> Sent: 01 February 2016 21:54
>> To: Hans Wennborg
>> Cc: xiuli pan; cfe-commits; Pekka Jääskeläinen; Anastasia Stulova
>> Subject: Re: r258782 - Recommit: R258773 [OpenCL] Pipe builtin 
>> functions
>>
>> On Thu, Jan 28, 2016 at 11:25 AM, Hans Wennborg 
>> 
>> wrote:
>> > I don't think we have a specific code owner for OpenCL in Clang, 
>> > which means Richard is the owner.
>> >
>> > Richard, what do you think?
>>
>> Is there a reason we want to push this new feature into 3.8 rather 
>> than waiting for the next release?
>>
>> > On Wed, Jan 27, 2016 at 10:08 PM, xiuli pan 
>> > wrote:
>> >> Hi hans,
>> >>
>> >> Request to merge it to release 38
>> >>
>> >> It adds Pipe BIFs to be used along with Pipe type committed 
>> >> earlier (in r257254).
>> >>
>> >> Thanks
>> >> Xiuli
>> >>
>> >> -Original Message-
>> >> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On 
>> >> Behalf Of Xiuli Pan via cfe-commits
>> >> Sent: Tuesday, January 26, 2016 12:04 PM
>> >> To: cfe-commits@lists.llvm.org
>> >> Subject: r258782 - Recommit: R258773 [OpenCL] Pipe builtin 
>> >> functions
>> >>
>> >> Author: pxl
>> >> Date: Mon Jan 25 22:03:48 2016
>> >> New Revision: 258782
>> >>
>> >> URL: http://llvm.org/viewvc/llvm-project?rev=258782&view=rev
>> >> Log:
>> >> Recommit: R258773 [OpenCL] Pipe builtin functions Fix arc patch 
>> >> fuzz error.
>> >> Summary:
>> >> Support for the pipe built-in functions for OpenCL 2.0.
>> >> The pipe builtin functions may have infinite kinds of element 
>> >> types, one approach would be to just generate calls that would 
>> >> always use generic types such as void*.
>> >> This patch is based on bader's opencl support patch on SPIR-V branch.
>> >>
>> >> Reviewers: Anastasia, pekka.jaaskelainen
>> >>
>> >> Subscribers: keryell, bader, cfe-commits
>> >>
>> >> Differential Revision: http://reviews.llvm.org/D15914
>> >>
>> >> Added:
>> >> cfe/trunk/test/CodeGenOpenCL/pipe_builtin.cl
>> >> cfe/trunk/test/SemaOpenCL/invalid-pipe-builtin-cl2.0.cl
>> >> Modified:
>> >> cfe/trunk/include/clang/Basic/Builtins.def
>> >> cfe/trunk/include/clang/Basic/Builtins.h
>> >> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
>> >> cfe/trunk/lib/Basic/Builtins.cpp
>> >> cfe/trunk/lib/CodeGen/CGBuiltin.cpp
>> >> cfe/trunk/lib/Sema/SemaChecking.cpp
>> >>
>> >> Modified: cfe/trunk/include/clang/Basic/Builtins.def
>> >> URL:
>> >> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/
>> >> Bui ltins.def?rev=258782&r1=258781&r2=258782&view=diff
>> >> ==
>> >> ===
>> >> =
>> >> --- cfe/trunk/include/clang/Basic/Builtins.def (original)
>> >> +++ cfe/trunk/include/clang/Basic/Builtins.def Mon Jan 25 22:03:48
>> >> +++ 2016
>> >> @@ -1252,6 +1252,32 @@ BUILTIN(__builtin___get_unsafe_stack_ptr
>> >>  BUILTIN(__builtin_nontemporal_store, "v.", "t") 
>> >> BUILTIN(__builtin_nontemporal_load, "v.", "t")
>> >>
>> >> +// OpenCL v2.0 s6.13.16, s9.17.3.5 - Pipe functions.
>> >> +// We need the generic prototype, since the packet type could be
>> >> anything.
>> >> +LANGBUILTIN(read_pipe, "i.", "tn", OCLC_LANG) 
>> >> +LANGBUILTIN(write_pipe, "i.", "tn", OCLC_LANG)
>> >> +
>> >> +LANGBUIL

Re: [PATCH] D12761: MPI-Checker patch for Clang Static Analyzer

[Alexander Droste via cfe-commits]

Alexander_Droste added inline comments.


Comment at: 
tools/clang/lib/StaticAnalyzer/Checkers/MPI-Checker/MPIChecker.cpp:43
@@ +42,3 @@
+private:
+  const std::unique_ptr CheckerSens;
+

zaks.anna wrote:
> Alexander_Droste wrote:
> > zaks.anna wrote:
> > > I'd stress "path" instead of "sensitive" in the name. Also, this 
> > > indirection is redundant if you remove the AST checks.
> > If sufficient, I would rename `MPICheckerPathSensitive` to `MPICheckerPath` 
> > then.
> > Do you mind the indirection?
> I indirection buying us anything? I think it makes the code more difficult to 
> follow,
I think, I like the entry point class being separated from the class which does 
the actual checking. But the necessity for `dynamicInit()` maybe outweighs 
that. I can collapse the two.


Comment at: 
tools/clang/lib/StaticAnalyzer/Checkers/MPI-Checker/MPICheckerPathSensitive.cpp:74
@@ +73,3 @@
+  // A wait has no matching nonblocking call.
+  BugReporter.reportUnmatchedWait(PreCallEvent, ReqRegion, ExplNode);
+}

zaks.anna wrote:
> Alexander_Droste wrote:
> > zaks.anna wrote:
> > > This is called in a loop. Should you break once the first error is 
> > > reported?
> > > 
> > > Also, as before you should use the CheckerContext API to produce a node 
> > > on which the error should be reported.
> > > 
> > > 
> > I don't think break should be called after the first error is reported. 
> > Each memory region
> > represents a different request, why this should be rated as multiple 
> > errors. 
> You might be right, I am not 100% sure what's more user-friendly..  
> Presumably the fixes are different in each case? Could you add a test case 
> where multiple errors on the same call site are reported? (Ups can use 
> expected-warning@+1 to report multiple warnings on the same line.)
This is comparable to calling free on different elements, for which memory was 
never allocated. So each report informs about a distinct missing nonblocking 
call. I'll give `expected-warning@+1` a try.


http://reviews.llvm.org/D12761



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

r259776 - [OPENMP 4.0] Fixed support of array sections/array subscripts.

[Alexey Bataev via cfe-commits]

Author: abataev
Date: Thu Feb  4 05:27:03 2016
New Revision: 259776

URL: http://llvm.org/viewvc/llvm-project?rev=259776&view=rev
Log:
[OPENMP 4.0] Fixed support of array sections/array subscripts.
Codegen for array sections/array subscripts worked only for expressions with 
arrays as base. Patch fixes codegen for bases with pointer/reference types.

Modified:
cfe/trunk/include/clang/AST/ExprOpenMP.h
cfe/trunk/lib/AST/Expr.cpp
cfe/trunk/lib/CodeGen/CGExpr.cpp
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.h
cfe/trunk/lib/Sema/SemaExpr.cpp
cfe/trunk/lib/Sema/SemaOpenMP.cpp
cfe/trunk/test/OpenMP/for_reduction_codegen.cpp
cfe/trunk/test/OpenMP/task_codegen.cpp

Modified: cfe/trunk/include/clang/AST/ExprOpenMP.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ExprOpenMP.h?rev=259776&r1=259775&r2=259776&view=diff
==
--- cfe/trunk/include/clang/AST/ExprOpenMP.h (original)
+++ cfe/trunk/include/clang/AST/ExprOpenMP.h Thu Feb  4 05:27:03 2016
@@ -85,7 +85,7 @@ public:
   void setBase(Expr *E) { SubExprs[BASE] = E; }
 
   /// \brief Return original type of the base expression for array section.
-  static QualType getBaseOriginalType(Expr *Base);
+  static QualType getBaseOriginalType(const Expr *Base);
 
   /// \brief Get lower bound of array section.
   Expr *getLowerBound() { return cast_or_null(SubExprs[LOWER_BOUND]); }

Modified: cfe/trunk/lib/AST/Expr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Expr.cpp?rev=259776&r1=259775&r2=259776&view=diff
==
--- cfe/trunk/lib/AST/Expr.cpp (original)
+++ cfe/trunk/lib/AST/Expr.cpp Thu Feb  4 05:27:03 2016
@@ -4026,16 +4026,18 @@ unsigned AtomicExpr::getNumSubExprs(Atom
   llvm_unreachable("unknown atomic op");
 }
 
-QualType OMPArraySectionExpr::getBaseOriginalType(Expr *Base) {
+QualType OMPArraySectionExpr::getBaseOriginalType(const Expr *Base) {
   unsigned ArraySectionCount = 0;
   while (auto *OASE = dyn_cast(Base->IgnoreParens())) {
 Base = OASE->getBase();
 ++ArraySectionCount;
   }
-  while (auto *ASE = dyn_cast(Base->IgnoreParens())) {
+  while (auto *ASE =
+ dyn_cast(Base->IgnoreParenImpCasts())) {
 Base = ASE->getBase();
 ++ArraySectionCount;
   }
+  Base = Base->IgnoreParenImpCasts();
   auto OriginalTy = Base->getType();
   if (auto *DRE = dyn_cast(Base))
 if (auto *PVD = dyn_cast(DRE->getDecl()))

Modified: cfe/trunk/lib/CodeGen/CGExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGExpr.cpp?rev=259776&r1=259775&r2=259776&view=diff
==
--- cfe/trunk/lib/CodeGen/CGExpr.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGExpr.cpp Thu Feb  4 05:27:03 2016
@@ -1949,6 +1949,21 @@ LValue CodeGenFunction::EmitLoadOfRefere
   return MakeAddrLValue(Addr, RefTy->getPointeeType(), Source);
 }
 
+Address CodeGenFunction::EmitLoadOfPointer(Address Ptr,
+   const PointerType *PtrTy,
+   AlignmentSource *Source) {
+  llvm::Value *Addr = Builder.CreateLoad(Ptr);
+  return Address(Addr, getNaturalTypeAlignment(PtrTy->getPointeeType(), Source,
+   /*forPointeeType=*/true));
+}
+
+LValue CodeGenFunction::EmitLoadOfPointerLValue(Address PtrAddr,
+const PointerType *PtrTy) {
+  AlignmentSource Source;
+  Address Addr = EmitLoadOfPointer(PtrAddr, PtrTy, &Source);
+  return MakeAddrLValue(Addr, PtrTy->getPointeeType(), Source);
+}
+
 static LValue EmitGlobalVarDeclLValue(CodeGenFunction &CGF,
   const Expr *E, const VarDecl *VD) {
   QualType T = E->getType();
@@ -2934,21 +2949,54 @@ LValue CodeGenFunction::EmitArraySubscri
   return LV;
 }
 
+static Address emitOMPArraySectionBase(CodeGenFunction &CGF, const Expr *Base,
+   AlignmentSource &AlignSource,
+   QualType BaseTy, QualType ElTy,
+   bool IsLowerBound) {
+  LValue BaseLVal;
+  if (auto *ASE = dyn_cast(Base->IgnoreParenImpCasts())) {
+BaseLVal = CGF.EmitOMPArraySectionExpr(ASE, IsLowerBound);
+if (BaseTy->isArrayType()) {
+  Address Addr = BaseLVal.getAddress();
+  AlignSource = BaseLVal.getAlignmentSource();
+
+  // If the array type was an incomplete type, we need to make sure
+  // the decay ends up being the right type.
+  llvm::Type *NewTy = CGF.ConvertType(BaseTy);
+  Addr = CGF.Builder.CreateElementBitCast(Addr, NewTy);
+
+  // Note that VLA pointers are always decayed, so we don't need to do
+  // anything here.
+  if (!BaseTy->isVariableArrayT

Re: [PATCH] D16626: [x86] Correct setting of WIntType for MCU target

[Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL259780: [x86] Correct setting of WIntType for MCU target 
(authored by asbokhan).

Changed prior to commit:
  http://reviews.llvm.org/D16626?vs=46125&id=46893#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D16626

Files:
  cfe/trunk/lib/Basic/Targets.cpp
  cfe/trunk/test/Preprocessor/elfiamcu-predefines.c

Index: cfe/trunk/test/Preprocessor/elfiamcu-predefines.c
===
--- cfe/trunk/test/Preprocessor/elfiamcu-predefines.c
+++ cfe/trunk/test/Preprocessor/elfiamcu-predefines.c
@@ -1,6 +1,7 @@
 // RUN: %clang_cc1 -E -dM -triple i586-intel-elfiamcu | FileCheck %s
 
 // CHECK: #define __USER_LABEL_PREFIX__ {{$}}
+// CHECK: #define __WINT_TYPE__ unsigned int
 // CHECK: #define __iamcu
 // CHECK: #define __iamcu__
 
Index: cfe/trunk/lib/Basic/Targets.cpp
===
--- cfe/trunk/lib/Basic/Targets.cpp
+++ cfe/trunk/lib/Basic/Targets.cpp
@@ -3908,6 +3908,7 @@
 LongDoubleWidth = 64;
 LongDoubleFormat = &llvm::APFloat::IEEEdouble;
 UserLabelPrefix = "";
+WIntType = UnsignedInt;
   }
 
   CallingConvCheckResult checkCallingConvention(CallingConv CC) const override 
{


Index: cfe/trunk/test/Preprocessor/elfiamcu-predefines.c
===
--- cfe/trunk/test/Preprocessor/elfiamcu-predefines.c
+++ cfe/trunk/test/Preprocessor/elfiamcu-predefines.c
@@ -1,6 +1,7 @@
 // RUN: %clang_cc1 -E -dM -triple i586-intel-elfiamcu | FileCheck %s
 
 // CHECK: #define __USER_LABEL_PREFIX__ {{$}}
+// CHECK: #define __WINT_TYPE__ unsigned int
 // CHECK: #define __iamcu
 // CHECK: #define __iamcu__
 
Index: cfe/trunk/lib/Basic/Targets.cpp
===
--- cfe/trunk/lib/Basic/Targets.cpp
+++ cfe/trunk/lib/Basic/Targets.cpp
@@ -3908,6 +3908,7 @@
 LongDoubleWidth = 64;
 LongDoubleFormat = &llvm::APFloat::IEEEdouble;
 UserLabelPrefix = "";
+WIntType = UnsignedInt;
   }
 
   CallingConvCheckResult checkCallingConvention(CallingConv CC) const override {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r259780 - [x86] Correct setting of WIntType for MCU target

[Andrey Bokhanko via cfe-commits]

Author: asbokhan
Date: Thu Feb  4 05:54:45 2016
New Revision: 259780

URL: http://llvm.org/viewvc/llvm-project?rev=259780&view=rev
Log:
[x86] Correct setting of WIntType for MCU target

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

Modified:
cfe/trunk/lib/Basic/Targets.cpp
cfe/trunk/test/Preprocessor/elfiamcu-predefines.c

Modified: cfe/trunk/lib/Basic/Targets.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=259780&r1=259779&r2=259780&view=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Thu Feb  4 05:54:45 2016
@@ -3908,6 +3908,7 @@ public:
 LongDoubleWidth = 64;
 LongDoubleFormat = &llvm::APFloat::IEEEdouble;
 UserLabelPrefix = "";
+WIntType = UnsignedInt;
   }
 
   CallingConvCheckResult checkCallingConvention(CallingConv CC) const override 
{

Modified: cfe/trunk/test/Preprocessor/elfiamcu-predefines.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Preprocessor/elfiamcu-predefines.c?rev=259780&r1=259779&r2=259780&view=diff
==
--- cfe/trunk/test/Preprocessor/elfiamcu-predefines.c (original)
+++ cfe/trunk/test/Preprocessor/elfiamcu-predefines.c Thu Feb  4 05:54:45 2016
@@ -1,6 +1,7 @@
 // RUN: %clang_cc1 -E -dM -triple i586-intel-elfiamcu | FileCheck %s
 
 // CHECK: #define __USER_LABEL_PREFIX__ {{$}}
+// CHECK: #define __WINT_TYPE__ unsigned int
 // CHECK: #define __iamcu
 // CHECK: #define __iamcu__
 


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

Re: r259622 - Fix miscompile and rejects-valids when disambiguating after an ambiguous

[Renato Golin via cfe-commits]

On 3 February 2016 at 18:53, Richard Smith  wrote:
> Fixed in r259677, sorry about that!

No worries, thanks!

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

Re: [PATCH] D16529: [clang-tidy] Add modernize-raw-string-literal check

[Alexander Kornienko via cfe-commits]

alexfh added a comment.

There are still a few comments open. One more important thing is to try running 
this check over a large enough project (LLVM + Clang, for example), apply 
fixes, look at the results and try to build the fixed code and run all tests. 
You can use the clang-tidy/tool/run-clang-tidy.py script (with proper 
-clang-tidy-binary and -clang-apply-replacements-binary options) to run the 
check and apply the fixes.



Comment at: clang-tidy/modernize/RawStringLiteralCheck.cpp:68
@@ +67,3 @@
+  // The NUL character disqualifies this literal.
+  if (Bytes.find('\000') != StringRef::npos)
+return false;

Do you have a test for this?


Comment at: clang-tidy/modernize/RawStringLiteralCheck.cpp:96
@@ +95,3 @@
+  std::string Delimiter;
+  for (int Counter = 0; containsDelimiter(Bytes, Delimiter); ++Counter) {
+Delimiter = (Counter == 0) ? "lit" : "lit" + std::to_string(Counter);

LegalizeAdulthood wrote:
> alexfh wrote:
> > Please address my comment above that relates to this code. Specifically, I 
> > find this generic algorithm unnecessarily inefficient and too rigid, i.e. 
> > one can't configure a custom set of delimiters that don't follow the 
> >  pattern. I suggest using a list of pre-concatenated pairs 
> > of strings (like `R"lit(` and `)lit"`).
> Raw strings are new and not many people are using them because the don't have 
> a good way to automatically convert disgusting quoted strings to raw strings. 
>  So I don't think it is reasonable to draw conclusions by looking in existing 
> code bases for raw strings.
> 
> We're having the same conversation we've had before.  I'm trying to do a 
> basic check and get things working properly and the review comments are 
> tending towards a desire for some kind of perfection.
> 
> I don't see why we have to make the perfect the enemy of the good.  Nothing 
> you are suggesting **must** be present now in order for this check to 
> function properly and reasonably.
We're looking at this from different perspectives. From my point of view, 
preventing a potentially wasteful code in ClangTidy checks before it's even 
committed is much easier than tracking down performance issues when tens of 
checks run on multiple machines analyzing millions lines of code. So I'm asking 
to avoid writing code using string allocations and concatenations when there 
are good alternatives. Apart from possible performance issues, in this case the 
generic solution you suggest is targets extremely rare cases, while most 
real-world situations can be handled with a fixed set of delimiters (possibly, 
configured by the user, while I expect the preferences for the choice of 
delimiters to be very different in different teams).


Comment at: clang-tidy/modernize/RawStringLiteralCheck.cpp:116
@@ +115,3 @@
+if (containsEscapedCharacters(Result, Literal))
+  replaceWithRawStringLiteral(Result, Literal);
+  }

aaron.ballman wrote:
> A configuration option makes sense to me, but I would be fine if it was a 
> follow-on patch. I think that someone running this check is likely fine with 
> the level of noise it will produce (which should be moderately low).
Agreed. This can be done in a follow up.


Comment at: test/clang-tidy/modernize-raw-string-literal.cpp:1
@@ +1,2 @@
+// RUN: %check_clang_tidy %s modernize-raw-string-literal %t
+

As usual, please add tests ensuring that replacements are done correctly in 
templates with multiple instantiations and in macro arguments (but not in macro 
bodies), e.g.

  template
  void f() {
(void)"asdf\\";
// CHECK-FIXES: void f() {
// CHECK-FIXES-NEXT: {{^  }}(void)R"(asdf\\\)";{{$}}
// CHECK-FIXES-NEXT: {{^}$}}
  }
  void g() {
f();
f();
  }

  #define M(x) x x x "a\\b\\"
  void h() {
const char *const s = M("c\\d\\");
// CHECK-FIXES: {{^}}#define M(x) x x x "a\\b\\"{{$}}
// CHECK-FIXES: {{^  }}const char *const s = M(R"(c\d\)");
  }




http://reviews.llvm.org/D16529



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

Re: [PATCH] D16113: [clang-tdiy] Add header file extension configuration support.

[Haojian Wu via cfe-commits]

hokein updated this revision to Diff 46897.
hokein added a comment.

Address Alex's comments.


http://reviews.llvm.org/D16113

Files:
  clang-tidy/ClangTidy.cpp
  clang-tidy/ClangTidy.h
  clang-tidy/google/GlobalNamesInHeadersCheck.cpp
  clang-tidy/google/GlobalNamesInHeadersCheck.h
  clang-tidy/google/UnnamedNamespaceInHeaderCheck.cpp
  clang-tidy/google/UnnamedNamespaceInHeaderCheck.h
  clang-tidy/misc/DefinitionsInHeadersCheck.cpp
  clang-tidy/misc/DefinitionsInHeadersCheck.h
  clang-tidy/utils/CMakeLists.txt
  clang-tidy/utils/HeaderFileExtensionsUtils.cpp
  clang-tidy/utils/HeaderFileExtensionsUtils.h

Index: clang-tidy/utils/HeaderFileExtensionsUtils.h
===
--- /dev/null
+++ clang-tidy/utils/HeaderFileExtensionsUtils.h
@@ -0,0 +1,51 @@
+//===--- HeaderFileExtensionsUtils.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_UTILS_HEADER_FILE_EXTENSIONS_UTILS_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_UTILS_HEADER_FILE_EXTENSIONS_UTILS_H
+
+#include 
+
+#include "clang/Basic/SourceLocation.h"
+#include "clang/Basic/SourceManager.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/ADT/SmallSet.h"
+#include "llvm/Support/Path.h"
+
+namespace clang {
+namespace tidy {
+namespace utils {
+
+typedef llvm::SmallSet HeaderFileExtensionsSet;
+
+/// \brief Checks whether expansion location of Loc is in header file.
+bool isExpansionLocInHeaderFile(
+SourceLocation Loc, const SourceManager &SM,
+const HeaderFileExtensionsSet &HeaderFileExtensions);
+
+/// \brief Checks whether presumed location of Loc is in header file.
+bool isPresumedLocInHeaderFile(
+SourceLocation Loc, SourceManager &SM,
+const HeaderFileExtensionsSet &HeaderFileExtensions);
+
+/// \brief Checks whether spelling location of Loc is in header file.
+bool isSpellingLocInHeaderFile(
+SourceLocation Loc, SourceManager &SM,
+const HeaderFileExtensionsSet &HeaderFileExtensions);
+
+/// \brief Parses header file extensions from a semicolon-separated list.
+bool parseHeaderFileExtensions(llvm::StringRef AllHeaderFileExtensions,
+   HeaderFileExtensionsSet &HeaderFileExtensions,
+   char delimiter);
+
+} // namespace utils
+} // namespace tidy
+} // namespace clang
+
+#endif // LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_UTILS_HEADER_FILE_EXTENSIONS_UTILS_H
Index: clang-tidy/utils/HeaderFileExtensionsUtils.cpp
===
--- /dev/null
+++ clang-tidy/utils/HeaderFileExtensionsUtils.cpp
@@ -0,0 +1,65 @@
+//===--- HeaderFileExtensionsUtils.cpp - clang-tidy--*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "HeaderFileExtensionsUtils.h"
+#include "clang/Basic/CharInfo.h"
+
+namespace clang {
+namespace tidy {
+namespace utils {
+
+bool isExpansionLocInHeaderFile(
+SourceLocation Loc, const SourceManager &SM,
+const HeaderFileExtensionsSet &HeaderFileExtensions) {
+  SourceLocation ExpansionLoc = SM.getExpansionLoc(Loc);
+  StringRef FileExtension =
+  llvm::sys::path::extension(SM.getFilename(ExpansionLoc));
+  return HeaderFileExtensions.count(FileExtension.substr(1)) > 0;
+}
+
+bool isPresumedLocInHeaderFile(
+SourceLocation Loc, SourceManager &SM,
+const HeaderFileExtensionsSet &HeaderFileExtensions) {
+  PresumedLoc PresumedLocation = SM.getPresumedLoc(Loc);
+  StringRef FileExtension =
+  llvm::sys::path::extension(PresumedLocation.getFilename());
+  return HeaderFileExtensions.count(FileExtension.substr(1)) > 0;
+}
+
+bool isSpellingLocInHeaderFile(
+SourceLocation Loc, SourceManager &SM,
+const HeaderFileExtensionsSet &HeaderFileExtensions) {
+  SourceLocation SpellingLoc = SM.getSpellingLoc(Loc);
+  StringRef FileExtension =
+  llvm::sys::path::extension(SM.getFilename(SpellingLoc));
+
+  return HeaderFileExtensions.count(FileExtension.substr(1)) > 0;
+}
+
+bool parseHeaderFileExtensions(llvm::StringRef AllHeaderFileExtensions,
+   HeaderFileExtensionsSet &HeaderFileExtensions,
+   char delimiter) {
+  SmallVector Suffixes;
+  AllHeaderFileExtensions.split(Suffixes, delimiter);
+  HeaderFileExtensions.clear();
+  for (llvm::StringRef Suffix : Suffixes) {
+llvm::StringRef Extension = Suffix.trim();
+for (llvm::StringRef::const_iterator it = Extension.begin();
+ it != Extension.end(); ++it) {
+  if 

Re: [PATCH] D16113: [clang-tdiy] Add header file extension configuration support.

[Haojian Wu via cfe-commits]

hokein marked 3 inline comments as done.


Comment at: clang-tidy/utils/HeaderFileExtensionsUtils.cpp:51
@@ +50,3 @@
+  HeaderFileExtensions.clear();
+  for (llvm::StringRef Suffix : Suffixes) {
+llvm::StringRef Extension = Suffix.trim();

Thanks for the explanation.
Now I add `delimiter` parameter to this function to allow developers to set 
specified character.
 


Comment at: clang-tidy/utils/HeaderFileExtensionsUtils.h:34
@@ +33,3 @@
+bool isPresumedLocInHeaderFile(
+SourceLocation Loc, SourceManager &SM,
+const HeaderFileExtensionsSet &HeaderFileExtensions);

It is used in `UnnamedNamespaceInHeaderCheck`.


http://reviews.llvm.org/D16113



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

Re: [PATCH] D16700: [Clang-tidy] Make null pointer literals for fixes configurable for two checks

[Aaron Ballman via cfe-commits]

aaron.ballman added inline comments.


Comment at: clang-tidy/readability/ImplicitBoolCastCheck.h:32
@@ -30,1 +31,3 @@
+Options.get("NullPointerLiteral",
+Context->getLangOpts().CPlusPlus11 ? "nullptr" : "0")) {}
   void registerMatchers(ast_matchers::MatchFinder *Finder) override;

Eugene.Zelenko wrote:
> LegalizeAdulthood wrote:
> > aaron.ballman wrote:
> > > I know you are following the pattern used in the code here, but I think 
> > > this class needs a storeOptions() function as well. See 
> > > AssertSideEffectCheck as an example.
> > This will need rebasing on the existing code, which is using "NULL" as the 
> > pre-C++11 fallback default, not "0".
> This was in original code. I just didn't want to change default.
If the code is using NULL as the pre-C++11 fallback, don't we also need an 
include for stddef.h/cstddef?


Comment at: clang-tidy/readability/ImplicitBoolCastCheck.h:36-38
@@ -32,1 +35,5 @@
 
+  StringRef getNullPointerLiteral() const {
+return NullPointerLiteral;
+  }
+

LegalizeAdulthood wrote:
> I don't understand why the checks need a public getter for the nullptr 
> literal being used.
Agreed, good catch.


Repository:
  rL LLVM

http://reviews.llvm.org/D16700



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

Re: [PATCH] D16882: [clang-tidy] More friendly warning in "google-runtime-references" when meeting an unnamed function parameter.

[Alexander Kornienko via cfe-commits]

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

Looks good. Thank you!


Repository:
  rL LLVM

http://reviews.llvm.org/D16882



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

Re: [PATCH] D16882: [clang-tidy] More friendly warning in "google-runtime-references" when meeting an unnamed function parameter.

[Haojian Wu via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL259787: [clang-tidy] More friendly warning in 
"google-runtime-references" when… (authored by hokein).

Changed prior to commit:
  http://reviews.llvm.org/D16882?vs=46902&id=46906#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D16882

Files:
  clang-tools-extra/trunk/clang-tidy/google/NonConstReferences.cpp
  clang-tools-extra/trunk/test/clang-tidy/google-runtime-references.cpp

Index: clang-tools-extra/trunk/clang-tidy/google/NonConstReferences.cpp
===
--- clang-tools-extra/trunk/clang-tidy/google/NonConstReferences.cpp
+++ clang-tools-extra/trunk/clang-tidy/google/NonConstReferences.cpp
@@ -108,9 +108,16 @@
   if (StringRef(ReferencedType.getAsString()).endswith("stream"))
 return;
 
-  diag(Parameter->getLocation(),
-   "non-const reference parameter '%0', make it const or use a pointer")
-  << Parameter->getName();
+  if (Parameter->getName().empty()) {
+diag(Parameter->getLocation(),
+ "non-const reference parameter at index %0, "
+ "make it const or use a pointer")
+<< Parameter->getFunctionScopeIndex();
+  } else {
+diag(Parameter->getLocation(),
+ "non-const reference parameter '%0', make it const or use a pointer")
+<< Parameter->getName();
+  }
 }
 
 } // namespace runtime
Index: clang-tools-extra/trunk/test/clang-tidy/google-runtime-references.cpp
===
--- clang-tools-extra/trunk/test/clang-tidy/google-runtime-references.cpp
+++ clang-tools-extra/trunk/test/clang-tidy/google-runtime-references.cpp
@@ -40,7 +40,7 @@
 void g4(int &a, int &b, int &);
 // CHECK-MESSAGES: [[@LINE-1]]:14: warning: non-const reference parameter 'a', 
{{.*}}
 // CHECK-MESSAGES: [[@LINE-2]]:22: warning: non-const reference parameter 'b', 
{{.*}}
-// CHECK-MESSAGES: [[@LINE-3]]:30: warning: non-const reference parameter '', 
{{.*}}
+// CHECK-MESSAGES: [[@LINE-3]]:30: warning: non-const reference parameter at 
index 2, {{.*}}
 
 class B {
   B(B& a) {}
@@ -60,7 +60,7 @@
 
 // Don't warn on the first parameter of stream inserters.
 A& operator<<(A& s, int&) { return s; }
-// CHECK-MESSAGES: [[@LINE-1]]:25: warning: non-const reference parameter '', 
{{.*}}
+// CHECK-MESSAGES: [[@LINE-1]]:25: warning: non-const reference parameter at 
index 1, {{.*}}
 
 // Don't warn on either parameter of stream extractors. Both need to be
 // non-const references by convention.


Index: clang-tools-extra/trunk/clang-tidy/google/NonConstReferences.cpp
===
--- clang-tools-extra/trunk/clang-tidy/google/NonConstReferences.cpp
+++ clang-tools-extra/trunk/clang-tidy/google/NonConstReferences.cpp
@@ -108,9 +108,16 @@
   if (StringRef(ReferencedType.getAsString()).endswith("stream"))
 return;
 
-  diag(Parameter->getLocation(),
-   "non-const reference parameter '%0', make it const or use a pointer")
-  << Parameter->getName();
+  if (Parameter->getName().empty()) {
+diag(Parameter->getLocation(),
+ "non-const reference parameter at index %0, "
+ "make it const or use a pointer")
+<< Parameter->getFunctionScopeIndex();
+  } else {
+diag(Parameter->getLocation(),
+ "non-const reference parameter '%0', make it const or use a pointer")
+<< Parameter->getName();
+  }
 }
 
 } // namespace runtime
Index: clang-tools-extra/trunk/test/clang-tidy/google-runtime-references.cpp
===
--- clang-tools-extra/trunk/test/clang-tidy/google-runtime-references.cpp
+++ clang-tools-extra/trunk/test/clang-tidy/google-runtime-references.cpp
@@ -40,7 +40,7 @@
 void g4(int &a, int &b, int &);
 // CHECK-MESSAGES: [[@LINE-1]]:14: warning: non-const reference parameter 'a', {{.*}}
 // CHECK-MESSAGES: [[@LINE-2]]:22: warning: non-const reference parameter 'b', {{.*}}
-// CHECK-MESSAGES: [[@LINE-3]]:30: warning: non-const reference parameter '', {{.*}}
+// CHECK-MESSAGES: [[@LINE-3]]:30: warning: non-const reference parameter at index 2, {{.*}}
 
 class B {
   B(B& a) {}
@@ -60,7 +60,7 @@
 
 // Don't warn on the first parameter of stream inserters.
 A& operator<<(A& s, int&) { return s; }
-// CHECK-MESSAGES: [[@LINE-1]]:25: warning: non-const reference parameter '', {{.*}}
+// CHECK-MESSAGES: [[@LINE-1]]:25: warning: non-const reference parameter at index 1, {{.*}}
 
 // Don't warn on either parameter of stream extractors. Both need to be
 // non-const references by convention.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] r259787 - [clang-tidy] More friendly warning in "google-runtime-references" when meeting an unnamed function parameter.

[Haojian Wu via cfe-commits]

Author: hokein
Date: Thu Feb  4 08:06:49 2016
New Revision: 259787

URL: http://llvm.org/viewvc/llvm-project?rev=259787&view=rev
Log:
[clang-tidy] More friendly warning in "google-runtime-references" when meeting 
an unnamed function parameter.

Reviewers: alexfh

Subscribers: cfe-commits

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

Modified:
clang-tools-extra/trunk/clang-tidy/google/NonConstReferences.cpp
clang-tools-extra/trunk/test/clang-tidy/google-runtime-references.cpp

Modified: clang-tools-extra/trunk/clang-tidy/google/NonConstReferences.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/google/NonConstReferences.cpp?rev=259787&r1=259786&r2=259787&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/google/NonConstReferences.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/google/NonConstReferences.cpp Thu Feb  4 
08:06:49 2016
@@ -108,9 +108,16 @@ void NonConstReferences::check(const Mat
   if (StringRef(ReferencedType.getAsString()).endswith("stream"))
 return;
 
-  diag(Parameter->getLocation(),
-   "non-const reference parameter '%0', make it const or use a pointer")
-  << Parameter->getName();
+  if (Parameter->getName().empty()) {
+diag(Parameter->getLocation(),
+ "non-const reference parameter at index %0, "
+ "make it const or use a pointer")
+<< Parameter->getFunctionScopeIndex();
+  } else {
+diag(Parameter->getLocation(),
+ "non-const reference parameter '%0', make it const or use a pointer")
+<< Parameter->getName();
+  }
 }
 
 } // namespace runtime

Modified: clang-tools-extra/trunk/test/clang-tidy/google-runtime-references.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/google-runtime-references.cpp?rev=259787&r1=259786&r2=259787&view=diff
==
--- clang-tools-extra/trunk/test/clang-tidy/google-runtime-references.cpp 
(original)
+++ clang-tools-extra/trunk/test/clang-tidy/google-runtime-references.cpp Thu 
Feb  4 08:06:49 2016
@@ -40,7 +40,7 @@ void g3(ref a);
 void g4(int &a, int &b, int &);
 // CHECK-MESSAGES: [[@LINE-1]]:14: warning: non-const reference parameter 'a', 
{{.*}}
 // CHECK-MESSAGES: [[@LINE-2]]:22: warning: non-const reference parameter 'b', 
{{.*}}
-// CHECK-MESSAGES: [[@LINE-3]]:30: warning: non-const reference parameter '', 
{{.*}}
+// CHECK-MESSAGES: [[@LINE-3]]:30: warning: non-const reference parameter at 
index 2, {{.*}}
 
 class B {
   B(B& a) {}
@@ -60,7 +60,7 @@ void B::g(int &b) {}
 
 // Don't warn on the first parameter of stream inserters.
 A& operator<<(A& s, int&) { return s; }
-// CHECK-MESSAGES: [[@LINE-1]]:25: warning: non-const reference parameter '', 
{{.*}}
+// CHECK-MESSAGES: [[@LINE-1]]:25: warning: non-const reference parameter at 
index 1, {{.*}}
 
 // Don't warn on either parameter of stream extractors. Both need to be
 // non-const references by convention.


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

Re: [PATCH] D16692: [OpenCL] Eliminate warning when declaring OpenCL builtin functions

[Yaxun Liu via cfe-commits]

yaxunl added a comment.

Thanks Xiuli.

It seems the review was not closed automatically due to missing Differential 
Revision:  at the end of commit message. Next time I will add the url to 
the review summary.


http://reviews.llvm.org/D16692



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

Re: [PATCH] D16846: PR26449: Fixes for bugs in __builtin_classify_type implementation

[Andrey Bokhanko via cfe-commits]

andreybokhanko updated this revision to Diff 46908.
andreybokhanko added a comment.

John, thank you for the review!

I refactored EvaluateBuiltinClassifyType according to your comments; please 
re-review.

Yours,
Andrey


http://reviews.llvm.org/D16846

Files:
  lib/AST/ExprConstant.cpp
  test/Sema/builtin-classify-type.c
  test/SemaCXX/builtin-classify-type.cpp

Index: lib/AST/ExprConstant.cpp
===
--- lib/AST/ExprConstant.cpp
+++ lib/AST/ExprConstant.cpp
@@ -6185,7 +6185,8 @@
 
 /// EvaluateBuiltinClassifyType - Evaluate __builtin_classify_type the same way
 /// as GCC.
-static int EvaluateBuiltinClassifyType(const CallExpr *E) {
+static int EvaluateBuiltinClassifyType(const CallExpr *E,
+   const LangOptions &LangOpts) {
   // The following enum mimics the values returned by GCC.
   // FIXME: Does GCC differ between lvalue and rvalue references here?
   enum gcc_type_class {
@@ -6205,37 +6206,88 @@
   if (E->getNumArgs() == 0)
 return no_type_class;
 
-  QualType ArgTy = E->getArg(0)->getType();
-  if (ArgTy->isVoidType())
-return void_type_class;
-  else if (ArgTy->isEnumeralType())
-return enumeral_type_class;
-  else if (ArgTy->isBooleanType())
-return boolean_type_class;
-  else if (ArgTy->isCharType())
-return string_type_class; // gcc doesn't appear to use char_type_class
-  else if (ArgTy->isIntegerType())
-return integer_type_class;
-  else if (ArgTy->isPointerType())
+  QualType CanTy = E->getArg(0)->getType().getCanonicalType();
+  const BuiltinType *BT = dyn_cast(CanTy);
+
+  switch (CanTy->getTypeClass()) {
+  case Type::Builtin:
+switch (BT->getKind()) {
+case BuiltinType::Void:
+  return void_type_class;
+
+case BuiltinType::Bool:
+  return boolean_type_class;
+
+case BuiltinType::Char_S: // gcc doesn't appear to use char_type_class
+case BuiltinType::Char_U:
+case BuiltinType::SChar:
+case BuiltinType::UChar:
+case BuiltinType::UShort:
+case BuiltinType::Short:
+case BuiltinType::Half:
+case BuiltinType::Int:
+case BuiltinType::UInt:
+case BuiltinType::Long:
+case BuiltinType::ULong:
+case BuiltinType::LongLong:
+case BuiltinType::ULongLong:
+case BuiltinType::Int128:
+case BuiltinType::UInt128:
+  return integer_type_class;
+
+case BuiltinType::NullPtr:
+  return pointer_type_class;
+
+case BuiltinType::Float:
+case BuiltinType::Double:
+case BuiltinType::LongDouble:
+  return real_type_class;
+
+default:
+  break;
+};
+
+  case Type::Enum:
+return LangOpts.CPlusPlus ? enumeral_type_class : integer_type_class;
+break;
+
+  case Type::Pointer:
 return pointer_type_class;
-  else if (ArgTy->isReferenceType())
-return reference_type_class;
-  else if (ArgTy->isRealType())
-return real_type_class;
-  else if (ArgTy->isComplexType())
+break;
+
+  case Type::MemberPointer:
+if (CanTy->isMemberDataPointerType())
+  return offset_type_class;
+else if (CanTy->isMemberFunctionPointerType())
+  return method_type_class;
+break;
+
+  case Type::Complex:
 return complex_type_class;
-  else if (ArgTy->isFunctionType())
-return function_type_class;
-  else if (ArgTy->isStructureOrClassType())
-return record_type_class;
-  else if (ArgTy->isUnionType())
-return union_type_class;
-  else if (ArgTy->isArrayType())
-return array_type_class;
-  else if (ArgTy->isUnionType())
-return union_type_class;
-  else  // FIXME: offset_type_class, method_type_class, & lang_type_class?
-llvm_unreachable("CallExpr::isBuiltinClassifyType(): unimplemented type");
+
+  case Type::FunctionNoProto:
+  case Type::FunctionProto:
+return LangOpts.CPlusPlus ? function_type_class : pointer_type_class;
+
+  case Type::Record:
+if (CanTy->isStructureOrClassType())
+  return record_type_class;
+else if (CanTy->isUnionType())
+  return union_type_class;
+break;
+
+  case Type::ConstantArray:
+  case Type::VariableArray:
+  case Type::IncompleteArray:
+  case Type::DependentSizedArray:
+return LangOpts.CPlusPlus ? array_type_class : pointer_type_class;
+
+  default:
+break;
+  }
+
+  // FIXME: string_type_class & lang_type_class?
+  llvm_unreachable("CallExpr::isBuiltinClassifyType(): unimplemented type");
 }
 
 /// EvaluateBuiltinConstantPForLValue - Determine the result of
@@ -6607,7 +6659,7 @@
   }
 
   case Builtin::BI__builtin_classify_type:
-return Success(EvaluateBuiltinClassifyType(E), E);
+return Success(EvaluateBuiltinClassifyType(E, Info.getLangOpts()), E);
 
   // FIXME: BI__builtin_clrsb
   // FIXME: BI__builtin_clrsbl
Index: test/SemaCXX/builtin-classify-type.cpp
===
--- test/SemaCXX/builtin-classify-type.cpp
+++ test/SemaCXX/builtin-classify-type.cpp
@@ -0,0 +1,54 @@
+// RUN: %clang_cc1 -fsyntax-only -verif

Re: [PATCH] D16113: [clang-tdiy] Add header file extension configuration support.

[Alexander Kornienko via cfe-commits]

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

Looks good with a couple of comments. Thanks for working on this!



Comment at: clang-tidy/utils/HeaderFileExtensionsUtils.cpp:45
@@ +44,3 @@
+
+bool parseHeaderFileExtensions(llvm::StringRef AllHeaderFileExtensions,
+   HeaderFileExtensionsSet &HeaderFileExtensions,

No need for llvm:: here.


Comment at: clang-tidy/utils/HeaderFileExtensionsUtils.cpp:46
@@ +45,3 @@
+bool parseHeaderFileExtensions(llvm::StringRef AllHeaderFileExtensions,
+   HeaderFileExtensionsSet &HeaderFileExtensions,
+   char delimiter) {

Actually, this could be changed to a more generic `parseStringSetOption` or 
something similar. Let's do this in a follow up.

But for now we need to change the output parameter type to 
llvm::SmallSetImpl to avoid hardcoding the small size template 
argument. The typedef is then not useful anymore.


Comment at: clang-tidy/utils/HeaderFileExtensionsUtils.h:34
@@ +33,3 @@
+bool isPresumedLocInHeaderFile(
+SourceLocation Loc, SourceManager &SM,
+const HeaderFileExtensionsSet &HeaderFileExtensions);

hokein wrote:
> It is used in `UnnamedNamespaceInHeaderCheck`.
Ah, missed this somehow. Then it's fine. I'm not sure though, whether 
PresumedLocation is the right thing in that check, but we can figure this out 
later.


http://reviews.llvm.org/D16113



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

Re: [PATCH] D16113: [clang-tdiy] Add header file extension configuration support.

[Alexander Kornienko via cfe-commits]

alexfh added inline comments.


Comment at: clang-tidy/misc/DefinitionsInHeadersCheck.cpp:40
@@ +39,3 @@
+',')) {
+// FIXME(hokein): Find a more suitable way to handle invalid configuration
+// options.

It's common to use just `FIXME:`, without the reference to the author.


http://reviews.llvm.org/D16113



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

Re: [PATCH] D16700: [Clang-tidy] Make null pointer literals for fixes configurable for two checks

[Alexander Kornienko via cfe-commits]

alexfh added a comment.

Please include full context to the diffs. See 
http://llvm.org/docs/Phabricator.html for instructions.


Repository:
  rL LLVM

http://reviews.llvm.org/D16700



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

Re: [PATCH] D16517: ClangTidy check to flag uninitialized builtin and pointer fields.

[Felix Berger via cfe-commits]

flx added a comment.

Hi Alex,

could you take a look at the questions I posted in my last comment. Maybe there 
is some renaming work I can tackle while you review the change in more detail.


http://reviews.llvm.org/D16517



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

Re: [PATCH] D16113: [clang-tdiy] Add header file extension configuration support.

[Haojian Wu via cfe-commits]

hokein added inline comments.


Comment at: clang-tidy/utils/HeaderFileExtensionsUtils.cpp:46
@@ +45,3 @@
+bool parseHeaderFileExtensions(llvm::StringRef AllHeaderFileExtensions,
+   HeaderFileExtensionsSet &HeaderFileExtensions,
+   char delimiter) {

alexfh wrote:
> Actually, this could be changed to a more generic `parseStringSetOption` or 
> something similar. Let's do this in a follow up.
> 
> But for now we need to change the output parameter type to 
> llvm::SmallSetImpl to avoid hardcoding the small size template 
> argument. The typedef is then not useful anymore.
> But for now we need to change the output parameter type to 
> llvm::SmallSetImpl to avoid hardcoding the small size template 
> argument. The typedef is then not useful anymore.

I can't find `llvm::SmallSetImpl` or any similar `Set` without size template 
argument.


http://reviews.llvm.org/D16113



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

Re: [PATCH] D16351: [FIX] Bug 25404 - Crash on typedef in OpenCL 2.0

[Anastasia Stulova via cfe-commits]

Anastasia added inline comments.


Comment at: test/SemaOpenCL/implicit-typedef.cl:3
@@ +2,3 @@
+// RUN: %clang_cc1 %s -cl-std=CL2.0 -fsyntax-only
+
+#if defined(TEST_WARNINGS)

ichesnokov wrote:
> Are you mean another text of warning? Notice that actual patch will work not 
> only in OpenCL, but any language. If builtin functions present, it will 
> prevent the crash. The single message "redefinition of typedef 'atomic_flag' 
> is a C11 feature" is default for all targets.
> Do you want to have specific warning text for OpenCL?
No, you can use select{OpenCL|C11} or you can pass 'OpenCL' or 'C11' as a 
string to the diagnostic as an argument.

You can take a look at err_opencl_unknown_type_specifier as an example, that 
uses both approaches.

LangOpts.OpenCL will help you to detect the language mode for selecting/passing 
the right string.



http://reviews.llvm.org/D16351



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

Re: [PATCH] D16113: [clang-tdiy] Add header file extension configuration support.

[Alexander Kornienko via cfe-commits]

alexfh added inline comments.


Comment at: clang-tidy/utils/HeaderFileExtensionsUtils.cpp:46
@@ +45,3 @@
+bool parseHeaderFileExtensions(llvm::StringRef AllHeaderFileExtensions,
+   HeaderFileExtensionsSet &HeaderFileExtensions,
+   char delimiter) {

hokein wrote:
> alexfh wrote:
> > Actually, this could be changed to a more generic `parseStringSetOption` or 
> > something similar. Let's do this in a follow up.
> > 
> > But for now we need to change the output parameter type to 
> > llvm::SmallSetImpl to avoid hardcoding the small size template 
> > argument. The typedef is then not useful anymore.
> > But for now we need to change the output parameter type to 
> > llvm::SmallSetImpl to avoid hardcoding the small size template 
> > argument. The typedef is then not useful anymore.
> 
> I can't find `llvm::SmallSetImpl` or any similar `Set` without size template 
> argument.
Hm, indeed SmallSet has no base class unlike SmallVector, for example. Ok, then 
seems good for now.


http://reviews.llvm.org/D16113



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

Re: [PATCH] D16351: [FIX] Bug 25404 - Crash on typedef in OpenCL 2.0

[Igor Chesnokov via cfe-commits]

ichesnokov added inline comments.


Comment at: test/SemaOpenCL/implicit-typedef.cl:3
@@ +2,3 @@
+// RUN: %clang_cc1 %s -cl-std=CL2.0 -fsyntax-only
+
+#if defined(TEST_WARNINGS)

Anastasia wrote:
> ichesnokov wrote:
> > Are you mean another text of warning? Notice that actual patch will work 
> > not only in OpenCL, but any language. If builtin functions present, it will 
> > prevent the crash. The single message "redefinition of typedef 
> > 'atomic_flag' is a C11 feature" is default for all targets.
> > Do you want to have specific warning text for OpenCL?
> No, you can use select{OpenCL|C11} or you can pass 'OpenCL' or 'C11' as a 
> string to the diagnostic as an argument.
> 
> You can take a look at err_opencl_unknown_type_specifier as an example, that 
> uses both approaches.
> 
> LangOpts.OpenCL will help you to detect the language mode for 
> selecting/passing the right string.
> 
I can't find anything like select{} in my local copy (there's LLVM and Clang).
I also can't find err_opencl_unknown_type_specifier, such file is not presernt 
in my WC (updated today).

> LangOpts.OpenCL will help you to detect the language mode for 
> selecting/passing the right string.
Currently it checks both Microsoft and Itanium manglers on all platforms, with 
one test case.
I am not sure how to use LangOpts.OpenCL... We are making .cl test suite and 
C++ classes will be unavailble here.

Excuse me, could you please explain more?


http://reviews.llvm.org/D16351



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

Re: [PATCH] D16113: [clang-tdiy] Add header file extension configuration support.

[Haojian Wu via cfe-commits]

hokein updated this revision to Diff 46923.
hokein added a comment.

Update.


http://reviews.llvm.org/D16113

Files:
  clang-tidy/ClangTidy.cpp
  clang-tidy/ClangTidy.h
  clang-tidy/google/GlobalNamesInHeadersCheck.cpp
  clang-tidy/google/GlobalNamesInHeadersCheck.h
  clang-tidy/google/UnnamedNamespaceInHeaderCheck.cpp
  clang-tidy/google/UnnamedNamespaceInHeaderCheck.h
  clang-tidy/misc/DefinitionsInHeadersCheck.cpp
  clang-tidy/misc/DefinitionsInHeadersCheck.h
  clang-tidy/utils/CMakeLists.txt
  clang-tidy/utils/HeaderFileExtensionsUtils.cpp
  clang-tidy/utils/HeaderFileExtensionsUtils.h

Index: clang-tidy/utils/HeaderFileExtensionsUtils.h
===
--- /dev/null
+++ clang-tidy/utils/HeaderFileExtensionsUtils.h
@@ -0,0 +1,51 @@
+//===--- HeaderFileExtensionsUtils.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_UTILS_HEADER_FILE_EXTENSIONS_UTILS_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_UTILS_HEADER_FILE_EXTENSIONS_UTILS_H
+
+#include 
+
+#include "clang/Basic/SourceLocation.h"
+#include "clang/Basic/SourceManager.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/ADT/SmallSet.h"
+#include "llvm/Support/Path.h"
+
+namespace clang {
+namespace tidy {
+namespace utils {
+
+typedef llvm::SmallSet HeaderFileExtensionsSet;
+
+/// \brief Checks whether expansion location of Loc is in header file.
+bool isExpansionLocInHeaderFile(
+SourceLocation Loc, const SourceManager &SM,
+const HeaderFileExtensionsSet &HeaderFileExtensions);
+
+/// \brief Checks whether presumed location of Loc is in header file.
+bool isPresumedLocInHeaderFile(
+SourceLocation Loc, SourceManager &SM,
+const HeaderFileExtensionsSet &HeaderFileExtensions);
+
+/// \brief Checks whether spelling location of Loc is in header file.
+bool isSpellingLocInHeaderFile(
+SourceLocation Loc, SourceManager &SM,
+const HeaderFileExtensionsSet &HeaderFileExtensions);
+
+/// \brief Parses header file extensions from a semicolon-separated list.
+bool parseHeaderFileExtensions(StringRef AllHeaderFileExtensions,
+   HeaderFileExtensionsSet &HeaderFileExtensions,
+   char delimiter);
+
+} // namespace utils
+} // namespace tidy
+} // namespace clang
+
+#endif // LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_UTILS_HEADER_FILE_EXTENSIONS_UTILS_H
Index: clang-tidy/utils/HeaderFileExtensionsUtils.cpp
===
--- /dev/null
+++ clang-tidy/utils/HeaderFileExtensionsUtils.cpp
@@ -0,0 +1,65 @@
+//===--- HeaderFileExtensionsUtils.cpp - clang-tidy--*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "HeaderFileExtensionsUtils.h"
+#include "clang/Basic/CharInfo.h"
+
+namespace clang {
+namespace tidy {
+namespace utils {
+
+bool isExpansionLocInHeaderFile(
+SourceLocation Loc, const SourceManager &SM,
+const HeaderFileExtensionsSet &HeaderFileExtensions) {
+  SourceLocation ExpansionLoc = SM.getExpansionLoc(Loc);
+  StringRef FileExtension =
+  llvm::sys::path::extension(SM.getFilename(ExpansionLoc));
+  return HeaderFileExtensions.count(FileExtension.substr(1)) > 0;
+}
+
+bool isPresumedLocInHeaderFile(
+SourceLocation Loc, SourceManager &SM,
+const HeaderFileExtensionsSet &HeaderFileExtensions) {
+  PresumedLoc PresumedLocation = SM.getPresumedLoc(Loc);
+  StringRef FileExtension =
+  llvm::sys::path::extension(PresumedLocation.getFilename());
+  return HeaderFileExtensions.count(FileExtension.substr(1)) > 0;
+}
+
+bool isSpellingLocInHeaderFile(
+SourceLocation Loc, SourceManager &SM,
+const HeaderFileExtensionsSet &HeaderFileExtensions) {
+  SourceLocation SpellingLoc = SM.getSpellingLoc(Loc);
+  StringRef FileExtension =
+  llvm::sys::path::extension(SM.getFilename(SpellingLoc));
+
+  return HeaderFileExtensions.count(FileExtension.substr(1)) > 0;
+}
+
+bool parseHeaderFileExtensions(StringRef AllHeaderFileExtensions,
+   HeaderFileExtensionsSet &HeaderFileExtensions,
+   char delimiter) {
+  SmallVector Suffixes;
+  AllHeaderFileExtensions.split(Suffixes, delimiter);
+  HeaderFileExtensions.clear();
+  for (StringRef Suffix : Suffixes) {
+StringRef Extension = Suffix.trim();
+for (StringRef::const_iterator it = Extension.begin();
+ it != Extension.end(); ++it) {
+  if (!isAlphanumeric(*it))
+return false;
+

Re: [PATCH] D16113: [clang-tdiy] Add header file extension configuration support.

[Haojian Wu via cfe-commits]

hokein marked 2 inline comments as done.
hokein added a comment.

http://reviews.llvm.org/D16113



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

Re: [PATCH] D16873: Refactor MemRegionManager::getVarRegion to call two new functions, improving readability

[Aleksei Sidorin via cfe-commits]

a.sidorin added a subscriber: a.sidorin.
a.sidorin added a comment.

Thanks ariccio! Some inline comments are below.



Comment at: 
llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h:1186
@@ +1185,3 @@
+  ///  associated with a specified globally stored, non-static local, VarDecl.
+  const MemRegion *getMemRegionGloballyStored(const VarDecl *D);
+

How about make these helper functions return `const MemSpaceRegion *` to make 
their signatures more meaningful?


Comment at: llvm/tools/clang/lib/StaticAnalyzer/Core/MemRegion.cpp:769
@@ -768,4 +768,3 @@
 
-const VarRegion* MemRegionManager::getVarRegion(const VarDecl *D,
-const LocationContext *LC) {
-  const MemRegion *sReg = nullptr;
+const MemRegion* MemRegionManager::getMemRegionGloballyStored(const VarDecl 
*D) {
+  assert(D->hasGlobalStorage());

`get[Global/StaticLocal]MemSpaceForVariable`?


Comment at: llvm/tools/clang/lib/StaticAnalyzer/Core/MemRegion.cpp:843
@@ +842,3 @@
+const LocationContext *LC) {
+  const MemRegion *sReg = nullptr;
+

`const MemSpaceRegion *StorageSpace?`


http://reviews.llvm.org/D16873



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

Re: [PATCH] D16808: [MCU] PR26438: Fix assertion failure on function returning an empty struct or union

[Denis Zobnin via cfe-commits]

d.zobnin.bugzilla added a comment.

Thank you for the review!

David, I started from the assertion failure and was going up the call stack 
trying to understand what should be changed to make the assertion go away. In 
shouldReturnTypeInRegister() function there is isRegisterSize(Size) check for 
i386, which returns false for 0-sized types, so I naively assumed that for MCU 
we missed the 0-case check. I must have read the ABI more carefully...

While searching for a correct solution for this, I saw that 'void' return type 
is handled in classifyReturnType() by returning ABIArgInfo::getIgnore(). 
According to the comments:

  /// Ignore - Ignore the argument (treat as void). Useful for void and
  /// empty structs.
  Ignore,

Does it mean that we can treat empty structs and unions in return type as void 
in this case?


http://reviews.llvm.org/D16808



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

Re: [PATCH] D16808: [MCU] PR26438: Fix assertion failure on function returning an empty struct or union

[David Kreitzer via cfe-commits]

DavidKreitzer added a comment.

From an MCU ABI perspective, yes, returning an empty struct is equivalent to 
returning void.


http://reviews.llvm.org/D16808



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

Re: r259183 - Add target triple to CodeGenOpenCL/pipe_types.cl test case

[Ulrich Weigand via cfe-commits]

Hans,

would it be OK to backport this test case fix to the 3.8 branch?
This is currently the only failing test on the branch for SystemZ.

Thanks!

>Author: uweigand
>Date: Fri Jan 29 04:45:23 2016
>New Revision: 259183
>
>URL: http://llvm.org/viewvc/llvm-project?rev=259183&view=rev
>Log:
>Add target triple to CodeGenOpenCL/pipe_types.cl test case
>
>The test is failing on SystemZ since different IR is being
>generated due to platform ABI differences.  Add a target triple.
>
>Fix suggested by Anastasia Stulova.
>
>
>Modified:
>cfe/trunk/test/CodeGenOpenCL/pipe_types.cl


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand | Phone: +49-7031/16-3727
  STSM, GNU/Linux compilers and toolchain
  IBM Deutschland Research & Development GmbH
  Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk
Wittkopp
  Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r259183 - Add target triple to CodeGenOpenCL/pipe_types.cl test case

[Hans Wennborg via cfe-commits]

Sure, r259808.

Thanks,
Hans

On Thu, Feb 4, 2016 at 10:13 AM, Ulrich Weigand
 wrote:
> Hans,
>
> would it be OK to backport this test case fix to the 3.8 branch?
> This is currently the only failing test on the branch for SystemZ.
>
> Thanks!
>
>>Author: uweigand
>>Date: Fri Jan 29 04:45:23 2016
>>New Revision: 259183
>>
>>URL: http://llvm.org/viewvc/llvm-project?rev=259183&view=rev
>>Log:
>>Add target triple to CodeGenOpenCL/pipe_types.cl test case
>>
>>The test is failing on SystemZ since different IR is being
>>generated due to platform ABI differences.  Add a target triple.
>>
>>Fix suggested by Anastasia Stulova.
>>
>>
>>Modified:
>>cfe/trunk/test/CodeGenOpenCL/pipe_types.cl
>
>
> Mit freundlichen Gruessen / Best Regards
>
> Ulrich Weigand
>
> --
> Dr. Ulrich Weigand | Phone: +49-7031/16-3727
> STSM, GNU/Linux compilers and toolchain
> IBM Deutschland Research & Development GmbH
> Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk
> Wittkopp
> Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart,
> HRB 243294
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D16808: [MCU] PR26438: Fix assertion failure on function returning an empty struct or union

[H.J Lu via cfe-commits]

hjl.tools added a comment.

Empty struct/union should be passed and returned as void for all IA psABs.


http://reviews.llvm.org/D16808



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

Re: [PATCH] D16870: [CUDA] Tweak attribute-based overload resolution to match nvcc behavior.

[Artem Belevich via cfe-commits]

tra updated this revision to Diff 46927.
tra marked an inline comment as done.
tra added a comment.

Addressed Jingyue's comments.
Fixed function-overload.cu tests to reflect stricter call target checks.


http://reviews.llvm.org/D16870

Files:
  include/clang/Sema/Sema.h
  lib/Sema/SemaCUDA.cpp
  lib/Sema/SemaOverload.cpp
  test/CodeGenCUDA/function-overload.cu
  test/SemaCUDA/function-overload.cu

Index: test/SemaCUDA/function-overload.cu
===
--- test/SemaCUDA/function-overload.cu
+++ test/SemaCUDA/function-overload.cu
@@ -70,27 +70,23 @@
 
 __host__ void hostf(void) {
   fp_t dp = d;
-  fp_t cdp = cd;
-#if !defined(NOCHECKS)
-  // expected-error@-3 {{reference to __device__ function 'd' in __host__ function}}
+  // expected-error@-1 {{reference to __device__ function 'd' in __host__ function}}
   // expected-note@65 {{'d' declared here}}
-  // expected-error@-4 {{reference to __device__ function 'cd' in __host__ function}}
+  fp_t cdp = cd;
+  // expected-error@-1 {{reference to __device__ function 'cd' in __host__ function}}
   // expected-note@68 {{'cd' declared here}}
-#endif
   fp_t hp = h;
   fp_t chp = ch;
   fp_t dhp = dh;
   fp_t cdhp = cdh;
   gp_t gp = g;
 
   d();
-  cd();
-#if !defined(NOCHECKS)
-  // expected-error@-3 {{no matching function for call to 'd'}}
+  // expected-error@-1 {{no matching function for call to 'd'}}
   // expected-note@65 {{candidate function not viable: call to __device__ function from __host__ function}}
-  // expected-error@-4 {{no matching function for call to 'cd'}}
+  cd();
+  // expected-error@-1 {{no matching function for call to 'cd'}}
   // expected-note@68 {{candidate function not viable: call to __device__ function from __host__ function}}
-#endif
   h();
   ch();
   dh();
@@ -104,28 +100,22 @@
   fp_t dp = d;
   fp_t cdp = cd;
   fp_t hp = h;
-  fp_t chp = ch;
-#if !defined(NOCHECKS)
-  // expected-error@-3 {{reference to __host__ function 'h' in __device__ function}}
+  // expected-error@-1 {{reference to __host__ function 'h' in __device__ function}}
   // expected-note@66 {{'h' declared here}}
-  // expected-error@-4 {{reference to __host__ function 'ch' in __device__ function}}
+  fp_t chp = ch;
+  // expected-error@-1 {{reference to __host__ function 'ch' in __device__ function}}
   // expected-note@69 {{'ch' declared here}}
-#endif
   fp_t dhp = dh;
   fp_t cdhp = cdh;
   gp_t gp = g; // expected-error {{reference to __global__ function 'g' in __device__ function}}
// expected-note@67 {{'g' declared here}}
 
   d();
   cd();
-  h();
-  ch();
-#if !defined(NOCHECKS)
-  // expected-error@-3 {{no matching function for call to 'h'}}
+  h(); // expected-error {{no matching function for call to 'h'}}
   // expected-note@66 {{candidate function not viable: call to __host__ function from __device__ function}}
-  // expected-error@-4 {{no matching function for call to 'ch'}}
+  ch(); // expected-error {{no matching function for call to 'ch'}}
   // expected-note@69 {{candidate function not viable: call to __host__ function from __device__ function}}
-#endif
   dh();
   cdh();
   g(); // expected-error {{no matching function for call to 'g'}}
@@ -138,28 +128,25 @@
   fp_t dp = d;
   fp_t cdp = cd;
   fp_t hp = h;
-  fp_t chp = ch;
-#if !defined(NOCHECKS)
-  // expected-error@-3 {{reference to __host__ function 'h' in __global__ function}}
+  // expected-error@-1 {{reference to __host__ function 'h' in __global__ function}}
   // expected-note@66 {{'h' declared here}}
-  // expected-error@-4 {{reference to __host__ function 'ch' in __global__ function}}
+  fp_t chp = ch;
+  // expected-error@-1 {{reference to __host__ function 'ch' in __global__ function}}
   // expected-note@69 {{'ch' declared here}}
-#endif
   fp_t dhp = dh;
   fp_t cdhp = cdh;
-  gp_t gp = g; // expected-error {{reference to __global__ function 'g' in __global__ function}}
-   // expected-note@67 {{'g' declared here}}
+  gp_t gp = g; 
+  // expected-error@-1 {{reference to __global__ function 'g' in __global__ function}}
+  // expected-note@67 {{'g' declared here}}
 
   d();
   cd();
   h();
-  ch();
-#if !defined(NOCHECKS)
-  // expected-error@-3 {{no matching function for call to 'h'}}
+  // expected-error@-1 {{no matching function for call to 'h'}}
   // expected-note@66 {{candidate function not viable: call to __host__ function from __global__ function}}
-  // expected-error@-4 {{no matching function for call to 'ch'}}
+  ch();
+  // expected-error@-1 {{no matching function for call to 'ch'}}
   // expected-note@69 {{candidate function not viable: call to __host__ function from __global__ function}}
-#endif
   dh();
   cdh();
   g(); // expected-error {{no matching function for call to 'g'}}
Index: test/CodeGenCUDA/function-overload.cu
===
--- test/CodeGenCUDA/function-overload.cu
+++ test/CodeGenCUDA/function-overload.cu
@@ -77,24 +

Re: [PATCH] D16870: [CUDA] Tweak attribute-based overload resolution to match nvcc behavior.

[Artem Belevich via cfe-commits]

tra marked an inline comment as done.


Comment at: lib/Sema/SemaCUDA.cpp:132-141
@@ -131,12 +131,12 @@
   // (d) HostDevice behavior depends on compilation mode.
   if (CallerTarget == CFT_HostDevice) {
 // Calling a function that matches compilation mode is OK.
 // Calling a function from the other side is frowned upon.
 if (getLangOpts().CUDAIsDevice)
-  return CalleeTarget == CFT_Device ? CFP_Fallback : QuestionableResult;
+  return CalleeTarget == CFT_Device ? CFP_SameSide : QuestionableResult;
 else
   return (CalleeTarget == CFT_Host || CalleeTarget == CFT_Global)
- ? CFP_Fallback
+ ? CFP_SameSide
  : QuestionableResult;
   }
 

jingyue wrote:
> Maybe a clearer way is to replace QuestionableResult with CFP_WrongSide in 
> this if block, and after this if block say
> 
> ```
> if (DisabletargetCallChecks && CFP_WrongSide)
>   return CFP_Never;
> ```
I've rearranged the code to make it easier to follow. I hope.


Comment at: lib/Sema/SemaOverload.cpp:8544
@@ +8543,3 @@
+S.IdentifyCUDAPreference(Caller, Cand2.Function);
+if (((CFP1 == Sema::CFP_SameSide || CFP1 == Sema::CFP_Native) &&
+ (CFP2 <= Sema::CFP_WrongSide)) ||

jingyue wrote:
> Why can't we just return `CFP1>CFP2`? What's a counter example for that? 
You can look at it this way -- if both callees are viable during compilation 
(i.e. we can generate code for both)  we want to use C++ overload resolution 
rules to pick best one (and can't return here). If one is viable and another is 
not, then the viable one always wins and that's what the check is for.

See template_vs_hd_function() in the test for example when we should not return 
here.


http://reviews.llvm.org/D16870



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

Re: [PATCH] D16846: PR26449: Fixes for bugs in __builtin_classify_type implementation

[John McCall via cfe-commits]

rjmccall added a comment.

Thank you, that's a lot better.  Just a few suggestions to promote exhaustive 
checking.



Comment at: lib/AST/ExprConstant.cpp:6246
@@ +6245,3 @@
+
+default:
+  break;

Again, try to avoid adding default cases.  There's an x-macro file for 
BuiltinTypes, too.


Comment at: lib/AST/ExprConstant.cpp:6262
@@ +6261,3 @@
+else if (CanTy->isMemberFunctionPointerType())
+  return method_type_class;
+break;

Please turn the else-if into an else with an assert.


Comment at: lib/AST/ExprConstant.cpp:6277
@@ +6276,3 @@
+  return union_type_class;
+break;
+

You can switch over the tag kind here.


Comment at: lib/AST/ExprConstant.cpp:6285
@@ +6284,3 @@
+
+  default:
+break;

Instead of having a default case, you should use an x-macro to exhaustively 
fill in all the cases that you're assuming can't happen.  That way, if somebody 
adds a new canonical type kind, they'll automatically get a warning here if 
they don't add it.

In this case, since you're working with a canonical type and it can't be 
dependent, this would look like:

  #define TYPE(ID, BASE)
  #define NON_CANONICAL_TYPE(ID, BASE) case Type::ID:
  #define NON_CANONICAL_UNLESS_DEPENDENT_TYPE(ID, BASE) case Type::ID:
  #define DEPENDENT_TYPE(ID, BASE) case Type::ID:
  #include "clang/AST/TypeNodes.def"


http://reviews.llvm.org/D16846



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

r259811 - [PGO] cc1 option name change for profile instrumentation

[Rong Xu via cfe-commits]

Author: xur
Date: Thu Feb  4 12:39:09 2016
New Revision: 259811

URL: http://llvm.org/viewvc/llvm-project?rev=259811&view=rev
Log:
[PGO] cc1 option name change for profile instrumentation

This patch changes cc1 option -fprofile-instr-generate to an enum option
-fprofile-instrument={clang|none}. It also changes cc1 options
-fprofile-instr-generate= to -fprofile-instrument-path=.
The driver level option -fprofile-instr-generate and -fprofile-instr-generate=
remain intact. This change will pave the way to integrate new PGO
instrumentation in IR level.

Review: http://reviews.llvm.org/D16730

Modified:
cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
cfe/trunk/include/clang/Driver/CC1Options.td
cfe/trunk/include/clang/Driver/Options.td
cfe/trunk/include/clang/Frontend/CodeGenOptions.def
cfe/trunk/include/clang/Frontend/CodeGenOptions.h
cfe/trunk/lib/CodeGen/BackendUtil.cpp
cfe/trunk/lib/CodeGen/CGStmt.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.h
cfe/trunk/lib/CodeGen/CodeGenPGO.cpp
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/test/CoverageMapping/block-storage-starts-region.m
cfe/trunk/test/CoverageMapping/break.c
cfe/trunk/test/CoverageMapping/builtinmacro.c
cfe/trunk/test/CoverageMapping/casts.c
cfe/trunk/test/CoverageMapping/classtemplate.cpp
cfe/trunk/test/CoverageMapping/comment-in-macro.c
cfe/trunk/test/CoverageMapping/continue.c
cfe/trunk/test/CoverageMapping/control-flow-macro.c
cfe/trunk/test/CoverageMapping/decl.c
cfe/trunk/test/CoverageMapping/header.cpp
cfe/trunk/test/CoverageMapping/if.c
cfe/trunk/test/CoverageMapping/implicit-def-in-macro.m
cfe/trunk/test/CoverageMapping/includehell.cpp
cfe/trunk/test/CoverageMapping/ir.c
cfe/trunk/test/CoverageMapping/label.cpp
cfe/trunk/test/CoverageMapping/lambda.cpp
cfe/trunk/test/CoverageMapping/logical.cpp
cfe/trunk/test/CoverageMapping/loopmacro.c
cfe/trunk/test/CoverageMapping/loops.cpp
cfe/trunk/test/CoverageMapping/macro-expansion.c
cfe/trunk/test/CoverageMapping/macro-expressions.cpp
cfe/trunk/test/CoverageMapping/macroception.c
cfe/trunk/test/CoverageMapping/macroparams.c
cfe/trunk/test/CoverageMapping/macroparams2.c
cfe/trunk/test/CoverageMapping/macros.c
cfe/trunk/test/CoverageMapping/macroscopes.cpp
cfe/trunk/test/CoverageMapping/md.cpp
cfe/trunk/test/CoverageMapping/moremacros.c
cfe/trunk/test/CoverageMapping/nestedclass.cpp
cfe/trunk/test/CoverageMapping/objc.m
cfe/trunk/test/CoverageMapping/preprocessor.c
cfe/trunk/test/CoverageMapping/return.c
cfe/trunk/test/CoverageMapping/switch.c
cfe/trunk/test/CoverageMapping/switchmacro.c
cfe/trunk/test/CoverageMapping/system_macro.c
cfe/trunk/test/CoverageMapping/templates.cpp
cfe/trunk/test/CoverageMapping/test.c
cfe/trunk/test/CoverageMapping/trycatch.cpp
cfe/trunk/test/CoverageMapping/trymacro.cpp
cfe/trunk/test/CoverageMapping/unreachable-macro.c
cfe/trunk/test/CoverageMapping/unused_names.c
cfe/trunk/test/CoverageMapping/while.c
cfe/trunk/test/Driver/clang_f_opts.c
cfe/trunk/test/Profile/c-captured.c
cfe/trunk/test/Profile/c-general.c
cfe/trunk/test/Profile/c-generate.c
cfe/trunk/test/Profile/c-indirect-call.c
cfe/trunk/test/Profile/c-linkage-available_externally.c
cfe/trunk/test/Profile/c-linkage.c
cfe/trunk/test/Profile/c-unreachable-after-switch.c
cfe/trunk/test/Profile/cxx-implicit.cpp
cfe/trunk/test/Profile/cxx-lambda.cpp
cfe/trunk/test/Profile/cxx-linkage.cpp
cfe/trunk/test/Profile/cxx-rangefor.cpp
cfe/trunk/test/Profile/cxx-structors.cpp
cfe/trunk/test/Profile/cxx-templates.cpp
cfe/trunk/test/Profile/cxx-virtual-destructor-calls.cpp
cfe/trunk/test/Profile/objc-general.m

Modified: cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td?rev=259811&r1=259810&r2=259811&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td Thu Feb  4 12:39:09 
2016
@@ -27,6 +27,8 @@ def err_drv_invalid_thread_model_for_tar
   "invalid thread model '%0' in '%1' for this target">;
 def err_drv_invalid_linker_name : Error<
   "invalid linker name in argument '%0'">;
+def err_drv_invalid_pgo_instrumentor: Error<
+  "invalid PGO instrumentor in argument '%0'">;
 def err_drv_invalid_rtlib_name : Error<
   "invalid runtime library name in argument '%0'">;
 def err_drv_unsupported_rtlib_for_platform : Error<

Modified: cfe/trunk/include/clang/Driver/CC1Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/CC1Options.td?rev=259811&r1=259810&r2=259811&view=diff
===

Re: [PATCH] D16876: [OpenCL] Refine pipe builtin support

[Yaxun Liu via cfe-commits]

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

LGTM



Comment at: lib/Sema/SemaChecking.cpp:343
@@ -332,3 +342,3 @@
   // Two kinds of read/write pipe
   // From OpenCL C Specification 6.13.16.2 the built-in read/write
   // functions have following forms.

should this follow the convention? e.g.
OpenCL v2.0 s6.13.16.2 - 


http://reviews.llvm.org/D16876



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

Re: [PATCH] D16351: [FIX] Bug 25404 - Crash on typedef in OpenCL 2.0

[Anastasia Stulova via cfe-commits]

Anastasia added inline comments.


Comment at: test/SemaOpenCL/implicit-typedef.cl:3
@@ +2,3 @@
+// RUN: %clang_cc1 %s -cl-std=CL2.0 -fsyntax-only
+
+#if defined(TEST_WARNINGS)

ichesnokov wrote:
> Anastasia wrote:
> > ichesnokov wrote:
> > > Are you mean another text of warning? Notice that actual patch will work 
> > > not only in OpenCL, but any language. If builtin functions present, it 
> > > will prevent the crash. The single message "redefinition of typedef 
> > > 'atomic_flag' is a C11 feature" is default for all targets.
> > > Do you want to have specific warning text for OpenCL?
> > No, you can use select{OpenCL|C11} or you can pass 'OpenCL' or 'C11' as a 
> > string to the diagnostic as an argument.
> > 
> > You can take a look at err_opencl_unknown_type_specifier as an example, 
> > that uses both approaches.
> > 
> > LangOpts.OpenCL will help you to detect the language mode for 
> > selecting/passing the right string.
> > 
> I can't find anything like select{} in my local copy (there's LLVM and Clang).
> I also can't find err_opencl_unknown_type_specifier, such file is not 
> presernt in my WC (updated today).
> 
> > LangOpts.OpenCL will help you to detect the language mode for 
> > selecting/passing the right string.
> Currently it checks both Microsoft and Itanium manglers on all platforms, 
> with one test case.
> I am not sure how to use LangOpts.OpenCL... We are making .cl test suite and 
> C++ classes will be unavailble here.
> 
> Excuse me, could you please explain more?
Example of select is in include/clang/Basic/DiagnosticSemaKinds.td line 7707 at 
revision 259811.
  def err_opencl_unknown_type_specifier : Error<
"OpenCL does not support the '%0' %select{type qualifier|storage class 
specifier}1">;


Regarding the OpenCL check you can call getLangOpts().OpenCL to check if you 
compile for OpenCL (see examples in lib/Sema/SemaDecl.cpp).
You can do something like:
  bool IsOpenCL  = getLangOpts().OpenCL ? 1: 0;  
  Diag(New->getLocation(), diag::ext_redefinition_of_typedef)
  << New->getDeclName() << IsOpenCL;




http://reviews.llvm.org/D16351



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

Re: [PATCH] D16870: [CUDA] Tweak attribute-based overload resolution to match nvcc behavior.

[Justin Lebar via cfe-commits]

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

Looks sane to me.  Just some suggestions on the comments.



Comment at: lib/Sema/SemaCUDA.cpp:71
@@ -70,3 +70,3 @@
 // H  - handled in (x)
-// Preferences: b-best, f-fallback, l-last resort, n-never.
+// Preferences: +:native, *:host-device, o:same side, .:wrong side, -:never.
 //

If we're going to use symbols rather than letters, could we use 4, 3, 2, 1, 0?  
I think that would be easier to follow.


Comment at: lib/Sema/SemaCUDA.cpp:127
@@ -132,9 +126,3 @@
   if (CallerTarget == CFT_HostDevice) {
-// Calling a function that matches compilation mode is OK.
-// Calling a function from the other side is frowned upon.
-if (getLangOpts().CUDAIsDevice)
-  return CalleeTarget == CFT_Device ? CFP_Fallback : QuestionableResult;
-else
-  return (CalleeTarget == CFT_Host || CalleeTarget == CFT_Global)
- ? CFP_Fallback
- : QuestionableResult;
+// It's OK to call mode-matching function from HD one.
+if ((getLangOpts().CUDAIsDevice && CalleeTarget == CFT_Device) ||

Nit: "It's OK to call a mode-matching function from an HD function."


Comment at: lib/Sema/SemaOverload.cpp:8536
@@ +8535,3 @@
+  // compatible with existing code that relies on this. If we see such
+  // a case, return better variant right away.
+  if (S.getLangOpts().CUDA && S.getLangOpts().CUDATargetOverloads &&

Since we have language lawyers on the team, suggest adding articles to comment:

If an HD function calls a function which has host-only and device-only 
overloads, nvcc sees only the host-side function during host compilation and 
only the device function during device-side compilation.  (This appears to be a 
side-effect of its splitting of host and device code into separate TUs.)  Alas 
we need to be compatible with existing code that relies on this, so if we see 
such a case, return the better variant right away.

I actually might suggest rephrasing this a bit more, to something like:

When performing host-side compilation, nvcc doesn't see device functions, and 
similarly when performing device-side compilation, nvcc doesn't see host 
functions.  (This is a consequence of the fact that it splits host and device 
code into separate TUs.)  We see all functions in both compilation modes, so to 
match nvcc's behavior, we need to exclude some overload candidates from 
consideration based only on their host/device attributes.  Specifically, if one 
candidate call is WrongSide and the other is Native or SameSide, we ignore the 
WrongSide candidate.  If we don't return early here, we'll consider the CUDA 
target attributes again later in this function, as a tiebreaker between calls 
with otherwise identical priority according to the regular C++ overloading 
rules.


Comment at: test/CodeGenCUDA/function-overload.cu:96
@@ +95,3 @@
+
+// In this case during host compilation we expect to cal function
+// template even if __device__ function may be available and allowed

call


http://reviews.llvm.org/D16870



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

Re: [PATCH] D15450: Avoid double deletion in Clang driver.

[Serge Pavlov via cfe-commits]

Any feedback?

Thanks,
--Serge

2016-02-02 3:31 GMT+06:00 Serge Pavlov :

> sepavloff updated this revision to Diff 46575.
> sepavloff added a comment.
>
> Added regression test.
>
>
> http://reviews.llvm.org/D15450
>
> Files:
>   lib/CodeGen/CodeGenAction.cpp
>   unittests/Frontend/CMakeLists.txt
>   unittests/Frontend/CodeGenActionTest.cpp
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D15450: Avoid double deletion in Clang driver.

[Serge Pavlov via cfe-commits]

sepavloff added a comment.

Any feedback?

Thanks,
--Serge


http://reviews.llvm.org/D15450



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

Re: [PATCH] D15881: [DWARF] Omitting the explicit import of an anonymous namespace is a debugger-tuning decision, not a target decision.

[Paul Robinson via cfe-commits]

probinson added a comment.

Ping #4.


http://reviews.llvm.org/D15881



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

Re: [PATCH] D16784: [OpenMP] Reorganize code to allow specialized code generation for different devices.

[Samuel Antao via cfe-commits]

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

Create CGOpenMPRuntimeNVPTX header file and mike specialization selection in 
CodeGenModule.


http://reviews.llvm.org/D16784

Files:
  include/clang/Basic/DiagnosticDriverKinds.td
  lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
  lib/CodeGen/CGOpenMPRuntimeNVPTX.h
  lib/CodeGen/CMakeLists.txt
  lib/CodeGen/CodeGenModule.cpp
  lib/Frontend/CompilerInvocation.cpp
  test/OpenMP/target_messages.cpp

Index: test/OpenMP/target_messages.cpp
===
--- test/OpenMP/target_messages.cpp
+++ test/OpenMP/target_messages.cpp
@@ -1,6 +1,9 @@
 // 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'
+// RUN: not %clang_cc1 -fopenmp -std=c++11 -triple nvptx64-nvidia-cuda -o - %s 2>&1 | FileCheck --check-prefix CHECK-UNSUPPORTED-HOST-TARGET %s
+// RUN: not %clang_cc1 -fopenmp -std=c++11 -triple nvptx-nvidia-cuda -o - %s 2>&1 | FileCheck --check-prefix CHECK-UNSUPPORTED-HOST-TARGET %s
+// CHECK-UNSUPPORTED-HOST-TARGET: error: The target '{{nvptx64-nvidia-cuda|nvptx-nvidia-cuda}}' is not a supported OpenMP host target.
 
 void foo() {
 }
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -1427,6 +1427,7 @@
 }
 
 static void ParseLangArgs(LangOptions &Opts, ArgList &Args, InputKind IK,
+  const TargetOptions &TargetOpts,
   DiagnosticsEngine &Diags) {
   // FIXME: Cleanup per-file based stuff.
   LangStandard::Kind LangStd = LangStandard::lang_unspecified;
@@ -1822,6 +1823,22 @@
   Opts.OpenMPIsDevice =
   Opts.OpenMP && Args.hasArg(options::OPT_fopenmp_is_device);
 
+  // Provide diagnostic when a given target is not expected to be an OpenMP
+  // device or host.
+  if (Opts.OpenMP && !Opts.OpenMPIsDevice) {
+llvm::Triple T(TargetOpts.Triple);
+switch (T.getArch()) {
+default:
+  break;
+// Add unsupported host targets here:
+case llvm::Triple::nvptx:
+case llvm::Triple::nvptx64:
+  Diags.Report(clang::diag::err_drv_omp_host_or_device_target_not_supported)
+  << TargetOpts.Triple << Opts.OpenMPIsDevice;
+  break;
+}
+  }
+
   // Get the OpenMP target triples if any.
   if (Arg *A = Args.getLastArg(options::OPT_omptargets_EQ)) {
 
@@ -2088,7 +2105,7 @@
 Diags, Res.getLangOpts()->Sanitize);
   } else {
 // Other LangOpts are only initialzed when the input is not AST or LLVM IR.
-ParseLangArgs(*Res.getLangOpts(), Args, DashX, Diags);
+ParseLangArgs(*Res.getLangOpts(), Args, DashX, Res.getTargetOpts(), Diags);
 if (Res.getFrontendOpts().ProgramAction == frontend::RewriteObjC)
   Res.getLangOpts()->ObjCExceptions = 1;
   }
Index: lib/CodeGen/CodeGenModule.cpp
===
--- lib/CodeGen/CodeGenModule.cpp
+++ lib/CodeGen/CodeGenModule.cpp
@@ -20,6 +20,7 @@
 #include "CGObjCRuntime.h"
 #include "CGOpenCLRuntime.h"
 #include "CGOpenMPRuntime.h"
+#include "CGOpenMPRuntimeNVPTX.h"
 #include "CodeGenFunction.h"
 #include "CodeGenPGO.h"
 #include "CodeGenTBAA.h"
@@ -200,7 +201,21 @@
 }
 
 void CodeGenModule::createOpenMPRuntime() {
-  OpenMPRuntime = new CGOpenMPRuntime(*this);
+  // Select a specialized code generation class based on the target, if any.
+  // If it does not exist use the default implementation.
+  switch (getTarget().getTriple().getArch()) {
+
+  case llvm::Triple::nvptx:
+  case llvm::Triple::nvptx64:
+assert(getLangOpts().OpenMPIsDevice &&
+   "OpenMP NVPTX is only prepared to deal with device code.");
+OpenMPRuntime = new CGOpenMPRuntimeNVPTX(*this);
+break;
+  default:
+OpenMPRuntime = new CGOpenMPRuntime(*this);
+break;
+  }
+  return;
 }
 
 void CodeGenModule::createCUDARuntime() {
Index: lib/CodeGen/CMakeLists.txt
===
--- lib/CodeGen/CMakeLists.txt
+++ lib/CodeGen/CMakeLists.txt
@@ -57,6 +57,7 @@
   CGObjCRuntime.cpp
   CGOpenCLRuntime.cpp
   CGOpenMPRuntime.cpp
+  CGOpenMPRuntimeNVPTX.cpp
   CGRecordLayoutBuilder.cpp
   CGStmt.cpp
   CGStmtOpenMP.cpp
Index: lib/CodeGen/CGOpenMPRuntimeNVPTX.h
===
--- /dev/null
+++ lib/CodeGen/CGOpenMPRuntimeNVPTX.h
@@ -0,0 +1,31 @@
+//===- CGOpenMPRuntimeNVPTX.h - Interface to OpenMP NVPTX Runtimes ===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+//
+// This provides a class for Open

Re: [PATCH] D16784: [OpenMP] Reorganize code to allow specialized code generation for different devices.

[Alexey Bataev via cfe-commits]

ABataev added inline comments.


Comment at: lib/CodeGen/CodeGenModule.cpp:218
@@ -204,1 +217,3 @@
+  }
+  return;
 }

I think this must be removed


Comment at: lib/Frontend/CompilerInvocation.cpp:1837
@@ +1836,3 @@
+  
Diags.Report(clang::diag::err_drv_omp_host_or_device_target_not_supported)
+  << TargetOpts.Triple << Opts.OpenMPIsDevice;
+  break;

OpenMPIsDevice is always false here. Do we really need it here?


http://reviews.llvm.org/D16784



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

Re: [PATCH] D16784: [OpenMP] Reorganize code to allow specialized code generation for different devices.

[Samuel Antao via cfe-commits]

sfantao updated this revision to Diff 46937.
sfantao marked 2 inline comments as done.
sfantao added a comment.

Remove return statement and use 'false' instead of relying on OpenMPIsDevice.


http://reviews.llvm.org/D16784

Files:
  include/clang/Basic/DiagnosticDriverKinds.td
  lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
  lib/CodeGen/CGOpenMPRuntimeNVPTX.h
  lib/CodeGen/CMakeLists.txt
  lib/CodeGen/CodeGenModule.cpp
  lib/Frontend/CompilerInvocation.cpp
  test/OpenMP/target_messages.cpp

Index: test/OpenMP/target_messages.cpp
===
--- test/OpenMP/target_messages.cpp
+++ test/OpenMP/target_messages.cpp
@@ -1,6 +1,9 @@
 // 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'
+// RUN: not %clang_cc1 -fopenmp -std=c++11 -triple nvptx64-nvidia-cuda -o - %s 2>&1 | FileCheck --check-prefix CHECK-UNSUPPORTED-HOST-TARGET %s
+// RUN: not %clang_cc1 -fopenmp -std=c++11 -triple nvptx-nvidia-cuda -o - %s 2>&1 | FileCheck --check-prefix CHECK-UNSUPPORTED-HOST-TARGET %s
+// CHECK-UNSUPPORTED-HOST-TARGET: error: The target '{{nvptx64-nvidia-cuda|nvptx-nvidia-cuda}}' is not a supported OpenMP host target.
 
 void foo() {
 }
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -1427,6 +1427,7 @@
 }
 
 static void ParseLangArgs(LangOptions &Opts, ArgList &Args, InputKind IK,
+  const TargetOptions &TargetOpts,
   DiagnosticsEngine &Diags) {
   // FIXME: Cleanup per-file based stuff.
   LangStandard::Kind LangStd = LangStandard::lang_unspecified;
@@ -1822,6 +1823,22 @@
   Opts.OpenMPIsDevice =
   Opts.OpenMP && Args.hasArg(options::OPT_fopenmp_is_device);
 
+  // Provide diagnostic when a given target is not expected to be an OpenMP
+  // device or host.
+  if (Opts.OpenMP && !Opts.OpenMPIsDevice) {
+llvm::Triple T(TargetOpts.Triple);
+switch (T.getArch()) {
+default:
+  break;
+// Add unsupported host targets here:
+case llvm::Triple::nvptx:
+case llvm::Triple::nvptx64:
+  Diags.Report(clang::diag::err_drv_omp_host_or_device_target_not_supported)
+  << TargetOpts.Triple << false;
+  break;
+}
+  }
+
   // Get the OpenMP target triples if any.
   if (Arg *A = Args.getLastArg(options::OPT_omptargets_EQ)) {
 
@@ -2088,7 +2105,7 @@
 Diags, Res.getLangOpts()->Sanitize);
   } else {
 // Other LangOpts are only initialzed when the input is not AST or LLVM IR.
-ParseLangArgs(*Res.getLangOpts(), Args, DashX, Diags);
+ParseLangArgs(*Res.getLangOpts(), Args, DashX, Res.getTargetOpts(), Diags);
 if (Res.getFrontendOpts().ProgramAction == frontend::RewriteObjC)
   Res.getLangOpts()->ObjCExceptions = 1;
   }
Index: lib/CodeGen/CodeGenModule.cpp
===
--- lib/CodeGen/CodeGenModule.cpp
+++ lib/CodeGen/CodeGenModule.cpp
@@ -20,6 +20,7 @@
 #include "CGObjCRuntime.h"
 #include "CGOpenCLRuntime.h"
 #include "CGOpenMPRuntime.h"
+#include "CGOpenMPRuntimeNVPTX.h"
 #include "CodeGenFunction.h"
 #include "CodeGenPGO.h"
 #include "CodeGenTBAA.h"
@@ -200,7 +201,20 @@
 }
 
 void CodeGenModule::createOpenMPRuntime() {
-  OpenMPRuntime = new CGOpenMPRuntime(*this);
+  // Select a specialized code generation class based on the target, if any.
+  // If it does not exist use the default implementation.
+  switch (getTarget().getTriple().getArch()) {
+
+  case llvm::Triple::nvptx:
+  case llvm::Triple::nvptx64:
+assert(getLangOpts().OpenMPIsDevice &&
+   "OpenMP NVPTX is only prepared to deal with device code.");
+OpenMPRuntime = new CGOpenMPRuntimeNVPTX(*this);
+break;
+  default:
+OpenMPRuntime = new CGOpenMPRuntime(*this);
+break;
+  }
 }
 
 void CodeGenModule::createCUDARuntime() {
Index: lib/CodeGen/CMakeLists.txt
===
--- lib/CodeGen/CMakeLists.txt
+++ lib/CodeGen/CMakeLists.txt
@@ -57,6 +57,7 @@
   CGObjCRuntime.cpp
   CGOpenCLRuntime.cpp
   CGOpenMPRuntime.cpp
+  CGOpenMPRuntimeNVPTX.cpp
   CGRecordLayoutBuilder.cpp
   CGStmt.cpp
   CGStmtOpenMP.cpp
Index: lib/CodeGen/CGOpenMPRuntimeNVPTX.h
===
--- /dev/null
+++ lib/CodeGen/CGOpenMPRuntimeNVPTX.h
@@ -0,0 +1,31 @@
+//===- CGOpenMPRuntimeNVPTX.h - Interface to OpenMP NVPTX Runtimes ===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+//
+// This provides a class for Op

Re: [PATCH] D16784: [OpenMP] Reorganize code to allow specialized code generation for different devices.

[Samuel Antao via cfe-commits]

sfantao added inline comments.


Comment at: lib/CodeGen/CodeGenModule.cpp:218
@@ -204,1 +217,3 @@
+  }
+  return;
 }

ABataev wrote:
> I think this must be removed
Ok, done.


Comment at: lib/Frontend/CompilerInvocation.cpp:1837
@@ +1836,3 @@
+  
Diags.Report(clang::diag::err_drv_omp_host_or_device_target_not_supported)
+  << TargetOpts.Triple << Opts.OpenMPIsDevice;
+  break;

ABataev wrote:
> OpenMPIsDevice is always false here. Do we really need it here?
Ok, hardcoded it to false.


http://reviews.llvm.org/D16784



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

Re: [PATCH] D16148: Fix for PR25271: Ensure that variadic template parameter defaults PCH roundtrip

[Richard Smith via cfe-commits]

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

LGTM, thanks!


Repository:
  rL LLVM

http://reviews.llvm.org/D16148



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

Re: [PATCH] D16784: [OpenMP] Reorganize code to allow specialized code generation for different devices.

[Samuel Antao via cfe-commits]

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

Add comment.


http://reviews.llvm.org/D16784

Files:
  include/clang/Basic/DiagnosticDriverKinds.td
  lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
  lib/CodeGen/CGOpenMPRuntimeNVPTX.h
  lib/CodeGen/CMakeLists.txt
  lib/CodeGen/CodeGenModule.cpp
  lib/Frontend/CompilerInvocation.cpp
  test/OpenMP/target_messages.cpp

Index: test/OpenMP/target_messages.cpp
===
--- test/OpenMP/target_messages.cpp
+++ test/OpenMP/target_messages.cpp
@@ -1,6 +1,9 @@
 // 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'
+// RUN: not %clang_cc1 -fopenmp -std=c++11 -triple nvptx64-nvidia-cuda -o - %s 2>&1 | FileCheck --check-prefix CHECK-UNSUPPORTED-HOST-TARGET %s
+// RUN: not %clang_cc1 -fopenmp -std=c++11 -triple nvptx-nvidia-cuda -o - %s 2>&1 | FileCheck --check-prefix CHECK-UNSUPPORTED-HOST-TARGET %s
+// CHECK-UNSUPPORTED-HOST-TARGET: error: The target '{{nvptx64-nvidia-cuda|nvptx-nvidia-cuda}}' is not a supported OpenMP host target.
 
 void foo() {
 }
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -1427,6 +1427,7 @@
 }
 
 static void ParseLangArgs(LangOptions &Opts, ArgList &Args, InputKind IK,
+  const TargetOptions &TargetOpts,
   DiagnosticsEngine &Diags) {
   // FIXME: Cleanup per-file based stuff.
   LangStandard::Kind LangStd = LangStandard::lang_unspecified;
@@ -1822,6 +1823,22 @@
   Opts.OpenMPIsDevice =
   Opts.OpenMP && Args.hasArg(options::OPT_fopenmp_is_device);
 
+  // Provide diagnostic when a given target is not expected to be an OpenMP
+  // device or host.
+  if (Opts.OpenMP && !Opts.OpenMPIsDevice) {
+llvm::Triple T(TargetOpts.Triple);
+switch (T.getArch()) {
+default:
+  break;
+// Add unsupported host targets here:
+case llvm::Triple::nvptx:
+case llvm::Triple::nvptx64:
+  Diags.Report(clang::diag::err_drv_omp_host_or_device_target_not_supported)
+  << TargetOpts.Triple << /*Device=*/false;
+  break;
+}
+  }
+
   // Get the OpenMP target triples if any.
   if (Arg *A = Args.getLastArg(options::OPT_omptargets_EQ)) {
 
@@ -2088,7 +2105,7 @@
 Diags, Res.getLangOpts()->Sanitize);
   } else {
 // Other LangOpts are only initialzed when the input is not AST or LLVM IR.
-ParseLangArgs(*Res.getLangOpts(), Args, DashX, Diags);
+ParseLangArgs(*Res.getLangOpts(), Args, DashX, Res.getTargetOpts(), Diags);
 if (Res.getFrontendOpts().ProgramAction == frontend::RewriteObjC)
   Res.getLangOpts()->ObjCExceptions = 1;
   }
Index: lib/CodeGen/CodeGenModule.cpp
===
--- lib/CodeGen/CodeGenModule.cpp
+++ lib/CodeGen/CodeGenModule.cpp
@@ -20,6 +20,7 @@
 #include "CGObjCRuntime.h"
 #include "CGOpenCLRuntime.h"
 #include "CGOpenMPRuntime.h"
+#include "CGOpenMPRuntimeNVPTX.h"
 #include "CodeGenFunction.h"
 #include "CodeGenPGO.h"
 #include "CodeGenTBAA.h"
@@ -200,7 +201,20 @@
 }
 
 void CodeGenModule::createOpenMPRuntime() {
-  OpenMPRuntime = new CGOpenMPRuntime(*this);
+  // Select a specialized code generation class based on the target, if any.
+  // If it does not exist use the default implementation.
+  switch (getTarget().getTriple().getArch()) {
+
+  case llvm::Triple::nvptx:
+  case llvm::Triple::nvptx64:
+assert(getLangOpts().OpenMPIsDevice &&
+   "OpenMP NVPTX is only prepared to deal with device code.");
+OpenMPRuntime = new CGOpenMPRuntimeNVPTX(*this);
+break;
+  default:
+OpenMPRuntime = new CGOpenMPRuntime(*this);
+break;
+  }
 }
 
 void CodeGenModule::createCUDARuntime() {
Index: lib/CodeGen/CMakeLists.txt
===
--- lib/CodeGen/CMakeLists.txt
+++ lib/CodeGen/CMakeLists.txt
@@ -57,6 +57,7 @@
   CGObjCRuntime.cpp
   CGOpenCLRuntime.cpp
   CGOpenMPRuntime.cpp
+  CGOpenMPRuntimeNVPTX.cpp
   CGRecordLayoutBuilder.cpp
   CGStmt.cpp
   CGStmtOpenMP.cpp
Index: lib/CodeGen/CGOpenMPRuntimeNVPTX.h
===
--- /dev/null
+++ lib/CodeGen/CGOpenMPRuntimeNVPTX.h
@@ -0,0 +1,31 @@
+//===- CGOpenMPRuntimeNVPTX.h - Interface to OpenMP NVPTX Runtimes ===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+//
+// This provides a class for OpenMP runtime code generation specialized to NVPTX
+// targets.
+//
+//===---

r259819 - [PGO] code simplification: use existing VP annotation API /NFC

[Xinliang David Li via cfe-commits]

Author: davidxl
Date: Thu Feb  4 13:54:17 2016
New Revision: 259819

URL: http://llvm.org/viewvc/llvm-project?rev=259819&view=rev
Log:
[PGO] code simplification: use existing VP annotation API /NFC

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

Modified: cfe/trunk/lib/CodeGen/CodeGenPGO.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenPGO.cpp?rev=259819&r1=259818&r2=259819&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenPGO.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenPGO.cpp Thu Feb  4 13:54:17 2016
@@ -780,35 +780,11 @@ void CodeGenPGO::valueProfile(CGBuilderT
 // pairs for each function.
 if (NumValueSites[ValueKind] >= ProfRecord->getNumValueSites(ValueKind))
   return;
-uint32_t NV = ProfRecord->getNumValueDataForSite(ValueKind,
- NumValueSites[ValueKind]);
-std::unique_ptr VD =
-ProfRecord->getValueForSite(ValueKind, NumValueSites[ValueKind]);
 
-uint64_t Sum = 0;
-for (uint32_t I = 0; I < NV; ++I)
-  Sum += VD[I].Count;
+llvm::annotateValueSite(CGM.getModule(), *ValueSite, *ProfRecord,
+(llvm::InstrProfValueKind)ValueKind,
+NumValueSites[ValueKind]);
 
-llvm::LLVMContext &Ctx = CGM.getLLVMContext();
-llvm::MDBuilder MDHelper(Ctx);
-SmallVector Vals;
-Vals.push_back(MDHelper.createString("VP"));
-Vals.push_back(MDHelper.createConstant(
-llvm::ConstantInt::get(llvm::Type::getInt32Ty(Ctx), ValueKind)));
-Vals.push_back(MDHelper.createConstant(
-llvm::ConstantInt::get(llvm::Type::getInt64Ty(Ctx), Sum)));
-
-uint32_t MDCount = 3;
-for (uint32_t I = 0; I < NV; ++I) {
-  Vals.push_back(MDHelper.createConstant(
-  llvm::ConstantInt::get(llvm::Type::getInt64Ty(Ctx), VD[I].Value)));
-  Vals.push_back(MDHelper.createConstant(
-  llvm::ConstantInt::get(llvm::Type::getInt64Ty(Ctx), VD[I].Count)));
-  if (--MDCount == 0)
-break;
-}
-ValueSite->setMetadata(
-llvm::LLVMContext::MD_prof, llvm::MDNode::get(Ctx, Vals));
 NumValueSites[ValueKind]++;
   }
 }


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

Re: [PATCH] D16784: [OpenMP] Reorganize code to allow specialized code generation for different devices.

[Alexey Bataev via cfe-commits]

ABataev added inline comments.


Comment at: lib/Frontend/CompilerInvocation.cpp:1837
@@ +1836,3 @@
+  
Diags.Report(clang::diag::err_drv_omp_host_or_device_target_not_supported)
+  << TargetOpts.Triple << /*Device=*/false;
+  break;

No, I mean do we really need this argument if this is a constant? I think for 
now we should just throw it away and edit error message so that it does not 
expect the second argument,


http://reviews.llvm.org/D16784



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

Re: [PATCH] D16784: [OpenMP] Reorganize code to allow specialized code generation for different devices.

[Samuel Antao via cfe-commits]

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

Change diagnostic for invalid host target.


http://reviews.llvm.org/D16784

Files:
  include/clang/Basic/DiagnosticDriverKinds.td
  lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
  lib/CodeGen/CGOpenMPRuntimeNVPTX.h
  lib/CodeGen/CMakeLists.txt
  lib/CodeGen/CodeGenModule.cpp
  lib/Frontend/CompilerInvocation.cpp
  test/OpenMP/target_messages.cpp

Index: test/OpenMP/target_messages.cpp
===
--- test/OpenMP/target_messages.cpp
+++ test/OpenMP/target_messages.cpp
@@ -1,6 +1,9 @@
 // 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'
+// RUN: not %clang_cc1 -fopenmp -std=c++11 -triple nvptx64-nvidia-cuda -o - %s 2>&1 | FileCheck --check-prefix CHECK-UNSUPPORTED-HOST-TARGET %s
+// RUN: not %clang_cc1 -fopenmp -std=c++11 -triple nvptx-nvidia-cuda -o - %s 2>&1 | FileCheck --check-prefix CHECK-UNSUPPORTED-HOST-TARGET %s
+// CHECK-UNSUPPORTED-HOST-TARGET: error: The target '{{nvptx64-nvidia-cuda|nvptx-nvidia-cuda}}' is not a supported OpenMP host target.
 
 void foo() {
 }
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -1427,6 +1427,7 @@
 }
 
 static void ParseLangArgs(LangOptions &Opts, ArgList &Args, InputKind IK,
+  const TargetOptions &TargetOpts,
   DiagnosticsEngine &Diags) {
   // FIXME: Cleanup per-file based stuff.
   LangStandard::Kind LangStd = LangStandard::lang_unspecified;
@@ -1822,6 +1823,22 @@
   Opts.OpenMPIsDevice =
   Opts.OpenMP && Args.hasArg(options::OPT_fopenmp_is_device);
 
+  // Provide diagnostic when a given target is not expected to be an OpenMP
+  // device or host.
+  if (Opts.OpenMP && !Opts.OpenMPIsDevice) {
+llvm::Triple T(TargetOpts.Triple);
+switch (T.getArch()) {
+default:
+  break;
+// Add unsupported host targets here:
+case llvm::Triple::nvptx:
+case llvm::Triple::nvptx64:
+  Diags.Report(clang::diag::err_drv_omp_host_target_not_supported)
+  << TargetOpts.Triple;
+  break;
+}
+  }
+
   // Get the OpenMP target triples if any.
   if (Arg *A = Args.getLastArg(options::OPT_omptargets_EQ)) {
 
@@ -2088,7 +2105,7 @@
 Diags, Res.getLangOpts()->Sanitize);
   } else {
 // Other LangOpts are only initialzed when the input is not AST or LLVM IR.
-ParseLangArgs(*Res.getLangOpts(), Args, DashX, Diags);
+ParseLangArgs(*Res.getLangOpts(), Args, DashX, Res.getTargetOpts(), Diags);
 if (Res.getFrontendOpts().ProgramAction == frontend::RewriteObjC)
   Res.getLangOpts()->ObjCExceptions = 1;
   }
Index: lib/CodeGen/CodeGenModule.cpp
===
--- lib/CodeGen/CodeGenModule.cpp
+++ lib/CodeGen/CodeGenModule.cpp
@@ -20,6 +20,7 @@
 #include "CGObjCRuntime.h"
 #include "CGOpenCLRuntime.h"
 #include "CGOpenMPRuntime.h"
+#include "CGOpenMPRuntimeNVPTX.h"
 #include "CodeGenFunction.h"
 #include "CodeGenPGO.h"
 #include "CodeGenTBAA.h"
@@ -200,7 +201,20 @@
 }
 
 void CodeGenModule::createOpenMPRuntime() {
-  OpenMPRuntime = new CGOpenMPRuntime(*this);
+  // Select a specialized code generation class based on the target, if any.
+  // If it does not exist use the default implementation.
+  switch (getTarget().getTriple().getArch()) {
+
+  case llvm::Triple::nvptx:
+  case llvm::Triple::nvptx64:
+assert(getLangOpts().OpenMPIsDevice &&
+   "OpenMP NVPTX is only prepared to deal with device code.");
+OpenMPRuntime = new CGOpenMPRuntimeNVPTX(*this);
+break;
+  default:
+OpenMPRuntime = new CGOpenMPRuntime(*this);
+break;
+  }
 }
 
 void CodeGenModule::createCUDARuntime() {
Index: lib/CodeGen/CMakeLists.txt
===
--- lib/CodeGen/CMakeLists.txt
+++ lib/CodeGen/CMakeLists.txt
@@ -57,6 +57,7 @@
   CGObjCRuntime.cpp
   CGOpenCLRuntime.cpp
   CGOpenMPRuntime.cpp
+  CGOpenMPRuntimeNVPTX.cpp
   CGRecordLayoutBuilder.cpp
   CGStmt.cpp
   CGStmtOpenMP.cpp
Index: lib/CodeGen/CGOpenMPRuntimeNVPTX.h
===
--- /dev/null
+++ lib/CodeGen/CGOpenMPRuntimeNVPTX.h
@@ -0,0 +1,31 @@
+//===- CGOpenMPRuntimeNVPTX.h - Interface to OpenMP NVPTX Runtimes ===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+//
+// This provides a class for OpenMP runtime code generation specialized to NVPTX
+// targets.
+//
+//===---

Re: [PATCH] D16784: [OpenMP] Reorganize code to allow specialized code generation for different devices.

[Samuel Antao via cfe-commits]

sfantao marked an inline comment as done.


Comment at: lib/Frontend/CompilerInvocation.cpp:1837
@@ +1836,3 @@
+  Diags.Report(clang::diag::err_drv_omp_host_target_not_supported)
+  << TargetOpts.Triple;
+  break;

Ok, I did as you say. thanks!


http://reviews.llvm.org/D16784



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

r259820 - Fix a crash when there is a typo in the return statement.

[Manman Ren via cfe-commits]

Author: mren
Date: Thu Feb  4 14:05:40 2016
New Revision: 259820

URL: http://llvm.org/viewvc/llvm-project?rev=259820&view=rev
Log:
Fix a crash when there is a typo in the return statement.

If the typo happens after a successful deduction for an earlier
return statement, we should check if the deduced type is null
before using it.

The typo correction happens after we try to deduce the return
type and we ignore the deduction from the typo and continue
to typo correction.

rdar://24342247

Added:
cfe/trunk/test/SemaCXX/typo-correction-crash.cpp
Modified:
cfe/trunk/lib/Sema/SemaStmt.cpp

Modified: cfe/trunk/lib/Sema/SemaStmt.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaStmt.cpp?rev=259820&r1=259819&r2=259820&view=diff
==
--- cfe/trunk/lib/Sema/SemaStmt.cpp (original)
+++ cfe/trunk/lib/Sema/SemaStmt.cpp Thu Feb  4 14:05:40 2016
@@ -3069,6 +3069,11 @@ bool Sema::DeduceFunctionTypeFromReturnE
   QualType DeducedT = AT->getDeducedType();
   if (!DeducedT.isNull() && !FD->isInvalidDecl()) {
 AutoType *NewAT = Deduced->getContainedAutoType();
+// It is possible that NewAT->getDeducedType() is null. When that happens,
+// we should not crash, instead we ignore this deduction.
+if (NewAT->getDeducedType().isNull())
+  return false;
+
 CanQualType OldDeducedType = Context.getCanonicalFunctionResultType(
DeducedT);
 CanQualType NewDeducedType = Context.getCanonicalFunctionResultType(

Added: cfe/trunk/test/SemaCXX/typo-correction-crash.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/typo-correction-crash.cpp?rev=259820&view=auto
==
--- cfe/trunk/test/SemaCXX/typo-correction-crash.cpp (added)
+++ cfe/trunk/test/SemaCXX/typo-correction-crash.cpp Thu Feb  4 14:05:40 2016
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -fsyntax-only -std=c++14 -verify %s
+auto check1() {
+  return 1;
+  return s; // expected-error {{use of undeclared identifier 's'}}
+}
+
+int test = 11; // expected-note {{'test' declared here}}
+auto check2() {
+  return "s";
+  return tes; // expected-error {{use of undeclared identifier 'tes'; did you 
mean 'test'?}}
+}


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

r259822 - Install cmake files to lib/cmake/clang

[Niels Ole Salscheider via cfe-commits]

Author: olesalscheider
Date: Thu Feb  4 14:08:27 2016
New Revision: 259822

URL: http://llvm.org/viewvc/llvm-project?rev=259822&view=rev
Log:
Install cmake files to lib/cmake/clang

This is the right location for platform-specific files.

Also, search for LLVM's CMake files in this directory.

Modified:
cfe/trunk/CMakeLists.txt

Modified: cfe/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/CMakeLists.txt?rev=259822&r1=259821&r2=259822&view=diff
==
--- cfe/trunk/CMakeLists.txt (original)
+++ cfe/trunk/CMakeLists.txt Thu Feb  4 14:08:27 2016
@@ -72,7 +72,7 @@ if( CMAKE_SOURCE_DIR STREQUAL CMAKE_CURR
   find_program(LLVM_TABLEGEN_EXE "llvm-tblgen" ${LLVM_TOOLS_BINARY_DIR}
 NO_DEFAULT_PATH)
 
-  set(LLVM_CMAKE_PATH "${LLVM_BINARY_DIR}/share/llvm/cmake")
+  set(LLVM_CMAKE_PATH "${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/cmake/llvm")
   set(LLVMCONFIG_FILE "${LLVM_CMAKE_PATH}/LLVMConfig.cmake")
   if(EXISTS ${LLVMCONFIG_FILE})
 list(APPEND CMAKE_MODULE_PATH "${LLVM_CMAKE_PATH}")
@@ -594,24 +594,24 @@ if (CLANG_BUILT_STANDALONE OR CMAKE_VERS
   # Generate a list of CMake library targets so that other CMake projects can
   # link against them. LLVM calls its version of this file LLVMExports.cmake, 
but
   # the usual CMake convention seems to be ${Project}Targets.cmake.
-  set(CLANG_INSTALL_PACKAGE_DIR share/clang/cmake)
+  set(CLANG_INSTALL_PACKAGE_DIR lib${LLVM_LIBDIR_SUFFIX}/cmake/clang)
   set(clang_cmake_builddir "${CMAKE_BINARY_DIR}/${CLANG_INSTALL_PACKAGE_DIR}")
   get_property(CLANG_EXPORTS GLOBAL PROPERTY CLANG_EXPORTS)
   export(TARGETS ${CLANG_EXPORTS} FILE 
${clang_cmake_builddir}/ClangTargets.cmake)
 
-  # Install a /share/clang/cmake/ClangConfig.cmake file so that
+  # Install a /lib/cmake/clang/ClangConfig.cmake file so that
   # find_package(Clang) works. Install the target list with it.
   install(EXPORT ClangTargets DESTINATION ${CLANG_INSTALL_PACKAGE_DIR})
 
   install(FILES
 ${CMAKE_CURRENT_SOURCE_DIR}/cmake/modules/ClangConfig.cmake
-DESTINATION share/clang/cmake)
+DESTINATION lib${LLVM_LIBDIR_SUFFIX}/cmake/clang)
 
   # Also copy ClangConfig.cmake to the build directory so that dependent 
projects
   # can build against a build directory of Clang more easily.
   configure_file(
 ${CMAKE_CURRENT_SOURCE_DIR}/cmake/modules/ClangConfig.cmake
-${CLANG_BINARY_DIR}/share/clang/cmake/ClangConfig.cmake
+${CLANG_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/cmake/clang/ClangConfig.cmake
 COPYONLY)
 endif ()
 


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

Re: [PATCH] D15506: [ASTMatchers] Allow hasName() to look through inline namespaces

[Piotr Padlewski via cfe-commits]

Prazek added a subscriber: Prazek.
Prazek added a comment.

What is the status of it?


http://reviews.llvm.org/D15506



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

Re: [PATCH] D16529: [clang-tidy] Add modernize-raw-string-literal check

[Richard via cfe-commits]

LegalizeAdulthood added a comment.

I agree it needs more testing.

I think also my current approach to newlines is overly aggressive and will 
result in more raw string literals than people would prefer.

It's really the Windows style path separators and regex ones that are not 
controversial transformations.


http://reviews.llvm.org/D16529



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

[PATCH] D16896: [CMake] Improve the clang order-file generation workflow

[Chris Bieneman via cfe-commits]

beanz created this revision.
beanz added a reviewer: bogner.
beanz added a subscriber: cfe-commits.

With this change generating clang order files using dtrace uses the following 
workflow:

# Configure LLVM & Clang using any options on a system with dtrace
cmake 

# Builds clang and runs the perf-training data to generate the order file
ninja generate-order-file

# Re-link clang with the new order file
ninja clang

This patch works by setting a default path to the order file (which can be 
overridden by the user). If the order file doesn't exist during configuration 
CMake will create an empty one.

CMake then ties up the dependencies between the clang link job and the order 
file, and generate-order-file overwrites CLANG_ORDER_FILE with the new order 
file.

http://reviews.llvm.org/D16896

Files:
  CMakeLists.txt
  tools/driver/CMakeLists.txt
  utils/perf-training/CMakeLists.txt

Index: utils/perf-training/CMakeLists.txt
===
--- utils/perf-training/CMakeLists.txt
+++ utils/perf-training/CMakeLists.txt
@@ -55,9 +55,8 @@
 COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py 
clean ${CMAKE_CURRENT_BINARY_DIR} dtrace
 COMMENT "Clearing old dtrace data")
 
-
   add_custom_target(generate-order-file
-COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py 
gen-order-file --binary $ --output 
${CMAKE_CURRENT_BINARY_DIR}/clang.order ${CMAKE_CURRENT_BINARY_DIR}
+COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py 
gen-order-file --binary $ --output ${CLANG_ORDER_FILE} 
${CMAKE_CURRENT_BINARY_DIR}
 COMMENT "Generating order file"
 DEPENDS generate-dtrace-logs)
 endif()
Index: tools/driver/CMakeLists.txt
===
--- tools/driver/CMakeLists.txt
+++ tools/driver/CMakeLists.txt
@@ -87,8 +87,10 @@
   set(TOOL_INFO_BUILD_VERSION)
 endif()
 
-if(CLANG_ORDER_FILE)
+# The MSVC linker doesn't respect the order_file option
+if(NOT MSVC)
   target_link_libraries(clang "-Wl,-order_file,${CLANG_ORDER_FILE}")
+  set_target_properties(clang PROPERTIES LINK_DEPENDS ${CLANG_ORDER_FILE})
 endif()
 
 if(WITH_POLLY AND LINK_POLLY_INTO_TOOLS)
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -586,9 +586,19 @@
   add_subdirectory(docs)
 endif()
 
-set(CLANG_ORDER_FILE "" CACHE FILEPATH
+# this line is needed as a cleanup to ensure that any CMakeCaches with the old
+# default value get updated to the new default.
+if(CLANG_ORDER_FILE STREQUAL "")
+  unset(CLANG_ORDER_FILE CACHE)
+endif()
+
+set(CLANG_ORDER_FILE ${CMAKE_CURRENT_BINARY_DIR}/clang.order CACHE FILEPATH
   "Order file to use when compiling clang in order to improve startup time.")
 
+if(NOT EXISTS ${CLANG_ORDER_FILE})
+  execute_process(COMMAND ${CMAKE_COMMAND} -E touch ${CLANG_ORDER_FILE})
+endif()
+
 if (CLANG_BUILT_STANDALONE OR CMAKE_VERSION VERSION_EQUAL 3 OR
 CMAKE_VERSION VERSION_GREATER 3)
   # Generate a list of CMake library targets so that other CMake projects can


Index: utils/perf-training/CMakeLists.txt
===
--- utils/perf-training/CMakeLists.txt
+++ utils/perf-training/CMakeLists.txt
@@ -55,9 +55,8 @@
 COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py clean ${CMAKE_CURRENT_BINARY_DIR} dtrace
 COMMENT "Clearing old dtrace data")
 
-
   add_custom_target(generate-order-file
-COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py gen-order-file --binary $ --output ${CMAKE_CURRENT_BINARY_DIR}/clang.order ${CMAKE_CURRENT_BINARY_DIR}
+COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py gen-order-file --binary $ --output ${CLANG_ORDER_FILE} ${CMAKE_CURRENT_BINARY_DIR}
 COMMENT "Generating order file"
 DEPENDS generate-dtrace-logs)
 endif()
Index: tools/driver/CMakeLists.txt
===
--- tools/driver/CMakeLists.txt
+++ tools/driver/CMakeLists.txt
@@ -87,8 +87,10 @@
   set(TOOL_INFO_BUILD_VERSION)
 endif()
 
-if(CLANG_ORDER_FILE)
+# The MSVC linker doesn't respect the order_file option
+if(NOT MSVC)
   target_link_libraries(clang "-Wl,-order_file,${CLANG_ORDER_FILE}")
+  set_target_properties(clang PROPERTIES LINK_DEPENDS ${CLANG_ORDER_FILE})
 endif()
 
 if(WITH_POLLY AND LINK_POLLY_INTO_TOOLS)
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -586,9 +586,19 @@
   add_subdirectory(docs)
 endif()
 
-set(CLANG_ORDER_FILE "" CACHE FILEPATH
+# this line is needed as a cleanup to ensure that any CMakeCaches with the old
+# default value get updated to the new default.
+if(CLANG_ORDER_FILE STREQUAL "")
+  unset(CLANG_ORDER_FILE CACHE)
+endif()
+
+set(CLANG_ORDER_FILE ${CMAKE_CURRENT_BINARY_DIR}/clang.order CACHE

Re: [PATCH] D13357: [Concepts] Diagnose when 'concept' is specified on a specialization

[Richard Smith via cfe-commits]

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

LGTM


http://reviews.llvm.org/D13357



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

Re: [PATCH] D16896: [CMake] Improve the clang order-file generation workflow

[Justin Bogner via cfe-commits]

Chris Bieneman  writes:
> beanz created this revision.
> beanz added a reviewer: bogner.
> beanz added a subscriber: cfe-commits.
>
> With this change generating clang order files using dtrace uses the
> following workflow:
>
> # Configure LLVM & Clang using any options on a system with dtrace
> cmake 
>
> # Builds clang and runs the perf-training data to generate the order file
> ninja generate-order-file
>
> # Re-link clang with the new order file
> ninja clang
>
> This patch works by setting a default path to the order file (which
> can be overridden by the user). If the order file doesn't exist during
> configuration CMake will create an empty one.
>
> CMake then ties up the dependencies between the clang link job and the
> order file, and generate-order-file overwrites CLANG_ORDER_FILE with
> the new order file.

This is kind of a strange workflow, but it seems reasonable (especially
for experimenting and testing purposes). LGTM once the comment below is
resolved.

> http://reviews.llvm.org/D16896
>
> Files:
>   CMakeLists.txt
>   tools/driver/CMakeLists.txt
>   utils/perf-training/CMakeLists.txt
>
> Index: utils/perf-training/CMakeLists.txt
> ===
> --- utils/perf-training/CMakeLists.txt
> +++ utils/perf-training/CMakeLists.txt
> @@ -55,9 +55,8 @@
>  COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py 
> clean ${CMAKE_CURRENT_BINARY_DIR} dtrace
>  COMMENT "Clearing old dtrace data")
>  
> -
>add_custom_target(generate-order-file
> -COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py 
> gen-order-file --binary $ --output 
> ${CMAKE_CURRENT_BINARY_DIR}/clang.order ${CMAKE_CURRENT_BINARY_DIR}
> +COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py 
> gen-order-file --binary $ --output ${CLANG_ORDER_FILE} 
> ${CMAKE_CURRENT_BINARY_DIR}
>  COMMENT "Generating order file"
>  DEPENDS generate-dtrace-logs)
>  endif()
> Index: tools/driver/CMakeLists.txt
> ===
> --- tools/driver/CMakeLists.txt
> +++ tools/driver/CMakeLists.txt
> @@ -87,8 +87,10 @@
>set(TOOL_INFO_BUILD_VERSION)
>  endif()
>  
> -if(CLANG_ORDER_FILE)
> +# The MSVC linker doesn't respect the order_file option
> +if(NOT MSVC)
>target_link_libraries(clang "-Wl,-order_file,${CLANG_ORDER_FILE}")
> +  set_target_properties(clang PROPERTIES LINK_DEPENDS ${CLANG_ORDER_FILE})

It's probably better to have cmake check if the linker supports this
flag rather than hard coding MSVC in particular here. Who knows what
strange linkers are being used in the wild.

>  endif()
>  
>  if(WITH_POLLY AND LINK_POLLY_INTO_TOOLS)
> Index: CMakeLists.txt
> ===
> --- CMakeLists.txt
> +++ CMakeLists.txt
> @@ -586,9 +586,19 @@
>add_subdirectory(docs)
>  endif()
>  
> -set(CLANG_ORDER_FILE "" CACHE FILEPATH
> +# this line is needed as a cleanup to ensure that any CMakeCaches with the 
> old
> +# default value get updated to the new default.
> +if(CLANG_ORDER_FILE STREQUAL "")
> +  unset(CLANG_ORDER_FILE CACHE)
> +endif()
> +
> +set(CLANG_ORDER_FILE ${CMAKE_CURRENT_BINARY_DIR}/clang.order CACHE FILEPATH
>"Order file to use when compiling clang in order to improve startup time.")
>  
> +if(NOT EXISTS ${CLANG_ORDER_FILE})
> +  execute_process(COMMAND ${CMAKE_COMMAND} -E touch ${CLANG_ORDER_FILE})
> +endif()
> +
>  if (CLANG_BUILT_STANDALONE OR CMAKE_VERSION VERSION_EQUAL 3 OR
>  CMAKE_VERSION VERSION_GREATER 3)
># Generate a list of CMake library targets so that other CMake projects can
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D15881: [DWARF] Omitting the explicit import of an anonymous namespace is a debugger-tuning decision, not a target decision.

[Eric Christopher via cfe-commits]

echristo added inline comments.


Comment at: lib/Frontend/CompilerInvocation.cpp:446-448
@@ -445,3 +445,5 @@
   Opts.DebugTypeExtRefs = Args.hasArg(OPT_dwarf_ext_refs);
-  Opts.DebugExplicitImport = Triple.isPS4CPU(); 
+  Opts.DebugExplicitImport =
+  Opts.getDebuggerTuning() != CodeGenOptions::DebuggerKindGDB &&
+  Opts.getDebuggerTuning() != CodeGenOptions::DebuggerKindLLDB;
 

probinson wrote:
> probinson wrote:
> > echristo wrote:
> > > probinson wrote:
> > > > echristo wrote:
> > > > > Why not just a positive for debugger tuning SCE?
> > > > Because the default (i.e., no tuning specified) behavior should be to 
> > > > conform to the DWARF spec, which basically says you need the explicit 
> > > > import.  There's a new extra RUN line in the test, with no tuning 
> > > > specified, to verify this.
> > > > GDB and LLDB are the oddballs here, they implement a special case for 
> > > > namespaces whose name meets certain criteria, and do something beyond 
> > > > what DWARF says to do.  So, the condition is written to express that.
> > > > 
> > > I don't necessarily agree with that interpretation on the explicit import 
> > > - I did skim the thread, perhaps you could highlight what makes you think 
> > > this?
> > Basically, a namespace is a "context" for declarations, and the DWARF 
> > mechanism for making declarations from one context available in another 
> > context is with DW_TAG_imported_declaration and DW_TAG_imported_module.
> > The C++ spec describes the behavior "as if" there was an explicit using 
> > directive, and DW_TAG_imported_module is the DWARF mechanism for describing 
> > a using directive.
> > 
> > The meaning of DWARF is determined by the DWARF spec, not the C++ spec, and 
> > the DWARF spec does not say there's anything special about a namespace that 
> > has no name.  There is a perfectly reasonable DWARF mechanism for getting 
> > the desired effect, so there's no reason for DWARF to make a special rule 
> > for an unnamed namespace.  Therefore, an anonymous namespace should be 
> > explicitly imported into the containing namespace. The explicit import 
> > would be marked artificial of course.
> > 
> Ping.  Have I missed something in the DWARF spec that makes you think my 
> interpretation is incorrect? Wouldn't be the first time...
I don't have anything to add to the reasoning the David has given you. We both 
agree and let's just make this a positive tuning for SCE.



http://reviews.llvm.org/D15881



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

Re: [PATCH] D15829: [PGO] Clang Option that enables IR level PGO instrumentation

[Rong Xu via cfe-commits]

xur updated this revision to Diff 46960.
xur added a comment.

Now http://reviews.llvm.org/D16730 has been committed (as r259811)

Here is the patch that adds cc1 option -fprofile-instrument=llvm to enable IR 
level PGO generate and use.

The pgo use part of the patch depends http://reviews.llvm.org/D15540 which 
differentiates the IR level and clang profiles. To detect the profile 
automatically, we need to first the profile. It can either done in driver or in 
Clang codegen (lib/CodeGen/CodeGenModule.cpp). If we do this in Clang codegen, 
we would have to change the Codegen option which does not seem to be a good 
approach. As a result, we do this in the driver in this patch.

Again like in http://reviews.llvm.org/D16730, this patch won't change any 
driver (user level) options. Only cc1 options are touched.

Thanks,

-Rong


http://reviews.llvm.org/D15829

Files:
  include/clang/Driver/CC1Options.td
  include/clang/Frontend/CodeGenOptions.h
  lib/CodeGen/BackendUtil.cpp
  lib/CodeGen/CodeGenModule.cpp
  lib/Driver/CMakeLists.txt
  lib/Driver/Tools.cpp
  lib/Frontend/CompilerInvocation.cpp
  test/CodeGen/Inputs/pgotestclang.profraw
  test/CodeGen/Inputs/pgotestir.profraw
  test/CodeGen/pgo-instrumentation.c

Index: test/CodeGen/pgo-instrumentation.c
===
--- test/CodeGen/pgo-instrumentation.c
+++ test/CodeGen/pgo-instrumentation.c
@@ -0,0 +1,28 @@
+// Test if PGO instrumentation and use pass are invoked.
+//
+// Ensure Pass PGOInstrumentationGenPass is invoked.
+// RUN: %clang -O2 -c -Xclang -fprofile-instrument=llvm -fprofile-instr-generate %s -mllvm -debug-pass=Structure 2>&1 | FileCheck %s -check-prefix=CHECK-PGOGENPASS-INVOKED-INSTR-GEN
+// CHECK-PGOGENPASS-INVOKED-INSTR-GEN: PGOInstrumentationGenPass
+//
+// Ensure Pass PGOInstrumentationGenPass is invoked.
+// RUN: %clang -O2 -c -Xclang -fprofile-instrument=llvm -fprofile-generate %s -mllvm -debug-pass=Structure 2>&1 | FileCheck %s -check-prefix=CHECK-PGOGENPASS-INVOKED-GEN
+// CHECK-PGOGENPASS-INVOKED-GEN: PGOInstrumentationGenPass
+//
+// Ensure Pass PGOInstrumentationGenPass is not invoked.
+// RUN: %clang -O2 -c -Xclang -fprofile-instrument=clang -fprofile-instr-generate %s -mllvm -debug-pass=Structure 2>&1 | FileCheck %s -check-prefix=CHECK-PGOGENPASS-INVOKED-INSTR-GEN-CLANG
+// CHECK-PGOGENPASS-INVOKED-INSTR-GEN-CLANG-NOT: PGOInstrumentationGenPass
+//
+// Ensure Pass PGOInstrumentationUsePass is invoked.
+// RUN: llvm-profdata merge -o %t.profdata %S/Inputs/pgotestir.profraw
+// RUN: %clang -O2 -c -Xclang -fprofile-instrument=llvm -fprofile-instr-use=%t.profdata %s -mllvm -debug-pass=Structure 2>&1 | FileCheck %s -check-prefix=CHECK-PGOUSEPASS-INVOKED-INSTR-USE
+// CHECK-PGOUSEPASS-INVOKED-INSTR-USE: PGOInstrumentationUsePass
+//
+// Ensure Pass PGOInstrumentationUsePass is invoked.
+// RUN: llvm-profdata merge -o %t.profdata %S/Inputs/pgotestir.profraw
+// RUN: %clang -O2 -c -Xclang -fprofile-instrument=llvm -fprofile-use=%t.profdata %s -mllvm -debug-pass=Structure 2>&1 | FileCheck %s -check-prefix=CHECK-PGOUSEPASS-INVOKED-USE
+// CHECK-PGOUSEPASS-INVOKED-USE: PGOInstrumentationUsePass
+//
+// Ensure Pass PGOInstrumentationUsePass is not invoked.
+// RUN: llvm-profdata merge -o %t.profdata %S/Inputs/pgotestclang.profraw
+// RUN: %clang -O2 -c -Xclang -fprofile-instrument=clang -fprofile-use=%t.profdata %s -mllvm -debug-pass=Structure 2>&1 | FileCheck %s -check-prefix=CHECK-PGOUSEPASS-INVOKED-USE-CLANG
+// CHECK-PGOUSEPASS-INVOKED-USE-CLANG-NOT: PGOInstrumentationUsePass
Index: test/CodeGen/Inputs/pgotestir.profraw
===
--- test/CodeGen/Inputs/pgotestir.profraw
+++ test/CodeGen/Inputs/pgotestir.profraw
@@ -0,0 +1 @@
+:ir
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -478,14 +478,18 @@
   Opts.Autolink = !Args.hasArg(OPT_fno_autolink);
   Opts.SampleProfileFile = Args.getLastArgValue(OPT_fprofile_sample_use_EQ);
 
-  enum PGOInstrumentor { Unknown, None, Clang };
+  enum PGOInstrumentor { Unknown, None, Clang, LLVM };
   if (Arg *A = Args.getLastArg(OPT_fprofile_instrument_EQ)) {
 StringRef Value = A->getValue();
 PGOInstrumentor Method = llvm::StringSwitch(Value)
- .Case("clang", Clang)
  .Case("none", None)
+ .Case("clang", Clang)
+ .Case("llvm", LLVM)
  .Default(Unknown);
 switch (Method) {
+case LLVM:
+  Opts.setProfileInstr(CodeGenOptions::ProfileIRInstr);
+  break;
 case Clang:
   Opts.setProfileInstr(CodeGenOptions::ProfileClangInstr);
   break;
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Dr

Re: [PATCH] D16686: [OpenCL] Generate metadata for opencl_unroll_hint attribute

[Yaxun Liu via cfe-commits]

yaxunl updated the summary for this revision.
yaxunl updated this revision to Diff 46961.
yaxunl marked 3 inline comments as done.
yaxunl added a comment.

Revised as Xiuli suggested.
Add test for OpenCL below 2.0.
Add diagnostic for opencl_unroll_hint attribute used below OpenCL 2.0.


http://reviews.llvm.org/D16686

Files:
  include/clang/Basic/Attr.td
  include/clang/Basic/AttrDocs.td
  include/clang/Basic/DiagnosticParseKinds.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Parse/Parser.h
  lib/CodeGen/CGLoopInfo.cpp
  lib/Parse/ParseDecl.cpp
  lib/Parse/ParseStmt.cpp
  lib/Sema/SemaStmtAttr.cpp
  test/CodeGenOpenCL/unroll-hint.cl
  test/Parser/opencl-unroll-hint.cl
  test/SemaOpenCL/unroll-hint-cl20.cl
  test/SemaOpenCL/unroll-hint.cl

Index: test/SemaOpenCL/unroll-hint.cl
===
--- /dev/null
+++ test/SemaOpenCL/unroll-hint.cl
@@ -0,0 +1,24 @@
+//RUN: %clang_cc1 -O0 -fsyntax-only -verify %s
+
+kernel void C (global int *x) {
+  int I = 3;
+  __attribute__((opencl_unroll_hint(I))) // expected-error {{'opencl_unroll_hint' attribute requires OpenCL version 2.0 or above}}
+  while (I--);
+}
+
+kernel void D (global int *x) {
+  int i = 10;
+  __attribute__((opencl_unroll_hint)) // expected-error {{'opencl_unroll_hint' attribute requires OpenCL version 2.0 or above}}
+  do {
+  } while(i--);
+}
+
+kernel void E() {
+  __attribute__((opencl_unroll_hint(2,4))) // expected-error {{'opencl_unroll_hint' attribute requires OpenCL version 2.0 or above}}
+  for(int i=0; i<100; i++);
+}
+
+kernel void F() {
+  __attribute__((opencl_unroll_hint(-1))) // expected-error {{'opencl_unroll_hint' attribute requires OpenCL version 2.0 or above}}
+  for(int i=0; i<100; i++);
+}
Index: test/SemaOpenCL/unroll-hint-cl20.cl
===
--- /dev/null
+++ test/SemaOpenCL/unroll-hint-cl20.cl
@@ -0,0 +1,24 @@
+//RUN: %clang_cc1 -O0 -cl-std=CL2.0 -fsyntax-only -verify %s
+
+kernel void C (global int *x) {
+  int I = 3;
+  __attribute__((opencl_unroll_hint(I))) // expected-error {{'opencl_unroll_hint' attribute requires an integer constant}}
+  while (I--);
+}
+
+kernel void D (global int *x) {
+  int i = 10;
+  __attribute__((opencl_unroll_hint))
+  do {
+  } while(i--);
+}
+
+kernel void E() {
+  __attribute__((opencl_unroll_hint(2,4))) // expected-error {{'opencl_unroll_hint' attribute takes no more than 1 argument}}
+  for(int i=0; i<100; i++);
+}
+
+kernel void F() {
+  __attribute__((opencl_unroll_hint(-1))) // expected-error {{'opencl_unroll_hint' attribute requires a positive integral compile time constant expression}}
+  for(int i=0; i<100; i++);
+}
Index: test/Parser/opencl-unroll-hint.cl
===
--- /dev/null
+++ test/Parser/opencl-unroll-hint.cl
@@ -0,0 +1,8 @@
+//RUN: %clang_cc1 -O0 -cl-std=CL2.0 -fsyntax-only -verify %s
+
+kernel void B (global int *x) {
+  __attribute__((opencl_unroll_hint(42)))
+  if (x[0]) // expected-error {{OpenCL only supports 'opencl_unroll_hint' attribute on for, while, and do statements}}
+x[0] = 15;
+}
+
Index: test/CodeGenOpenCL/unroll-hint.cl
===
--- /dev/null
+++ test/CodeGenOpenCL/unroll-hint.cl
@@ -0,0 +1,96 @@
+// RUN: %clang_cc1 -emit-llvm -O0 -cl-std=CL2.0 -o - %s | FileCheck %s
+
+/*** for ***/
+void for_count()
+{
+// CHECK-LABEL: for_count
+__attribute__((opencl_unroll_hint(8)))
+for( int i = 0; i < 1000; ++i);
+// CHECK: br label %{{.*}}, !llvm.loop ![[FOR_COUNT:.*]]
+}
+
+void for_disable()
+{
+// CHECK-LABEL: for_disable
+__attribute__((opencl_unroll_hint(1)))
+for( int i = 0; i < 1000; ++i);
+// CHECK: br label %{{.*}}, !llvm.loop ![[FOR_DISABLE:.*]]
+}
+
+void for_full()
+{
+// CHECK-LABEL: for_full
+__attribute__((opencl_unroll_hint))
+for( int i = 0; i < 1000; ++i);
+// CHECK: br label %{{.*}}, !llvm.loop ![[FOR_FULL:.*]]
+}
+
+/*** while ***/
+void while_count()
+{
+// CHECK-LABEL: while_count
+int i = 1000;
+__attribute__((opencl_unroll_hint(8)))
+while(i-->0);
+// CHECK: br label %{{.*}}, !llvm.loop ![[WHILE_COUNT:.*]]
+}
+
+void while_disable()
+{
+// CHECK-LABEL: while_disable
+int i = 1000;
+__attribute__((opencl_unroll_hint(1)))
+while(i-->0);
+// CHECK: br label %{{.*}}, !llvm.loop ![[WHILE_DISABLE:.*]]
+}
+
+void while_full()
+{
+// CHECK-LABEL: while_full
+int i = 1000;
+__attribute__((opencl_unroll_hint))
+while(i-->0);
+// CHECK: br label %{{.*}}, !llvm.loop ![[WHILE_FULL:.*]]
+}
+
+/*** do ***/
+void do_count()
+{
+// CHECK-LABEL: do_count
+int i = 1000;
+__attribute__((opencl_unroll_hint(8)))
+do {} while(i--> 0);
+// CHECK: br i1 %{{.*}}, label %{{.*}}, label %{{.*}}, !llvm.loop ![[DO_COUNT:.*]]
+}
+
+void do_disable()
+{
+// CHECK-LABEL: do_disable
+int i = 1000;
+__attribute__((opencl_unroll_hint(

Re: [PATCH] D15881: [DWARF] Omitting the explicit import of an anonymous namespace is a debugger-tuning decision, not a target decision.

[Paul Robinson via cfe-commits]

probinson marked an inline comment as done.


Comment at: lib/Frontend/CompilerInvocation.cpp:446-448
@@ -445,3 +445,5 @@
   Opts.DebugTypeExtRefs = Args.hasArg(OPT_dwarf_ext_refs);
-  Opts.DebugExplicitImport = Triple.isPS4CPU(); 
+  Opts.DebugExplicitImport =
+  Opts.getDebuggerTuning() != CodeGenOptions::DebuggerKindGDB &&
+  Opts.getDebuggerTuning() != CodeGenOptions::DebuggerKindLLDB;
 

echristo wrote:
> probinson wrote:
> > probinson wrote:
> > > echristo wrote:
> > > > probinson wrote:
> > > > > echristo wrote:
> > > > > > Why not just a positive for debugger tuning SCE?
> > > > > Because the default (i.e., no tuning specified) behavior should be to 
> > > > > conform to the DWARF spec, which basically says you need the explicit 
> > > > > import.  There's a new extra RUN line in the test, with no tuning 
> > > > > specified, to verify this.
> > > > > GDB and LLDB are the oddballs here, they implement a special case for 
> > > > > namespaces whose name meets certain criteria, and do something beyond 
> > > > > what DWARF says to do.  So, the condition is written to express that.
> > > > > 
> > > > I don't necessarily agree with that interpretation on the explicit 
> > > > import - I did skim the thread, perhaps you could highlight what makes 
> > > > you think this?
> > > Basically, a namespace is a "context" for declarations, and the DWARF 
> > > mechanism for making declarations from one context available in another 
> > > context is with DW_TAG_imported_declaration and DW_TAG_imported_module.
> > > The C++ spec describes the behavior "as if" there was an explicit using 
> > > directive, and DW_TAG_imported_module is the DWARF mechanism for 
> > > describing a using directive.
> > > 
> > > The meaning of DWARF is determined by the DWARF spec, not the C++ spec, 
> > > and the DWARF spec does not say there's anything special about a 
> > > namespace that has no name.  There is a perfectly reasonable DWARF 
> > > mechanism for getting the desired effect, so there's no reason for DWARF 
> > > to make a special rule for an unnamed namespace.  Therefore, an anonymous 
> > > namespace should be explicitly imported into the containing namespace. 
> > > The explicit import would be marked artificial of course.
> > > 
> > Ping.  Have I missed something in the DWARF spec that makes you think my 
> > interpretation is incorrect? Wouldn't be the first time...
> I don't have anything to add to the reasoning the David has given you. We 
> both agree and let's just make this a positive tuning for SCE.
> 
Fine.  It'll be on just for SCE.
// Pedantic DWARF requires explicit import but only SCE insists.



http://reviews.llvm.org/D15881



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

Re: [PATCH] D16538: [cc1as] Add MCTargetOptions argument to createAsmBackend

[Eric Christopher via cfe-commits]

echristo added a comment.

In http://reviews.llvm.org/D16538#344540, @joelkevinjones wrote:

> Ping.


The FIXME at cc1as_main.cpp:413


http://reviews.llvm.org/D16538



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

Re: [PATCH] D15881: [DWARF] Omitting the explicit import of an anonymous namespace is a debugger-tuning decision, not a target decision.

[Eric Christopher via cfe-commits]

echristo added inline comments.


Comment at: lib/Frontend/CompilerInvocation.cpp:446-448
@@ -445,3 +445,5 @@
   Opts.DebugTypeExtRefs = Args.hasArg(OPT_dwarf_ext_refs);
-  Opts.DebugExplicitImport = Triple.isPS4CPU(); 
+  Opts.DebugExplicitImport =
+  Opts.getDebuggerTuning() != CodeGenOptions::DebuggerKindGDB &&
+  Opts.getDebuggerTuning() != CodeGenOptions::DebuggerKindLLDB;
 

probinson wrote:
> echristo wrote:
> > probinson wrote:
> > > probinson wrote:
> > > > echristo wrote:
> > > > > probinson wrote:
> > > > > > echristo wrote:
> > > > > > > Why not just a positive for debugger tuning SCE?
> > > > > > Because the default (i.e., no tuning specified) behavior should be 
> > > > > > to conform to the DWARF spec, which basically says you need the 
> > > > > > explicit import.  There's a new extra RUN line in the test, with no 
> > > > > > tuning specified, to verify this.
> > > > > > GDB and LLDB are the oddballs here, they implement a special case 
> > > > > > for namespaces whose name meets certain criteria, and do something 
> > > > > > beyond what DWARF says to do.  So, the condition is written to 
> > > > > > express that.
> > > > > > 
> > > > > I don't necessarily agree with that interpretation on the explicit 
> > > > > import - I did skim the thread, perhaps you could highlight what 
> > > > > makes you think this?
> > > > Basically, a namespace is a "context" for declarations, and the DWARF 
> > > > mechanism for making declarations from one context available in another 
> > > > context is with DW_TAG_imported_declaration and DW_TAG_imported_module.
> > > > The C++ spec describes the behavior "as if" there was an explicit using 
> > > > directive, and DW_TAG_imported_module is the DWARF mechanism for 
> > > > describing a using directive.
> > > > 
> > > > The meaning of DWARF is determined by the DWARF spec, not the C++ spec, 
> > > > and the DWARF spec does not say there's anything special about a 
> > > > namespace that has no name.  There is a perfectly reasonable DWARF 
> > > > mechanism for getting the desired effect, so there's no reason for 
> > > > DWARF to make a special rule for an unnamed namespace.  Therefore, an 
> > > > anonymous namespace should be explicitly imported into the containing 
> > > > namespace. The explicit import would be marked artificial of course.
> > > > 
> > > Ping.  Have I missed something in the DWARF spec that makes you think my 
> > > interpretation is incorrect? Wouldn't be the first time...
> > I don't have anything to add to the reasoning the David has given you. We 
> > both agree and let's just make this a positive tuning for SCE.
> > 
> Fine.  It'll be on just for SCE.
> // Pedantic DWARF requires explicit import but only SCE insists.
> 
Please don't add that comment to this, I don't believe that it is valid or 
useful.


http://reviews.llvm.org/D15881



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

Re: [PATCH] D15881: [DWARF] Omitting the explicit import of an anonymous namespace is a debugger-tuning decision, not a target decision.

[Paul Robinson via cfe-commits]

probinson marked an inline comment as done.


Comment at: lib/Frontend/CompilerInvocation.cpp:446-448
@@ -445,3 +445,5 @@
   Opts.DebugTypeExtRefs = Args.hasArg(OPT_dwarf_ext_refs);
-  Opts.DebugExplicitImport = Triple.isPS4CPU(); 
+  Opts.DebugExplicitImport =
+  Opts.getDebuggerTuning() != CodeGenOptions::DebuggerKindGDB &&
+  Opts.getDebuggerTuning() != CodeGenOptions::DebuggerKindLLDB;
 

echristo wrote:
> probinson wrote:
> > echristo wrote:
> > > probinson wrote:
> > > > probinson wrote:
> > > > > echristo wrote:
> > > > > > probinson wrote:
> > > > > > > echristo wrote:
> > > > > > > > Why not just a positive for debugger tuning SCE?
> > > > > > > Because the default (i.e., no tuning specified) behavior should 
> > > > > > > be to conform to the DWARF spec, which basically says you need 
> > > > > > > the explicit import.  There's a new extra RUN line in the test, 
> > > > > > > with no tuning specified, to verify this.
> > > > > > > GDB and LLDB are the oddballs here, they implement a special case 
> > > > > > > for namespaces whose name meets certain criteria, and do 
> > > > > > > something beyond what DWARF says to do.  So, the condition is 
> > > > > > > written to express that.
> > > > > > > 
> > > > > > I don't necessarily agree with that interpretation on the explicit 
> > > > > > import - I did skim the thread, perhaps you could highlight what 
> > > > > > makes you think this?
> > > > > Basically, a namespace is a "context" for declarations, and the DWARF 
> > > > > mechanism for making declarations from one context available in 
> > > > > another context is with DW_TAG_imported_declaration and 
> > > > > DW_TAG_imported_module.
> > > > > The C++ spec describes the behavior "as if" there was an explicit 
> > > > > using directive, and DW_TAG_imported_module is the DWARF mechanism 
> > > > > for describing a using directive.
> > > > > 
> > > > > The meaning of DWARF is determined by the DWARF spec, not the C++ 
> > > > > spec, and the DWARF spec does not say there's anything special about 
> > > > > a namespace that has no name.  There is a perfectly reasonable DWARF 
> > > > > mechanism for getting the desired effect, so there's no reason for 
> > > > > DWARF to make a special rule for an unnamed namespace.  Therefore, an 
> > > > > anonymous namespace should be explicitly imported into the containing 
> > > > > namespace. The explicit import would be marked artificial of course.
> > > > > 
> > > > Ping.  Have I missed something in the DWARF spec that makes you think 
> > > > my interpretation is incorrect? Wouldn't be the first time...
> > > I don't have anything to add to the reasoning the David has given you. We 
> > > both agree and let's just make this a positive tuning for SCE.
> > > 
> > Fine.  It'll be on just for SCE.
> > // Pedantic DWARF requires explicit import but only SCE insists.
> > 
> Please don't add that comment to this, I don't believe that it is valid or 
> useful.
The DWARF committee disagrees with your validity opinion, but I will take the 
comment out.


http://reviews.llvm.org/D15881



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

Re: [PATCH] D15881: [DWARF] Omitting the explicit import of an anonymous namespace is a debugger-tuning decision, not a target decision.

[Eric Christopher via cfe-commits]

echristo added inline comments.


Comment at: lib/Frontend/CompilerInvocation.cpp:446-448
@@ -445,3 +445,5 @@
   Opts.DebugTypeExtRefs = Args.hasArg(OPT_dwarf_ext_refs);
-  Opts.DebugExplicitImport = Triple.isPS4CPU(); 
+  Opts.DebugExplicitImport =
+  Opts.getDebuggerTuning() != CodeGenOptions::DebuggerKindGDB &&
+  Opts.getDebuggerTuning() != CodeGenOptions::DebuggerKindLLDB;
 

probinson wrote:
> echristo wrote:
> > probinson wrote:
> > > echristo wrote:
> > > > probinson wrote:
> > > > > probinson wrote:
> > > > > > echristo wrote:
> > > > > > > probinson wrote:
> > > > > > > > echristo wrote:
> > > > > > > > > Why not just a positive for debugger tuning SCE?
> > > > > > > > Because the default (i.e., no tuning specified) behavior should 
> > > > > > > > be to conform to the DWARF spec, which basically says you need 
> > > > > > > > the explicit import.  There's a new extra RUN line in the test, 
> > > > > > > > with no tuning specified, to verify this.
> > > > > > > > GDB and LLDB are the oddballs here, they implement a special 
> > > > > > > > case for namespaces whose name meets certain criteria, and do 
> > > > > > > > something beyond what DWARF says to do.  So, the condition is 
> > > > > > > > written to express that.
> > > > > > > > 
> > > > > > > I don't necessarily agree with that interpretation on the 
> > > > > > > explicit import - I did skim the thread, perhaps you could 
> > > > > > > highlight what makes you think this?
> > > > > > Basically, a namespace is a "context" for declarations, and the 
> > > > > > DWARF mechanism for making declarations from one context available 
> > > > > > in another context is with DW_TAG_imported_declaration and 
> > > > > > DW_TAG_imported_module.
> > > > > > The C++ spec describes the behavior "as if" there was an explicit 
> > > > > > using directive, and DW_TAG_imported_module is the DWARF mechanism 
> > > > > > for describing a using directive.
> > > > > > 
> > > > > > The meaning of DWARF is determined by the DWARF spec, not the C++ 
> > > > > > spec, and the DWARF spec does not say there's anything special 
> > > > > > about a namespace that has no name.  There is a perfectly 
> > > > > > reasonable DWARF mechanism for getting the desired effect, so 
> > > > > > there's no reason for DWARF to make a special rule for an unnamed 
> > > > > > namespace.  Therefore, an anonymous namespace should be explicitly 
> > > > > > imported into the containing namespace. The explicit import would 
> > > > > > be marked artificial of course.
> > > > > > 
> > > > > Ping.  Have I missed something in the DWARF spec that makes you think 
> > > > > my interpretation is incorrect? Wouldn't be the first time...
> > > > I don't have anything to add to the reasoning the David has given you. 
> > > > We both agree and let's just make this a positive tuning for SCE.
> > > > 
> > > Fine.  It'll be on just for SCE.
> > > // Pedantic DWARF requires explicit import but only SCE insists.
> > > 
> > Please don't add that comment to this, I don't believe that it is valid or 
> > useful.
> The DWARF committee disagrees with your validity opinion, but I will take the 
> comment out.
Bring it up on the list then.


http://reviews.llvm.org/D15881



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

Re: [PATCH] D15881: [DWARF] Omitting the explicit import of an anonymous namespace is a debugger-tuning decision, not a target decision.

[Paul Robinson via cfe-commits]

probinson added inline comments.


Comment at: lib/Frontend/CompilerInvocation.cpp:446-448
@@ -445,3 +445,5 @@
   Opts.DebugTypeExtRefs = Args.hasArg(OPT_dwarf_ext_refs);
-  Opts.DebugExplicitImport = Triple.isPS4CPU(); 
+  Opts.DebugExplicitImport =
+  Opts.getDebuggerTuning() != CodeGenOptions::DebuggerKindGDB &&
+  Opts.getDebuggerTuning() != CodeGenOptions::DebuggerKindLLDB;
 

echristo wrote:
> probinson wrote:
> > echristo wrote:
> > > probinson wrote:
> > > > echristo wrote:
> > > > > probinson wrote:
> > > > > > probinson wrote:
> > > > > > > echristo wrote:
> > > > > > > > probinson wrote:
> > > > > > > > > echristo wrote:
> > > > > > > > > > Why not just a positive for debugger tuning SCE?
> > > > > > > > > Because the default (i.e., no tuning specified) behavior 
> > > > > > > > > should be to conform to the DWARF spec, which basically says 
> > > > > > > > > you need the explicit import.  There's a new extra RUN line 
> > > > > > > > > in the test, with no tuning specified, to verify this.
> > > > > > > > > GDB and LLDB are the oddballs here, they implement a special 
> > > > > > > > > case for namespaces whose name meets certain criteria, and do 
> > > > > > > > > something beyond what DWARF says to do.  So, the condition is 
> > > > > > > > > written to express that.
> > > > > > > > > 
> > > > > > > > I don't necessarily agree with that interpretation on the 
> > > > > > > > explicit import - I did skim the thread, perhaps you could 
> > > > > > > > highlight what makes you think this?
> > > > > > > Basically, a namespace is a "context" for declarations, and the 
> > > > > > > DWARF mechanism for making declarations from one context 
> > > > > > > available in another context is with DW_TAG_imported_declaration 
> > > > > > > and DW_TAG_imported_module.
> > > > > > > The C++ spec describes the behavior "as if" there was an explicit 
> > > > > > > using directive, and DW_TAG_imported_module is the DWARF 
> > > > > > > mechanism for describing a using directive.
> > > > > > > 
> > > > > > > The meaning of DWARF is determined by the DWARF spec, not the C++ 
> > > > > > > spec, and the DWARF spec does not say there's anything special 
> > > > > > > about a namespace that has no name.  There is a perfectly 
> > > > > > > reasonable DWARF mechanism for getting the desired effect, so 
> > > > > > > there's no reason for DWARF to make a special rule for an unnamed 
> > > > > > > namespace.  Therefore, an anonymous namespace should be 
> > > > > > > explicitly imported into the containing namespace. The explicit 
> > > > > > > import would be marked artificial of course.
> > > > > > > 
> > > > > > Ping.  Have I missed something in the DWARF spec that makes you 
> > > > > > think my interpretation is incorrect? Wouldn't be the first time...
> > > > > I don't have anything to add to the reasoning the David has given 
> > > > > you. We both agree and let's just make this a positive tuning for SCE.
> > > > > 
> > > > Fine.  It'll be on just for SCE.
> > > > // Pedantic DWARF requires explicit import but only SCE insists.
> > > > 
> > > Please don't add that comment to this, I don't believe that it is valid 
> > > or useful.
> > The DWARF committee disagrees with your validity opinion, but I will take 
> > the comment out.
> Bring it up on the list then.
I brought it up during the document review; see my ping comment from Jan 28.


http://reviews.llvm.org/D15881



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

Re: [PATCH] D15881: [DWARF] Omitting the explicit import of an anonymous namespace is a debugger-tuning decision, not a target decision.

[Eric Christopher via cfe-commits]

echristo added inline comments.


Comment at: lib/Frontend/CompilerInvocation.cpp:446-448
@@ -445,3 +445,5 @@
   Opts.DebugTypeExtRefs = Args.hasArg(OPT_dwarf_ext_refs);
-  Opts.DebugExplicitImport = Triple.isPS4CPU(); 
+  Opts.DebugExplicitImport =
+  Opts.getDebuggerTuning() != CodeGenOptions::DebuggerKindGDB &&
+  Opts.getDebuggerTuning() != CodeGenOptions::DebuggerKindLLDB;
 

probinson wrote:
> echristo wrote:
> > probinson wrote:
> > > echristo wrote:
> > > > probinson wrote:
> > > > > echristo wrote:
> > > > > > probinson wrote:
> > > > > > > probinson wrote:
> > > > > > > > echristo wrote:
> > > > > > > > > probinson wrote:
> > > > > > > > > > echristo wrote:
> > > > > > > > > > > Why not just a positive for debugger tuning SCE?
> > > > > > > > > > Because the default (i.e., no tuning specified) behavior 
> > > > > > > > > > should be to conform to the DWARF spec, which basically 
> > > > > > > > > > says you need the explicit import.  There's a new extra RUN 
> > > > > > > > > > line in the test, with no tuning specified, to verify this.
> > > > > > > > > > GDB and LLDB are the oddballs here, they implement a 
> > > > > > > > > > special case for namespaces whose name meets certain 
> > > > > > > > > > criteria, and do something beyond what DWARF says to do.  
> > > > > > > > > > So, the condition is written to express that.
> > > > > > > > > > 
> > > > > > > > > I don't necessarily agree with that interpretation on the 
> > > > > > > > > explicit import - I did skim the thread, perhaps you could 
> > > > > > > > > highlight what makes you think this?
> > > > > > > > Basically, a namespace is a "context" for declarations, and the 
> > > > > > > > DWARF mechanism for making declarations from one context 
> > > > > > > > available in another context is with 
> > > > > > > > DW_TAG_imported_declaration and DW_TAG_imported_module.
> > > > > > > > The C++ spec describes the behavior "as if" there was an 
> > > > > > > > explicit using directive, and DW_TAG_imported_module is the 
> > > > > > > > DWARF mechanism for describing a using directive.
> > > > > > > > 
> > > > > > > > The meaning of DWARF is determined by the DWARF spec, not the 
> > > > > > > > C++ spec, and the DWARF spec does not say there's anything 
> > > > > > > > special about a namespace that has no name.  There is a 
> > > > > > > > perfectly reasonable DWARF mechanism for getting the desired 
> > > > > > > > effect, so there's no reason for DWARF to make a special rule 
> > > > > > > > for an unnamed namespace.  Therefore, an anonymous namespace 
> > > > > > > > should be explicitly imported into the containing namespace. 
> > > > > > > > The explicit import would be marked artificial of course.
> > > > > > > > 
> > > > > > > Ping.  Have I missed something in the DWARF spec that makes you 
> > > > > > > think my interpretation is incorrect? Wouldn't be the first 
> > > > > > > time...
> > > > > > I don't have anything to add to the reasoning the David has given 
> > > > > > you. We both agree and let's just make this a positive tuning for 
> > > > > > SCE.
> > > > > > 
> > > > > Fine.  It'll be on just for SCE.
> > > > > // Pedantic DWARF requires explicit import but only SCE insists.
> > > > > 
> > > > Please don't add that comment to this, I don't believe that it is valid 
> > > > or useful.
> > > The DWARF committee disagrees with your validity opinion, but I will take 
> > > the comment out.
> > Bring it up on the list then.
> I brought it up during the document review; see my ping comment from Jan 28.
I saw. If you want that to be a required element of the spec then we need to 
change multiple wordings in the DWARF spec. I think the right place to bring 
that up is with the committee. The example is perfectly valid DWARF with the 
import, it's just unnecessary.


http://reviews.llvm.org/D15881



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

Re: [PATCH] D16148: Fix for PR25271: Ensure that variadic template parameter defaults PCH roundtrip

[Richard Smith via cfe-commits]

rsmith closed this revision.
rsmith added a comment.

Committed as r259836.


Repository:
  rL LLVM

http://reviews.llvm.org/D16148



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

r259836 - PR25271: When attaching default template arguments to redeclarations of a

[Richard Smith via cfe-commits]

Author: rsmith
Date: Thu Feb  4 16:54:41 2016
New Revision: 259836

URL: http://llvm.org/viewvc/llvm-project?rev=259836&view=rev
Log:
PR25271: When attaching default template arguments to redeclarations of a
template, keep looking for default arguments if we see a template parameter
pack. There may be default arguments preceding a pack with no default argument.

Patch by Jannis Harder!

Added:
cfe/trunk/test/PCH/cxx-variadic-templates-with-default-params.cpp
Modified:
cfe/trunk/lib/Serialization/ASTReaderDecl.cpp

Modified: cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTReaderDecl.cpp?rev=259836&r1=259835&r2=259836&view=diff
==
--- cfe/trunk/lib/Serialization/ASTReaderDecl.cpp (original)
+++ cfe/trunk/lib/Serialization/ASTReaderDecl.cpp Thu Feb  4 16:54:41 2016
@@ -3016,6 +3016,8 @@ static void inheritDefaultTemplateArgume
 
   for (unsigned I = 0, N = FromTP->size(); I != N; ++I) {
 NamedDecl *FromParam = FromTP->getParam(N - I - 1);
+if (FromParam->isParameterPack())
+  continue;
 NamedDecl *ToParam = ToTP->getParam(N - I - 1);
 
 if (auto *FTTP = dyn_cast(FromParam)) {

Added: cfe/trunk/test/PCH/cxx-variadic-templates-with-default-params.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/PCH/cxx-variadic-templates-with-default-params.cpp?rev=259836&view=auto
==
--- cfe/trunk/test/PCH/cxx-variadic-templates-with-default-params.cpp (added)
+++ cfe/trunk/test/PCH/cxx-variadic-templates-with-default-params.cpp Thu Feb  
4 16:54:41 2016
@@ -0,0 +1,26 @@
+// Test this without pch.
+// RUN: %clang_cc1 -std=c++11 -include %s -fsyntax-only -verify %s
+
+// Test with pch.
+// RUN: %clang_cc1 -std=c++11 -x c++-header -emit-pch -o %t %s
+// RUN: %clang_cc1 -std=c++11 -include-pch %t -fsyntax-only -verify %s
+
+// expected-no-diagnostics
+
+// PR25271: Ensure that default template arguments prior to a parameter pack
+// successfully round-trip.
+#ifndef HEADER
+#define HEADER
+template
+class dummy;
+
+template
+class dummy {
+int field[T];
+};
+#else
+void f() {
+dummy<> x;
+(void)x;
+}
+#endif


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

Re: [PATCH] D16896: [CMake] Improve the clang order-file generation workflow

[Chris Bieneman via cfe-commits]

beanz updated this revision to Diff 46966.
beanz added a comment.

Gate adding the -order_file linker option on whether the linker supports it.


http://reviews.llvm.org/D16896

Files:
  CMakeLists.txt
  tools/driver/CMakeLists.txt
  utils/perf-training/CMakeLists.txt

Index: utils/perf-training/CMakeLists.txt
===
--- utils/perf-training/CMakeLists.txt
+++ utils/perf-training/CMakeLists.txt
@@ -55,9 +55,8 @@
 COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py 
clean ${CMAKE_CURRENT_BINARY_DIR} dtrace
 COMMENT "Clearing old dtrace data")
 
-
   add_custom_target(generate-order-file
-COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py 
gen-order-file --binary $ --output 
${CMAKE_CURRENT_BINARY_DIR}/clang.order ${CMAKE_CURRENT_BINARY_DIR}
+COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py 
gen-order-file --binary $ --output ${CLANG_ORDER_FILE} 
${CMAKE_CURRENT_BINARY_DIR}
 COMMENT "Generating order file"
 DEPENDS generate-dtrace-logs)
 endif()
Index: tools/driver/CMakeLists.txt
===
--- tools/driver/CMakeLists.txt
+++ tools/driver/CMakeLists.txt
@@ -87,8 +87,12 @@
   set(TOOL_INFO_BUILD_VERSION)
 endif()
 
-if(CLANG_ORDER_FILE)
+check_cxx_compiler_flag("-Wl,-order_file,${CLANG_ORDER_FILE}"
+  LINKER_HAS_ORDER_FILE_FLAG)
+
+if(LINKER_HAS_ORDER_FILE_FLAG)
   target_link_libraries(clang "-Wl,-order_file,${CLANG_ORDER_FILE}")
+  set_target_properties(clang PROPERTIES LINK_DEPENDS ${CLANG_ORDER_FILE})
 endif()
 
 if(WITH_POLLY AND LINK_POLLY_INTO_TOOLS)
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -586,9 +586,19 @@
   add_subdirectory(docs)
 endif()
 
-set(CLANG_ORDER_FILE "" CACHE FILEPATH
+# this line is needed as a cleanup to ensure that any CMakeCaches with the old
+# default value get updated to the new default.
+if(CLANG_ORDER_FILE STREQUAL "")
+  unset(CLANG_ORDER_FILE CACHE)
+endif()
+
+set(CLANG_ORDER_FILE ${CMAKE_CURRENT_BINARY_DIR}/clang.order CACHE FILEPATH
   "Order file to use when compiling clang in order to improve startup time.")
 
+if(NOT EXISTS ${CLANG_ORDER_FILE})
+  execute_process(COMMAND ${CMAKE_COMMAND} -E touch ${CLANG_ORDER_FILE})
+endif()
+
 if (CLANG_BUILT_STANDALONE OR CMAKE_VERSION VERSION_EQUAL 3 OR
 CMAKE_VERSION VERSION_GREATER 3)
   # Generate a list of CMake library targets so that other CMake projects can


Index: utils/perf-training/CMakeLists.txt
===
--- utils/perf-training/CMakeLists.txt
+++ utils/perf-training/CMakeLists.txt
@@ -55,9 +55,8 @@
 COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py clean ${CMAKE_CURRENT_BINARY_DIR} dtrace
 COMMENT "Clearing old dtrace data")
 
-
   add_custom_target(generate-order-file
-COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py gen-order-file --binary $ --output ${CMAKE_CURRENT_BINARY_DIR}/clang.order ${CMAKE_CURRENT_BINARY_DIR}
+COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py gen-order-file --binary $ --output ${CLANG_ORDER_FILE} ${CMAKE_CURRENT_BINARY_DIR}
 COMMENT "Generating order file"
 DEPENDS generate-dtrace-logs)
 endif()
Index: tools/driver/CMakeLists.txt
===
--- tools/driver/CMakeLists.txt
+++ tools/driver/CMakeLists.txt
@@ -87,8 +87,12 @@
   set(TOOL_INFO_BUILD_VERSION)
 endif()
 
-if(CLANG_ORDER_FILE)
+check_cxx_compiler_flag("-Wl,-order_file,${CLANG_ORDER_FILE}"
+  LINKER_HAS_ORDER_FILE_FLAG)
+
+if(LINKER_HAS_ORDER_FILE_FLAG)
   target_link_libraries(clang "-Wl,-order_file,${CLANG_ORDER_FILE}")
+  set_target_properties(clang PROPERTIES LINK_DEPENDS ${CLANG_ORDER_FILE})
 endif()
 
 if(WITH_POLLY AND LINK_POLLY_INTO_TOOLS)
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -586,9 +586,19 @@
   add_subdirectory(docs)
 endif()
 
-set(CLANG_ORDER_FILE "" CACHE FILEPATH
+# this line is needed as a cleanup to ensure that any CMakeCaches with the old
+# default value get updated to the new default.
+if(CLANG_ORDER_FILE STREQUAL "")
+  unset(CLANG_ORDER_FILE CACHE)
+endif()
+
+set(CLANG_ORDER_FILE ${CMAKE_CURRENT_BINARY_DIR}/clang.order CACHE FILEPATH
   "Order file to use when compiling clang in order to improve startup time.")
 
+if(NOT EXISTS ${CLANG_ORDER_FILE})
+  execute_process(COMMAND ${CMAKE_COMMAND} -E touch ${CLANG_ORDER_FILE})
+endif()
+
 if (CLANG_BUILT_STANDALONE OR CMAKE_VERSION VERSION_EQUAL 3 OR
 CMAKE_VERSION VERSION_GREATER 3)
   # Generate a list of CMake library targets so that other CMake projects can
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.

Re: [PATCH] D16538: [cc1as] Add MCTargetOptions argument to createAsmBackend

[Joel Jones via cfe-commits]

joelkevinjones added a comment.

Ping.


http://reviews.llvm.org/D16538



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

[PATCH] D16901: [Clang driver, ARM] Do not add +long-calls in PIC mode

[Oleg Ranevskyy via cfe-commits]

iid_iunknown created this revision.
iid_iunknown added reviewers: asl, rengolin, t.p.northover.
iid_iunknown added a subscriber: cfe-commits.
iid_iunknown set the repository for this revision to rL LLVM.
Herald added subscribers: rengolin, aemerson.

The driver resets the PIC / PIE flags to false if compiling for kernel/kext 
considering the OS and its version. From ParsePICArgs():
```
if (KernelOrKext && ((!Triple.isiOS() || Triple.isOSVersionLT(6)) && 
!Triple.isWatchOS()))
PIC = PIE = false;
```
The condition for adding the +long-calls ARM feature in getARMTargetFeatures() 
is exactly the same.
Since +long-calls is not applicable for PIC, both conditions should be kept 
synchronized, otherwise one can get not working binaries.

This patch suggests to control the +long-calls option based on whether the code 
is PIC or not, which is a more natural way of doing this.

Repository:
  rL LLVM

http://reviews.llvm.org/D16901

Files:
  lib/Driver/Tools.cpp

Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -755,7 +755,7 @@
  const llvm::Triple &Triple,
  const ArgList &Args,
  std::vector &Features,
- bool ForAS) {
+ bool IsPIC, bool ForAS) {
   const Driver &D = TC.getDriver();
 
   bool KernelOrKext =
@@ -891,8 +891,7 @@
options::OPT_mno_long_calls)) {
 if (A->getOption().matches(options::OPT_mlong_calls))
   Features.push_back("+long-calls");
-  } else if (KernelOrKext && (!Triple.isiOS() || Triple.isOSVersionLT(6)) &&
- !Triple.isWatchOS()) {
+  } else if (KernelOrKext && !IsPIC) {
   Features.push_back("+long-calls");
   }
 
@@ -2291,7 +2290,7 @@
 
 static void getTargetFeatures(const ToolChain &TC, const llvm::Triple &Triple,
   const ArgList &Args, ArgStringList &CmdArgs,
-  bool ForAS) {
+  bool IsPIC, bool ForAS) {
   const Driver &D = TC.getDriver();
   std::vector Features;
   switch (Triple.getArch()) {
@@ -2308,7 +2307,7 @@
   case llvm::Triple::armeb:
   case llvm::Triple::thumb:
   case llvm::Triple::thumbeb:
-getARMTargetFeatures(TC, Triple, Args, Features, ForAS);
+getARMTargetFeatures(TC, Triple, Args, Features, IsPIC, ForAS);
 break;
 
   case llvm::Triple::ppc:
@@ -4047,7 +4046,7 @@
   }
 
   // Add the target features
-  getTargetFeatures(getToolChain(), Triple, Args, CmdArgs, false);
+  getTargetFeatures(getToolChain(), Triple, Args, CmdArgs, PICLevel > 0, 
false);
 
   // Add target specific flags.
   switch (getToolChain().getArch()) {
@@ -6025,7 +6024,7 @@
   }
 
   // Add the target features
-  getTargetFeatures(getToolChain(), Triple, Args, CmdArgs, true);
+  getTargetFeatures(getToolChain(), Triple, Args, CmdArgs, /*IsPIC*/ false, 
true);
 
   // Ignore explicit -force_cpusubtype_ALL option.
   (void)Args.hasArg(options::OPT_force__cpusubtype__ALL);


Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -755,7 +755,7 @@
  const llvm::Triple &Triple,
  const ArgList &Args,
  std::vector &Features,
- bool ForAS) {
+ bool IsPIC, bool ForAS) {
   const Driver &D = TC.getDriver();
 
   bool KernelOrKext =
@@ -891,8 +891,7 @@
options::OPT_mno_long_calls)) {
 if (A->getOption().matches(options::OPT_mlong_calls))
   Features.push_back("+long-calls");
-  } else if (KernelOrKext && (!Triple.isiOS() || Triple.isOSVersionLT(6)) &&
- !Triple.isWatchOS()) {
+  } else if (KernelOrKext && !IsPIC) {
   Features.push_back("+long-calls");
   }
 
@@ -2291,7 +2290,7 @@
 
 static void getTargetFeatures(const ToolChain &TC, const llvm::Triple &Triple,
   const ArgList &Args, ArgStringList &CmdArgs,
-  bool ForAS) {
+  bool IsPIC, bool ForAS) {
   const Driver &D = TC.getDriver();
   std::vector Features;
   switch (Triple.getArch()) {
@@ -2308,7 +2307,7 @@
   case llvm::Triple::armeb:
   case llvm::Triple::thumb:
   case llvm::Triple::thumbeb:
-getARMTargetFeatures(TC, Triple, Args, Features, ForAS);
+getARMTargetFeatures(TC, Triple, Args, Features, IsPIC, ForAS);
 break;
 
   case llvm::Triple::ppc:
@@ -4047,7 +4046,7 @@
   }
 
   // Add the target features
-  getTargetFeatures(getToolChain(), Triple, Args, CmdArgs, false);
+  getTargetFeatures(getToolChain(), Triple, Args, CmdArgs, PICLevel > 0, false);
 
   // Add target specific flags.
   switch (getToolChain().getArch()) {
@@ -6025,7 +6024,7 @@

[libcxx] r259842 - Fix the search path for CMake files

[Niels Ole Salscheider via cfe-commits]

Author: olesalscheider
Date: Thu Feb  4 17:17:20 2016
New Revision: 259842

URL: http://llvm.org/viewvc/llvm-project?rev=259842&view=rev
Log:
Fix the search path for CMake files

This allows to find the LLVM's CMake files after moving them in
r259821.

Modified:
libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake

Modified: libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake?rev=259842&r1=259841&r2=259842&view=diff
==
--- libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake (original)
+++ libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake Thu Feb  4 17:17:20 
2016
@@ -35,7 +35,7 @@ macro(find_llvm_parts)
 set(LLVM_INCLUDE_DIR ${INCLUDE_DIR} CACHE PATH "Path to llvm/include")
 set(LLVM_BINARY_DIR ${LLVM_OBJ_ROOT} CACHE PATH "Path to LLVM build tree")
 set(LLVM_MAIN_SRC_DIR ${MAIN_SRC_DIR} CACHE PATH "Path to LLVM source 
tree")
-set(LLVM_CMAKE_PATH "${LLVM_BINARY_DIR}/share/llvm/cmake")
+set(LLVM_CMAKE_PATH 
"${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/cmake/llvm")
   else()
 set(LLVM_FOUND OFF)
 return()


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

Re: [PATCH] D16873: Refactor MemRegionManager::getVarRegion to call two new functions, improving readability

[Alexander Riccio via cfe-commits]

ariccio added a comment.

Responded to comments.

Will happily make changes when questions are answered.



Comment at: 
llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h:1186
@@ +1185,3 @@
+  ///  associated with a specified globally stored, non-static local, VarDecl.
+  const MemRegion *getMemRegionGloballyStored(const VarDecl *D);
+

a.sidorin wrote:
> How about make these helper functions return `const MemSpaceRegion *` to make 
> their signatures more meaningful?
Would that change their behavior functionally?


Comment at: llvm/tools/clang/lib/StaticAnalyzer/Core/MemRegion.cpp:769
@@ -768,4 +768,3 @@
 
-const VarRegion* MemRegionManager::getVarRegion(const VarDecl *D,
-const LocationContext *LC) {
-  const MemRegion *sReg = nullptr;
+const MemRegion* MemRegionManager::getMemRegionGloballyStored(const VarDecl 
*D) {
+  assert(D->hasGlobalStorage());

a.sidorin wrote:
> `get[Global/StaticLocal]MemSpaceForVariable`?
Ahh, that might make more sense. I did this refactoring without any sense of 
context, as the unnecessary complexity was a hindrance thereto.



Comment at: llvm/tools/clang/lib/StaticAnalyzer/Core/MemRegion.cpp:769
@@ -768,4 +768,3 @@
 
-const VarRegion* MemRegionManager::getVarRegion(const VarDecl *D,
-const LocationContext *LC) {
-  const MemRegion *sReg = nullptr;
+const MemRegion* MemRegionManager::getMemRegionGloballyStored(const VarDecl 
*D) {
+  assert(D->hasGlobalStorage());

ariccio wrote:
> a.sidorin wrote:
> > `get[Global/StaticLocal]MemSpaceForVariable`?
> Ahh, that might make more sense. I did this refactoring without any sense of 
> context, as the unnecessary complexity was a hindrance thereto.
> 
How about `getGlobalMemSpaceForGlobalVariable`? I'm hesitant to drop the second 
global, to be clear about the scope of the variable that's stored globally. Is 
that a reasonable concern, or is that redundant?


Comment at: llvm/tools/clang/lib/StaticAnalyzer/Core/MemRegion.cpp:843
@@ +842,3 @@
+const LocationContext *LC) {
+  const MemRegion *sReg = nullptr;
+

a.sidorin wrote:
> `const MemSpaceRegion *StorageSpace?`
Same question as above: Would that change their behavior functionally?


(if not, then I'll happily change it)


http://reviews.llvm.org/D16873



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

Buildbot numbers for week of 1/24/2016 - 1/30/2016

[Galina Kistanova via cfe-commits]

Hello everyone,

Below are some buildbot numbers for the last week of 1/24/2016 - 1/30/2016.

Thanks

Galina


Number of commits by project:


 project   |   commits
---+---
 llvm  |   283
 cfe   |   100
 lld   |46
 lldb  |46
 compiler-rt   |36
 clang-tools-extra |16
 libcxx|14
 openmp|13
 polly |11
---+---
   565


Number of completed builds, failed builds and average build time for
successful builds per active builder:

 buildername   | completed  |
failed | time
---+++
 clang-aarch64-lnt | 44
| 21 | 02:25:25
 clang-atom-d525-fedora|136
|130 | 09:02:23
 clang-atom-d525-fedora-rel|146
|117 | 01:57:06
 clang-bpf-build   |311
| 32 | 00:03:29
 clang-cmake-aarch64-42vma |150
| 31 | 00:47:52
 clang-cmake-aarch64-full  | 50
| 15 | 03:38:37
 clang-cmake-aarch64-quick |162
| 36 | 00:43:11
 clang-cmake-armv7-a15 |168
| 17 | 00:36:58
 clang-cmake-armv7-a15-full| 76
|  4 | 01:51:26
 clang-cmake-armv7-a15-selfhost| 34
|  1 | 04:21:24
 clang-cmake-armv7-a15-selfhost-neon   | 24
|  2 | 06:25:21
 clang-cmake-mips  | 89
| 14 | 01:40:21
 clang-cmake-mipsel| 26
|  6 | 07:45:24
 clang-cmake-thumbv7-a15   |177
| 24 | 00:32:34
 clang-cmake-thumbv7-a15-full-sh   | 23
|  1 | 06:47:51
 clang-hexagon-elf | 90
| 17 | 00:19:14
 clang-native-aarch64-full | 18
|  1 | 07:28:21
 clang-native-arm-lnt  | 90
|  2 | 01:25:41
 clang-native-arm-lnt-perf | 18
|  1 | 08:42:18
 clang-ppc64be-linux   |299
| 41 | 00:07:41
 clang-ppc64be-linux-lnt   | 57
| 18 | 01:01:57
 clang-ppc64be-linux-multistage|169
| 13 | 00:35:54
 clang-ppc64le-linux   |217
| 86 | 00:21:30
 clang-ppc64le-linux-lnt   | 22
|  1 | 02:39:35
 clang-ppc64le-linux-multistage|111
| 20 | 01:07:57
 clang-s390x-linux |133
| 86 | 00:09:07
 clang-sphinx-docs |108
| 42 | 00:00:23
 clang-x64-ninja-win7  |180
|152 | 00:37:35
 clang-x86-win2008-selfhost|122
| 49 | 01:17:24
 clang-x86_64-darwin13-cross-arm   | 76
|  2 | 00:20:11
 clang-x86_64-darwin13-cross-mingw32   | 68
|  3 | 00:24:06
 clang-x86_64-debian-fast  |122
| 76 | 00:14:17
 clang-x86_64-linux-abi-test   |316
| 73 | 00:09:56
 clang-x86_64-linux-selfhost-modules   |257
| 52 | 00:16:36
 libcxx-libcxxabi-arm-linux| 13
|| 01:08:38
 libcxx-libcxxabi-singlethreaded-x86_64-linux-debian   | 13
|  8 | 00:08:26
 libcxx-libcxxabi-x86_64-linux-debian  | 12
|  2 | 00:09:44
 libcxx-libcxxabi-x86_64-linux-debian-noexceptions | 11
|  2 | 00:09:23
 libcxx-libcxxabi-x86_64-linux-ubuntu-asan | 12
|| 00:11:04
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03| 12
|| 00:05:42
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx11| 13
|| 00:06:39
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14| 13
|| 00:07:11
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx1z| 12
|| 00:07:12
 libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11  | 12
| 12 |
 libcxx

Re: [PATCH] D16873: Refactor MemRegionManager::getVarRegion to call two new functions, improving readability

[Devin Coughlin via cfe-commits]

dcoughlin added a comment.

I guess this is a reasonable refactoring. Although someone with different 
tastes might come along and inline it back in since the two extracted functions 
each only have single callers.



Comment at: 
llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h:1185
@@ +1184,3 @@
+  /// getMemRegionGloballyStored - Retrieve or create the memory region
+  ///  associated with a specified globally stored, non-static local, VarDecl.
+  const MemRegion *getMemRegionGloballyStored(const VarDecl *D);

I think describing this as taking a "globally stored, non-static local, 
VarDecl" is ambiguous. This method operates on global variables. It does not 
act on local variables (static or otherwise). How about "Retrieve or create the 
memory region associated with a VarDecl for a global variable."

Also, the recommended style these days is to not prefix the doc comment with 
the name of the member, so I would remove "getMemRegionGloballyStored - " even 
though getVarRegion() has the same thing. The doc comment style in this file is 
sufficiently mismatched that I think it is better to do the now-recommend thing 
rather than try to match its surrounding context.


Comment at: llvm/tools/clang/lib/StaticAnalyzer/Core/MemRegion.cpp:769
@@ -768,4 +768,3 @@
 
-const VarRegion* MemRegionManager::getVarRegion(const VarDecl *D,
-const LocationContext *LC) {
-  const MemRegion *sReg = nullptr;
+const MemRegion* MemRegionManager::getMemRegionGloballyStored(const VarDecl 
*D) {
+  assert(D->hasGlobalStorage());

a.sidorin wrote:
> `get[Global/StaticLocal]MemSpaceForVariable`?
The rest of the method in class follow a pattern of getAdjectiveNoun, so I 
would suggest something like getGlobalVarRegion() and getLocalVarRegion()


Comment at: llvm/tools/clang/lib/StaticAnalyzer/Core/MemRegion.cpp:792
@@ -783,12 +791,3 @@
 
-// Treat other globals as GlobalInternal unless they are constants.
-} else {
-  QualType GQT = D->getType();
-  const Type *GT = GQT.getTypePtrOrNull();
-  // TODO: We could walk the complex types here and see if everything is
-  // constified.
-  if (GT && GQT.isConstQualified() && GT->isArithmeticType())
-sReg = getGlobalsRegion(MemRegion::GlobalImmutableSpaceRegionKind);
-  else
-sReg = getGlobalsRegion();
-}
+const MemRegion* MemRegionManager::getMemRegionStaticLocal(const VarDecl *D, 
const LocationContext *LC) {
+  // FIXME: Once we implement scope handling, we will need to properly lookup

It looks to me like this function operates on both locals *and* static locals. 
I would change the name to reflect that.


Comment at: llvm/tools/clang/lib/StaticAnalyzer/Core/MemRegion.cpp:848
@@ +847,3 @@
+
+  // Finally handle static locals.
+  } else {

This comment was wrong before and very misleading. I would just remove it so no 
one else trips on it!


http://reviews.llvm.org/D16873



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

[PATCH] D16906: [Parser] Perform CachedTokens update dependent on token consume request

[Bruno Cardoso Lopes via cfe-commits]

bruno created this revision.
bruno added reviewers: rsmith, doug.gregor, akyrtzi.
bruno added subscribers: cfe-commits, dexonsmith.

In the context where we break one tok::greatergreater into two tok::greater in 
order to correctly update the cached tokens; update the CachedTokens with two 
tok::greater only if ParseGreaterThanInTemplateList clients asks to consume the 
last token. Otherwise we only need to add one because the second is already 
added later on, as the current token.

This is a follow up from r259311.

http://reviews.llvm.org/D16906

Files:
  lib/Parse/ParseTemplate.cpp
  test/Parser/objcxx11-protocol-in-template.mm

Index: test/Parser/objcxx11-protocol-in-template.mm
===
--- test/Parser/objcxx11-protocol-in-template.mm
+++ test/Parser/objcxx11-protocol-in-template.mm
@@ -16,3 +16,11 @@
 typedef int some_t;
 
 id FA(NSArray> *h, some_t group);
+
+template  void F(Functor functor) {}
+
+void z() {
+  id x = 0;
+  (void)x;
+  F( [ x = vector>{} ] {} );
+}
Index: lib/Parse/ParseTemplate.cpp
===
--- lib/Parse/ParseTemplate.cpp
+++ lib/Parse/ParseTemplate.cpp
@@ -855,8 +855,12 @@
   RemainingToken == tok::greater && PP.IsPreviousCachedToken(PrevTok)) {
 PrevTok.setKind(RemainingToken);
 PrevTok.setLength(1);
-Token NewToks[] = {PrevTok, Tok};
-PP.ReplacePreviousCachedToken(NewToks);
+// Break tok::greatergreater into two tok::greater but only add the second
+// one in case the client asks to consume the last token.
+if (ConsumeLastToken)
+  PP.ReplacePreviousCachedToken({PrevTok, Tok});
+else
+  PP.ReplacePreviousCachedToken({PrevTok});
   }
 
   if (!ConsumeLastToken) {


Index: test/Parser/objcxx11-protocol-in-template.mm
===
--- test/Parser/objcxx11-protocol-in-template.mm
+++ test/Parser/objcxx11-protocol-in-template.mm
@@ -16,3 +16,11 @@
 typedef int some_t;
 
 id FA(NSArray> *h, some_t group);
+
+template  void F(Functor functor) {}
+
+void z() {
+  id x = 0;
+  (void)x;
+  F( [ x = vector>{} ] {} );
+}
Index: lib/Parse/ParseTemplate.cpp
===
--- lib/Parse/ParseTemplate.cpp
+++ lib/Parse/ParseTemplate.cpp
@@ -855,8 +855,12 @@
   RemainingToken == tok::greater && PP.IsPreviousCachedToken(PrevTok)) {
 PrevTok.setKind(RemainingToken);
 PrevTok.setLength(1);
-Token NewToks[] = {PrevTok, Tok};
-PP.ReplacePreviousCachedToken(NewToks);
+// Break tok::greatergreater into two tok::greater but only add the second
+// one in case the client asks to consume the last token.
+if (ConsumeLastToken)
+  PP.ReplacePreviousCachedToken({PrevTok, Tok});
+else
+  PP.ReplacePreviousCachedToken({PrevTok});
   }
 
   if (!ConsumeLastToken) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r259859 - Don't synthesize an ImportDecl for a module named in -fmodule-implementation-of

[Ben Langmuir via cfe-commits]

Author: benlangmuir
Date: Thu Feb  4 19:10:05 2016
New Revision: 259859

URL: http://llvm.org/viewvc/llvm-project?rev=259859&view=rev
Log:
Don't synthesize an ImportDecl for a module named in -fmodule-implementation-of

When building a PCH with modules enabled this import would assert in the
ASTWriter and (if assertions were disabled) sometimes crash the compiler
that loaded the resulting PCH when trying to lookup the submodule ID.

rdar://problem/24137448

Modified:
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/test/Modules/Inputs/category_right.h
cfe/trunk/test/Modules/objc-categories.m

Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=259859&r1=259858&r2=259859&view=diff
==
--- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDecl.cpp Thu Feb  4 19:10:05 2016
@@ -14783,9 +14783,15 @@ void Sema::ActOnModuleInclude(SourceLoca
   TUKind == TU_Module &&
   getSourceManager().isWrittenInMainFile(DirectiveLoc);
 
+  // Similarly, if this module is specified by -fmodule-implementation-of
+  // don't actually synthesize an illegal module import.
+  bool ShouldAddImport = !IsInModuleIncludes &&
+(getLangOpts().ImplementationOfModule.empty() ||
+ getLangOpts().ImplementationOfModule != Mod->getTopLevelModuleName());
+
   // If this module import was due to an inclusion directive, create an 
   // implicit import declaration to capture it in the AST.
-  if (!IsInModuleIncludes) {
+  if (ShouldAddImport) {
 TranslationUnitDecl *TU = getASTContext().getTranslationUnitDecl();
 ImportDecl *ImportD = ImportDecl::CreateImplicit(getASTContext(), TU,
  DirectiveLoc, Mod,

Modified: cfe/trunk/test/Modules/Inputs/category_right.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/category_right.h?rev=259859&r1=259858&r2=259859&view=diff
==
--- cfe/trunk/test/Modules/Inputs/category_right.h (original)
+++ cfe/trunk/test/Modules/Inputs/category_right.h Thu Feb  4 19:10:05 2016
@@ -1,4 +1,5 @@
 @import category_top;
+#import "category_right_sub.h"
 
 @interface Foo(Right1)
 -(void)right1;

Modified: cfe/trunk/test/Modules/objc-categories.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/objc-categories.m?rev=259859&r1=259858&r2=259859&view=diff
==
--- cfe/trunk/test/Modules/objc-categories.m (original)
+++ cfe/trunk/test/Modules/objc-categories.m Thu Feb  4 19:10:05 2016
@@ -9,7 +9,7 @@
 @import category_bottom;
 
 // expected-note@Inputs/category_left.h:14 {{previous definition}}
-// expected-warning@Inputs/category_right.h:11 {{duplicate definition of 
category}}
+// expected-warning@Inputs/category_right.h:12 {{duplicate definition of 
category}}
 // expected-note@Inputs/category_top.h:1 {{receiver is instance of class 
declared here}}
 
 @interface Foo(Source)


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

Re: [PATCH] D16896: [CMake] Improve the clang order-file generation workflow

[Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL259862: [CMake] Improve the clang order-file generation 
workflow (authored by cbieneman).

Changed prior to commit:
  http://reviews.llvm.org/D16896?vs=46966&id=46982#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D16896

Files:
  cfe/trunk/CMakeLists.txt
  cfe/trunk/tools/driver/CMakeLists.txt
  cfe/trunk/utils/perf-training/CMakeLists.txt

Index: cfe/trunk/tools/driver/CMakeLists.txt
===
--- cfe/trunk/tools/driver/CMakeLists.txt
+++ cfe/trunk/tools/driver/CMakeLists.txt
@@ -87,8 +87,12 @@
   set(TOOL_INFO_BUILD_VERSION)
 endif()
 
-if(CLANG_ORDER_FILE)
+check_cxx_compiler_flag("-Wl,-order_file,${CLANG_ORDER_FILE}"
+  LINKER_HAS_ORDER_FILE_FLAG)
+
+if(LINKER_HAS_ORDER_FILE_FLAG)
   target_link_libraries(clang "-Wl,-order_file,${CLANG_ORDER_FILE}")
+  set_target_properties(clang PROPERTIES LINK_DEPENDS ${CLANG_ORDER_FILE})
 endif()
 
 if(WITH_POLLY AND LINK_POLLY_INTO_TOOLS)
Index: cfe/trunk/utils/perf-training/CMakeLists.txt
===
--- cfe/trunk/utils/perf-training/CMakeLists.txt
+++ cfe/trunk/utils/perf-training/CMakeLists.txt
@@ -55,9 +55,8 @@
 COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py 
clean ${CMAKE_CURRENT_BINARY_DIR} dtrace
 COMMENT "Clearing old dtrace data")
 
-
   add_custom_target(generate-order-file
-COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py 
gen-order-file --binary $ --output 
${CMAKE_CURRENT_BINARY_DIR}/clang.order ${CMAKE_CURRENT_BINARY_DIR}
+COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py 
gen-order-file --binary $ --output ${CLANG_ORDER_FILE} 
${CMAKE_CURRENT_BINARY_DIR}
 COMMENT "Generating order file"
 DEPENDS generate-dtrace-logs)
 endif()
Index: cfe/trunk/CMakeLists.txt
===
--- cfe/trunk/CMakeLists.txt
+++ cfe/trunk/CMakeLists.txt
@@ -586,9 +586,19 @@
   add_subdirectory(docs)
 endif()
 
-set(CLANG_ORDER_FILE "" CACHE FILEPATH
+# this line is needed as a cleanup to ensure that any CMakeCaches with the old
+# default value get updated to the new default.
+if(CLANG_ORDER_FILE STREQUAL "")
+  unset(CLANG_ORDER_FILE CACHE)
+endif()
+
+set(CLANG_ORDER_FILE ${CMAKE_CURRENT_BINARY_DIR}/clang.order CACHE FILEPATH
   "Order file to use when compiling clang in order to improve startup time.")
 
+if(NOT EXISTS ${CLANG_ORDER_FILE})
+  execute_process(COMMAND ${CMAKE_COMMAND} -E touch ${CLANG_ORDER_FILE})
+endif()
+
 if (CLANG_BUILT_STANDALONE OR CMAKE_VERSION VERSION_EQUAL 3 OR
 CMAKE_VERSION VERSION_GREATER 3)
   # Generate a list of CMake library targets so that other CMake projects can


Index: cfe/trunk/tools/driver/CMakeLists.txt
===
--- cfe/trunk/tools/driver/CMakeLists.txt
+++ cfe/trunk/tools/driver/CMakeLists.txt
@@ -87,8 +87,12 @@
   set(TOOL_INFO_BUILD_VERSION)
 endif()
 
-if(CLANG_ORDER_FILE)
+check_cxx_compiler_flag("-Wl,-order_file,${CLANG_ORDER_FILE}"
+  LINKER_HAS_ORDER_FILE_FLAG)
+
+if(LINKER_HAS_ORDER_FILE_FLAG)
   target_link_libraries(clang "-Wl,-order_file,${CLANG_ORDER_FILE}")
+  set_target_properties(clang PROPERTIES LINK_DEPENDS ${CLANG_ORDER_FILE})
 endif()
 
 if(WITH_POLLY AND LINK_POLLY_INTO_TOOLS)
Index: cfe/trunk/utils/perf-training/CMakeLists.txt
===
--- cfe/trunk/utils/perf-training/CMakeLists.txt
+++ cfe/trunk/utils/perf-training/CMakeLists.txt
@@ -55,9 +55,8 @@
 COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py clean ${CMAKE_CURRENT_BINARY_DIR} dtrace
 COMMENT "Clearing old dtrace data")
 
-
   add_custom_target(generate-order-file
-COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py gen-order-file --binary $ --output ${CMAKE_CURRENT_BINARY_DIR}/clang.order ${CMAKE_CURRENT_BINARY_DIR}
+COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py gen-order-file --binary $ --output ${CLANG_ORDER_FILE} ${CMAKE_CURRENT_BINARY_DIR}
 COMMENT "Generating order file"
 DEPENDS generate-dtrace-logs)
 endif()
Index: cfe/trunk/CMakeLists.txt
===
--- cfe/trunk/CMakeLists.txt
+++ cfe/trunk/CMakeLists.txt
@@ -586,9 +586,19 @@
   add_subdirectory(docs)
 endif()
 
-set(CLANG_ORDER_FILE "" CACHE FILEPATH
+# this line is needed as a cleanup to ensure that any CMakeCaches with the old
+# default value get updated to the new default.
+if(CLANG_ORDER_FILE STREQUAL "")
+  unset(CLANG_ORDER_FILE CACHE)
+endif()
+
+set(CLANG_ORDER_FILE ${CMAKE_CURRENT_BINARY_DIR}/clang.order CACHE FILEPATH
   "Order file to use when compiling clang in order to improve startup time.")
 
+if(NOT EXISTS ${CLANG_ORDER_FILE})
+  execute_process(COMMAND ${CM

r259862 - [CMake] Improve the clang order-file generation workflow

[Chris Bieneman via cfe-commits]

Author: cbieneman
Date: Thu Feb  4 19:22:03 2016
New Revision: 259862

URL: http://llvm.org/viewvc/llvm-project?rev=259862&view=rev
Log:
[CMake] Improve the clang order-file generation workflow

Summary:
With this change generating clang order files using dtrace uses the following 
workflow:

cmake 

ninja generate-order-file

ninja clang

This patch works by setting a default path to the order file (which can be 
overridden by the user). If the order file doesn't exist during configuration 
CMake will create an empty one.

CMake then ties up the dependencies between the clang link job and the order 
file, and generate-order-file overwrites CLANG_ORDER_FILE with the new order 
file.

Reviewers: bogner

Subscribers: cfe-commits

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

Modified:
cfe/trunk/CMakeLists.txt
cfe/trunk/tools/driver/CMakeLists.txt
cfe/trunk/utils/perf-training/CMakeLists.txt

Modified: cfe/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/CMakeLists.txt?rev=259862&r1=259861&r2=259862&view=diff
==
--- cfe/trunk/CMakeLists.txt (original)
+++ cfe/trunk/CMakeLists.txt Thu Feb  4 19:22:03 2016
@@ -586,9 +586,19 @@ if( CLANG_INCLUDE_DOCS )
   add_subdirectory(docs)
 endif()
 
-set(CLANG_ORDER_FILE "" CACHE FILEPATH
+# this line is needed as a cleanup to ensure that any CMakeCaches with the old
+# default value get updated to the new default.
+if(CLANG_ORDER_FILE STREQUAL "")
+  unset(CLANG_ORDER_FILE CACHE)
+endif()
+
+set(CLANG_ORDER_FILE ${CMAKE_CURRENT_BINARY_DIR}/clang.order CACHE FILEPATH
   "Order file to use when compiling clang in order to improve startup time.")
 
+if(NOT EXISTS ${CLANG_ORDER_FILE})
+  execute_process(COMMAND ${CMAKE_COMMAND} -E touch ${CLANG_ORDER_FILE})
+endif()
+
 if (CLANG_BUILT_STANDALONE OR CMAKE_VERSION VERSION_EQUAL 3 OR
 CMAKE_VERSION VERSION_GREATER 3)
   # Generate a list of CMake library targets so that other CMake projects can

Modified: cfe/trunk/tools/driver/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/driver/CMakeLists.txt?rev=259862&r1=259861&r2=259862&view=diff
==
--- cfe/trunk/tools/driver/CMakeLists.txt (original)
+++ cfe/trunk/tools/driver/CMakeLists.txt Thu Feb  4 19:22:03 2016
@@ -87,8 +87,12 @@ if (APPLE)
   set(TOOL_INFO_BUILD_VERSION)
 endif()
 
-if(CLANG_ORDER_FILE)
+check_cxx_compiler_flag("-Wl,-order_file,${CLANG_ORDER_FILE}"
+  LINKER_HAS_ORDER_FILE_FLAG)
+
+if(LINKER_HAS_ORDER_FILE_FLAG)
   target_link_libraries(clang "-Wl,-order_file,${CLANG_ORDER_FILE}")
+  set_target_properties(clang PROPERTIES LINK_DEPENDS ${CLANG_ORDER_FILE})
 endif()
 
 if(WITH_POLLY AND LINK_POLLY_INTO_TOOLS)

Modified: cfe/trunk/utils/perf-training/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/utils/perf-training/CMakeLists.txt?rev=259862&r1=259861&r2=259862&view=diff
==
--- cfe/trunk/utils/perf-training/CMakeLists.txt (original)
+++ cfe/trunk/utils/perf-training/CMakeLists.txt Thu Feb  4 19:22:03 2016
@@ -55,9 +55,8 @@ if(DTRACE)
 COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py 
clean ${CMAKE_CURRENT_BINARY_DIR} dtrace
 COMMENT "Clearing old dtrace data")
 
-
   add_custom_target(generate-order-file
-COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py 
gen-order-file --binary $ --output 
${CMAKE_CURRENT_BINARY_DIR}/clang.order ${CMAKE_CURRENT_BINARY_DIR}
+COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py 
gen-order-file --binary $ --output ${CLANG_ORDER_FILE} 
${CMAKE_CURRENT_BINARY_DIR}
 COMMENT "Generating order file"
 DEPENDS generate-dtrace-logs)
 endif()


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

r259864 - [CMake] Trying to fix a bot failure I introduced in r259862

[Chris Bieneman via cfe-commits]

Author: cbieneman
Date: Thu Feb  4 19:27:31 2016
New Revision: 259864

URL: http://llvm.org/viewvc/llvm-project?rev=259864&view=rev
Log:
[CMake] Trying to fix a bot failure I introduced in r259862

CMake caching behavior makes me sad.

Modified:
cfe/trunk/tools/driver/CMakeLists.txt

Modified: cfe/trunk/tools/driver/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/driver/CMakeLists.txt?rev=259864&r1=259863&r2=259864&view=diff
==
--- cfe/trunk/tools/driver/CMakeLists.txt (original)
+++ cfe/trunk/tools/driver/CMakeLists.txt Thu Feb  4 19:27:31 2016
@@ -90,7 +90,7 @@ endif()
 check_cxx_compiler_flag("-Wl,-order_file,${CLANG_ORDER_FILE}"
   LINKER_HAS_ORDER_FILE_FLAG)
 
-if(LINKER_HAS_ORDER_FILE_FLAG)
+if(LINKER_HAS_ORDER_FILE_FLAG AND CLANG_ORDER_FILE)
   target_link_libraries(clang "-Wl,-order_file,${CLANG_ORDER_FILE}")
   set_target_properties(clang PROPERTIES LINK_DEPENDS ${CLANG_ORDER_FILE})
 endif()


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

r259866 - [modules] Factor out common code to mark identifier being "from AST", and add a

[Richard Smith via cfe-commits]

Author: rsmith
Date: Thu Feb  4 19:40:54 2016
New Revision: 259866

URL: http://llvm.org/viewvc/llvm-project?rev=259866&view=rev
Log:
[modules] Factor out common code to mark identifier being "from AST", and add a
call in one more place to reduce the size of identifier tables in non-leaf
modules. No behavior change.

Modified:
cfe/trunk/lib/Serialization/ASTReader.cpp

Modified: cfe/trunk/lib/Serialization/ASTReader.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTReader.cpp?rev=259866&r1=259865&r2=259866&view=diff
==
--- cfe/trunk/lib/Serialization/ASTReader.cpp (original)
+++ cfe/trunk/lib/Serialization/ASTReader.cpp Thu Feb  4 19:40:54 2016
@@ -768,6 +768,15 @@ IdentID ASTIdentifierLookupTrait::ReadId
   return Reader.getGlobalIdentifierID(F, RawID >> 1);
 }
 
+static void markIdentifierFromAST(ASTReader &Reader, IdentifierInfo &II) {
+  if (!II.isFromAST()) {
+II.setIsFromAST();
+bool IsModule = Reader.getPreprocessor().getCurrentModule() != nullptr;
+if (isInterestingIdentifier(Reader, II, IsModule))
+  II.setChangedSinceDeserialization();
+  }
+}
+
 IdentifierInfo *ASTIdentifierLookupTrait::ReadData(const internal_key_type& k,
const unsigned char* d,
unsigned DataLen) {
@@ -784,12 +793,7 @@ IdentifierInfo *ASTIdentifierLookupTrait
 II = &Reader.getIdentifierTable().getOwn(k);
 KnownII = II;
   }
-  if (!II->isFromAST()) {
-II->setIsFromAST();
-bool IsModule = Reader.PP.getCurrentModule() != nullptr;
-if (isInterestingIdentifier(Reader, *II, IsModule))
-  II->setChangedSinceDeserialization();
-  }
+  markIdentifierFromAST(Reader, *II);
   Reader.markIdentifierUpToDate(II);
 
   IdentID ID = Reader.getGlobalIdentifierID(F, RawID);
@@ -3560,12 +3564,7 @@ ASTReader::ASTReadResult ASTReader::Read
 
   // Mark this identifier as being from an AST file so that we can track
   // whether we need to serialize it.
-  if (!II.isFromAST()) {
-II.setIsFromAST();
-bool IsModule = PP.getCurrentModule() != nullptr;
-if (isInterestingIdentifier(*this, II, IsModule))
-  II.setChangedSinceDeserialization();
-  }
+  markIdentifierFromAST(*this, II);
 
   // Associate the ID with the identifier so that the writer can reuse it.
   auto ID = Trait.ReadIdentifierID(Data + KeyDataLen.first);
@@ -7455,10 +7454,11 @@ IdentifierInfo *ASTReader::DecodeIdentif
 const unsigned char *StrLenPtr = (const unsigned char*) Str - 2;
 unsigned StrLen = (((unsigned) StrLenPtr[0])
| (((unsigned) StrLenPtr[1]) << 8)) - 1;
-IdentifiersLoaded[ID]
-  = &PP.getIdentifierTable().get(StringRef(Str, StrLen));
+auto &II = PP.getIdentifierTable().get(StringRef(Str, StrLen));
+IdentifiersLoaded[ID] = &II;
+markIdentifierFromAST(*this,  II);
 if (DeserializationListener)
-  DeserializationListener->IdentifierRead(ID + 1, IdentifiersLoaded[ID]);
+  DeserializationListener->IdentifierRead(ID + 1, &II);
   }
 
   return IdentifiersLoaded[ID];


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

Re: r258524 - Merge templated static member variables, fixes http://llvm.org/pr26179.

[Richard Smith via cfe-commits]

I suspect we'll need to do a little more than this: when we rebuild the
redeclaration chain, we should probably propagate the complete type to
later redeclarations in the same scope. Otherwise, if we import a module
that has a complete type and one that has an incomplete type, the
declaration found by name lookup might be the one with the incomplete type,
possibly resulting in rejects-valid on code like this:

a.h:
extern int a[5];

b.h:
extern int a[];

x.cc:
#include "a.h"
#include "b.h"
int k = sizeof(a);

On Fri, Jan 22, 2016 at 11:03 AM, Yaron Keren via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: yrnkrn
> Date: Fri Jan 22 13:03:27 2016
> New Revision: 258524
>
> URL: http://llvm.org/viewvc/llvm-project?rev=258524&view=rev
> Log:
> Merge templated static member variables, fixes http://llvm.org/pr26179.
>
> Patch by Vassil Vassilev!
> Reviewed by Richard Smith.
>
>
> Added:
> cfe/trunk/test/Modules/Inputs/PR26179/
> cfe/trunk/test/Modules/Inputs/PR26179/A.h
> cfe/trunk/test/Modules/Inputs/PR26179/B.h
> cfe/trunk/test/Modules/Inputs/PR26179/basic_string.h
> cfe/trunk/test/Modules/Inputs/PR26179/module.modulemap
> cfe/trunk/test/Modules/pr26179.cpp
> Modified:
> cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
>
> Modified: cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTReaderDecl.cpp?rev=258524&r1=258523&r2=258524&view=diff
>
> ==
> --- cfe/trunk/lib/Serialization/ASTReaderDecl.cpp (original)
> +++ cfe/trunk/lib/Serialization/ASTReaderDecl.cpp Fri Jan 22 13:03:27 2016
> @@ -2595,8 +2595,24 @@ static bool isSameEntity(NamedDecl *X, N
>// Variables with the same type and linkage match.
>if (VarDecl *VarX = dyn_cast(X)) {
>  VarDecl *VarY = cast(Y);
> -return (VarX->getLinkageInternal() == VarY->getLinkageInternal()) &&
> -  VarX->getASTContext().hasSameType(VarX->getType(), VarY->getType());
> +if (VarX->getLinkageInternal() == VarY->getLinkageInternal()) {
> +  ASTContext &C = VarX->getASTContext();
> +  if (C.hasSameType(VarX->getType(), VarY->getType()))
> +return true;
> +
> +  // We can get decls with different types on the redecl chain. Eg.
> +  // template  struct S { static T Var[]; }; // #1
> +  // template  T S::Var[sizeof(T)]; // #2
> +  // Only? happens when completing an incomplete array type. In this
> case
> +  // when comparing #1 and #2 we should go through their elements
> types.
> +  const ArrayType *VarXTy = C.getAsArrayType(VarX->getType());
> +  const ArrayType *VarYTy = C.getAsArrayType(VarY->getType());
> +  if (!VarXTy || !VarYTy)
> +return false;
> +  if (VarXTy->isIncompleteArrayType() ||
> VarYTy->isIncompleteArrayType())
> +return C.hasSameType(VarXTy->getElementType(),
> VarYTy->getElementType());
> +}
> +return false;
>}
>
>// Namespaces with the same name and inlinedness match.
>
> Added: cfe/trunk/test/Modules/Inputs/PR26179/A.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/PR26179/A.h?rev=258524&view=auto
>
> ==
> --- cfe/trunk/test/Modules/Inputs/PR26179/A.h (added)
> +++ cfe/trunk/test/Modules/Inputs/PR26179/A.h Fri Jan 22 13:03:27 2016
> @@ -0,0 +1,4 @@
> +#include "basic_string.h"
> +#include "B.h"
> +
> +int *p = a;
>
> Added: cfe/trunk/test/Modules/Inputs/PR26179/B.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/PR26179/B.h?rev=258524&view=auto
>
> ==
> --- cfe/trunk/test/Modules/Inputs/PR26179/B.h (added)
> +++ cfe/trunk/test/Modules/Inputs/PR26179/B.h Fri Jan 22 13:03:27 2016
> @@ -0,0 +1,2 @@
> +#include "basic_string.h"
> +extern int a[5];
>
> Added: cfe/trunk/test/Modules/Inputs/PR26179/basic_string.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/PR26179/basic_string.h?rev=258524&view=auto
>
> ==
> --- cfe/trunk/test/Modules/Inputs/PR26179/basic_string.h (added)
> +++ cfe/trunk/test/Modules/Inputs/PR26179/basic_string.h Fri Jan 22
> 13:03:27 2016
> @@ -0,0 +1,14 @@
> +#ifndef _GLIBCXX_STRING
> +#define _GLIBCXX_STRING 1
> +
> +template
> +struct basic_string {
> +  static T _S_empty_rep_storage[];
> +};
> +
> +template
> +T basic_string::_S_empty_rep_storage[sizeof(T)];
> +
> +extern int a[];
> +
> +#endif
>
> Added: cfe/trunk/test/Modules/Inputs/PR26179/module.modulemap
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/PR26179/module.modulemap?rev=258524&view=auto
>
> ==
> --- cfe/trunk/test/Modules/Inputs/PR26179/module.modulemap (added)
> +++ cfe/trunk/test

[PATCH] D16913: Adding doxygen comments to the LLVM intrinsics (part 4, pmmintrin.h)

[Katya Romanova via cfe-commits]

kromanova created this revision.
kromanova added reviewers: ygao, echristo, jroelofs, gribozavr, craig.topper, 
probinson.
kromanova added a subscriber: cfe-commits.
kromanova set the repository for this revision to rL LLVM.

Hello,

Here is the patch with the doxygen comments for the intrinsincs in the header 
file pmmintrin.h.
The doxygen comments are automatically generated based on SCE internal 
intrinsics document using DCG tool that I wrote.

I will submit more doxygen comments for the other intrinsic header files as 
soon as this patch is approved.

Here is the link to the general discussion about adding comments to x86 
intrinsics headers.
http://permalink.gmane.org/gmane.comp.compilers.clang.devel/42032

Here are the links to the similar code reviews for the doxygen comments other 
header files.

http://reviews.llvm.org/D8762 (closed) 
http://reviews.llvm.org/D15999 (closed)
http://reviews.llvm.org/D16562 (closed)

Katya.

Repository:
  rL LLVM

http://reviews.llvm.org/D16913

Files:
  pmmintrin.h

Index: pmmintrin.h
===
--- pmmintrin.h
+++ pmmintrin.h
@@ -27,64 +27,231 @@
 #include 
 
 /* Define the default attributes for the functions in this file. */
-#define __DEFAULT_FN_ATTRS __attribute__((__always_inline__, __nodebug__, __target__("sse3")))
+#define __DEFAULT_FN_ATTRS \
+  __attribute__((__always_inline__, __nodebug__, __target__("sse3")))
 
+/// \brief Loads data from an unaligned memory location to elements in a 128-bit
+///vector. If the address of the data is not 16-byte aligned, the 
+///instruction may read two adjacent aligned blocks of memory to retrieve 
+///the requested data. 
+///
+/// \headerfile 
+///
+/// This intrinsic corresponds to the \c VLDDQU instruction.
+///
+/// \param __p
+///A pointer to a 128-bit integer vector containing integer values.
+/// \returns A 128-bit vector containing the moved values.
 static __inline__ __m128i __DEFAULT_FN_ATTRS
 _mm_lddqu_si128(__m128i const *__p)
 {
   return (__m128i)__builtin_ia32_lddqu((char const *)__p);
 }
 
+/// \brief Adds the even-indexed values and subtracts the odd-indexed values of
+///two 128-bit vectors of [4 x float].
+///
+/// \headerfile 
+///
+/// This intrinsic corresponds to the \c VADDSUBPS instruction.
+///
+/// \param __a
+///A 128-bit vector of [4 x float] containing the left source operand.
+/// \param __b
+///A 128-bit vector of [4 x float] containing the right source operand.
+/// \returns A 128-bit vector of [4 x float] containing the alternating sums and
+///differences of both operands.
 static __inline__ __m128 __DEFAULT_FN_ATTRS
 _mm_addsub_ps(__m128 __a, __m128 __b)
 {
   return __builtin_ia32_addsubps(__a, __b);
 }
 
+/// \brief Horizontally adds the adjacent pairs of values contained in two
+///128-bit vectors of [4 x float].
+///
+/// \headerfile 
+///
+/// This intrinsic corresponds to the \c VHADDPS instruction.
+///
+/// \param __a
+///A 128-bit vector of [4 x float] containing one of the source operands. 
+///The horizontal sums of the values are stored in the lower bits of the 
+///destination.
+/// \param __b
+///A 128-bit vector of [4 x float] containing one of the source operands. 
+///The horizontal sums of the values are stored in the upper bits of the 
+///destination.
+/// \returns A 128-bit vector of [4 x float] containing the horizontal sums of 
+///both operands.
 static __inline__ __m128 __DEFAULT_FN_ATTRS
 _mm_hadd_ps(__m128 __a, __m128 __b)
 {
   return __builtin_ia32_haddps(__a, __b);
 }
 
+/// \brief Horizontally subtracts the adjacent pairs of values contained in two
+///128-bit vectors of [4 x float].
+///
+/// \headerfile 
+///
+/// This intrinsic corresponds to the \c VHSUBPS instruction.
+///
+/// \param __a
+///A 128-bit vector of [4 x float] containing one of the source operands. 
+///The horizontal differences between the values are stored in the lower 
+///bits of the destination.
+/// \param __b
+///A 128-bit vector of [4 x float] containing one of the source operands. 
+///The horizontal differences between the values are stored in the upper 
+///bits of the destination.
+/// \returns A 128-bit vector of [4 x float] containing the horizontal 
+///differences of both operands.
 static __inline__ __m128 __DEFAULT_FN_ATTRS
 _mm_hsub_ps(__m128 __a, __m128 __b)
 {
   return __builtin_ia32_hsubps(__a, __b);
 }
 
+/// \brief Moves and duplicates high-order (odd-indexed) values from a 128-bit
+///vector of [4 x float] to float values stored in a 128-bit vector of
+///[4 x float].
+///Bits [127:96] of the source are written to bits [127:96] and [95:64] of
+///the destination.
+///Bits [63:32] of the source are written to bits [63:32] and [31:0] of the
+///destination.
+///
+/// \headerfile 
+///
+/// This intrinsic corresponds to the \c VMOVSHDUP instruction.
+///
+/// \param __a
+///A 128-bi

Re: r259862 - [CMake] Improve the clang order-file generation workflow

[Richard Smith via cfe-commits]

This is causing my links to fail with:

FAILED: : && /usr/local/google/home/richardsmith/bin/clang++
-fcolor-diagnostics -std=c++11 -stdlib=libc++ -fPIC
-fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings
-Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long
-Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor
-std=c++11 -fcolor-diagnostics -fno-common -Woverloaded-virtual
-Wno-nested-anon-types -g  -Wl,-allow-shlib-undefined
-Wl,--export-dynamic
tools/clang/tools/driver/CMakeFiles/clang.dir/driver.cpp.o
tools/clang/tools/driver/CMakeFiles/clang.dir/cc1_main.cpp.o
tools/clang/tools/driver/CMakeFiles/clang.dir/cc1as_main.cpp.o  -o
bin/clang-3.8  lib/libLLVMAArch64CodeGen.a lib/libLLVMAArch64AsmPrinter.a
lib/libLLVMAArch64AsmParser.a lib/libLLVMAArch64Desc.a
lib/libLLVMAArch64Info.a lib/libLLVMAArch64Disassembler.a
lib/libLLVMAMDGPUCodeGen.a lib/libLLVMAMDGPUAsmPrinter.a
lib/libLLVMAMDGPUAsmParser.a lib/libLLVMAMDGPUDesc.a
lib/libLLVMAMDGPUInfo.a lib/libLLVMARMCodeGen.a lib/libLLVMARMAsmPrinter.a
lib/libLLVMARMAsmParser.a lib/libLLVMARMDesc.a lib/libLLVMARMInfo.a
lib/libLLVMARMDisassembler.a lib/libLLVMBPFCodeGen.a
lib/libLLVMBPFAsmPrinter.a lib/libLLVMBPFDesc.a lib/libLLVMBPFInfo.a
lib/libLLVMCppBackendCodeGen.a lib/libLLVMCppBackendInfo.a
lib/libLLVMHexagonCodeGen.a lib/libLLVMHexagonAsmParser.a
lib/libLLVMHexagonDesc.a lib/libLLVMHexagonInfo.a
lib/libLLVMHexagonDisassembler.a lib/libLLVMMipsCodeGen.a
lib/libLLVMMipsAsmPrinter.a lib/libLLVMMipsAsmParser.a
lib/libLLVMMipsDesc.a lib/libLLVMMipsInfo.a lib/libLLVMMipsDisassembler.a
lib/libLLVMMSP430CodeGen.a lib/libLLVMMSP430AsmPrinter.a
lib/libLLVMMSP430Desc.a lib/libLLVMMSP430Info.a lib/libLLVMNVPTXCodeGen.a
lib/libLLVMNVPTXAsmPrinter.a lib/libLLVMNVPTXDesc.a lib/libLLVMNVPTXInfo.a
lib/libLLVMPowerPCCodeGen.a lib/libLLVMPowerPCAsmPrinter.a
lib/libLLVMPowerPCAsmParser.a lib/libLLVMPowerPCDesc.a
lib/libLLVMPowerPCInfo.a lib/libLLVMPowerPCDisassembler.a
lib/libLLVMSparcCodeGen.a lib/libLLVMSparcAsmPrinter.a
lib/libLLVMSparcAsmParser.a lib/libLLVMSparcDesc.a lib/libLLVMSparcInfo.a
lib/libLLVMSparcDisassembler.a lib/libLLVMSystemZCodeGen.a
lib/libLLVMSystemZAsmPrinter.a lib/libLLVMSystemZAsmParser.a
lib/libLLVMSystemZDesc.a lib/libLLVMSystemZInfo.a
lib/libLLVMSystemZDisassembler.a lib/libLLVMX86CodeGen.a
lib/libLLVMX86AsmPrinter.a lib/libLLVMX86AsmParser.a lib/libLLVMX86Desc.a
lib/libLLVMX86Info.a lib/libLLVMX86Disassembler.a lib/libLLVMXCoreCodeGen.a
lib/libLLVMXCoreAsmPrinter.a lib/libLLVMXCoreDesc.a lib/libLLVMXCoreInfo.a
lib/libLLVMXCoreDisassembler.a lib/libLLVMAnalysis.a lib/libLLVMCodeGen.a
lib/libLLVMCore.a lib/libLLVMipo.a lib/libLLVMInstCombine.a
lib/libLLVMInstrumentation.a lib/libLLVMMC.a lib/libLLVMMCParser.a
lib/libLLVMObjCARCOpts.a lib/libLLVMOption.a lib/libLLVMScalarOpts.a
lib/libLLVMSupport.a lib/libLLVMTransformUtils.a lib/libLLVMVectorize.a
lib/libclangBasic.a lib/libclangCodeGen.a lib/libclangDriver.a
lib/libclangFrontend.a lib/libclangFrontendTool.a
-Wl,-order_file,/usr/local/google/home/richardsmith/clang-8/build/tools/clang/clang.order
lib/libLLVMAArch64Desc.a lib/libLLVMAArch64AsmPrinter.a
lib/libLLVMAArch64Info.a lib/libLLVMAArch64Utils.a
lib/libLLVMAMDGPUAsmPrinter.a lib/libLLVMAMDGPUUtils.a lib/libLLVMARMDesc.a
lib/libLLVMARMAsmPrinter.a lib/libLLVMARMInfo.a lib/libLLVMBPFAsmPrinter.a
lib/libLLVMHexagonDesc.a lib/libLLVMHexagonInfo.a
lib/libLLVMMipsAsmPrinter.a lib/libLLVMMipsInfo.a
lib/libLLVMMSP430AsmPrinter.a lib/libLLVMNVPTXAsmPrinter.a
lib/libLLVMPowerPCAsmPrinter.a lib/libLLVMPowerPCInfo.a
lib/libLLVMSparcAsmPrinter.a lib/libLLVMSparcInfo.a
lib/libLLVMSystemZDesc.a lib/libLLVMSystemZAsmPrinter.a
lib/libLLVMSystemZInfo.a lib/libLLVMX86AsmPrinter.a lib/libLLVMX86Utils.a
lib/libLLVMX86Info.a lib/libLLVMXCoreAsmPrinter.a lib/libLLVMAsmPrinter.a
lib/libLLVMDebugInfoCodeView.a lib/libLLVMSelectionDAG.a
lib/libLLVMCodeGen.a lib/libLLVMXCoreInfo.a lib/libLLVMMCDisassembler.a
lib/libclangCodeGen.a lib/libLLVMipo.a lib/libLLVMVectorize.a
lib/libLLVMInstrumentation.a lib/libLLVMObjCARCOpts.a
lib/libLLVMScalarOpts.a lib/libLLVMInstCombine.a lib/libLLVMTarget.a
lib/libLLVMBitWriter.a lib/libLLVMIRReader.a lib/libLLVMAsmParser.a
lib/libLLVMLinker.a lib/libLLVMTransformUtils.a lib/libLLVMAnalysis.a
lib/libLLVMProfileData.a lib/libLLVMObject.a lib/libclangRewriteFrontend.a
lib/libclangARCMigrate.a lib/libclangStaticAnalyzerFrontend.a
lib/libclangFrontend.a lib/libclangDriver.a lib/libLLVMOption.a
lib/libclangParse.a lib/libLLVMMCParser.a lib/libclangSerialization.a
lib/libLLVMBitReader.a lib/libclangSema.a lib/libclangEdit.a
lib/libclangStaticAnalyzerCheckers.a lib/libclangStaticAnalyzerCore.a
lib/libclangAnalysis.a lib/libclangAST.a lib/libclangRewrite.a
lib/libclangLex.a lib/libclangBasic.a lib/libLLVMCore.a lib/libLLVMMC.a
lib/libLLVMSupport.a -lrt -ldl -ltinfo -lpthread -lz -lm
-Wl,-rpath,"\$ORIGIN/../lib" && :
/usr/local/google/home/richardsmith/clang-8/build/tools/clang/clang.order:
file 

Re: [PATCH] D16876: [OpenCL] Refine pipe builtin support

[Xiuli PAN via cfe-commits]

pxli168 updated this revision to Diff 46991.

http://reviews.llvm.org/D16876

Files:
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/Sema/SemaChecking.cpp
  test/SemaOpenCL/invalid-pipe-builtin-cl2.0.cl

Index: test/SemaOpenCL/invalid-pipe-builtin-cl2.0.cl
===
--- test/SemaOpenCL/invalid-pipe-builtin-cl2.0.cl
+++ test/SemaOpenCL/invalid-pipe-builtin-cl2.0.cl
@@ -5,51 +5,51 @@
   reserve_id_t rid;
 
   // read/write_pipe
-  read_pipe(tmp, p);// expected-error {{first argument to read_pipe must be a pipe type}}
-  read_pipe(p);   // expected-error {{invalid number of arguments to function: read_pipe}}
-  read_pipe(p, tmp, tmp, ptr);   // expected-error {{invalid argument type to function read_pipe (expecting 'reserve_id_t')}}
-  read_pipe(p, rid, rid, ptr);   // expected-error {{invalid argument type to function read_pipe (expecting 'unsigned int')}}
-  read_pipe(p, tmp);   // expected-error {{invalid argument type to function read_pipe (expecting 'int *')}}
+  read_pipe(tmp, p);// expected-error {{first argument to 'read_pipe' must be a pipe type}}
+  read_pipe(p);   // expected-error {{invalid number of arguments to function: 'read_pipe'}}
+  read_pipe(p, tmp, tmp, ptr);   // expected-error {{invalid argument type to function 'read_pipe' (expecting 'reserve_id_t')}}
+  read_pipe(p, rid, rid, ptr);   // expected-error {{invalid argument type to function 'read_pipe' (expecting 'unsigned int')}}
+  read_pipe(p, tmp);   // expected-error {{invalid argument type to function 'read_pipe' (expecting 'int *')}}
   write_pipe(p, ptr);// expected-error {{invalid pipe access modifier (expecting write_only)}}
   write_pipe(p, rid, tmp, ptr);// expected-error {{invalid pipe access modifier (expecting write_only)}}
 
   // reserve_read/write_pipe
-  reserve_read_pipe(p, ptr);// expected-error{{invalid argument type to function reserve_read_pipe (expecting 'unsigned int')}}
-  work_group_reserve_read_pipe(tmp, tmp);// expected-error{{first argument to work_group_reserve_read_pipe must be a pipe type}}
+  reserve_read_pipe(p, ptr);// expected-error{{invalid argument type to function 'reserve_read_pipe' (expecting 'unsigned int')}}
+  work_group_reserve_read_pipe(tmp, tmp);// expected-error{{first argument to 'work_group_reserve_read_pipe' must be a pipe type}}
   sub_group_reserve_write_pipe(p, tmp);// expected-error{{invalid pipe access modifier (expecting write_only)}}
 
   // commit_read/write_pipe
-  commit_read_pipe(tmp, rid);// expected-error{{first argument to commit_read_pipe must be a pipe type}}
-  work_group_commit_read_pipe(p, tmp);// expected-error{{invalid argument type to function work_group_commit_read_pipe (expecting 'reserve_id_t')}}
+  commit_read_pipe(tmp, rid);// expected-error{{first argument to 'commit_read_pipe' must be a pipe type}}
+  work_group_commit_read_pipe(p, tmp);// expected-error{{invalid argument type to function 'work_group_commit_read_pipe' (expecting 'reserve_id_t')}}
   sub_group_commit_write_pipe(p, tmp);// expected-error{{nvalid pipe access modifier (expecting write_only)}}
 }
 
 void test2(write_only pipe int p, global int* ptr){
   int tmp;
   reserve_id_t rid;
 
   // read/write_pipe
-  write_pipe(tmp, p);// expected-error {{first argument to write_pipe must be a pipe type}}
-  write_pipe(p);   // expected-error {{invalid number of arguments to function: write_pipe}}
-  write_pipe(p, tmp, tmp, ptr);   // expected-error {{invalid argument type to function write_pipe (expecting 'reserve_id_t')}}
-  write_pipe(p, rid, rid, ptr);   // expected-error {{invalid argument type to function write_pipe (expecting 'unsigned int')}}
-  write_pipe(p, tmp);   // expected-error {{invalid argument type to function write_pipe (expecting 'int *')}}
+  write_pipe(tmp, p);// expected-error {{first argument to 'write_pipe' must be a pipe type}}
+  write_pipe(p);   // expected-error {{invalid number of arguments to function: 'write_pipe'}}
+  write_pipe(p, tmp, tmp, ptr);   // expected-error {{invalid argument type to function 'write_pipe' (expecting 'reserve_id_t')}}
+  write_pipe(p, rid, rid, ptr);   // expected-error {{invalid argument type to function 'write_pipe' (expecting 'unsigned int')}}
+  write_pipe(p, tmp);   // expected-error {{invalid argument type to function 'write_pipe' (expecting 'int *')}}
   read_pipe(p, ptr);// expected-error {{invalid pipe access modifier (expecting read_only)}}
   read_pipe(p, rid, tmp, ptr);// expected-error {{invalid pipe access modifier (expecting read_only)}}
 
   // reserve_read/write_pipe
-  reserve_write_pipe(p, ptr);// expected-error{{invalid argument type to function reserve_write_pipe (expecting 'unsigned int')}}
-  work_group_reserve_write_pipe(tmp, tmp);// expected-error{{first argument to work_group_reserve_write_pipe must be a pipe type}}
+  reserve_write_pipe(p, ptr);// expected-error{{invalid argume

Re: [PATCH] D16876: [OpenCL] Refine pipe builtin support

[Xiuli PAN via cfe-commits]

pxli168 requested a review of this revision.


Comment at: lib/Sema/SemaChecking.cpp:343
@@ -332,3 +342,3 @@
   // Two kinds of read/write pipe
   // From OpenCL C Specification 6.13.16.2 the built-in read/write
   // functions have following forms.

yaxunl wrote:
> should this follow the convention? e.g.
> OpenCL v2.0 s6.13.16.2 - 
right, this will be more clear.


http://reviews.llvm.org/D16876



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

Re: r259862 - [CMake] Improve the clang order-file generation workflow

[Chris Bieneman via cfe-commits]

What linker are you using and on what OS? I’m looking at this now, and will 
revert if I can’t find a solution.

-Chris

> On Feb 4, 2016, at 6:38 PM, Richard Smith  wrote:
> 
> This is causing my links to fail with:
> 
> FAILED: : && /usr/local/google/home/richardsmith/bin/clang++   
> -fcolor-diagnostics -std=c++11 -stdlib=libc++ -fPIC 
> -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings 
> -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long 
> -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor 
> -std=c++11 -fcolor-diagnostics -fno-common -Woverloaded-virtual 
> -Wno-nested-anon-types -g  -Wl,-allow-shlib-undefined   -Wl,--export-dynamic 
> tools/clang/tools/driver/CMakeFiles/clang.dir/driver.cpp.o 
> tools/clang/tools/driver/CMakeFiles/clang.dir/cc1_main.cpp.o 
> tools/clang/tools/driver/CMakeFiles/clang.dir/cc1as_main.cpp.o  -o 
> bin/clang-3.8  lib/libLLVMAArch64CodeGen.a lib/libLLVMAArch64AsmPrinter.a 
> lib/libLLVMAArch64AsmParser.a lib/libLLVMAArch64Desc.a 
> lib/libLLVMAArch64Info.a lib/libLLVMAArch64Disassembler.a 
> lib/libLLVMAMDGPUCodeGen.a lib/libLLVMAMDGPUAsmPrinter.a 
> lib/libLLVMAMDGPUAsmParser.a lib/libLLVMAMDGPUDesc.a lib/libLLVMAMDGPUInfo.a 
> lib/libLLVMARMCodeGen.a lib/libLLVMARMAsmPrinter.a lib/libLLVMARMAsmParser.a 
> lib/libLLVMARMDesc.a lib/libLLVMARMInfo.a lib/libLLVMARMDisassembler.a 
> lib/libLLVMBPFCodeGen.a lib/libLLVMBPFAsmPrinter.a lib/libLLVMBPFDesc.a 
> lib/libLLVMBPFInfo.a lib/libLLVMCppBackendCodeGen.a 
> lib/libLLVMCppBackendInfo.a lib/libLLVMHexagonCodeGen.a 
> lib/libLLVMHexagonAsmParser.a lib/libLLVMHexagonDesc.a 
> lib/libLLVMHexagonInfo.a lib/libLLVMHexagonDisassembler.a 
> lib/libLLVMMipsCodeGen.a lib/libLLVMMipsAsmPrinter.a 
> lib/libLLVMMipsAsmParser.a lib/libLLVMMipsDesc.a lib/libLLVMMipsInfo.a 
> lib/libLLVMMipsDisassembler.a lib/libLLVMMSP430CodeGen.a 
> lib/libLLVMMSP430AsmPrinter.a lib/libLLVMMSP430Desc.a lib/libLLVMMSP430Info.a 
> lib/libLLVMNVPTXCodeGen.a lib/libLLVMNVPTXAsmPrinter.a lib/libLLVMNVPTXDesc.a 
> lib/libLLVMNVPTXInfo.a lib/libLLVMPowerPCCodeGen.a 
> lib/libLLVMPowerPCAsmPrinter.a lib/libLLVMPowerPCAsmParser.a 
> lib/libLLVMPowerPCDesc.a lib/libLLVMPowerPCInfo.a 
> lib/libLLVMPowerPCDisassembler.a lib/libLLVMSparcCodeGen.a 
> lib/libLLVMSparcAsmPrinter.a lib/libLLVMSparcAsmParser.a 
> lib/libLLVMSparcDesc.a lib/libLLVMSparcInfo.a lib/libLLVMSparcDisassembler.a 
> lib/libLLVMSystemZCodeGen.a lib/libLLVMSystemZAsmPrinter.a 
> lib/libLLVMSystemZAsmParser.a lib/libLLVMSystemZDesc.a 
> lib/libLLVMSystemZInfo.a lib/libLLVMSystemZDisassembler.a 
> lib/libLLVMX86CodeGen.a lib/libLLVMX86AsmPrinter.a lib/libLLVMX86AsmParser.a 
> lib/libLLVMX86Desc.a lib/libLLVMX86Info.a lib/libLLVMX86Disassembler.a 
> lib/libLLVMXCoreCodeGen.a lib/libLLVMXCoreAsmPrinter.a lib/libLLVMXCoreDesc.a 
> lib/libLLVMXCoreInfo.a lib/libLLVMXCoreDisassembler.a lib/libLLVMAnalysis.a 
> lib/libLLVMCodeGen.a lib/libLLVMCore.a lib/libLLVMipo.a 
> lib/libLLVMInstCombine.a lib/libLLVMInstrumentation.a lib/libLLVMMC.a 
> lib/libLLVMMCParser.a lib/libLLVMObjCARCOpts.a lib/libLLVMOption.a 
> lib/libLLVMScalarOpts.a lib/libLLVMSupport.a lib/libLLVMTransformUtils.a 
> lib/libLLVMVectorize.a lib/libclangBasic.a lib/libclangCodeGen.a 
> lib/libclangDriver.a lib/libclangFrontend.a lib/libclangFrontendTool.a 
> -Wl,-order_file,/usr/local/google/home/richardsmith/clang-8/build/tools/clang/clang.order
>  lib/libLLVMAArch64Desc.a lib/libLLVMAArch64AsmPrinter.a 
> lib/libLLVMAArch64Info.a lib/libLLVMAArch64Utils.a 
> lib/libLLVMAMDGPUAsmPrinter.a lib/libLLVMAMDGPUUtils.a lib/libLLVMARMDesc.a 
> lib/libLLVMARMAsmPrinter.a lib/libLLVMARMInfo.a lib/libLLVMBPFAsmPrinter.a 
> lib/libLLVMHexagonDesc.a lib/libLLVMHexagonInfo.a lib/libLLVMMipsAsmPrinter.a 
> lib/libLLVMMipsInfo.a lib/libLLVMMSP430AsmPrinter.a 
> lib/libLLVMNVPTXAsmPrinter.a lib/libLLVMPowerPCAsmPrinter.a 
> lib/libLLVMPowerPCInfo.a lib/libLLVMSparcAsmPrinter.a lib/libLLVMSparcInfo.a 
> lib/libLLVMSystemZDesc.a lib/libLLVMSystemZAsmPrinter.a 
> lib/libLLVMSystemZInfo.a lib/libLLVMX86AsmPrinter.a lib/libLLVMX86Utils.a 
> lib/libLLVMX86Info.a lib/libLLVMXCoreAsmPrinter.a lib/libLLVMAsmPrinter.a 
> lib/libLLVMDebugInfoCodeView.a lib/libLLVMSelectionDAG.a lib/libLLVMCodeGen.a 
> lib/libLLVMXCoreInfo.a lib/libLLVMMCDisassembler.a lib/libclangCodeGen.a 
> lib/libLLVMipo.a lib/libLLVMVectorize.a lib/libLLVMInstrumentation.a 
> lib/libLLVMObjCARCOpts.a lib/libLLVMScalarOpts.a lib/libLLVMInstCombine.a 
> lib/libLLVMTarget.a lib/libLLVMBitWriter.a lib/libLLVMIRReader.a 
> lib/libLLVMAsmParser.a lib/libLLVMLinker.a lib/libLLVMTransformUtils.a 
> lib/libLLVMAnalysis.a lib/libLLVMProfileData.a lib/libLLVMObject.a 
> lib/libclangRewriteFrontend.a lib/libclangARCMigrate.a 
> lib/libclangStaticAnalyzerFrontend.a lib/libclangFrontend.a 
> lib/libclangDriver.a lib/libLLVMOption.a lib/libclangParse.a 
> lib/libLLVMMCParser.a lib/libclangSerialization.a lib/libLLVMBitReader.a 
> lib/libclangSema.a li

Re: [PATCH] D16913: Adding doxygen comments to the LLVM intrinsics (part 4, pmmintrin.h)

[Eric Christopher via cfe-commits]

(Without looking)

Please go ahead and feel free to commit any documentation to the intrinsic
files. :)

On Thu, Feb 4, 2016, 5:59 PM Katya Romanova <
katya_roman...@playstation.sony.com> wrote:

> kromanova created this revision.
> kromanova added reviewers: ygao, echristo, jroelofs, gribozavr,
> craig.topper, probinson.
> kromanova added a subscriber: cfe-commits.
> kromanova set the repository for this revision to rL LLVM.
>
> Hello,
>
> Here is the patch with the doxygen comments for the intrinsincs in the
> header file pmmintrin.h.
> The doxygen comments are automatically generated based on SCE internal
> intrinsics document using DCG tool that I wrote.
>
> I will submit more doxygen comments for the other intrinsic header files
> as soon as this patch is approved.
>
> Here is the link to the general discussion about adding comments to x86
> intrinsics headers.
> http://permalink.gmane.org/gmane.comp.compilers.clang.devel/42032
>
> Here are the links to the similar code reviews for the doxygen comments
> other header files.
>
> http://reviews.llvm.org/D8762 (closed)
> http://reviews.llvm.org/D15999 (closed)
> http://reviews.llvm.org/D16562 (closed)
>
> Katya.
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D16913
>
> Files:
>   pmmintrin.h
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

RE: [PATCH] D16913: Adding doxygen comments to the LLVM intrinsics (part 4, pmmintrin.h)

[Romanova, Katya via cfe-commits]

Thank you!
Paul Robinson did a very detailed code review yesterday, so I suspect that this 
doxygen comment patch is of very good quality. ☺
Katya.

From: Eric Christopher [mailto:echri...@gmail.com]
Sent: Thursday, February 04, 2016 6:47 PM
To: reviews+d16913+public+13cb39057c425...@reviews.llvm.org; Romanova, Katya; 
Gao, Yunzhong; jonat...@codesourcery.com; griboz...@gmail.com; 
craig.top...@gmail.com; Robinson, Paul
Cc: cfe-commits@lists.llvm.org
Subject: Re: [PATCH] D16913: Adding doxygen comments to the LLVM intrinsics 
(part 4, pmmintrin.h)


(Without looking)

Please go ahead and feel free to commit any documentation to the intrinsic 
files. :)

On Thu, Feb 4, 2016, 5:59 PM Katya Romanova 
mailto:katya_roman...@playstation.sony.com>>
 wrote:
kromanova created this revision.
kromanova added reviewers: ygao, echristo, jroelofs, gribozavr, craig.topper, 
probinson.
kromanova added a subscriber: cfe-commits.
kromanova set the repository for this revision to rL LLVM.

Hello,

Here is the patch with the doxygen comments for the intrinsincs in the header 
file pmmintrin.h.
The doxygen comments are automatically generated based on SCE internal 
intrinsics document using DCG tool that I wrote.

I will submit more doxygen comments for the other intrinsic header files as 
soon as this patch is approved.

Here is the link to the general discussion about adding comments to x86 
intrinsics headers.
http://permalink.gmane.org/gmane.comp.compilers.clang.devel/42032

Here are the links to the similar code reviews for the doxygen comments other 
header files.

http://reviews.llvm.org/D8762 (closed)
http://reviews.llvm.org/D15999 (closed)
http://reviews.llvm.org/D16562 (closed)

Katya.

Repository:
  rL LLVM

http://reviews.llvm.org/D16913

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

Re: [PATCH] D16913: Adding doxygen comments to the LLVM intrinsics (part 4, pmmintrin.h)

[Eric Christopher via cfe-commits]

:)

We can look at them/deal with them in post-commit review from here on out.
No need to block on me.

-eric

On Thu, Feb 4, 2016 at 6:50 PM Romanova, Katya <
katya_roman...@playstation.sony.com> wrote:

> Thank you!
>
> Paul Robinson did a very detailed code review yesterday, so I suspect that
> this doxygen comment patch is of very good quality. J
>
> Katya.
>
>
>
> *From:* Eric Christopher [mailto:echri...@gmail.com]
> *Sent:* Thursday, February 04, 2016 6:47 PM
> *To:* reviews+d16913+public+13cb39057c425...@reviews.llvm.org; Romanova,
> Katya; Gao, Yunzhong; jonat...@codesourcery.com; griboz...@gmail.com;
> craig.top...@gmail.com; Robinson, Paul
> *Cc:* cfe-commits@lists.llvm.org
> *Subject:* Re: [PATCH] D16913: Adding doxygen comments to the LLVM
> intrinsics (part 4, pmmintrin.h)
>
>
>
> (Without looking)
>
> Please go ahead and feel free to commit any documentation to the intrinsic
> files. :)
>
>
>
> On Thu, Feb 4, 2016, 5:59 PM Katya Romanova <
> katya_roman...@playstation.sony.com> wrote:
>
> kromanova created this revision.
> kromanova added reviewers: ygao, echristo, jroelofs, gribozavr,
> craig.topper, probinson.
> kromanova added a subscriber: cfe-commits.
> kromanova set the repository for this revision to rL LLVM.
>
> Hello,
>
> Here is the patch with the doxygen comments for the intrinsincs in the
> header file pmmintrin.h.
> The doxygen comments are automatically generated based on SCE internal
> intrinsics document using DCG tool that I wrote.
>
> I will submit more doxygen comments for the other intrinsic header files
> as soon as this patch is approved.
>
> Here is the link to the general discussion about adding comments to x86
> intrinsics headers.
> http://permalink.gmane.org/gmane.comp.compilers.clang.devel/42032
>
> Here are the links to the similar code reviews for the doxygen comments
> other header files.
>
> http://reviews.llvm.org/D8762 (closed)
> http://reviews.llvm.org/D15999 (closed)
> http://reviews.llvm.org/D16562 (closed)
>
> Katya.
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D16913
>
> Files:
>   pmmintrin.h
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D16914: [CodeGen] Fix an assert in CodeGenFunction::EmitFunctionEpilog

[Akira Hatanaka via cfe-commits]

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

The assert near CGCall.cpp:2465 is triggered because 
QualType::isObjCRetainableType() is called on different types. In 
CodeGenFunction::StartFunction, it returns true because it is called on the 
typedef marked with __attribute__((NSObject)), whereas in 
CodeGenFunction::EmitFunctionEpilog it returns false because it's called on the 
canonical type.

To fix the assert, this patch changes the code in 
CodeGenFunction::EmitFunctionEpilog to get the function's return type from 
CodeGenFunction::CurCodeDecl or BlockInfo instead of from CGFunctionInfo.

http://reviews.llvm.org/D16914

Files:
  lib/CodeGen/CGCall.cpp
  test/CodeGenObjCXX/auto-release-result-assert.mm

Index: test/CodeGenObjCXX/auto-release-result-assert.mm
===
--- /dev/null
+++ test/CodeGenObjCXX/auto-release-result-assert.mm
@@ -0,0 +1,35 @@
+// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -emit-llvm -fblocks 
-fobjc-arc -o - %s | FileCheck %s
+
+// CHECK-LABEL: define %struct.S1* @_Z4foo1i(
+// CHECK: %[[CALL:[a-z0-9]+]] = call %struct.S1* @_Z4foo0i
+// CHECK: ret %struct.S1* %[[CALL]]
+
+// CHECK-LABEL: define %struct.S1* @_ZN2S22m1Ev(
+// CHECK: %[[CALL:[a-z0-9]+]] = call %struct.S1* @_Z4foo0i
+// CHECK: ret %struct.S1* %[[CALL]]
+
+// CHECK-LABEL: define internal %struct.S1* @Block1_block_invoke(
+// CHECK: %[[CALL:[a-z0-9]+]] = call %struct.S1* @_Z4foo0i
+// CHECK: ret %struct.S1* %[[CALL]]
+
+struct S1;
+
+typedef __attribute__((NSObject)) struct __attribute__((objc_bridge(id))) S1 * 
S1Ref;
+
+S1Ref foo0(int);
+
+struct S2 {
+  S1Ref m1();
+};
+
+S1Ref foo1(int a) {
+  return foo0(a);
+}
+
+S1Ref S2::m1() {
+  return foo0(0);
+}
+
+S1Ref (^Block1)(void) = ^{
+  return foo0(0);
+};
Index: lib/CodeGen/CGCall.cpp
===
--- lib/CodeGen/CGCall.cpp
+++ lib/CodeGen/CGCall.cpp
@@ -14,6 +14,7 @@
 
 #include "CGCall.h"
 #include "ABIInfo.h"
+#include "CGBlocks.h"
 #include "CGCXXABI.h"
 #include "CGCleanup.h"
 #include "CodeGenFunction.h"
@@ -2462,9 +2463,21 @@
 // In ARC, end functions that return a retainable type with a call
 // to objc_autoreleaseReturnValue.
 if (AutoreleaseResult) {
+  QualType RT;
+
+  if (auto *FD = dyn_cast(CurCodeDecl))
+RT = FD->getReturnType();
+  else if (auto *MD = dyn_cast(CurCodeDecl))
+RT = MD->getReturnType();
+  else if (isa(CurCodeDecl))
+RT = BlockInfo->BlockExpression->getFunctionType()->getReturnType();
+  else
+llvm_unreachable("Unexpected function/method type");
+
+  (void)RT;
   assert(getLangOpts().ObjCAutoRefCount &&
  !FI.isReturnsRetained() &&
- RetTy->isObjCRetainableType());
+ RT->isObjCRetainableType());
   RV = emitAutoreleaseOfResult(*this, RV);
 }
 


Index: test/CodeGenObjCXX/auto-release-result-assert.mm
===
--- /dev/null
+++ test/CodeGenObjCXX/auto-release-result-assert.mm
@@ -0,0 +1,35 @@
+// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -emit-llvm -fblocks -fobjc-arc -o - %s | FileCheck %s
+
+// CHECK-LABEL: define %struct.S1* @_Z4foo1i(
+// CHECK: %[[CALL:[a-z0-9]+]] = call %struct.S1* @_Z4foo0i
+// CHECK: ret %struct.S1* %[[CALL]]
+
+// CHECK-LABEL: define %struct.S1* @_ZN2S22m1Ev(
+// CHECK: %[[CALL:[a-z0-9]+]] = call %struct.S1* @_Z4foo0i
+// CHECK: ret %struct.S1* %[[CALL]]
+
+// CHECK-LABEL: define internal %struct.S1* @Block1_block_invoke(
+// CHECK: %[[CALL:[a-z0-9]+]] = call %struct.S1* @_Z4foo0i
+// CHECK: ret %struct.S1* %[[CALL]]
+
+struct S1;
+
+typedef __attribute__((NSObject)) struct __attribute__((objc_bridge(id))) S1 * S1Ref;
+
+S1Ref foo0(int);
+
+struct S2 {
+  S1Ref m1();
+};
+
+S1Ref foo1(int a) {
+  return foo0(a);
+}
+
+S1Ref S2::m1() {
+  return foo0(0);
+}
+
+S1Ref (^Block1)(void) = ^{
+  return foo0(0);
+};
Index: lib/CodeGen/CGCall.cpp
===
--- lib/CodeGen/CGCall.cpp
+++ lib/CodeGen/CGCall.cpp
@@ -14,6 +14,7 @@
 
 #include "CGCall.h"
 #include "ABIInfo.h"
+#include "CGBlocks.h"
 #include "CGCXXABI.h"
 #include "CGCleanup.h"
 #include "CodeGenFunction.h"
@@ -2462,9 +2463,21 @@
 // In ARC, end functions that return a retainable type with a call
 // to objc_autoreleaseReturnValue.
 if (AutoreleaseResult) {
+  QualType RT;
+
+  if (auto *FD = dyn_cast(CurCodeDecl))
+RT = FD->getReturnType();
+  else if (auto *MD = dyn_cast(CurCodeDecl))
+RT = MD->getReturnType();
+  else if (isa(CurCodeDecl))
+RT = BlockInfo->BlockExpression->getFunctionType()->getReturnType();
+  else
+llvm_unreachable("Unexpected function/method type");
+
+  (void)RT;
   assert(getLangOpts().ObjCAutoRefCount &&
  !FI.isReturnsRetained() &&
- RetTy->isObjCRetainableTy

r259870 - [CMake] Speculative fix for linker error on Linux

[Chris Bieneman via cfe-commits]

Author: cbieneman
Date: Thu Feb  4 20:51:33 2016
New Revision: 259870

URL: http://llvm.org/viewvc/llvm-project?rev=259870&view=rev
Log:
[CMake] Speculative fix for linker error on Linux

I can't reproduce this locally, but I think this may fix it.

Modified:
cfe/trunk/CMakeLists.txt

Modified: cfe/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/CMakeLists.txt?rev=259870&r1=259869&r2=259870&view=diff
==
--- cfe/trunk/CMakeLists.txt (original)
+++ cfe/trunk/CMakeLists.txt Thu Feb  4 20:51:33 2016
@@ -595,8 +595,8 @@ endif()
 set(CLANG_ORDER_FILE ${CMAKE_CURRENT_BINARY_DIR}/clang.order CACHE FILEPATH
   "Order file to use when compiling clang in order to improve startup time.")
 
-if(NOT EXISTS ${CLANG_ORDER_FILE})
-  execute_process(COMMAND ${CMAKE_COMMAND} -E touch ${CLANG_ORDER_FILE})
+if(CLANG_ORDER_FILE AND NOT EXISTS ${CLANG_ORDER_FILE})
+  file(WRITE ${CLANG_ORDER_FILE} "\n")
 endif()
 
 if (CLANG_BUILT_STANDALONE OR CMAKE_VERSION VERSION_EQUAL 3 OR


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

Re: r259862 - [CMake] Improve the clang order-file generation workflow

[Chris Bieneman via cfe-commits]

I pushed a speculative fix for this in r259870. I’m unable to reproduce 
locally. There are a few bots that hit the same issue, so I’m watching them.

-Chris

> On Feb 4, 2016, at 6:44 PM, Chris Bieneman via cfe-commits 
>  wrote:
> 
> What linker are you using and on what OS? I’m looking at this now, and will 
> revert if I can’t find a solution.
> 
> -Chris
> 
>> On Feb 4, 2016, at 6:38 PM, Richard Smith > > wrote:
>> 
>> This is causing my links to fail with:
>> 
>> FAILED: : && /usr/local/google/home/richardsmith/bin/clang++   
>> -fcolor-diagnostics -std=c++11 -stdlib=libc++ -fPIC 
>> -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings 
>> -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long 
>> -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor 
>> -std=c++11 -fcolor-diagnostics -fno-common -Woverloaded-virtual 
>> -Wno-nested-anon-types -g  -Wl,-allow-shlib-undefined   -Wl,--export-dynamic 
>> tools/clang/tools/driver/CMakeFiles/clang.dir/driver.cpp.o 
>> tools/clang/tools/driver/CMakeFiles/clang.dir/cc1_main.cpp.o 
>> tools/clang/tools/driver/CMakeFiles/clang.dir/cc1as_main.cpp.o  -o 
>> bin/clang-3.8  lib/libLLVMAArch64CodeGen.a lib/libLLVMAArch64AsmPrinter.a 
>> lib/libLLVMAArch64AsmParser.a lib/libLLVMAArch64Desc.a 
>> lib/libLLVMAArch64Info.a lib/libLLVMAArch64Disassembler.a 
>> lib/libLLVMAMDGPUCodeGen.a lib/libLLVMAMDGPUAsmPrinter.a 
>> lib/libLLVMAMDGPUAsmParser.a lib/libLLVMAMDGPUDesc.a lib/libLLVMAMDGPUInfo.a 
>> lib/libLLVMARMCodeGen.a lib/libLLVMARMAsmPrinter.a lib/libLLVMARMAsmParser.a 
>> lib/libLLVMARMDesc.a lib/libLLVMARMInfo.a lib/libLLVMARMDisassembler.a 
>> lib/libLLVMBPFCodeGen.a lib/libLLVMBPFAsmPrinter.a lib/libLLVMBPFDesc.a 
>> lib/libLLVMBPFInfo.a lib/libLLVMCppBackendCodeGen.a 
>> lib/libLLVMCppBackendInfo.a lib/libLLVMHexagonCodeGen.a 
>> lib/libLLVMHexagonAsmParser.a lib/libLLVMHexagonDesc.a 
>> lib/libLLVMHexagonInfo.a lib/libLLVMHexagonDisassembler.a 
>> lib/libLLVMMipsCodeGen.a lib/libLLVMMipsAsmPrinter.a 
>> lib/libLLVMMipsAsmParser.a lib/libLLVMMipsDesc.a lib/libLLVMMipsInfo.a 
>> lib/libLLVMMipsDisassembler.a lib/libLLVMMSP430CodeGen.a 
>> lib/libLLVMMSP430AsmPrinter.a lib/libLLVMMSP430Desc.a 
>> lib/libLLVMMSP430Info.a lib/libLLVMNVPTXCodeGen.a 
>> lib/libLLVMNVPTXAsmPrinter.a lib/libLLVMNVPTXDesc.a lib/libLLVMNVPTXInfo.a 
>> lib/libLLVMPowerPCCodeGen.a lib/libLLVMPowerPCAsmPrinter.a 
>> lib/libLLVMPowerPCAsmParser.a lib/libLLVMPowerPCDesc.a 
>> lib/libLLVMPowerPCInfo.a lib/libLLVMPowerPCDisassembler.a 
>> lib/libLLVMSparcCodeGen.a lib/libLLVMSparcAsmPrinter.a 
>> lib/libLLVMSparcAsmParser.a lib/libLLVMSparcDesc.a lib/libLLVMSparcInfo.a 
>> lib/libLLVMSparcDisassembler.a lib/libLLVMSystemZCodeGen.a 
>> lib/libLLVMSystemZAsmPrinter.a lib/libLLVMSystemZAsmParser.a 
>> lib/libLLVMSystemZDesc.a lib/libLLVMSystemZInfo.a 
>> lib/libLLVMSystemZDisassembler.a lib/libLLVMX86CodeGen.a 
>> lib/libLLVMX86AsmPrinter.a lib/libLLVMX86AsmParser.a lib/libLLVMX86Desc.a 
>> lib/libLLVMX86Info.a lib/libLLVMX86Disassembler.a lib/libLLVMXCoreCodeGen.a 
>> lib/libLLVMXCoreAsmPrinter.a lib/libLLVMXCoreDesc.a lib/libLLVMXCoreInfo.a 
>> lib/libLLVMXCoreDisassembler.a lib/libLLVMAnalysis.a lib/libLLVMCodeGen.a 
>> lib/libLLVMCore.a lib/libLLVMipo.a lib/libLLVMInstCombine.a 
>> lib/libLLVMInstrumentation.a lib/libLLVMMC.a lib/libLLVMMCParser.a 
>> lib/libLLVMObjCARCOpts.a lib/libLLVMOption.a lib/libLLVMScalarOpts.a 
>> lib/libLLVMSupport.a lib/libLLVMTransformUtils.a lib/libLLVMVectorize.a 
>> lib/libclangBasic.a lib/libclangCodeGen.a lib/libclangDriver.a 
>> lib/libclangFrontend.a lib/libclangFrontendTool.a 
>> -Wl,-order_file,/usr/local/google/home/richardsmith/clang-8/build/tools/clang/clang.order
>>  lib/libLLVMAArch64Desc.a lib/libLLVMAArch64AsmPrinter.a 
>> lib/libLLVMAArch64Info.a lib/libLLVMAArch64Utils.a 
>> lib/libLLVMAMDGPUAsmPrinter.a lib/libLLVMAMDGPUUtils.a lib/libLLVMARMDesc.a 
>> lib/libLLVMARMAsmPrinter.a lib/libLLVMARMInfo.a lib/libLLVMBPFAsmPrinter.a 
>> lib/libLLVMHexagonDesc.a lib/libLLVMHexagonInfo.a 
>> lib/libLLVMMipsAsmPrinter.a lib/libLLVMMipsInfo.a 
>> lib/libLLVMMSP430AsmPrinter.a lib/libLLVMNVPTXAsmPrinter.a 
>> lib/libLLVMPowerPCAsmPrinter.a lib/libLLVMPowerPCInfo.a 
>> lib/libLLVMSparcAsmPrinter.a lib/libLLVMSparcInfo.a lib/libLLVMSystemZDesc.a 
>> lib/libLLVMSystemZAsmPrinter.a lib/libLLVMSystemZInfo.a 
>> lib/libLLVMX86AsmPrinter.a lib/libLLVMX86Utils.a lib/libLLVMX86Info.a 
>> lib/libLLVMXCoreAsmPrinter.a lib/libLLVMAsmPrinter.a 
>> lib/libLLVMDebugInfoCodeView.a lib/libLLVMSelectionDAG.a 
>> lib/libLLVMCodeGen.a lib/libLLVMXCoreInfo.a lib/libLLVMMCDisassembler.a 
>> lib/libclangCodeGen.a lib/libLLVMipo.a lib/libLLVMVectorize.a 
>> lib/libLLVMInstrumentation.a lib/libLLVMObjCARCOpts.a 
>> lib/libLLVMScalarOpts.a lib/libLLVMInstCombine.a lib/libLLVMTarget.a 
>> lib/libLLVMBitWriter.a lib/libLLVMIRReader.a lib/libLLVMAsmParser.a 
>> lib/libLLVMLinker.a lib/libLLVMTransformUtils.