Re: [PATCH] D11690: [CUDA] Added stubs for new attributes used by CUDA headers.

[Artem Belevich via cfe-commits]

tra added a comment.

LGTM'ed by Aaron Ballman via email that didn't make it to Phabricator.


http://reviews.llvm.org/D11690



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

Re: [PATCH] D11857: CFI: Introduce -fsanitize=cfi-icall flag.

[Alexey Samsonov via cfe-commits]

samsonov added a comment.

Driver changes look good.


http://reviews.llvm.org/D11857



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

Re: [PATCH] D11781: Refactored pthread usage in libcxx

[Fulvio Esposito via cfe-commits]

espositofulvio added inline comments.


Comment at: include/__config:742
@@ +741,3 @@
+#ifndef _LIBCPP_HAS_NO_THREADS
+# if defined(__FreeBSD__) || defined(__NetBSD__) || defined(__linux__) || 
defined(__APPLE__)
+#  define _LIBCPP_THREAD_API _LIBCPP_PTHREAD

ed wrote:
> espositofulvio wrote:
> > theraven wrote:
> > > #ifdef unix will catch most of these (for some reason, not OS X, even 
> > > though it's the only one that actually is certified as UNIX...)
> > I didn't know that and I'm not sure I've included all the supported 
> > platforms (in include/__config there are definitions for __ sun __ and __ 
> > CloudABI __ which I know very little about). Is there somewhere a list of 
> > supported platforms?
> CloudABI has pthreads, but it does not have `unix` defined. Both FreeBSD and 
> CloudABI also support C11 ``.
> 
> If you're going to stick to the code you have right now, be sure to add 
> `defined(__CloudABI__)` to that list of operating systems.
> 
> The POSIX way of testing whether pthreads is available is:
> 
> #include 
> #if _POSIX_THREADS > 0
> ...
> #endif
> 
> See: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/unistd.h.html
Unfortunately I think the POSIX way would fail on any system that hasn't 
unistd.h (Windows), so I think I'll stick with the list and add the missing 
ones.


Comment at: include/__config:742
@@ +741,3 @@
+#ifndef _LIBCPP_HAS_NO_THREADS
+# if defined(__FreeBSD__) || defined(__NetBSD__) || defined(__linux__) || 
defined(__APPLE__)
+#  define _LIBCPP_THREAD_API _LIBCPP_PTHREAD

espositofulvio wrote:
> ed wrote:
> > espositofulvio wrote:
> > > theraven wrote:
> > > > #ifdef unix will catch most of these (for some reason, not OS X, even 
> > > > though it's the only one that actually is certified as UNIX...)
> > > I didn't know that and I'm not sure I've included all the supported 
> > > platforms (in include/__config there are definitions for __ sun __ and __ 
> > > CloudABI __ which I know very little about). Is there somewhere a list of 
> > > supported platforms?
> > CloudABI has pthreads, but it does not have `unix` defined. Both FreeBSD 
> > and CloudABI also support C11 ``.
> > 
> > If you're going to stick to the code you have right now, be sure to add 
> > `defined(__CloudABI__)` to that list of operating systems.
> > 
> > The POSIX way of testing whether pthreads is available is:
> > 
> > #include 
> > #if _POSIX_THREADS > 0
> > ...
> > #endif
> > 
> > See: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/unistd.h.html
> Unfortunately I think the POSIX way would fail on any system that hasn't 
> unistd.h (Windows), so I think I'll stick with the list and add the missing 
> ones.
It looks like unix is not defined on Linux, but it has __unix. I think it's 
safer to stick to the list.


Repository:
  rL LLVM

http://reviews.llvm.org/D11781



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

r244497 - [CUDA] Added stubs for new attributes used by CUDA headers.

[Artem Belevich via cfe-commits]

Author: tra
Date: Mon Aug 10 15:33:56 2015
New Revision: 244497

URL: http://llvm.org/viewvc/llvm-project?rev=244497&view=rev
Log:
[CUDA] Added stubs for new attributes used by CUDA headers.

The main purpose is to avoid errors and warnings while parsing CUDA
header files. The attributes are currently unused otherwise.

Differential version: http://reviews.llvm.org/D11690

Added:
cfe/trunk/test/SemaCUDA/attributes.cu
Modified:
cfe/trunk/include/clang/Basic/Attr.td
cfe/trunk/test/Index/attributes-cuda.cu

Modified: cfe/trunk/include/clang/Basic/Attr.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=244497&r1=244496&r2=244497&view=diff
==
--- cfe/trunk/include/clang/Basic/Attr.td (original)
+++ cfe/trunk/include/clang/Basic/Attr.td Mon Aug 10 15:33:56 2015
@@ -557,6 +557,11 @@ def CUDAConstant : InheritableAttr {
   let Documentation = [Undocumented];
 }
 
+def CUDACudartBuiltin : IgnoredAttr {
+  let Spellings = [GNU<"cudart_builtin">];
+  let LangOpts = [CUDA];
+}
+
 def CUDADevice : InheritableAttr {
   let Spellings = [GNU<"device">];
   let Subjects = SubjectList<[Function, Var]>;
@@ -564,6 +569,21 @@ def CUDADevice : InheritableAttr {
   let Documentation = [Undocumented];
 }
 
+def CUDADeviceBuiltin : IgnoredAttr {
+  let Spellings = [GNU<"device_builtin">];
+  let LangOpts = [CUDA];
+}
+
+def CUDADeviceBuiltinSurfaceType : IgnoredAttr {
+  let Spellings = [GNU<"device_builtin_surface_type">];
+  let LangOpts = [CUDA];
+}
+
+def CUDADeviceBuiltinTextureType : IgnoredAttr {
+  let Spellings = [GNU<"device_builtin_texture_type">];
+  let LangOpts = [CUDA];
+}
+
 def CUDAGlobal : InheritableAttr {
   let Spellings = [GNU<"global">];
   let Subjects = SubjectList<[Function]>;
@@ -1015,6 +1035,11 @@ def NoThrow : InheritableAttr {
   let Documentation = [Undocumented];
 }
 
+def NvWeak : IgnoredAttr {
+  let Spellings = [GNU<"nv_weak">];
+  let LangOpts = [CUDA];
+}
+
 def ObjCBridge : InheritableAttr {
   let Spellings = [GNU<"objc_bridge">];
   let Subjects = SubjectList<[Record, TypedefName], ErrorDiag,

Modified: cfe/trunk/test/Index/attributes-cuda.cu
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Index/attributes-cuda.cu?rev=244497&r1=244496&r2=244497&view=diff
==
--- cfe/trunk/test/Index/attributes-cuda.cu (original)
+++ cfe/trunk/test/Index/attributes-cuda.cu Mon Aug 10 15:33:56 2015
@@ -7,6 +7,14 @@ __attribute__((global)) void f_global();
 __attribute__((constant)) int* g_constant;
 __attribute__((shared)) float *g_shared;
 __attribute__((host)) void f_host();
+__attribute__((device_builtin)) void f_device_builtin();
+typedef __attribute__((device_builtin)) const void *t_device_builtin;
+enum __attribute__((device_builtin)) e_device_builtin {};
+__attribute__((device_builtin)) int v_device_builtin;
+__attribute__((cudart_builtin)) void f_cudart_builtin();
+__attribute__((nv_weak)) void f_nv_weak();
+__attribute__((device_builtin_surface_type)) unsigned long long surface_var;
+__attribute__((device_builtin_texture_type)) unsigned long long texture_var;
 
 // CHECK:   attributes-cuda.cu:5:30: FunctionDecl=f_device:5:30
 // CHECK-NEXT:  attributes-cuda.cu:5:16: attribute(device)
@@ -18,3 +26,11 @@ __attribute__((host)) void f_host();
 // CHECK-NEXT:  attributes-cuda.cu:8:16: attribute(shared)
 // CHECK:   attributes-cuda.cu:9:28: FunctionDecl=f_host:9:28
 // CHECK-NEXT:  attributes-cuda.cu:9:16: attribute(host)
+// CHECK:  attributes-cuda.cu:10:38: FunctionDecl=f_device_builtin:10:38
+// CHECK:  attributes-cuda.cu:11:53: TypedefDecl=t_device_builtin:11:53
+// CHECK:  attributes-cuda.cu:12:38: EnumDecl=e_device_builtin:12:38
+// CHECK:  attributes-cuda.cu:13:37: VarDecl=v_device_builtin:13:37
+// CHECK:  attributes-cuda.cu:14:38: FunctionDecl=f_cudart_builtin:14:38
+// CHECK:  attributes-cuda.cu:15:31: FunctionDecl=f_nv_weak:15:31
+// CHECK:  attributes-cuda.cu:16:65: VarDecl=surface_var:16:65
+// CHECK:  attributes-cuda.cu:17:65: VarDecl=texture_var:17:65

Added: cfe/trunk/test/SemaCUDA/attributes.cu
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCUDA/attributes.cu?rev=244497&view=auto
==
--- cfe/trunk/test/SemaCUDA/attributes.cu (added)
+++ cfe/trunk/test/SemaCUDA/attributes.cu Mon Aug 10 15:33:56 2015
@@ -0,0 +1,33 @@
+// Tests handling of CUDA attributes.
+//
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+// RUN: %clang_cc1 -fsyntax-only -fcuda-is-device -verify %s
+// Now pretend that we're compiling a C file. There should be warnings.
+// RUN: %clang_cc1 -DEXPECT_WARNINGS -fsyntax-only -verify -x c %s
+
+#if defined(EXPECT_WARNINGS)
+// expected-warning@+12 {{'device' attribute ignored}}
+// expected-warning@+12 {{'global' attribute ignored}}
+// expected-warni

Re: [PATCH] D11781: Refactored pthread usage in libcxx

[Fulvio Esposito via cfe-commits]

espositofulvio updated this revision to Diff 31716.
espositofulvio added a comment.

Added __CloudABI__ to the list of platform using pthread


Repository:
  rL LLVM

http://reviews.llvm.org/D11781

Files:
  include/__config
  include/__mutex_base
  include/mutex
  include/support/condition_variable.h
  include/support/mutex.h
  include/support/pthread/condition_variable.h
  include/support/pthread/mutex.h
  include/support/pthread/thread.h
  include/support/thread.h
  include/thread
  include/type_traits
  lib/CMakeLists.txt
  src/algorithm.cpp
  src/condition_variable.cpp
  src/memory.cpp
  src/mutex.cpp
  src/support/pthread/condition_variable.cpp
  src/support/pthread/mutex.cpp
  src/support/pthread/thread.cpp
  src/thread.cpp

Index: src/thread.cpp
===
--- src/thread.cpp
+++ src/thread.cpp
@@ -32,6 +32,8 @@
 
 _LIBCPP_BEGIN_NAMESPACE_STD
 
+using namespace __libcpp_support;
+
 thread::~thread()
 {
 if (__t_ != 0)
@@ -41,7 +43,7 @@
 void
 thread::join()
 {
-int ec = pthread_join(__t_, 0);
+int ec = __os_thread_join(__t_);
 #ifndef _LIBCPP_NO_EXCEPTIONS
 if (ec)
 throw system_error(error_code(ec, system_category()), "thread::join failed");
@@ -57,7 +59,7 @@
 int ec = EINVAL;
 if (__t_ != 0)
 {
-ec = pthread_detach(__t_);
+ec = __os_thread_detach(__t_);
 if (ec == 0)
 __t_ = 0;
 }
@@ -101,37 +103,6 @@
 #endif  // defined(CTL_HW) && defined(HW_NCPU)
 }
 
-namespace this_thread
-{
-
-void
-sleep_for(const chrono::nanoseconds& ns)
-{
-using namespace chrono;
-if (ns > nanoseconds::zero())
-{
-seconds s = duration_cast(ns);
-timespec ts;
-typedef decltype(ts.tv_sec) ts_sec;
-_LIBCPP_CONSTEXPR ts_sec ts_sec_max = numeric_limits::max();
-if (s.count() < ts_sec_max)
-{
-ts.tv_sec = static_cast(s.count());
-ts.tv_nsec = static_cast((ns-s).count());
-}
-else
-{
-ts.tv_sec = ts_sec_max;
-ts.tv_nsec = giga::num - 1;
-}
-
-while (nanosleep(&ts, &ts) == -1 && errno == EINTR)
-;
-}
-}
-
-}  // this_thread
-
 __thread_specific_ptr<__thread_struct>&
 __thread_local_data()
 {
Index: src/support/pthread/thread.cpp
===
--- /dev/null
+++ src/support/pthread/thread.cpp
@@ -0,0 +1,54 @@
+// -*- C++ -*-
+//===-- support/pthread/thread.cpp ===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "__config"
+
+#include 
+#include 
+#define _LIBCPP_INCLUDE_THREAD_API
+#include 
+#undef _LIBCPP_INCLUDE_THREAD_API
+
+_LIBCPP_BEGIN_NAMESPACE_STD
+#ifndef _LIBCPP_HAS_NO_THREADS
+
+namespace __libcpp_support
+{
+
+void
+__os_sleep_for(const chrono::nanoseconds& ns)
+{
+using namespace chrono;
+if (ns > nanoseconds::zero())
+{
+seconds s = duration_cast(ns);
+timespec ts;
+typedef decltype(ts.tv_sec) ts_sec;
+_LIBCPP_CONSTEXPR ts_sec ts_sec_max = numeric_limits::max();
+if (s.count() < ts_sec_max)
+{
+ts.tv_sec = static_cast(s.count());
+ts.tv_nsec = static_cast((ns-s).count());
+}
+else
+{
+ts.tv_sec = ts_sec_max;
+ts.tv_nsec = giga::num - 1;
+}
+
+while (nanosleep(&ts, &ts) == -1 && errno == EINTR)
+;
+}
+}
+
+} //namespace __libcpp_support
+
+#endif // _LIBCPP_HAS_NO_THREADS
+_LIBCPP_END_NAMESPACE_STD
Index: src/support/pthread/mutex.cpp
===
--- /dev/null
+++ src/support/pthread/mutex.cpp
@@ -0,0 +1,131 @@
+// -*- C++ -*-
+//===-- support/pthread/thread.cpp ===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "__config"
+
+#include 
+#include 
+#include "../atomic_support.h"
+
+#define _LIBCPP_INCLUDE_THREAD_API
+#include 
+#undef _LIBCPP_INCLUDE_THREAD_API
+
+_LIBCPP_BEGIN_NAMESPACE_STD
+#ifndef _LIBCPP_HAS_NO_THREADS
+
+namespace __libcpp_support
+{
+
+void __os_recursive_mutex_init(__os_mutex* __m)
+{
+pthread_mutexattr_t attr;
+int ec = pthread_mutexattr_init(&attr);
+if (ec)
+goto fail;
+ec = pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE);
+if (ec)
+{
+pthread_mutexattr_destroy(&attr);
+goto fail;
+}
+ec = pthread_mute

Re: [PATCH] D11781: Refactored pthread usage in libcxx

[Fulvio Esposito via cfe-commits]

espositofulvio marked 5 inline comments as done.
espositofulvio added a comment.

Repository:
  rL LLVM

http://reviews.llvm.org/D11781



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

Re: [PATCH] D11781: Refactored pthread usage in libcxx

[Jonathan Roelofs via cfe-commits]

jroelofs added inline comments.


Comment at: include/__config:742
@@ +741,3 @@
+#ifndef _LIBCPP_HAS_NO_THREADS
+# if defined(__FreeBSD__) || \
+defined(__NetBSD__) || \

@espositofulvio: @ed meant this:

```
#ifndef _WIN32
#  include 
#  if _POSIX_THREADS > 0
...
#  endif
#endif
```

Which //is// the correct way to test for this.


Repository:
  rL LLVM

http://reviews.llvm.org/D11781



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

Re: [PATCH] D11781: Refactored pthread usage in libcxx

[Jonathan Roelofs via cfe-commits]

jroelofs added inline comments.


Comment at: include/__config:742
@@ +741,3 @@
+#ifndef _LIBCPP_HAS_NO_THREADS
+# if defined(__FreeBSD__) || \
+defined(__NetBSD__) || \

jroelofs wrote:
> @espositofulvio: @ed meant this:
> 
> ```
> #ifndef _WIN32
> #  include 
> #  if _POSIX_THREADS > 0
> ...
> #  endif
> #endif
> ```
> 
> Which //is// the correct way to test for this.
That being said, there have been discussions before about whether or not we 
should #include  in <__config>, with the conclusion being that we 
shouldn't.

It would be better if this were a CMake configure-time check that sets 
_LIBCPP_THREAD_API, rather than these build-time guards.


Repository:
  rL LLVM

http://reviews.llvm.org/D11781



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

r244501 - [CUDA] Add implicit __attribute__((used)) to all __global__ functions.

[Artem Belevich via cfe-commits]

Author: tra
Date: Mon Aug 10 15:57:02 2015
New Revision: 244501

URL: http://llvm.org/viewvc/llvm-project?rev=244501&view=rev
Log:
[CUDA] Add implicit __attribute__((used)) to all __global__ functions.

This allows emitting kernels that were instantiated from the host code
and which would never be explicitly referenced otherwise.

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

Modified:
cfe/trunk/lib/Sema/SemaDeclAttr.cpp
cfe/trunk/test/CodeGenCUDA/ptx-kernels.cu

Modified: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclAttr.cpp?rev=244501&r1=244500&r2=244501&view=diff
==
--- cfe/trunk/lib/Sema/SemaDeclAttr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp Mon Aug 10 15:57:02 2015
@@ -3350,6 +3350,10 @@ static void handleGlobalAttr(Sema &S, De
   D->addAttr(::new (S.Context)
   CUDAGlobalAttr(Attr.getRange(), S.Context,
  Attr.getAttributeSpellingListIndex()));
+
+  // Add implicit attribute((used)) so we don't eliminate kernels
+  // because there is nothing referencing them on device side.
+  D->addAttr(UsedAttr::CreateImplicit(S.Context));
 }
 
 static void handleGNUInlineAttr(Sema &S, Decl *D, const AttributeList &Attr) {

Modified: cfe/trunk/test/CodeGenCUDA/ptx-kernels.cu
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCUDA/ptx-kernels.cu?rev=244501&r1=244500&r2=244501&view=diff
==
--- cfe/trunk/test/CodeGenCUDA/ptx-kernels.cu (original)
+++ cfe/trunk/test/CodeGenCUDA/ptx-kernels.cu Mon Aug 10 15:57:02 2015
@@ -1,7 +1,16 @@
+// Make sure that __global__ functions are emitted along with correct
+// annotations and are added to @llvm.used to prevent their elimination.
+// REQUIRES: nvptx-registered-target
+//
 // RUN: %clang_cc1 %s -triple nvptx-unknown-unknown -fcuda-is-device 
-emit-llvm -o - | FileCheck %s
 
 #include "Inputs/cuda.h"
 
+// Make sure that all __global__ functiona are added to @llvm.used
+// CHECK: @llvm.used = appending global
+// CHECK-SAME: @global_function
+// CHECK-SAME: @_Z16templated_kernelIiEvT_
+
 // CHECK-LABEL: define void @device_function
 extern "C"
 __device__ void device_function() {}
@@ -13,4 +22,10 @@ __global__ void global_function() {
   device_function();
 }
 
+// Make sure host-instantiated kernels are preserved on device side.
+template  __global__ void templated_kernel(T param) {}
+// CHECK-LABEL: define linkonce_odr void @_Z16templated_kernelIiEvT_
+void host_function() { templated_kernel<<<0,0>>>(0); }
+
 // CHECK: !{{[0-9]+}} = !{void ()* @global_function, !"kernel", i32 1}
+// CHECK: !{{[0-9]+}} = !{void (i32)* @_Z16templated_kernelIiEvT_, !"kernel", 
i32 1}


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

Re: [PATCH] D11666: [CUDA] Make sure we emit all templated __global__ functions on device side.

[Artem Belevich via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL244501: [CUDA] Add implicit __attribute__((used)) to all 
__global__ functions. (authored by tra).

Changed prior to commit:
  http://reviews.llvm.org/D11666?vs=31128&id=31718#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D11666

Files:
  cfe/trunk/lib/Sema/SemaDeclAttr.cpp
  cfe/trunk/test/CodeGenCUDA/ptx-kernels.cu

Index: cfe/trunk/test/CodeGenCUDA/ptx-kernels.cu
===
--- cfe/trunk/test/CodeGenCUDA/ptx-kernels.cu
+++ cfe/trunk/test/CodeGenCUDA/ptx-kernels.cu
@@ -1,7 +1,16 @@
+// Make sure that __global__ functions are emitted along with correct
+// annotations and are added to @llvm.used to prevent their elimination.
+// REQUIRES: nvptx-registered-target
+//
 // RUN: %clang_cc1 %s -triple nvptx-unknown-unknown -fcuda-is-device 
-emit-llvm -o - | FileCheck %s
 
 #include "Inputs/cuda.h"
 
+// Make sure that all __global__ functiona are added to @llvm.used
+// CHECK: @llvm.used = appending global
+// CHECK-SAME: @global_function
+// CHECK-SAME: @_Z16templated_kernelIiEvT_
+
 // CHECK-LABEL: define void @device_function
 extern "C"
 __device__ void device_function() {}
@@ -13,4 +22,10 @@
   device_function();
 }
 
+// Make sure host-instantiated kernels are preserved on device side.
+template  __global__ void templated_kernel(T param) {}
+// CHECK-LABEL: define linkonce_odr void @_Z16templated_kernelIiEvT_
+void host_function() { templated_kernel<<<0,0>>>(0); }
+
 // CHECK: !{{[0-9]+}} = !{void ()* @global_function, !"kernel", i32 1}
+// CHECK: !{{[0-9]+}} = !{void (i32)* @_Z16templated_kernelIiEvT_, !"kernel", 
i32 1}
Index: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
===
--- cfe/trunk/lib/Sema/SemaDeclAttr.cpp
+++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp
@@ -3350,6 +3350,10 @@
   D->addAttr(::new (S.Context)
   CUDAGlobalAttr(Attr.getRange(), S.Context,
  Attr.getAttributeSpellingListIndex()));
+
+  // Add implicit attribute((used)) so we don't eliminate kernels
+  // because there is nothing referencing them on device side.
+  D->addAttr(UsedAttr::CreateImplicit(S.Context));
 }
 
 static void handleGNUInlineAttr(Sema &S, Decl *D, const AttributeList &Attr) {


Index: cfe/trunk/test/CodeGenCUDA/ptx-kernels.cu
===
--- cfe/trunk/test/CodeGenCUDA/ptx-kernels.cu
+++ cfe/trunk/test/CodeGenCUDA/ptx-kernels.cu
@@ -1,7 +1,16 @@
+// Make sure that __global__ functions are emitted along with correct
+// annotations and are added to @llvm.used to prevent their elimination.
+// REQUIRES: nvptx-registered-target
+//
 // RUN: %clang_cc1 %s -triple nvptx-unknown-unknown -fcuda-is-device -emit-llvm -o - | FileCheck %s
 
 #include "Inputs/cuda.h"
 
+// Make sure that all __global__ functiona are added to @llvm.used
+// CHECK: @llvm.used = appending global
+// CHECK-SAME: @global_function
+// CHECK-SAME: @_Z16templated_kernelIiEvT_
+
 // CHECK-LABEL: define void @device_function
 extern "C"
 __device__ void device_function() {}
@@ -13,4 +22,10 @@
   device_function();
 }
 
+// Make sure host-instantiated kernels are preserved on device side.
+template  __global__ void templated_kernel(T param) {}
+// CHECK-LABEL: define linkonce_odr void @_Z16templated_kernelIiEvT_
+void host_function() { templated_kernel<<<0,0>>>(0); }
+
 // CHECK: !{{[0-9]+}} = !{void ()* @global_function, !"kernel", i32 1}
+// CHECK: !{{[0-9]+}} = !{void (i32)* @_Z16templated_kernelIiEvT_, !"kernel", i32 1}
Index: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
===
--- cfe/trunk/lib/Sema/SemaDeclAttr.cpp
+++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp
@@ -3350,6 +3350,10 @@
   D->addAttr(::new (S.Context)
   CUDAGlobalAttr(Attr.getRange(), S.Context,
  Attr.getAttributeSpellingListIndex()));
+
+  // Add implicit attribute((used)) so we don't eliminate kernels
+  // because there is nothing referencing them on device side.
+  D->addAttr(UsedAttr::CreateImplicit(S.Context));
 }
 
 static void handleGNUInlineAttr(Sema &S, Decl *D, const AttributeList &Attr) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r244502 - Fix test case to work with -Asserts builds.

[Chih-Hung Hsieh via cfe-commits]

Author: chh
Date: Mon Aug 10 15:58:54 2015
New Revision: 244502

URL: http://llvm.org/viewvc/llvm-project?rev=244502&view=rev
Log:
Fix test case to work with -Asserts builds.

When clang is built with -DLLVM_ENABLE_ASSERTIONS=Off,
it does not create names for IR values.

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


Modified:
cfe/trunk/test/CodeGen/x86_64-fp128.c

Modified: cfe/trunk/test/CodeGen/x86_64-fp128.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/x86_64-fp128.c?rev=244502&r1=244501&r2=244502&view=diff
==
--- cfe/trunk/test/CodeGen/x86_64-fp128.c (original)
+++ cfe/trunk/test/CodeGen/x86_64-fp128.c Mon Aug 10 15:58:54 2015
@@ -31,20 +31,20 @@ typedef __builtin_va_list va_list;
 
 int TestGetVarInt(va_list ap) {
   return __builtin_va_arg(ap, int);
-// Since int can be passed in memory or in register there is a branch and a 
phi.
+// Since int can be passed in memory or register there are two branches.
 // CHECK:   define i32 @TestGetVarInt(
-// CHECK:   br
-// CHECK:   load {{.*}} %overflow_arg_area_p
+// CHECK:   br label
+// CHECK:   br label
 // CHECK:   = phi
 // CHECK:   ret i32
 }
 
 double TestGetVarDouble(va_list ap) {
   return __builtin_va_arg(ap, double);
-// Since double can be passed in memory or in register there is a branch and a 
phi.
+// Since double can be passed in memory or register there are two branches.
 // CHECK:   define double @TestGetVarDouble(
-// CHECK:   br
-// CHECK:   load {{.*}} %overflow_arg_area_p
+// CHECK:   br label
+// CHECK:   br label
 // CHECK:   = phi
 // CHECK:   ret double
 }
@@ -54,10 +54,10 @@ long double TestGetVarLD(va_list ap) {
 // fp128 can be passed in memory or in register, but x86_fp80 is in memory.
 // ANDROID: define fp128 @TestGetVarLD(
 // GNU: define x86_fp80 @TestGetVarLD(
-// ANDROID: br
-// GNU-NOT: br
-// CHECK:   load {{.*}} %overflow_arg_area_p
+// ANDROID: br label
+// ANDROID: br label
 // ANDROID: = phi
+// GNU-NOT: br
 // GNU-NOT: = phi
 // ANDROID: ret fp128
 // GNU: ret x86_fp80
@@ -69,7 +69,6 @@ long double _Complex TestGetVarLDC(va_li
 // ANDROID:   define void @TestGetVarLDC({ fp128, fp128 }* {{.*}}, 
%struct.__va_list_tag*
 // GNU:   define { x86_fp80, x86_fp80 } @TestGetVarLDC(
 // CHECK-NOT: br
-// CHECK: load {{.*}} %overflow_arg_area_p
 // CHECK-NOT: phi
 // ANDROID:   ret void
 // GNU:   ret { x86_fp80, x86_fp80 }
@@ -106,11 +105,11 @@ void TestPassVarLD(long double x) {
 void TestPassVarLDC(long double _Complex x) {
   TestVarArg("A", x);
 // ANDROID:  define void @TestPassVarLDC({ fp128, fp128 }* {{.*}} %x)
-// ANDROID:  store fp128 %x.{{.*}}, fp128* %
-// ANDROID-NEXT: store fp128 %x.{{.*}}, fp128* %
+// ANDROID:  store fp128 %{{.*}}, fp128* %
+// ANDROID-NEXT: store fp128 %{{.*}}, fp128* %
 // ANDROID-NEXT: call {{.*}} @TestVarArg(i8* {{.*}}, { fp128, fp128 }* {{.*}} %
 // GNU:  define void @TestPassVarLDC({ x86_fp80, x86_fp80 }* {{.*}} %x)
-// GNU:  store x86_fp80 %x.{{.*}}, x86_fp80* %
-// GNU-NEXT: store x86_fp80 %x.{{.*}}, x86_fp80* %
+// GNU:  store x86_fp80 %{{.*}}, x86_fp80* %
+// GNU-NEXT: store x86_fp80 %{{.*}}, x86_fp80* %
 // GNGNU-NEXT:   call {{.*}} @TestVarArg(i8* {{.*}}, { x86_fp80, x86_fp80 }* 
{{.*}} %
 }


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

Re: r244468 - Correct x86_64 fp128 calling convention

[Chih-hung Hsieh via cfe-commits]

I submitted a new patch into r244502.
Please let me know if there is any other error.
Thanks.


On Mon, Aug 10, 2015 at 12:46 PM, David Blaikie  wrote:

>
>
> On Mon, Aug 10, 2015 at 10:33 AM, Chih-Hung Hsieh via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: chh
>> Date: Mon Aug 10 12:33:31 2015
>> New Revision: 244468
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=244468&view=rev
>> Log:
>> Correct x86_64 fp128 calling convention
>>
>> These changes are for Android x86_64 targets to be compatible
>> with current Android g++ and conform to AMD64 ABI.
>>
>> https://llvm.org/bugs/show_bug.cgi?id=23897
>>   * Return type of long double (fp128) should be fp128, not x86_fp80.
>>   * Vararg of long double (fp128) could be in register and overflowed to
>> memory.
>>
>> https://llvm.org/bugs/show_bug.cgi?id=24111
>>   * Return value of long double (fp128) _Complex should be in memory like
>> a structure of {fp128,fp128}.
>>
>> Differential Revision: http://reviews.llvm.org/D11437
>>
>>
>> Added:
>> cfe/trunk/test/CodeGen/x86_64-fp128.c
>> Modified:
>> cfe/trunk/lib/CodeGen/TargetInfo.cpp
>>
>> Modified: cfe/trunk/lib/CodeGen/TargetInfo.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/TargetInfo.cpp?rev=244468&r1=244467&r2=244468&view=diff
>>
>> ==
>> --- cfe/trunk/lib/CodeGen/TargetInfo.cpp (original)
>> +++ cfe/trunk/lib/CodeGen/TargetInfo.cpp Mon Aug 10 12:33:31 2015
>> @@ -1862,13 +1862,20 @@ void X86_64ABIInfo::classify(QualType Ty
>>Hi = Integer;
>>  } else if (k >= BuiltinType::Bool && k <= BuiltinType::LongLong) {
>>Current = Integer;
>> -} else if ((k == BuiltinType::Float || k == BuiltinType::Double) ||
>> -   (k == BuiltinType::LongDouble &&
>> -getTarget().getTriple().isOSNaCl())) {
>> +} else if (k == BuiltinType::Float || k == BuiltinType::Double) {
>>Current = SSE;
>>  } else if (k == BuiltinType::LongDouble) {
>> -  Lo = X87;
>> -  Hi = X87Up;
>> +  const llvm::fltSemantics *LDF = &getTarget().getLongDoubleFormat();
>> +  if (LDF == &llvm::APFloat::IEEEquad) {
>> +Lo = SSE;
>> +Hi = SSEUp;
>> +  } else if (LDF == &llvm::APFloat::x87DoubleExtended) {
>> +Lo = X87;
>> +Hi = X87Up;
>> +  } else if (LDF == &llvm::APFloat::IEEEdouble) {
>> +Current = SSE;
>> +  } else
>> +llvm_unreachable("unexpected long double representation!");
>>  }
>>  // FIXME: _Decimal32 and _Decimal64 are SSE.
>>  // FIXME: _float128 and _Decimal128 are (SSE, SSEUp).
>> @@ -1973,14 +1980,21 @@ void X86_64ABIInfo::classify(QualType Ty
>>  Current = Integer;
>>else if (Size <= 128)
>>  Lo = Hi = Integer;
>> -} else if (ET == getContext().FloatTy)
>> +} else if (ET == getContext().FloatTy) {
>>Current = SSE;
>> -else if (ET == getContext().DoubleTy ||
>> - (ET == getContext().LongDoubleTy &&
>> -  getTarget().getTriple().isOSNaCl()))
>> +} else if (ET == getContext().DoubleTy) {
>>Lo = Hi = SSE;
>> -else if (ET == getContext().LongDoubleTy)
>> -  Current = ComplexX87;
>> +} else if (ET == getContext().LongDoubleTy) {
>> +  const llvm::fltSemantics *LDF = &getTarget().getLongDoubleFormat();
>> +  if (LDF == &llvm::APFloat::IEEEquad)
>> +Current = Memory;
>> +  else if (LDF == &llvm::APFloat::x87DoubleExtended)
>> +Current = ComplexX87;
>> +  else if (LDF == &llvm::APFloat::IEEEdouble)
>> +Lo = Hi = SSE;
>> +  else
>> +llvm_unreachable("unexpected long double representation!");
>> +}
>>
>>  // If this complex type crosses an eightbyte boundary then it
>>  // should be split.
>> @@ -2249,7 +2263,8 @@ llvm::Type *X86_64ABIInfo::GetByteVector
>>  Ty = QualType(InnerTy, 0);
>>
>>llvm::Type *IRType = CGT.ConvertType(Ty);
>> -  if(isa(IRType))
>> +  if (isa(IRType) ||
>> +  IRType->getTypeID() == llvm::Type::FP128TyID)
>>  return IRType;
>>
>>// We couldn't find the preferred IR vector type for 'Ty'.
>>
>> Added: cfe/trunk/test/CodeGen/x86_64-fp128.c
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/x86_64-fp128.c?rev=244468&view=auto
>>
>> ==
>> --- cfe/trunk/test/CodeGen/x86_64-fp128.c (added)
>> +++ cfe/trunk/test/CodeGen/x86_64-fp128.c Mon Aug 10 12:33:31 2015
>> @@ -0,0 +1,116 @@
>> +// RUN: %clang_cc1 -triple x86_64-linux-android -emit-llvm -O -o - %s \
>> +// RUN:| FileCheck %s --check-prefix=ANDROID --check-prefix=CHECK
>> +// RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm -O -o - %s \
>> +// RUN:| FileCheck %s --check-prefix=GNU --check-prefix=CHECK
>> +// RUN: %clang_cc1 -triple x86_64 -emit-llvm -O -o - %s \
>> +// RUN:| FileCheck %s --check-prefix=GNU --check-prefi

Re: [Patch][LoopVectorize]Late evaluation of vectorization requirements

[Tyler Nowicki via cfe-commits]

Thanks!

Committed in clang r244492, llvm r244489/r244505/r244494.

Tyler

> On Aug 9, 2015, at 9:33 PM, Hal Finkel  wrote:
> 
> Hi Tyler,
> 
> These LGTM, thanks!
> 
> -Hal
> 
> - Original Message -
>> From: "Tyler Nowicki" 
>> To: "Hal J. Finkel" , "Gerolf Hoflehner" 
>> 
>> Cc: "Commit Messages and Patches for LLVM" , 
>> "llvm cfe" 
>> Sent: Thursday, August 6, 2015 3:12:29 PM
>> Subject: Re: [Patch][LoopVectorize]Late evaluation of vectorization  
>> requirements
>> 
>> 
>> I’ve updated the patches a bit. I am going post another pair of
>> patches to add another late diagnostic soon as well.
>> 
>> 
>> Please review,
>> 
>> 
>> Tyler
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Aug 5, 2015, at 1:57 PM, Tyler Nowicki < tnowi...@apple.com >
>> wrote:
>> 
>> 
>> Hi,
>> 
>> 
>> Could I get a review of these patches?
>> 
>> 
>> Thanks,
>> 
>> 
>> Tyler
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Jul 27, 2015, at 4:45 PM, Tyler Nowicki < tnowi...@apple.com >
>> wrote:
>> 
>> Please ignore the debug line in the LLVM late-evaluation patch. It
>> won’t be part of the commit.
>> 
>> 
>> + DEBUG(dbgs() << "LV: Emitting analysis message.\n”);
>> 
>> 
>> Tyler
>> 
>> 
>> 
>> 
>> 
>> On Jul 27, 2015, at 3:23 PM, Tyler Nowicki < tnowi...@apple.com >
>> wrote:
>> 
>> 
>> 
>> Hi Hal,
>> 
>> 
>> Thanks for the review! No worries about the delay.
>> 
>> 
>> 
>> 
>> 
>> 
>> Could I get a review of these patches for cfe and llvm?
>> 
>> Hi Tyler,
>> 
>> I'm apologize for the delay. I think this generally looks good, but I
>> don't understand the motivation for introducing the additional
>> FrontendOptions member. Why not just make a subclass of
>> DiagnosticInfoOptimizationRemarkAnalysis that the frontend can
>> handle specially (and detect using the normal isa/dyn_cast
>> mechanism?\
>> 
>> 
>> 
>> The diagnostic handling code doesn’t use isa or dyn_cast, rather it
>> uses switches to select between different types. I modified the
>> patch to use a subclass rather than a member variable. Let me know
>> what patch you think would work out better?
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> I should have also said in my previous email that I am not thrilled
>> by the need to use O3 in the clang-side test.
>> 
>> So using -O2 or using -fvectorize does not help?
>> 
>> 
>> 
>> Using -O1 with -fvectorize seems to work, at least it is a smaller
>> set of passes than O3.
>> 
>> 
>> I attached the updated patches. I also noticed that
>> DiagnosticInfoOptimizationBase::classof() was incorrectly
>> implemented. It would need its own diagnostic kind, but that doesn’t
>> make sense because you would never instantiate the base class. I
>> thought it was best just to remove it. See the third patch.
>> 
>> 
>> Tyler
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> cfe-commits mailing list
>> cfe-comm...@cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>> 
>> 
> 
> -- 
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory

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

r244506 - Remove non-ascii characters.

[Tyler Nowicki via cfe-commits]

Author: tnowicki
Date: Mon Aug 10 16:18:01 2015
New Revision: 244506

URL: http://llvm.org/viewvc/llvm-project?rev=244506&view=rev
Log:
Remove non-ascii characters.

Modified:
cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
cfe/trunk/test/Frontend/optimization-remark-options.c

Modified: cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td?rev=244506&r1=244505&r2=244506&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td Mon Aug 10 
16:18:01 2015
@@ -46,8 +46,8 @@ def remark_fe_backend_optimization_remar
 def remark_fe_backend_optimization_remark_analysis : Remark<"%0">, BackendInfo,
 InGroup;
 def remark_fe_backend_optimization_remark_analysis_fpcommute : Remark<"%0; "
-"allow commutativity by specifying ‘#pragma clang loop 
vectorize(enable)’ "
-"before the loop or by providing the compiler option ‘-ffast-math’">,
+"allow commutativity by specifying '#pragma clang loop vectorize(enable)' "
+"before the loop or by providing the compiler option '-ffast-math'">,
 BackendInfo, InGroup;
 def warn_fe_backend_optimization_failure : Warning<"%0">, BackendInfo,
 InGroup, DefaultWarn;

Modified: cfe/trunk/test/Frontend/optimization-remark-options.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/optimization-remark-options.c?rev=244506&r1=244505&r2=244506&view=diff
==
--- cfe/trunk/test/Frontend/optimization-remark-options.c (original)
+++ cfe/trunk/test/Frontend/optimization-remark-options.c Mon Aug 10 16:18:01 
2015
@@ -1,6 +1,6 @@
 // RUN: %clang -O1 -fvectorize -Rpass-analysis=loop-vectorize -emit-llvm -S %s 
-o - 2>&1 | FileCheck %s
 
-// CHECK: {{.*}}:9:11: remark: loop not vectorized: vectorization requires 
changes in the order of operations, however IEEE 754 floating-point operations 
are not commutative; allow commutativity by specifying ‘#pragma clang loop 
vectorize(enable)’ before the loop or by providing the compiler option 
‘-ffast-math’
+// CHECK: {{.*}}:9:11: remark: loop not vectorized: vectorization requires 
changes in the order of operations, however IEEE 754 floating-point operations 
are not commutative; allow commutativity by specifying '#pragma clang loop 
vectorize(enable)' before the loop or by providing the compiler option 
'-ffast-math'
 
 double foo(int N) {
   double v = 0.0;


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

Re: r244492 - Append options for floating-point commutivity when related diagnostics are produced.

[Tyler Nowicki via cfe-commits]

Thanks Aaron!

Fixed in r244506.

Tyler

On Mon, Aug 10, 2015 at 12:58 PM, Aaron Ballman 
wrote:

> On Mon, Aug 10, 2015 at 3:56 PM, Tyler Nowicki via cfe-commits
>  wrote:
> > Author: tnowicki
> > Date: Mon Aug 10 14:56:40 2015
> > New Revision: 244492
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=244492&view=rev
> > Log:
> > Append options for floating-point commutivity when related diagnostics
> are produced.
> >
> > With this patch clang appends the command line options that would allow
> vectorization when floating-point commutativity is required. Specifically
> those are enabling fast-math or specifying a loop hint.
> >
> > Added:
> > cfe/trunk/test/Frontend/optimization-remark-options.c
> > Modified:
> > cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
> > cfe/trunk/lib/CodeGen/CodeGenAction.cpp
> >
> > Modified: cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
> > URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td?rev=244492&r1=244491&r2=244492&view=diff
> >
> ==
> > --- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td (original)
> > +++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td Mon Aug 10
> 14:56:40 2015
> > @@ -45,6 +45,10 @@ def remark_fe_backend_optimization_remar
> >  InGroup;
> >  def remark_fe_backend_optimization_remark_analysis : Remark<"%0">,
> BackendInfo,
> >  InGroup;
> > +def remark_fe_backend_optimization_remark_analysis_fpcommute :
> Remark<"%0; "
> > +"allow commutativity by specifying ‘#pragma clang loop
> vectorize(enable)’ "
> > +"before the loop or by providing the compiler option
> ‘-ffast-math’">,
> > +BackendInfo, InGroup;
>
> It looks like some non-ASCII characters snuck in here.
>
> >  def warn_fe_backend_optimization_failure : Warning<"%0">, BackendInfo,
> >  InGroup, DefaultWarn;
> >  def note_fe_backend_optimization_remark_invalid_loc : Note<"could "
> >
> > Modified: cfe/trunk/lib/CodeGen/CodeGenAction.cpp
> > URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenAction.cpp?rev=244492&r1=244491&r2=244492&view=diff
> >
> ==
> > --- cfe/trunk/lib/CodeGen/CodeGenAction.cpp (original)
> > +++ cfe/trunk/lib/CodeGen/CodeGenAction.cpp Mon Aug 10 14:56:40 2015
> > @@ -256,6 +256,8 @@ namespace clang {
> >  const llvm::DiagnosticInfoOptimizationRemarkMissed &D);
> >  void OptimizationRemarkHandler(
> >  const llvm::DiagnosticInfoOptimizationRemarkAnalysis &D);
> > +void OptimizationRemarkHandler(
> > +const llvm::DiagnosticInfoOptimizationRemarkAnalysisFPCommute
> &D);
> >  void OptimizationFailureHandler(
> >  const llvm::DiagnosticInfoOptimizationFailure &D);
> >};
> > @@ -500,6 +502,17 @@ void BackendConsumer::OptimizationRemark
> >  D, diag::remark_fe_backend_optimization_remark_analysis);
> >  }
> >
> > +void BackendConsumer::OptimizationRemarkHandler(
> > +const llvm::DiagnosticInfoOptimizationRemarkAnalysisFPCommute &D) {
> > +  // Optimization analysis remarks are active only if the
> -Rpass-analysis
> > +  // flag has a regular expression that matches the name of the pass
> > +  // name in \p D.
> > +  if (CodeGenOpts.OptimizationRemarkAnalysisPattern &&
> > +
> CodeGenOpts.OptimizationRemarkAnalysisPattern->match(D.getPassName()))
> > +EmitOptimizationMessage(
> > +D,
> diag::remark_fe_backend_optimization_remark_analysis_fpcommute);
> > +}
> > +
> >  void BackendConsumer::OptimizationFailureHandler(
> >  const llvm::DiagnosticInfoOptimizationFailure &D) {
> >EmitOptimizationMessage(D,
> diag::warn_fe_backend_optimization_failure);
> > @@ -553,6 +566,12 @@ void BackendConsumer::DiagnosticHandlerI
> >  OptimizationRemarkHandler(
> >  cast(DI));
> >  return;
> > +  case llvm::DK_OptimizationRemarkAnalysisFPCommute:
> > +// Optimization remarks are always handled completely by this
> > +// handler. There is no generic way of emitting them.
> > +OptimizationRemarkHandler(
> > +cast(DI));
> > +return;
> >case llvm::DK_OptimizationFailure:
> >  // Optimization failures are always handled completely by this
> >  // handler.
> >
> > Added: cfe/trunk/test/Frontend/optimization-remark-options.c
> > URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/optimization-remark-options.c?rev=244492&view=auto
> >
> ==
> > --- cfe/trunk/test/Frontend/optimization-remark-options.c (added)
> > +++ cfe/trunk/test/Frontend/optimization-remark-options.c Mon Aug 10
> 14:56:40 2015
> > @@ -0,0 +1,12 @@
> > +// RUN: %clang -O1 -fvectorize -Rpass-analysis=loop-vectorize
> -emit-llvm -S %s -o - 2>&1 | FileCheck %s
> > +
> > +// CHECK: {{.*}}:9:11: remark: loop not vectorized: 

Re: [PATCH] D11859: Generating vptr assume loads

[Daniel Jasper via cfe-commits]

djasper added a subscriber: djasper.


Comment at: lib/CodeGen/CGClass.cpp:1842
@@ +1841,3 @@
+  CGM.getCXXABI().getVTableAddressPoint(vptr.Base, vptr.VTableClass);
+  if (!VTableGlobal) return;
+

Prazek wrote:
> majnemer wrote:
> > The return should be on it's own line, please clang-format this.
> > Also, under which conditions is this case possible?
> Unfortunatelly clang-format puts short instructions in the same line
Not, it doesn't. At least not if you properly configure LLVM style.


http://reviews.llvm.org/D11859



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

r244515 - If a variable template is inside a context with template arguments that is being instantiated, and that instantiation fails, fail our instantiation instead of crashing. Errors have already b

[Nick Lewycky via cfe-commits]

Author: nicholas
Date: Mon Aug 10 16:54:08 2015
New Revision: 244515

URL: http://llvm.org/viewvc/llvm-project?rev=244515&view=rev
Log:
If a variable template is inside a context with template arguments that is 
being instantiated, and that instantiation fails, fail our instantiation 
instead of crashing. Errors have already been emitted.

Modified:
cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
cfe/trunk/test/SemaCXX/cxx1y-variable-templates_in_class.cpp

Modified: cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp?rev=244515&r1=244514&r2=244515&view=diff
==
--- cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp (original)
+++ cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp Mon Aug 10 16:54:08 2015
@@ -1143,6 +1143,7 @@ Decl *TemplateDeclInstantiator::VisitVar
   VarDecl *VarInst =
   cast_or_null(VisitVarDecl(Pattern,
  /*InstantiatingVarTemplate=*/true));
+  if (!VarInst) return nullptr;
 
   DeclContext *DC = Owner;
 

Modified: cfe/trunk/test/SemaCXX/cxx1y-variable-templates_in_class.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/cxx1y-variable-templates_in_class.cpp?rev=244515&r1=244514&r2=244515&view=diff
==
--- cfe/trunk/test/SemaCXX/cxx1y-variable-templates_in_class.cpp (original)
+++ cfe/trunk/test/SemaCXX/cxx1y-variable-templates_in_class.cpp Mon Aug 10 
16:54:08 2015
@@ -327,3 +327,14 @@ struct S {
   static int f : I; // expected-error {{static member 'f' cannot be a 
bit-field}}
 };
 }
+
+namespace b20896909 {
+  // This used to crash.
+  template struct helper {};
+  template class A {
+template  static helper x;  // expected-error 
{{type 'int' cannot be used prior to '::' because it has no members}}
+  };
+  void test() {
+A ai;  // expected-note {{in instantiation of}}
+  }
+}


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

Re: [PATCH] D11781: Refactored pthread usage in libcxx

[Fulvio Esposito via cfe-commits]

espositofulvio added inline comments.


Comment at: include/__config:742
@@ +741,3 @@
+#ifndef _LIBCPP_HAS_NO_THREADS
+# if defined(__FreeBSD__) || \
+defined(__NetBSD__) || \

jroelofs wrote:
> jroelofs wrote:
> > @espositofulvio: @ed meant this:
> > 
> > ```
> > #ifndef _WIN32
> > #  include 
> > #  if _POSIX_THREADS > 0
> > ...
> > #  endif
> > #endif
> > ```
> > 
> > Which //is// the correct way to test for this.
> That being said, there have been discussions before about whether or not we 
> should #include  in <__config>, with the conclusion being that we 
> shouldn't.
> 
> It would be better if this were a CMake configure-time check that sets 
> _LIBCPP_THREAD_API, rather than these build-time guards.
Tried adding that as configure time checks, but then libcxxabi fails to compile 
because of the guard in __config to check that _LIBCPP_THREAD_API has beed 
defined when _LIBCPP_HAS_NO_THREADS is not. 

As a side note: Is Windows the only OS which hasn't got unistd.h?


Repository:
  rL LLVM

http://reviews.llvm.org/D11781



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

r244517 - Make frontend floating-point commutivity test X86 specific to avoid cost-model related problems on arm-thumb and hexagon.

[Tyler Nowicki via cfe-commits]

Author: tnowicki
Date: Mon Aug 10 17:17:40 2015
New Revision: 244517

URL: http://llvm.org/viewvc/llvm-project?rev=244517&view=rev
Log:
Make frontend floating-point commutivity test X86 specific to avoid cost-model 
related problems on arm-thumb and hexagon.

Modified:
cfe/trunk/test/Frontend/optimization-remark-options.c

Modified: cfe/trunk/test/Frontend/optimization-remark-options.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/optimization-remark-options.c?rev=244517&r1=244516&r2=244517&view=diff
==
--- cfe/trunk/test/Frontend/optimization-remark-options.c (original)
+++ cfe/trunk/test/Frontend/optimization-remark-options.c Mon Aug 10 17:17:40 
2015
@@ -1,4 +1,4 @@
-// RUN: %clang -O1 -fvectorize -Rpass-analysis=loop-vectorize -emit-llvm -S %s 
-o - 2>&1 | FileCheck %s
+// RUN: %clang -O1 -fvectorize -target x86_64-unknown-unknown 
-Rpass-analysis=loop-vectorize -emit-llvm -S %s -o - 2>&1 | FileCheck %s
 
 // CHECK: {{.*}}:9:11: remark: loop not vectorized: vectorization requires 
changes in the order of operations, however IEEE 754 floating-point operations 
are not commutative; allow commutativity by specifying '#pragma clang loop 
vectorize(enable)' before the loop or by providing the compiler option 
'-ffast-math'
 


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

Re: [PATCH] D11781: Refactored pthread usage in libcxx

[Jonathan Roelofs via cfe-commits]

jroelofs added inline comments.


Comment at: include/__config:742
@@ +741,3 @@
+#ifndef _LIBCPP_HAS_NO_THREADS
+# if defined(__FreeBSD__) || \
+defined(__NetBSD__) || \

espositofulvio wrote:
> jroelofs wrote:
> > jroelofs wrote:
> > > @espositofulvio: @ed meant this:
> > > 
> > > ```
> > > #ifndef _WIN32
> > > #  include 
> > > #  if _POSIX_THREADS > 0
> > > ...
> > > #  endif
> > > #endif
> > > ```
> > > 
> > > Which //is// the correct way to test for this.
> > That being said, there have been discussions before about whether or not we 
> > should #include  in <__config>, with the conclusion being that we 
> > shouldn't.
> > 
> > It would be better if this were a CMake configure-time check that sets 
> > _LIBCPP_THREAD_API, rather than these build-time guards.
> Tried adding that as configure time checks, but then libcxxabi fails to 
> compile because of the guard in __config to check that _LIBCPP_THREAD_API has 
> beed defined when _LIBCPP_HAS_NO_THREADS is not. 
> 
> As a side note: Is Windows the only OS which hasn't got unistd.h?
> Tried adding that as configure time checks...

Can you put the patch for that up on gist.github.com, or a pastebin?... I'll 
take a look.

> As a side note: Is Windows the only OS which hasn't got unistd.h?

For the platforms libcxx currently builds on, yes.


Repository:
  rL LLVM

http://reviews.llvm.org/D11781



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

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

[Anna Zaks via cfe-commits]

zaks.anna added a comment.

We need a way to test this functionality. One way of testing this would be to 
write unit tests. Gabor has already added such tests for the static analyzer.


http://reviews.llvm.org/D10305



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

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

[Anna Zaks via cfe-commits]

zaks.anna added a comment.

honggyu.kim,

You are right, CmpRuns.py does not work with HTML files.

The list of HTML reports is produced by scan-build and there is no facility 
there to search for newly generated reports. It is also not clear that there 
should be one HTML file per report. This is what we have now but the current 
approach does not scale well for large files with numerous reports (since we 
create a copy of the file for each report.) We do not have a proper design for 
issue uniquing with HTML interface in tree.


http://reviews.llvm.org/D10305



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

[PATCH] D11921: Add NaCl (a target where long double = double) to long double ABI test

[Derek Schuff via cfe-commits]

dschuff created this revision.
dschuff added reviewers: rnk, chh, majnemer, echristo.
dschuff added a subscriber: cfe-commits.
Herald added subscribers: srhines, danalbert, tberghammer, jfb.

A test was recently (r244468) added to cover long double calling convention
codegen, distinguishing between Android and GNU conventions (where long doubles
are fp128 and x86_fp80, respectively). Native Client is a target where long
doubles are the same as doubles. This change augments the test to cover
that case.

http://reviews.llvm.org/D11921

Files:
  test/CodeGen/x86_64-fp128.c

Index: test/CodeGen/x86_64-fp128.c
===
--- test/CodeGen/x86_64-fp128.c
+++ test/CodeGen/x86_64-fp128.c
@@ -4,6 +4,9 @@
 // RUN:| FileCheck %s --check-prefix=GNU --check-prefix=CHECK
 // RUN: %clang_cc1 -triple x86_64 -emit-llvm -O -o - %s \
 // RUN:| FileCheck %s --check-prefix=GNU --check-prefix=CHECK
+// NaCl is an example of a target for which long double is the same as double.
+// RUN: %clang_cc1 -triple x86_64-nacl -emit-llvm -O -o - %s \
+// RUN:| FileCheck %s --check-prefix=NACL --check-prefix=CHECK
 
 // Android uses fp128 for long double but other x86_64 targets use x86_fp80.
 
@@ -19,12 +22,14 @@
   return x * x;
 // ANDROID: define fp128 @TestLD(fp128 %x)
 // GNU: define x86_fp80 @TestLD(x86_fp80 %x)
+// NACL: define double @TestLD(double %x)
 }
 
 long double _Complex TestLDC(long double _Complex x) {
   return x * x;
 // ANDROID: define void @TestLDC({ fp128, fp128 }* {{.*}}, { fp128, fp128 }* 
{{.*}} %x)
 // GNU: define { x86_fp80, x86_fp80 } @TestLDC({ x86_fp80, x86_fp80 }* {{.*}} 
%x)
+// NACL: define { double, double } @TestLDC(double %x{{.*}}, double %x{{.*}})
 }
 
 typedef __builtin_va_list va_list;
@@ -51,14 +56,18 @@
 
 long double TestGetVarLD(va_list ap) {
   return __builtin_va_arg(ap, long double);
-// fp128 can be passed in memory or in register, but x86_fp80 is in memory.
+// fp128 and double can be passed in memory or in register, but x86_fp80 is in
+// memory.
 // ANDROID: define fp128 @TestGetVarLD(
 // GNU: define x86_fp80 @TestGetVarLD(
+// NACL: define double @TestGetVarLD(
 // ANDROID: br
 // GNU-NOT: br
+// NACL: br
 // CHECK:   load {{.*}} %overflow_arg_area_p
 // ANDROID: = phi
 // GNU-NOT: = phi
+// NACL: = phi
 // ANDROID: ret fp128
 // GNU: ret x86_fp80
 }
@@ -68,11 +77,18 @@
 // Pair of fp128 or x86_fp80 are passed as struct in memory.
 // ANDROID:   define void @TestGetVarLDC({ fp128, fp128 }* {{.*}}, 
%struct.__va_list_tag*
 // GNU:   define { x86_fp80, x86_fp80 } @TestGetVarLDC(
-// CHECK-NOT: br
+// Pair of double can go in SSE registers or memory
+// NACL:   define { double, double } @TestGetVarLDC(
+// ANDROID-NOT: br
+// GNU-NOT: br
+// NACL: br
 // CHECK: load {{.*}} %overflow_arg_area_p
-// CHECK-NOT: phi
+// ANDROID-NOT: phi
+// GNU-NOT: phi
+// NACL: phi
 // ANDROID:   ret void
 // GNU:   ret { x86_fp80, x86_fp80 }
+// NACL:   ret { double, double }
 }
 
 void TestVarArg(const char *s, ...);
@@ -101,6 +117,8 @@
 // ANDROID: call {{.*}} @TestVarArg(i8* {{.*}}, fp128 %x
 // GNU: define void @TestPassVarLD(x86_fp80 %x)
 // GNU: call {{.*}} @TestVarArg(i8* {{.*}}, x86_fp80 %x
+// NACL: define void @TestPassVarLD(double %x)
+// NACL: call {{.*}} @TestVarArg(i8* {{.*}}, double %x
 }
 
 void TestPassVarLDC(long double _Complex x) {
@@ -112,5 +130,7 @@
 // GNU:  define void @TestPassVarLDC({ x86_fp80, x86_fp80 }* {{.*}} %x)
 // GNU:  store x86_fp80 %x.{{.*}}, x86_fp80* %
 // GNU-NEXT: store x86_fp80 %x.{{.*}}, x86_fp80* %
-// GNGNU-NEXT:   call {{.*}} @TestVarArg(i8* {{.*}}, { x86_fp80, x86_fp80 }* 
{{.*}} %
+// GNU-NEXT:   call {{.*}} @TestVarArg(i8* {{.*}}, { x86_fp80, x86_fp80 }* 
{{.*}} %
+// NACL:  define void @TestPassVarLDC(double %x{{.*}}, double %x{{.*}})
+// NACL: call {{.*}} @TestVarArg(i8* {{.*}}, double %x{{.*}}, double %x{{.*}})
 }


Index: test/CodeGen/x86_64-fp128.c
===
--- test/CodeGen/x86_64-fp128.c
+++ test/CodeGen/x86_64-fp128.c
@@ -4,6 +4,9 @@
 // RUN:| FileCheck %s --check-prefix=GNU --check-prefix=CHECK
 // RUN: %clang_cc1 -triple x86_64 -emit-llvm -O -o - %s \
 // RUN:| FileCheck %s --check-prefix=GNU --check-prefix=CHECK
+// NaCl is an example of a target for which long double is the same as double.
+// RUN: %clang_cc1 -triple x86_64-nacl -emit-llvm -O -o - %s \
+// RUN:| FileCheck %s --check-prefix=NACL --check-prefix=CHECK
 
 // Android uses fp128 for long double but other x86_64 targets use x86_fp80.
 
@@ -19,12 +22,14 @@
   return x * x;
 // ANDROID: define fp128 @TestLD(fp128 %x)
 // GNU: define x86_fp80 @TestLD(x86_fp80 %x)
+// NACL: define double @TestLD(double %x)
 }
 
 long double _Complex TestLDC(long double _Complex x) {
   return x * x;
 // ANDROID: define void @TestLDC({ fp128, fp128 }* {{.*}}, { fp128, fp128 }* {{.*}} %x)
 // GNU: define { x86_fp80, x86_

Re: [PATCH] D11921: Add NaCl (a target where long double = double) to long double ABI test

[Derek Schuff via cfe-commits]

dschuff added a comment.

Should this test be renamed to x86_longdouble.c or some such instead of fp128?


http://reviews.llvm.org/D11921



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

Re: [PATCH] D11921: Add NaCl (a target where long double = double) to long double ABI test

[Reid Kleckner via cfe-commits]

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

lgtm

In http://reviews.llvm.org/D11921#221136, @dschuff wrote:

> Should this test be renamed to x86_longdouble.c or some such instead of fp128?


Yeah, x86_64-longdouble.c is probably better.


http://reviews.llvm.org/D11921



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

Re: [PATCH] D11921: Add NaCl (a target where long double = double) to long double ABI test

[Derek Schuff via cfe-commits]

dschuff updated this revision to Diff 31741.
dschuff added a comment.
Herald added a subscriber: dschuff.

- rename to x86_64-longdouble.c


http://reviews.llvm.org/D11921

Files:
  test/CodeGen/x86_64-fp128.c
  test/CodeGen/x86_64-longdouble.c

Index: test/CodeGen/x86_64-longdouble.c
===
--- test/CodeGen/x86_64-longdouble.c
+++ test/CodeGen/x86_64-longdouble.c
@@ -4,6 +4,9 @@
 // RUN:| FileCheck %s --check-prefix=GNU --check-prefix=CHECK
 // RUN: %clang_cc1 -triple x86_64 -emit-llvm -O -o - %s \
 // RUN:| FileCheck %s --check-prefix=GNU --check-prefix=CHECK
+// NaCl is an example of a target for which long double is the same as double.
+// RUN: %clang_cc1 -triple x86_64-nacl -emit-llvm -O -o - %s \
+// RUN:| FileCheck %s --check-prefix=NACL --check-prefix=CHECK
 
 // Android uses fp128 for long double but other x86_64 targets use x86_fp80.
 
@@ -19,12 +22,14 @@
   return x * x;
 // ANDROID: define fp128 @TestLD(fp128 %x)
 // GNU: define x86_fp80 @TestLD(x86_fp80 %x)
+// NACL: define double @TestLD(double %x)
 }
 
 long double _Complex TestLDC(long double _Complex x) {
   return x * x;
 // ANDROID: define void @TestLDC({ fp128, fp128 }* {{.*}}, { fp128, fp128 }* 
{{.*}} %x)
 // GNU: define { x86_fp80, x86_fp80 } @TestLDC({ x86_fp80, x86_fp80 }* {{.*}} 
%x)
+// NACL: define { double, double } @TestLDC(double %x{{.*}}, double %x{{.*}})
 }
 
 typedef __builtin_va_list va_list;
@@ -51,14 +56,18 @@
 
 long double TestGetVarLD(va_list ap) {
   return __builtin_va_arg(ap, long double);
-// fp128 can be passed in memory or in register, but x86_fp80 is in memory.
+// fp128 and double can be passed in memory or in register, but x86_fp80 is in
+// memory.
 // ANDROID: define fp128 @TestGetVarLD(
 // GNU: define x86_fp80 @TestGetVarLD(
+// NACL: define double @TestGetVarLD(
 // ANDROID: br
 // GNU-NOT: br
+// NACL: br
 // CHECK:   load {{.*}} %overflow_arg_area_p
 // ANDROID: = phi
 // GNU-NOT: = phi
+// NACL: = phi
 // ANDROID: ret fp128
 // GNU: ret x86_fp80
 }
@@ -68,11 +77,18 @@
 // Pair of fp128 or x86_fp80 are passed as struct in memory.
 // ANDROID:   define void @TestGetVarLDC({ fp128, fp128 }* {{.*}}, 
%struct.__va_list_tag*
 // GNU:   define { x86_fp80, x86_fp80 } @TestGetVarLDC(
-// CHECK-NOT: br
+// Pair of double can go in SSE registers or memory
+// NACL:   define { double, double } @TestGetVarLDC(
+// ANDROID-NOT: br
+// GNU-NOT: br
+// NACL: br
 // CHECK: load {{.*}} %overflow_arg_area_p
-// CHECK-NOT: phi
+// ANDROID-NOT: phi
+// GNU-NOT: phi
+// NACL: phi
 // ANDROID:   ret void
 // GNU:   ret { x86_fp80, x86_fp80 }
+// NACL:   ret { double, double }
 }
 
 void TestVarArg(const char *s, ...);
@@ -101,6 +117,8 @@
 // ANDROID: call {{.*}} @TestVarArg(i8* {{.*}}, fp128 %x
 // GNU: define void @TestPassVarLD(x86_fp80 %x)
 // GNU: call {{.*}} @TestVarArg(i8* {{.*}}, x86_fp80 %x
+// NACL: define void @TestPassVarLD(double %x)
+// NACL: call {{.*}} @TestVarArg(i8* {{.*}}, double %x
 }
 
 void TestPassVarLDC(long double _Complex x) {
@@ -112,5 +130,7 @@
 // GNU:  define void @TestPassVarLDC({ x86_fp80, x86_fp80 }* {{.*}} %x)
 // GNU:  store x86_fp80 %x.{{.*}}, x86_fp80* %
 // GNU-NEXT: store x86_fp80 %x.{{.*}}, x86_fp80* %
-// GNGNU-NEXT:   call {{.*}} @TestVarArg(i8* {{.*}}, { x86_fp80, x86_fp80 }* 
{{.*}} %
+// GNU-NEXT:   call {{.*}} @TestVarArg(i8* {{.*}}, { x86_fp80, x86_fp80 }* 
{{.*}} %
+// NACL:  define void @TestPassVarLDC(double %x{{.*}}, double %x{{.*}})
+// NACL: call {{.*}} @TestVarArg(i8* {{.*}}, double %x{{.*}}, double %x{{.*}})
 }


Index: test/CodeGen/x86_64-longdouble.c
===
--- test/CodeGen/x86_64-longdouble.c
+++ test/CodeGen/x86_64-longdouble.c
@@ -4,6 +4,9 @@
 // RUN:| FileCheck %s --check-prefix=GNU --check-prefix=CHECK
 // RUN: %clang_cc1 -triple x86_64 -emit-llvm -O -o - %s \
 // RUN:| FileCheck %s --check-prefix=GNU --check-prefix=CHECK
+// NaCl is an example of a target for which long double is the same as double.
+// RUN: %clang_cc1 -triple x86_64-nacl -emit-llvm -O -o - %s \
+// RUN:| FileCheck %s --check-prefix=NACL --check-prefix=CHECK
 
 // Android uses fp128 for long double but other x86_64 targets use x86_fp80.
 
@@ -19,12 +22,14 @@
   return x * x;
 // ANDROID: define fp128 @TestLD(fp128 %x)
 // GNU: define x86_fp80 @TestLD(x86_fp80 %x)
+// NACL: define double @TestLD(double %x)
 }
 
 long double _Complex TestLDC(long double _Complex x) {
   return x * x;
 // ANDROID: define void @TestLDC({ fp128, fp128 }* {{.*}}, { fp128, fp128 }* {{.*}} %x)
 // GNU: define { x86_fp80, x86_fp80 } @TestLDC({ x86_fp80, x86_fp80 }* {{.*}} %x)
+// NACL: define { double, double } @TestLDC(double %x{{.*}}, double %x{{.*}})
 }
 
 typedef __builtin_va_list va_list;
@@ -51,14 +56,18 @@
 
 long double TestGetVarLD(va_list ap) {
   return __builtin_va_arg(ap, long double);
-// fp128 can be passed 

r244524 - Add NaCl (a target where long double = double) to long double ABI test

[Derek Schuff via cfe-commits]

Author: dschuff
Date: Mon Aug 10 18:02:37 2015
New Revision: 244524

URL: http://llvm.org/viewvc/llvm-project?rev=244524&view=rev
Log:
Add NaCl (a target where long double = double) to long double ABI test

A test was recently (r244468) added to cover long double calling convention
codegen, distinguishing between Android and GNU conventions (where long doubles
are fp128 and x86_fp80, respectively). Native Client is a target where long
doubles are the same as doubles. This change augments the test to cover
that case.

Also rename the test to test/codeGen/X86_64-longdouble.c

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

Added:
cfe/trunk/test/CodeGen/x86_64-longdouble.c
  - copied, changed from r244517, cfe/trunk/test/CodeGen/x86_64-fp128.c
Removed:
cfe/trunk/test/CodeGen/x86_64-fp128.c

Removed: cfe/trunk/test/CodeGen/x86_64-fp128.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/x86_64-fp128.c?rev=244523&view=auto
==
--- cfe/trunk/test/CodeGen/x86_64-fp128.c (original)
+++ cfe/trunk/test/CodeGen/x86_64-fp128.c (removed)
@@ -1,115 +0,0 @@
-// RUN: %clang_cc1 -triple x86_64-linux-android -emit-llvm -O -o - %s \
-// RUN:| FileCheck %s --check-prefix=ANDROID --check-prefix=CHECK
-// RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm -O -o - %s \
-// RUN:| FileCheck %s --check-prefix=GNU --check-prefix=CHECK
-// RUN: %clang_cc1 -triple x86_64 -emit-llvm -O -o - %s \
-// RUN:| FileCheck %s --check-prefix=GNU --check-prefix=CHECK
-
-// Android uses fp128 for long double but other x86_64 targets use x86_fp80.
-
-long double dataLD = 1.0L;
-// ANDROID: @dataLD = global fp128 0xL3FFF, align 
16
-// GNU: @dataLD = global x86_fp80 0xK3FFF8000, align 16
-
-long double _Complex dataLDC = {1.0L, 1.0L};
-// ANDROID: @dataLDC = global { fp128, fp128 } { fp128 
0xL3FFF, fp128 0xL3FFF 
}, align 16
-// GNU: @dataLDC = global { x86_fp80, x86_fp80 } { x86_fp80 
0xK3FFF8000, x86_fp80 0xK3FFF8000 }, align 16
-
-long double TestLD(long double x) {
-  return x * x;
-// ANDROID: define fp128 @TestLD(fp128 %x)
-// GNU: define x86_fp80 @TestLD(x86_fp80 %x)
-}
-
-long double _Complex TestLDC(long double _Complex x) {
-  return x * x;
-// ANDROID: define void @TestLDC({ fp128, fp128 }* {{.*}}, { fp128, fp128 }* 
{{.*}} %x)
-// GNU: define { x86_fp80, x86_fp80 } @TestLDC({ x86_fp80, x86_fp80 }* {{.*}} 
%x)
-}
-
-typedef __builtin_va_list va_list;
-
-int TestGetVarInt(va_list ap) {
-  return __builtin_va_arg(ap, int);
-// Since int can be passed in memory or register there are two branches.
-// CHECK:   define i32 @TestGetVarInt(
-// CHECK:   br label
-// CHECK:   br label
-// CHECK:   = phi
-// CHECK:   ret i32
-}
-
-double TestGetVarDouble(va_list ap) {
-  return __builtin_va_arg(ap, double);
-// Since double can be passed in memory or register there are two branches.
-// CHECK:   define double @TestGetVarDouble(
-// CHECK:   br label
-// CHECK:   br label
-// CHECK:   = phi
-// CHECK:   ret double
-}
-
-long double TestGetVarLD(va_list ap) {
-  return __builtin_va_arg(ap, long double);
-// fp128 can be passed in memory or in register, but x86_fp80 is in memory.
-// ANDROID: define fp128 @TestGetVarLD(
-// GNU: define x86_fp80 @TestGetVarLD(
-// ANDROID: br label
-// ANDROID: br label
-// ANDROID: = phi
-// GNU-NOT: br
-// GNU-NOT: = phi
-// ANDROID: ret fp128
-// GNU: ret x86_fp80
-}
-
-long double _Complex TestGetVarLDC(va_list ap) {
-  return __builtin_va_arg(ap, long double _Complex);
-// Pair of fp128 or x86_fp80 are passed as struct in memory.
-// ANDROID:   define void @TestGetVarLDC({ fp128, fp128 }* {{.*}}, 
%struct.__va_list_tag*
-// GNU:   define { x86_fp80, x86_fp80 } @TestGetVarLDC(
-// CHECK-NOT: br
-// CHECK-NOT: phi
-// ANDROID:   ret void
-// GNU:   ret { x86_fp80, x86_fp80 }
-}
-
-void TestVarArg(const char *s, ...);
-
-void TestPassVarInt(int x) {
-  TestVarArg("A", x);
-// CHECK: define void @TestPassVarInt(i32 %x)
-// CHECK: call {{.*}} @TestVarArg(i8* {{.*}}, i32 %x)
-}
-
-void TestPassVarFloat(float x) {
-  TestVarArg("A", x);
-// CHECK: define void @TestPassVarFloat(float %x)
-// CHECK: call {{.*}} @TestVarArg(i8* {{.*}}, double %
-}
-
-void TestPassVarDouble(double x) {
-  TestVarArg("A", x);
-// CHECK: define void @TestPassVarDouble(double %x)
-// CHECK: call {{.*}} @TestVarArg(i8* {{.*}}, double %x
-}
-
-void TestPassVarLD(long double x) {
-  TestVarArg("A", x);
-// ANDROID: define void @TestPassVarLD(fp128 %x)
-// ANDROID: call {{.*}} @TestVarArg(i8* {{.*}}, fp128 %x
-// GNU: define void @TestPassVarLD(x86_fp80 %x)
-// GNU: call {{.*}} @TestVarArg(i8* {{.*}}, x86_fp80 %x
-}
-
-void TestPassVarLDC(long double _Complex x) {
-  TestVarArg("A", x);
-// ANDROID:  define void @TestPassVarLDC({ fp128, fp128 }* {{.*}} %x)
-// ANDROID:  store fp128 %{{

Re: [PATCH] D11921: Add NaCl (a target where long double = double) to long double ABI test

[Derek Schuff via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL244524: Add NaCl (a target where long double = double) to 
long double ABI test (authored by dschuff).

Changed prior to commit:
  http://reviews.llvm.org/D11921?vs=31741&id=31743#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D11921

Files:
  cfe/trunk/test/CodeGen/x86_64-fp128.c
  cfe/trunk/test/CodeGen/x86_64-longdouble.c

Index: cfe/trunk/test/CodeGen/x86_64-longdouble.c
===
--- cfe/trunk/test/CodeGen/x86_64-longdouble.c
+++ cfe/trunk/test/CodeGen/x86_64-longdouble.c
@@ -0,0 +1,135 @@
+// RUN: %clang_cc1 -triple x86_64-linux-android -emit-llvm -O -o - %s \
+// RUN:| FileCheck %s --check-prefix=ANDROID --check-prefix=CHECK
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm -O -o - %s \
+// RUN:| FileCheck %s --check-prefix=GNU --check-prefix=CHECK
+// RUN: %clang_cc1 -triple x86_64 -emit-llvm -O -o - %s \
+// RUN:| FileCheck %s --check-prefix=GNU --check-prefix=CHECK
+// NaCl is an example of a target for which long double is the same as double.
+// RUN: %clang_cc1 -triple x86_64-nacl -emit-llvm -O -o - %s \
+// RUN:| FileCheck %s --check-prefix=NACL --check-prefix=CHECK
+
+// Android uses fp128 for long double but other x86_64 targets use x86_fp80.
+
+long double dataLD = 1.0L;
+// ANDROID: @dataLD = global fp128 0xL3FFF, align 16
+// GNU: @dataLD = global x86_fp80 0xK3FFF8000, align 16
+
+long double _Complex dataLDC = {1.0L, 1.0L};
+// ANDROID: @dataLDC = global { fp128, fp128 } { fp128 0xL3FFF, fp128 0xL3FFF }, align 16
+// GNU: @dataLDC = global { x86_fp80, x86_fp80 } { x86_fp80 0xK3FFF8000, x86_fp80 0xK3FFF8000 }, align 16
+
+long double TestLD(long double x) {
+  return x * x;
+// ANDROID: define fp128 @TestLD(fp128 %x)
+// GNU: define x86_fp80 @TestLD(x86_fp80 %x)
+// NACL: define double @TestLD(double %x)
+}
+
+long double _Complex TestLDC(long double _Complex x) {
+  return x * x;
+// ANDROID: define void @TestLDC({ fp128, fp128 }* {{.*}}, { fp128, fp128 }* {{.*}} %x)
+// GNU: define { x86_fp80, x86_fp80 } @TestLDC({ x86_fp80, x86_fp80 }* {{.*}} %x)
+// NACL: define { double, double } @TestLDC(double %x{{.*}}, double %x{{.*}})
+}
+
+typedef __builtin_va_list va_list;
+
+int TestGetVarInt(va_list ap) {
+  return __builtin_va_arg(ap, int);
+// Since int can be passed in memory or register there are two branches.
+// CHECK:   define i32 @TestGetVarInt(
+// CHECK:   br label
+// CHECK:   br label
+// CHECK:   = phi
+// CHECK:   ret i32
+}
+
+double TestGetVarDouble(va_list ap) {
+  return __builtin_va_arg(ap, double);
+// Since double can be passed in memory or register there are two branches.
+// CHECK:   define double @TestGetVarDouble(
+// CHECK:   br label
+// CHECK:   br label
+// CHECK:   = phi
+// CHECK:   ret double
+}
+
+long double TestGetVarLD(va_list ap) {
+  return __builtin_va_arg(ap, long double);
+// fp128 and double can be passed in memory or in register, but x86_fp80 is in
+// memory.
+// ANDROID: define fp128 @TestGetVarLD(
+// GNU: define x86_fp80 @TestGetVarLD(
+// NACL: define double @TestGetVarLD(
+// ANDROID: br label
+// ANDROID: br label
+// NACL: br
+// ANDROID: = phi
+// GNU-NOT: br
+// GNU-NOT: = phi
+// NACL: = phi
+// ANDROID: ret fp128
+// GNU: ret x86_fp80
+}
+
+long double _Complex TestGetVarLDC(va_list ap) {
+  return __builtin_va_arg(ap, long double _Complex);
+// Pair of fp128 or x86_fp80 are passed as struct in memory.
+// ANDROID:   define void @TestGetVarLDC({ fp128, fp128 }* {{.*}}, %struct.__va_list_tag*
+// GNU:   define { x86_fp80, x86_fp80 } @TestGetVarLDC(
+// Pair of double can go in SSE registers or memory
+// NACL:   define { double, double } @TestGetVarLDC(
+// ANDROID-NOT: br
+// GNU-NOT: br
+// NACL: br
+// ANDROID-NOT: phi
+// GNU-NOT: phi
+// NACL: phi
+// ANDROID:   ret void
+// GNU:   ret { x86_fp80, x86_fp80 }
+// NACL:   ret { double, double }
+}
+
+void TestVarArg(const char *s, ...);
+
+void TestPassVarInt(int x) {
+  TestVarArg("A", x);
+// CHECK: define void @TestPassVarInt(i32 %x)
+// CHECK: call {{.*}} @TestVarArg(i8* {{.*}}, i32 %x)
+}
+
+void TestPassVarFloat(float x) {
+  TestVarArg("A", x);
+// CHECK: define void @TestPassVarFloat(float %x)
+// CHECK: call {{.*}} @TestVarArg(i8* {{.*}}, double %
+}
+
+void TestPassVarDouble(double x) {
+  TestVarArg("A", x);
+// CHECK: define void @TestPassVarDouble(double %x)
+// CHECK: call {{.*}} @TestVarArg(i8* {{.*}}, double %x
+}
+
+void TestPassVarLD(long double x) {
+  TestVarArg("A", x);
+// ANDROID: define void @TestPassVarLD(fp128 %x)
+// ANDROID: call {{.*}} @TestVarArg(i8* {{.*}}, fp128 %x
+// GNU: define void @TestPassVarLD(x86_fp80 %x)
+// GNU: call {{.*}} @TestVarArg(i8* {{.*}}, x86_fp80 %x
+// NACL: define void @TestPassVarLD(double %x)
+// NACL: call {{.*

Re: [PATCH] D11921: Add NaCl (a target where long double = double) to long double ABI test

[Chih-Hung Hsieh via cfe-commits]

chh added a comment.

Please rebase the change to r244502 or newer, to run with -Asserts builds.
Thanks.


Repository:
  rL LLVM

http://reviews.llvm.org/D11921



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

Re: [PATCH] D11921: Add NaCl (a target where long double = double) to long double ABI test

[Derek Schuff via cfe-commits]

dschuff added a comment.

In http://reviews.llvm.org/D11921#221172, @chh wrote:

> Please rebase the change to r244502 or newer, to run with -Asserts builds.


Did that; Not sure it's reflected on Phabricator, but I did check the diff.
Thanks!


Repository:
  rL LLVM

http://reviews.llvm.org/D11921



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

r244526 - Append options for vectorization when pointer checking threshold is exceeded.

[Tyler Nowicki via cfe-commits]

Author: tnowicki
Date: Mon Aug 10 18:05:16 2015
New Revision: 244526

URL: http://llvm.org/viewvc/llvm-project?rev=244526&view=rev
Log:
Append options for vectorization when pointer checking threshold is exceeded.

Following one of the appended options will allow the loop to be vectorized. We 
do not include a command line option for modifying the pointer checking 
threshold because there is no clang-level interface for this currently.

Modified:
cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
cfe/trunk/lib/CodeGen/CodeGenAction.cpp
cfe/trunk/test/Frontend/optimization-remark-options.c

Modified: cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td?rev=244526&r1=244525&r2=244526&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td Mon Aug 10 
18:05:16 2015
@@ -49,6 +49,12 @@ def remark_fe_backend_optimization_remar
 "allow commutativity by specifying '#pragma clang loop vectorize(enable)' "
 "before the loop or by providing the compiler option '-ffast-math'">,
 BackendInfo, InGroup;
+def remark_fe_backend_optimization_remark_analysis_aliasing : Remark<"%0; "
+"avoid runtime pointer checking when you know the arrays will always be "
+"independent by specifying '#pragma clang loop vectorize(assume_safety)' "
+"before the loop or by specifying 'restrict' on the array arguments. "
+"Erroneous results will occur if these options are incorrectly applied!">,
+BackendInfo, InGroup;
 def warn_fe_backend_optimization_failure : Warning<"%0">, BackendInfo,
 InGroup, DefaultWarn;
 def note_fe_backend_optimization_remark_invalid_loc : Note<"could "

Modified: cfe/trunk/lib/CodeGen/CodeGenAction.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenAction.cpp?rev=244526&r1=244525&r2=244526&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenAction.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenAction.cpp Mon Aug 10 18:05:16 2015
@@ -258,6 +258,8 @@ namespace clang {
 const llvm::DiagnosticInfoOptimizationRemarkAnalysis &D);
 void OptimizationRemarkHandler(
 const llvm::DiagnosticInfoOptimizationRemarkAnalysisFPCommute &D);
+void OptimizationRemarkHandler(
+const llvm::DiagnosticInfoOptimizationRemarkAnalysisAliasing &D);
 void OptimizationFailureHandler(
 const llvm::DiagnosticInfoOptimizationFailure &D);
   };
@@ -513,6 +515,17 @@ void BackendConsumer::OptimizationRemark
 D, diag::remark_fe_backend_optimization_remark_analysis_fpcommute);
 }
 
+void BackendConsumer::OptimizationRemarkHandler(
+const llvm::DiagnosticInfoOptimizationRemarkAnalysisAliasing &D) {
+  // Optimization analysis remarks are active only if the -Rpass-analysis
+  // flag has a regular expression that matches the name of the pass
+  // name in \p D.
+  if (CodeGenOpts.OptimizationRemarkAnalysisPattern &&
+  CodeGenOpts.OptimizationRemarkAnalysisPattern->match(D.getPassName()))
+EmitOptimizationMessage(
+D, diag::remark_fe_backend_optimization_remark_analysis_aliasing);
+}
+
 void BackendConsumer::OptimizationFailureHandler(
 const llvm::DiagnosticInfoOptimizationFailure &D) {
   EmitOptimizationMessage(D, diag::warn_fe_backend_optimization_failure);
@@ -572,6 +585,12 @@ void BackendConsumer::DiagnosticHandlerI
 OptimizationRemarkHandler(
 cast(DI));
 return;
+  case llvm::DK_OptimizationRemarkAnalysisAliasing:
+// Optimization remarks are always handled completely by this
+// handler. There is no generic way of emitting them.
+OptimizationRemarkHandler(
+cast(DI));
+return;
   case llvm::DK_OptimizationFailure:
 // Optimization failures are always handled completely by this
 // handler.

Modified: cfe/trunk/test/Frontend/optimization-remark-options.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/optimization-remark-options.c?rev=244526&r1=244525&r2=244526&view=diff
==
--- cfe/trunk/test/Frontend/optimization-remark-options.c (original)
+++ cfe/trunk/test/Frontend/optimization-remark-options.c Mon Aug 10 18:05:16 
2015
@@ -10,3 +10,12 @@ double foo(int N) {
 
   return v;
 }
+
+// CHECK: {{.*}}:18:13: remark: loop not vectorized: cannot prove pointers 
refer to independent arrays in memory. The loop requires 9 runtime independence 
checks to vectorize the loop, but that would exceed the limit of 8 checks; 
avoid runtime pointer checking when you know the arrays will always be 
independent by specifying '#pragma clang loop vectorize(assume_safety)' before 
the loop or by specifying 'restrict' on the array arguments. Erron

Re: [Patch][LoopVectorize] Late evaluate of runtime pointer check's threshold

[Tyler Nowicki via cfe-commits]

Hi Hal,

Thanks, the patches are committed in r244523 and r244526.

There are two possibilities to give the user control over pointer checking. We 
could add a loop hint option like vectorize(check_safety) that would be a safe 
version of ‘assume_safety’ or we could simply make it always emit the necessary 
pointer checks, no matter how many of them there are, when the loop hint 
vectorize(enable) is specified?

What do you think?

Tyler

> On Aug 9, 2015, at 9:41 PM, Hal Finkel  wrote:
> 
> Hi Tyler,
> 
> This looks very useful.
> 
> Please don't mention '-mllvm -runtime-memory-check-threshold=' in the error 
> message. We should add some clause to #pragma clang loop to control this 
> feature with some associated metadata. '-mllvm' things should not be part of 
> the advertised interface to end users (but that should be a separate set of 
> patches regardless).
> 
> Otherwise, LGTM.
> 
> Thanks again,
> Hal
> 
> - Original Message -
>> From: "Tyler Nowicki" mailto:tnowi...@apple.com>>
>> To: "Hal J. Finkel" mailto:hfin...@anl.gov>>, "Commit 
>> Messages and Patches for LLVM" > >, "llvm
>> cfe" mailto:cfe-commits@lists.llvm.org>>
>> Cc: "Gerolf Hoflehner" mailto:ghofleh...@apple.com>>
>> Sent: Thursday, August 6, 2015 3:25:26 PM
>> Subject: [Patch][LoopVectorize] Late evaluate of runtime pointer check's 
>> threshold
>> 
>> 
>> Hi,
>> 
>> 
>> This patch extends the patches in ' Late evaluation of vectorization
>> requirements’ (still in review). This makes the num runtime pointer
>> checks test into a late diagnostic so we can give the user a better
>> diagnostic message. Clang appends the diagnostic with options for
>> getting the loop vectorized. Here is an example of the diagnostic
>> the user will see:
>> 
>> 
>> "remark: loop not vectorized: cannot prove pointers refer to
>> independent arrays in memory. The loop requires 9 runtime
>> independence checks to safely vectorize the loop, but that would
>> exceed the limit of 8 checks; increase the number of runtime pointer
>> checks with the compiler option ‘-mllvm
>> -runtime-memory-check-threshold=’. To avoid runtime pointer checking
>> when you know the arrays will always be independent specify ‘#pragma
>> clang loop vectorize(assume_safety)’ before the loop or specify
>> ‘restrict’ on the array arguments. Erroneous results will occur if
>> these options are incorrectly applied."
>> 
>> 
>> The diagnostic is produced when the command line option
>> -Rpass-analysis=loop-vectorize is provided.
>> 
>> 
>> Reviews/comments are much appreciated!
>> 
>> 
>> Tyler
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
> -- 
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory

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

Re: [PATCH] D11781: Refactored pthread usage in libcxx

[Fulvio Esposito via cfe-commits]

espositofulvio added inline comments.


Comment at: include/__config:742
@@ +741,3 @@
+#ifndef _LIBCPP_HAS_NO_THREADS
+# if defined(__FreeBSD__) || \
+defined(__NetBSD__) || \

jroelofs wrote:
> espositofulvio wrote:
> > jroelofs wrote:
> > > jroelofs wrote:
> > > > @espositofulvio: @ed meant this:
> > > > 
> > > > ```
> > > > #ifndef _WIN32
> > > > #  include 
> > > > #  if _POSIX_THREADS > 0
> > > > ...
> > > > #  endif
> > > > #endif
> > > > ```
> > > > 
> > > > Which //is// the correct way to test for this.
> > > That being said, there have been discussions before about whether or not 
> > > we should #include  in <__config>, with the conclusion being 
> > > that we shouldn't.
> > > 
> > > It would be better if this were a CMake configure-time check that sets 
> > > _LIBCPP_THREAD_API, rather than these build-time guards.
> > Tried adding that as configure time checks, but then libcxxabi fails to 
> > compile because of the guard in __config to check that _LIBCPP_THREAD_API 
> > has beed defined when _LIBCPP_HAS_NO_THREADS is not. 
> > 
> > As a side note: Is Windows the only OS which hasn't got unistd.h?
> > Tried adding that as configure time checks...
> 
> Can you put the patch for that up on gist.github.com, or a pastebin?... I'll 
> take a look.
> 
> > As a side note: Is Windows the only OS which hasn't got unistd.h?
> 
> For the platforms libcxx currently builds on, yes.
> Can you put the patch for that up on gist.github.com, or a pastebin?... I'll 
> take a look.

It's here https://gist.github.com/espositofulvio/eac2fb08acf2e430c516


Repository:
  rL LLVM

http://reviews.llvm.org/D11781



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

[PATCH] D11922: Add NaCl to long double/fp128 mangling test

[Derek Schuff via cfe-commits]

dschuff created this revision.
dschuff added reviewers: rnk, chh.
dschuff added a subscriber: cfe-commits.
Herald added subscribers: dschuff, jfb.

NaCl is a platform where long double is the same as double.
Its mangling is spelled with "long double" but its ABI lowering is the same
as double.

http://reviews.llvm.org/D11922

Files:
  test/CodeGen/long_double_fp128.cpp

Index: test/CodeGen/long_double_fp128.cpp
===
--- test/CodeGen/long_double_fp128.cpp
+++ test/CodeGen/long_double_fp128.cpp
@@ -10,6 +10,8 @@
 // RUN:| FileCheck %s --check-prefix=G32
 // RUN: %clang_cc1 -triple powerpc-linux-gnu -emit-llvm -o - %s \
 // RUN:| FileCheck %s --check-prefix=P32
+// RUN: %clang_cc1 -triple x86_64-nacl -emit-llvm -o - %s \
+// RUN:| FileCheck %s --check-prefix=N64
 
 // Check mangled name of long double.
 // Android's gcc and llvm use fp128 for long double.
@@ -20,3 +22,4 @@
 // A32:  define void @_Z4testlfdeCe(i32, float, double, double, { double, 
double }*
 // G32:  define void @_Z4testlfdeCe(i32, float, double, x86_fp80, { x86_fp80, 
x86_fp80 }*
 // P32:  define void @_Z4testlfdgCg(i32, float, double, ppc_fp128, { 
ppc_fp128, ppc_fp128 }*
+// N64: define void @_Z4testlfdeCe(i32, float, double, double, double {{.*}}, 
double


Index: test/CodeGen/long_double_fp128.cpp
===
--- test/CodeGen/long_double_fp128.cpp
+++ test/CodeGen/long_double_fp128.cpp
@@ -10,6 +10,8 @@
 // RUN:| FileCheck %s --check-prefix=G32
 // RUN: %clang_cc1 -triple powerpc-linux-gnu -emit-llvm -o - %s \
 // RUN:| FileCheck %s --check-prefix=P32
+// RUN: %clang_cc1 -triple x86_64-nacl -emit-llvm -o - %s \
+// RUN:| FileCheck %s --check-prefix=N64
 
 // Check mangled name of long double.
 // Android's gcc and llvm use fp128 for long double.
@@ -20,3 +22,4 @@
 // A32:  define void @_Z4testlfdeCe(i32, float, double, double, { double, double }*
 // G32:  define void @_Z4testlfdeCe(i32, float, double, x86_fp80, { x86_fp80, x86_fp80 }*
 // P32:  define void @_Z4testlfdgCg(i32, float, double, ppc_fp128, { ppc_fp128, ppc_fp128 }*
+// N64: define void @_Z4testlfdeCe(i32, float, double, double, double {{.*}}, double
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D11922: Add NaCl to long double/fp128 mangling test

[Derek Schuff via cfe-commits]

dschuff added a comment.

I'm not an expert in mangling, and I'm not 100% sure if this is right. The 
Itanium ABI's spec lists "long double" as the same as __float80. Should we use 
"double" in mangling instead?


http://reviews.llvm.org/D11922



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

Re: [PATCH] D11922: Add NaCl to long double/fp128 mangling test

[Reid Kleckner via cfe-commits]

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

lgtm

Feel free to commit more test coverage like this with just post-commit review.


http://reviews.llvm.org/D11922



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

Re: [PATCH] D11922: Add NaCl to long double/fp128 mangling test

[Reid Kleckner via cfe-commits]

rnk added a comment.

In http://reviews.llvm.org/D11922#221185, @dschuff wrote:

> I'm not an expert in mangling, and I'm not 100% sure if this is right. The 
> Itanium ABI's spec lists "long double" as the same as __float80. Should we 
> use "double" in mangling instead?


If you can have different overloads between double and long double, we need a 
separate mangling.


http://reviews.llvm.org/D11922



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

r244530 - Remove some dead code.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Mon Aug 10 18:26:54 2015
New Revision: 244530

URL: http://llvm.org/viewvc/llvm-project?rev=244530&view=rev
Log:
Remove some dead code.

Modified:
cfe/trunk/include/clang/Serialization/ASTReader.h
cfe/trunk/lib/Serialization/ASTReader.cpp

Modified: cfe/trunk/include/clang/Serialization/ASTReader.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Serialization/ASTReader.h?rev=244530&r1=244529&r2=244530&view=diff
==
--- cfe/trunk/include/clang/Serialization/ASTReader.h (original)
+++ cfe/trunk/include/clang/Serialization/ASTReader.h Mon Aug 10 18:26:54 2015
@@ -1056,8 +1056,6 @@ private:
 
   /// \brief Reads the stored information about an input file.
   InputFileInfo readInputFileInfo(ModuleFile &F, unsigned ID);
-  /// \brief A convenience method to read the filename from an input file.
-  std::string getInputFileName(ModuleFile &F, unsigned ID);
 
   /// \brief Retrieve the file entry and 'overridden' bit for an input
   /// file in the given module file.
@@ -2088,12 +2086,8 @@ public:
   SmallVector, 8> CommentsCursors;
 
-  //RIDErief Loads comments ranges.
+  /// \brief Loads comments ranges.
   void ReadComments() override;
-
-  /// Return all input files for the given module file.
-  void getInputFiles(ModuleFile &F,
- SmallVectorImpl &Files);
 };
 
 /// \brief Helper class that saves the current stream position and

Modified: cfe/trunk/lib/Serialization/ASTReader.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTReader.cpp?rev=244530&r1=244529&r2=244530&view=diff
==
--- cfe/trunk/lib/Serialization/ASTReader.cpp (original)
+++ cfe/trunk/lib/Serialization/ASTReader.cpp Mon Aug 10 18:26:54 2015
@@ -1878,10 +1878,6 @@ ASTReader::readInputFileInfo(ModuleFile
   return R;
 }
 
-std::string ASTReader::getInputFileName(ModuleFile &F, unsigned int ID) {
-  return readInputFileInfo(F, ID).Filename;
-}
-
 InputFile ASTReader::getInputFile(ModuleFile &F, unsigned ID, bool Complain) {
   // If this ID is bogus, just return an empty input file.
   if (ID == 0 || ID > F.InputFilesLoaded.size())
@@ -8069,14 +8065,6 @@ void ASTReader::ReadComments() {
   }
 }
 
-void ASTReader::getInputFiles(ModuleFile &F,
- SmallVectorImpl &Files) 
{
-  for (unsigned I = 0, E = F.InputFilesLoaded.size(); I != E; ++I) {
-unsigned ID = I+1;
-Files.push_back(getInputFile(F, ID));
-  }
-}
-
 std::string ASTReader::getOwningModuleNameForDiagnostic(const Decl *D) {
   // If we know the owning module, use it.
   if (Module *M = D->getImportedOwningModule())


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

Re: r244526 - Append options for vectorization when pointer checking threshold is exceeded.

[Hal Finkel via cfe-commits]

- Original Message -
> From: "Tyler Nowicki via cfe-commits" 
> To: cfe-commits@lists.llvm.org
> Sent: Monday, August 10, 2015 6:05:17 PM
> Subject: r244526 - Append options for vectorization when pointer checking 
> threshold is exceeded.
> 
> Author: tnowicki
> Date: Mon Aug 10 18:05:16 2015
> New Revision: 244526
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=244526&view=rev
> Log:
> Append options for vectorization when pointer checking threshold is
> exceeded.
> 
> Following one of the appended options will allow the loop to be
> vectorized. We do not include a command line option for modifying
> the pointer checking threshold because there is no clang-level
> interface for this currently.
> 
> Modified:
> cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
> cfe/trunk/lib/CodeGen/CodeGenAction.cpp
> cfe/trunk/test/Frontend/optimization-remark-options.c
> 
> Modified: cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td?rev=244526&r1=244525&r2=244526&view=diff
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
> (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td Mon Aug
> 10 18:05:16 2015
> @@ -49,6 +49,12 @@ def remark_fe_backend_optimization_remar
>  "allow commutativity by specifying '#pragma clang loop
>  vectorize(enable)' "
>  "before the loop or by providing the compiler option
>  '-ffast-math'">,
>  BackendInfo, InGroup;
> +def remark_fe_backend_optimization_remark_analysis_aliasing :
> Remark<"%0; "
> +"avoid runtime pointer checking when you know the arrays will
> always be "
> +"independent by specifying '#pragma clang loop
> vectorize(assume_safety)' "
> +"before the loop or by specifying 'restrict' on the array
> arguments. "

Hi Tyler,

Sorry I missed this earlier, but this needs to say '__restrict__' (or 
'__restrict') when compiling in C++ mode because 'restrict' is not a valid 
keyword in C++.

Thanks again,
Hal

> +"Erroneous results will occur if these options are incorrectly
> applied!">,
> +BackendInfo, InGroup;
>  def warn_fe_backend_optimization_failure : Warning<"%0">,
>  BackendInfo,
>  InGroup, DefaultWarn;
>  def note_fe_backend_optimization_remark_invalid_loc : Note<"could "
> 
> Modified: cfe/trunk/lib/CodeGen/CodeGenAction.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenAction.cpp?rev=244526&r1=244525&r2=244526&view=diff
> ==
> --- cfe/trunk/lib/CodeGen/CodeGenAction.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CodeGenAction.cpp Mon Aug 10 18:05:16 2015
> @@ -258,6 +258,8 @@ namespace clang {
>  const llvm::DiagnosticInfoOptimizationRemarkAnalysis &D);
>  void OptimizationRemarkHandler(
>  const
>  llvm::DiagnosticInfoOptimizationRemarkAnalysisFPCommute
>  &D);
> +void OptimizationRemarkHandler(
> +const llvm::DiagnosticInfoOptimizationRemarkAnalysisAliasing
> &D);
>  void OptimizationFailureHandler(
>  const llvm::DiagnosticInfoOptimizationFailure &D);
>};
> @@ -513,6 +515,17 @@ void BackendConsumer::OptimizationRemark
>  D,
>  diag::remark_fe_backend_optimization_remark_analysis_fpcommute);
>  }
>  
> +void BackendConsumer::OptimizationRemarkHandler(
> +const llvm::DiagnosticInfoOptimizationRemarkAnalysisAliasing &D)
> {
> +  // Optimization analysis remarks are active only if the
> -Rpass-analysis
> +  // flag has a regular expression that matches the name of the pass
> +  // name in \p D.
> +  if (CodeGenOpts.OptimizationRemarkAnalysisPattern &&
> +
>  CodeGenOpts.OptimizationRemarkAnalysisPattern->match(D.getPassName()))
> +EmitOptimizationMessage(
> +D,
> diag::remark_fe_backend_optimization_remark_analysis_aliasing);
> +}
> +
>  void BackendConsumer::OptimizationFailureHandler(
>  const llvm::DiagnosticInfoOptimizationFailure &D) {
>EmitOptimizationMessage(D,
>diag::warn_fe_backend_optimization_failure);
> @@ -572,6 +585,12 @@ void BackendConsumer::DiagnosticHandlerI
>  OptimizationRemarkHandler(
>  cast(DI));
>  return;
> +  case llvm::DK_OptimizationRemarkAnalysisAliasing:
> +// Optimization remarks are always handled completely by this
> +// handler. There is no generic way of emitting them.
> +OptimizationRemarkHandler(
> +cast(DI));
> +return;
>case llvm::DK_OptimizationFailure:
>  // Optimization failures are always handled completely by this
>  // handler.
> 
> Modified: cfe/trunk/test/Frontend/optimization-remark-options.c
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/optimization-remark-options.c?rev=244526&r1=244525&r2=244526&view=diff
> 

Re: [PATCH] D11832: [Patch] [Analyzer] false positive: Potential leak connected with memcpy (PR 22954)

[Anna Zaks via cfe-commits]

zaks.anna added inline comments.


Comment at: lib/StaticAnalyzer/Core/RegionStore.cpp:1098
@@ +1097,3 @@
+  if (!NumElements)
+return;
+  QualType ElementTy = AT->getElementType();

What happens on early returns? Here and the one below. Are there tests for 
these cases?


http://reviews.llvm.org/D11832



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

Re: r244488 - [dllimport] A non-imported class with an imported key can't have a key

[Richard Smith via cfe-commits]

On Mon, Aug 10, 2015 at 12:39 PM, Reid Kleckner via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rnk
> Date: Mon Aug 10 14:39:01 2015
> New Revision: 244488
>
> URL: http://llvm.org/viewvc/llvm-project?rev=244488&view=rev
> Log:
> [dllimport] A non-imported class with an imported key can't have a key
>
> Summary:
> The vtable takes its DLL storage class from the class, not the key
> function. When they disagree, the vtable won't be exported by the DLL
> that defines the key function. The easiest way to ensure that importers
> of the class emit their own vtable is to say that the class has no key
> function.
>
> Reviewers: hans, majnemer
>
> Subscribers: cfe-commits
>
> Differential Revision: http://reviews.llvm.org/D11913
>
> Modified:
> cfe/trunk/lib/AST/RecordLayoutBuilder.cpp
> cfe/trunk/test/CodeGenCXX/dllimport-rtti.cpp
>
> Modified: cfe/trunk/lib/AST/RecordLayoutBuilder.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/RecordLayoutBuilder.cpp?rev=244488&r1=244487&r2=244488&view=diff
>
> ==
> --- cfe/trunk/lib/AST/RecordLayoutBuilder.cpp (original)
> +++ cfe/trunk/lib/AST/RecordLayoutBuilder.cpp Mon Aug 10 14:39:01 2015
> @@ -2008,6 +2008,12 @@ static const CXXMethodDecl *computeKeyFu
>  continue;
>  }
>
> +// If the key function is dllimport but the class isn't, then the
> class has
> +// no key function. The DLL that exports the key function won't
> export the
> +// vtable in this case.
> +if (MD->hasAttr() && !RD->hasAttr())
> +  return nullptr;
>

Does the same apply if the key function is DLLExport and the class is not?
(Presumably this would just lead us to export a vtable that we don't need
to, which is presumably harmless?)


> +
>  // We found it.
>  return MD;
>}
>
> Modified: cfe/trunk/test/CodeGenCXX/dllimport-rtti.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/dllimport-rtti.cpp?rev=244488&r1=244487&r2=244488&view=diff
>
> ==
> --- cfe/trunk/test/CodeGenCXX/dllimport-rtti.cpp (original)
> +++ cfe/trunk/test/CodeGenCXX/dllimport-rtti.cpp Mon Aug 10 14:39:01 2015
> @@ -22,3 +22,11 @@ struct __declspec(dllimport) V {
>  // GNU-DAG: @_ZTV1V = available_externally dllimport
>  // GNU-DAG: @_ZTS1V = linkonce_odr
>  // GNU-DAG: @_ZTI1V = linkonce_odr
> +
> +struct W {
> +  __declspec(dllimport) virtual void f();
> +  virtual void g();
> +} w;
> +// GNU-DAG: @_ZTV1W = linkonce_odr
> +// GNU-DAG: @_ZTS1W = linkonce_odr
> +// GNU-DAG: @_ZTI1W = linkonce_odr
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [Patch][LoopVectorize] Late evaluate of runtime pointer check's threshold

[Hal Finkel via cfe-commits]

- Original Message -
> From: "Tyler Nowicki" 
> To: "Hal Finkel" 
> Cc: "Gerolf Hoflehner" , "Commit Messages and Patches 
> for LLVM" ,
> "llvm cfe" 
> Sent: Monday, August 10, 2015 6:06:24 PM
> Subject: Re: [Patch][LoopVectorize] Late evaluate of runtime pointer check's 
> threshold
> 
> Hi Hal,
> 
> 
> Thanks, the patches are committed in r 244523 and r 244526 .
> 
> There are two possibilities to give the user control over pointer
> checking. We could add a loop hint option like
> vectorize(check_safety) that would be a safe version of
> ‘assume_safety’ or we could simply make it always emit the necessary
> pointer checks, no matter how many of them there are, when the loop
> hint vectorize(enable) is specified?
> 
> What do you think?
> 

I think that we should just emit the checks when the user specifies 
'vectorize(enable)' regardless of the number. In a sense, the user is already 
instructing us to override our cost model and vectorize anyway, and this is 
just another aspect of that cost model that we should override.

That having been said, as with unrolling, we should have a large internal limit 
to prevent running out of memory, etc. when compiling.

 -Hal

> 
> Tyler
> 
> 
> 
> 
> 
> On Aug 9, 2015, at 9:41 PM, Hal Finkel < hfin...@anl.gov > wrote:
> 
> Hi Tyler,
> 
> This looks very useful.
> 
> Please don't mention '-mllvm -runtime-memory-check-threshold=' in the
> error message. We should add some clause to #pragma clang loop to
> control this feature with some associated metadata. '-mllvm' things
> should not be part of the advertised interface to end users (but
> that should be a separate set of patches regardless).
> 
> Otherwise, LGTM.
> 
> Thanks again,
> Hal
> 
> - Original Message -
> 
> 
> From: "Tyler Nowicki" < tnowi...@apple.com >
> To: "Hal J. Finkel" < hfin...@anl.gov >, "Commit Messages and Patches
> for LLVM" < llvm-comm...@lists.llvm.org >, "llvm
> cfe" < cfe-commits@lists.llvm.org >
> Cc: "Gerolf Hoflehner" < ghofleh...@apple.com >
> Sent: Thursday, August 6, 2015 3:25:26 PM
> Subject: [Patch][LoopVectorize] Late evaluate of runtime pointer
> check's threshold
> 
> 
> Hi,
> 
> 
> This patch extends the patches in ' Late evaluation of vectorization
> requirements’ (still in review). This makes the num runtime pointer
> checks test into a late diagnostic so we can give the user a better
> diagnostic message. Clang appends the diagnostic with options for
> getting the loop vectorized. Here is an example of the diagnostic
> the user will see:
> 
> 
> "remark: loop not vectorized: cannot prove pointers refer to
> independent arrays in memory. The loop requires 9 runtime
> independence checks to safely vectorize the loop, but that would
> exceed the limit of 8 checks; increase the number of runtime pointer
> checks with the compiler option ‘-mllvm
> -runtime-memory-check-threshold=’. To avoid runtime pointer checking
> when you know the arrays will always be independent specify ‘#pragma
> clang loop vectorize(assume_safety)’ before the loop or specify
> ‘restrict’ on the array arguments. Erroneous results will occur if
> these options are incorrectly applied."
> 
> 
> The diagnostic is produced when the command line option
> -Rpass-analysis=loop-vectorize is provided.
> 
> 
> Reviews/comments are much appreciated!
> 
> 
> Tyler
> 
> 
> 
> 
> 
> 
> 
> 
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> 

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

Re: [PATCH] Have clang list the imported modules in the debug info

[Adrian Prantl via cfe-commits]

[resending because I accidentally sent this to the old mailing list].

> On Jul 24, 2015, at 12:33 PM, David Blaikie  > wrote:
> 
> *reads back through the thread*

appreciated, it’s long :-)

> So what I originally had in mind about a year ago when we discussed this, was 
> that the module data could have an extra table from type hash to whatever 
> useful internal representation to find the type in the PCM.

It turned out that the most useful internal type representation to find a type 
in a PCM is the type’s DeclContext+Name; this is how (surprise!) clang looks up 
types in a PCM and the format is supposed to be fast for these kind of lookups.

> Everything else would just be DWARF with type units and fission (with the 
> slight wrinkle of type units that aren't resolvable within a single object 
> file - they could reference cross-object/dwo file) - emitting a fission CU 
> for each referenced module.
> 
> Needing modules to disambiguate/avoid collisions/support non-odr languages 
> wasn't something I understood/had considered back then. That explains the 
> need to add module references to the CU, so the debugger can know which 
> modules to search for the types in (& doesn't just go loading all of them, 
> etc).
> 
> I would still picture this as "normal type units + a table in the module to 
> resolve types", but if you guys particularly like using the mangled string 
> name (or other identifier) in the DWARF that may avoid the need for an 
> intermediate table (but it doesn't sound like you are avoiding an 
> intermediate table - you said something about having an 
> accelerator-table-like thing to aid in the DWARF->AST mapping? So could that 
> be key'd of the type hash/signature we're using, thus keeping the DWARF more 
> plain/vanilla DWARF5 (type units + fission)?)

I originally disliked type signatures and favored using mangled names because 
the mangled names contained the DeclContext necessary to find types in the PCM. 
But if we can squeeze the DeclContext somewhere else, that’s fine.

From the discussion we had on FlagExternalTypeRef I got the impression that 
long-form forward declarations are starting to look more attractive: If every 
external type reference is a reference to a forward declaration that has a 
complete decl context, with a DW_TAG_module at the root of the decl context 
chain, and a DW_AT_name+DW_AT_signature at the other end, we would have all the 
information we need without introducing any further LLVM-specific DWARF 
extensions. To look up an external type from the PCM, the consumer imports the 
DW_TAG_module and deserializes the type found by declcontext+name. To load the 
type from DWARF, the consumer grabs the signature from the forward declaration 
and magically (1) finds the PCM and looks up the type by signature (2).

(1) My suggestion is to extend LLVM so it can put the DW_TAG_module with the 
forward declaration inside the skeleton compile unit (which has the path to the 
PCM and its DWOid).
(2) On ELF with type units this works out of the box, on MachO without type 
units we need some kind of index mapping signature -> DIE (bag of DWARF style?).

Assuming that many external types will share a similar DeclContext prefix I am 
not very worried by the space needed to store the long forward references. 
Compared to storing the mangled name for every type it will often actually take 
up less space. Also, on Darwin at least, llvm-dsymutil can strip them out of 
the way after resolving the external type references.

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

r244537 - Fix some tabs.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Mon Aug 10 19:03:28 2015
New Revision: 244537

URL: http://llvm.org/viewvc/llvm-project?rev=244537&view=rev
Log:
Fix some tabs.

Modified:
cfe/trunk/lib/Frontend/CompilerInstance.cpp

Modified: cfe/trunk/lib/Frontend/CompilerInstance.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/CompilerInstance.cpp?rev=244537&r1=244536&r2=244537&view=diff
==
--- cfe/trunk/lib/Frontend/CompilerInstance.cpp (original)
+++ cfe/trunk/lib/Frontend/CompilerInstance.cpp Mon Aug 10 19:03:28 2015
@@ -1631,11 +1631,10 @@ GlobalModuleIndex *CompilerInstance::loa
   if (!Entry) {
 SmallVector, 2> Path;
 Path.push_back(std::make_pair(
- 
getPreprocessor().getIdentifierInfo(TheModule->Name), TriggerLoc));
+getPreprocessor().getIdentifierInfo(TheModule->Name), TriggerLoc));
 std::reverse(Path.begin(), Path.end());
-   // Load a module as hidden.  This also adds it to the 
global index.
-loadModule(TheModule->DefinitionLoc, Path,
- Module::Hidden, false);
+// Load a module as hidden.  This also adds it to the global index.
+loadModule(TheModule->DefinitionLoc, Path, Module::Hidden, false);
 RecreateIndex = true;
   }
 }


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

r244538 - [modules] Properly diagnose errors in module files for which we have no

[Richard Smith via cfe-commits]

Author: rsmith
Date: Mon Aug 10 19:05:21 2015
New Revision: 244538

URL: http://llvm.org/viewvc/llvm-project?rev=244538&view=rev
Log:
[modules] Properly diagnose errors in module files for which we have no
corresponding include location (those specified on the command line).

Modified:
cfe/trunk/lib/Frontend/DiagnosticRenderer.cpp
cfe/trunk/lib/Frontend/TextDiagnostic.cpp
cfe/trunk/test/Modules/explicit-build-missing-files.cpp

Modified: cfe/trunk/lib/Frontend/DiagnosticRenderer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/DiagnosticRenderer.cpp?rev=244538&r1=244537&r2=244538&view=diff
==
--- cfe/trunk/lib/Frontend/DiagnosticRenderer.cpp (original)
+++ cfe/trunk/lib/Frontend/DiagnosticRenderer.cpp Mon Aug 10 19:05:21 2015
@@ -245,7 +245,7 @@ void DiagnosticRenderer::emitIncludeStac
   // import stack rather than the 
   // FIXME: We want submodule granularity here.
   std::pair Imported = SM.getModuleImportLoc(Loc);
-  if (Imported.first.isValid()) {
+  if (!Imported.second.empty()) {
 // This location was imported by a module. Emit the module import stack.
 emitImportStackRecursively(Imported.first, Imported.second, SM);
 return;
@@ -276,13 +276,11 @@ void DiagnosticRenderer::emitImportStack
 void DiagnosticRenderer::emitImportStackRecursively(SourceLocation Loc,
 StringRef ModuleName,
 const SourceManager &SM) {
-  if (Loc.isInvalid()) {
+  if (ModuleName.empty()) {
 return;
   }
 
   PresumedLoc PLoc = SM.getPresumedLoc(Loc, DiagOpts->ShowPresumedLoc);
-  if (PLoc.isInvalid())
-return;
 
   // Emit the other import frames first.
   std::pair NextImportLoc
@@ -501,8 +499,11 @@ void DiagnosticNoteRenderer::emitImportL
   // Generate a note indicating the include location.
   SmallString<200> MessageStorage;
   llvm::raw_svector_ostream Message(MessageStorage);
-  Message << "in module '" << ModuleName << "' imported from "
-  << PLoc.getFilename() << ':' << PLoc.getLine() << ":";
+  Message << "in module '" << ModuleName;
+  if (!PLoc.isInvalid())
+Message << "' imported from " << PLoc.getFilename() << ':'
+<< PLoc.getLine();
+  Message << ":";
   emitNote(Loc, Message.str(), &SM);
 }
 

Modified: cfe/trunk/lib/Frontend/TextDiagnostic.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/TextDiagnostic.cpp?rev=244538&r1=244537&r2=244538&view=diff
==
--- cfe/trunk/lib/Frontend/TextDiagnostic.cpp (original)
+++ cfe/trunk/lib/Frontend/TextDiagnostic.cpp Mon Aug 10 19:05:21 2015
@@ -875,7 +875,7 @@ void TextDiagnostic::emitDiagnosticLoc(S
 void TextDiagnostic::emitIncludeLocation(SourceLocation Loc,
  PresumedLoc PLoc,
  const SourceManager &SM) {
-  if (DiagOpts->ShowLocation)
+  if (DiagOpts->ShowLocation && PLoc.getFilename())
 OS << "In file included from " << PLoc.getFilename() << ':'
<< PLoc.getLine() << ":\n";
   else
@@ -885,11 +885,11 @@ void TextDiagnostic::emitIncludeLocation
 void TextDiagnostic::emitImportLocation(SourceLocation Loc, PresumedLoc PLoc,
 StringRef ModuleName,
 const SourceManager &SM) {
-  if (DiagOpts->ShowLocation)
+  if (DiagOpts->ShowLocation && PLoc.getFilename())
 OS << "In module '" << ModuleName << "' imported from "
<< PLoc.getFilename() << ':' << PLoc.getLine() << ":\n";
   else
-OS << "In module " << ModuleName << "':\n";
+OS << "In module '" << ModuleName << "':\n";
 }
 
 void TextDiagnostic::emitBuildingModuleLocation(SourceLocation Loc,

Modified: cfe/trunk/test/Modules/explicit-build-missing-files.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/explicit-build-missing-files.cpp?rev=244538&r1=244537&r2=244538&view=diff
==
--- cfe/trunk/test/Modules/explicit-build-missing-files.cpp (original)
+++ cfe/trunk/test/Modules/explicit-build-missing-files.cpp Mon Aug 10 19:05:21 
2015
@@ -1,7 +1,7 @@
 // RUN: rm -rf %t
 // RUN: mkdir %t
 // RUN: echo 'extern int a;' > %t/a.h
-// RUN: echo 'extern int b;' > %t/b.h
+// RUN: echo 'extern int b; template int b2 = T::error;' > %t/b.h
 // RUN: echo 'module a { header "a.h" header "b.h" }' > %t/modulemap
 
 // We lazily check that the files referenced by an explicitly-specified .pcm
@@ -10,12 +10,23 @@
 //
 // RUN: %clang_cc1 -fmodules -I %t -emit-module -fmodule-name=a -x c++ 
%t/modulemap -o %t/a.pcm
 // RUN: %clang_cc1 -fmodules -I %t -fmodule-file=%t/a.pcm %s
+// RUN: not %clang_cc1 -fmodules -I %t -fmodule-file=%t/a.pcm %s -DERRORS 2>&1 
| FileCheck %s
 // RUN: rm %t/modulemap
 // RUN: %clang_cc1 -fmod

Re: [PATCH] D11922: Add NaCl to long double/fp128 mangling test

[Derek Schuff via cfe-commits]

dschuff added a comment.

Looks like all the other unix targets that use IEEEDouble as their format do 
this too, including all the NaCl compilers.


http://reviews.llvm.org/D11922



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

Re: [PATCH] D11658: [Sema] main can't be declared as global variable

[Richard Smith via cfe-commits]

rsmith added a comment.

Maybe you could refactor the check to something like:

  if (Name.isIdentifier() && Name.getAsIdentifierInfo()->isStr("main")
  NewVD->getDeclContext()->getRedeclContext()->isTranslationUnit() &&
  !getLangOpts().Freestanding && !NewVD->getDescribedVarTemplate()) {
if (getLangOpts().CPlusPlus)
  Diag1;
else if (NewVD->hasExternalFormalLinkage())
  Diag2;
  }



Comment at: include/clang/Basic/DiagnosticSemaKinds.td:514
@@ +513,3 @@
+def err_main_global_variable : Error<"main can't be declared as global 
variable">;
+def warn_main_redefined : Warning<"external-linkage variable named 'main' has "
+"undefined behavior">, InGroup;

Hyphenating 'external linkage' is unusual; how about 'variable named 'main' 
with external linkage has undefined behavior'?


Comment at: lib/Sema/SemaDecl.cpp:6113
@@ +6112,3 @@
+// A program that declares a variable main at global scope is ill-formed.
+if (getLangOpts().CPlusPlus && !getLangOpts().Freestanding &&
+NewVD->hasGlobalStorage() && !NewVD->isStaticLocal() &&

The freestanding check should apply in C too.


Comment at: lib/Sema/SemaDecl.cpp:6114-6116
@@ +6113,5 @@
+if (getLangOpts().CPlusPlus && !getLangOpts().Freestanding &&
+NewVD->hasGlobalStorage() && !NewVD->isStaticLocal() &&
+!NewVD->isStaticDataMember() && !NewVD->getDescribedVarTemplate() 
&&
+NewVD->getDeclContext()->isTranslationUnit())
+  Diag(D.getLocStart(), diag::err_main_global_variable);

The only checks you need here are: 1) DeclContext's redecl context is the 
translation unit, and 2) NewVD is not a variable template. All the other checks 
are implied by the DC check. I'd suggest factoring these out into the main 
check.


Comment at: lib/Sema/SemaDecl.cpp:6116
@@ +6115,3 @@
+!NewVD->isStaticDataMember() && !NewVD->getDescribedVarTemplate() 
&&
+NewVD->getDeclContext()->isTranslationUnit())
+  Diag(D.getLocStart(), diag::err_main_global_variable);

You need to check `NewVD->getDeclContext()->getRedeclContext()`, in case there 
are `LinkageSpecDecl`s surrounding the variable (`extern "C++" int main;`).


Comment at: lib/Sema/SemaDecl.cpp:6121
@@ +6120,3 @@
+// behavior.
+if (!getLangOpts().CPlusPlus && NewVD->isExternC())
+  Diag(D.getLocStart(), diag::warn_main_redefined);

It's weird to ask `isExternC` from C. Use `hasExternalFormalLinkage` instead.


http://reviews.llvm.org/D11658



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

Re: [PATCH] D11922: Add NaCl to long double/fp128 mangling test

[Derek Schuff via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL244541: Add NaCl to long double/fp128 mangling test 
(authored by dschuff).

Changed prior to commit:
  http://reviews.llvm.org/D11922?vs=31744&id=31747#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D11922

Files:
  cfe/trunk/test/CodeGen/long_double_fp128.cpp

Index: cfe/trunk/test/CodeGen/long_double_fp128.cpp
===
--- cfe/trunk/test/CodeGen/long_double_fp128.cpp
+++ cfe/trunk/test/CodeGen/long_double_fp128.cpp
@@ -10,6 +10,8 @@
 // RUN:| FileCheck %s --check-prefix=G32
 // RUN: %clang_cc1 -triple powerpc-linux-gnu -emit-llvm -o - %s \
 // RUN:| FileCheck %s --check-prefix=P32
+// RUN: %clang_cc1 -triple x86_64-nacl -emit-llvm -o - %s \
+// RUN:| FileCheck %s --check-prefix=N64
 
 // Check mangled name of long double.
 // Android's gcc and llvm use fp128 for long double.
@@ -20,3 +22,4 @@
 // A32:  define void @_Z4testlfdeCe(i32, float, double, double, { double, 
double }*
 // G32:  define void @_Z4testlfdeCe(i32, float, double, x86_fp80, { x86_fp80, 
x86_fp80 }*
 // P32:  define void @_Z4testlfdgCg(i32, float, double, ppc_fp128, { 
ppc_fp128, ppc_fp128 }*
+// N64: define void @_Z4testlfdeCe(i32, float, double, double, double {{.*}}, 
double


Index: cfe/trunk/test/CodeGen/long_double_fp128.cpp
===
--- cfe/trunk/test/CodeGen/long_double_fp128.cpp
+++ cfe/trunk/test/CodeGen/long_double_fp128.cpp
@@ -10,6 +10,8 @@
 // RUN:| FileCheck %s --check-prefix=G32
 // RUN: %clang_cc1 -triple powerpc-linux-gnu -emit-llvm -o - %s \
 // RUN:| FileCheck %s --check-prefix=P32
+// RUN: %clang_cc1 -triple x86_64-nacl -emit-llvm -o - %s \
+// RUN:| FileCheck %s --check-prefix=N64
 
 // Check mangled name of long double.
 // Android's gcc and llvm use fp128 for long double.
@@ -20,3 +22,4 @@
 // A32:  define void @_Z4testlfdeCe(i32, float, double, double, { double, double }*
 // G32:  define void @_Z4testlfdeCe(i32, float, double, x86_fp80, { x86_fp80, x86_fp80 }*
 // P32:  define void @_Z4testlfdgCg(i32, float, double, ppc_fp128, { ppc_fp128, ppc_fp128 }*
+// N64: define void @_Z4testlfdeCe(i32, float, double, double, double {{.*}}, double
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r244542 - add comment

[Derek Schuff via cfe-commits]

Author: dschuff
Date: Mon Aug 10 19:19:54 2015
New Revision: 244542

URL: http://llvm.org/viewvc/llvm-project?rev=244542&view=rev
Log:
add comment

Modified:
cfe/trunk/test/CodeGen/long_double_fp128.cpp

Modified: cfe/trunk/test/CodeGen/long_double_fp128.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/long_double_fp128.cpp?rev=244542&r1=244541&r2=244542&view=diff
==
--- cfe/trunk/test/CodeGen/long_double_fp128.cpp (original)
+++ cfe/trunk/test/CodeGen/long_double_fp128.cpp Mon Aug 10 19:19:54 2015
@@ -15,6 +15,7 @@
 
 // Check mangled name of long double.
 // Android's gcc and llvm use fp128 for long double.
+// NaCl uses double format for long double, but still has separate overloads.
 void test(long, float, double, long double, long double _Complex) { }
 // A64:  define void @_Z4testlfdgCg(i64, float, double, fp128, { fp128, fp128 
}*
 // G64:  define void @_Z4testlfdeCe(i64, float, double, x86_fp80, { x86_fp80, 
x86_fp80 }*


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

r244541 - Add NaCl to long double/fp128 mangling test

[Derek Schuff via cfe-commits]

Author: dschuff
Date: Mon Aug 10 19:19:53 2015
New Revision: 244541

URL: http://llvm.org/viewvc/llvm-project?rev=244541&view=rev
Log:
Add NaCl to long double/fp128 mangling test

Summary:
NaCl is a platform where long double is the same as double.
Its mangling is spelled with "long double" but its ABI lowering is the same
as double.

Reviewers: rnk, chh

Subscribers: jfb, cfe-commits, dschuff

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

Modified:
cfe/trunk/test/CodeGen/long_double_fp128.cpp

Modified: cfe/trunk/test/CodeGen/long_double_fp128.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/long_double_fp128.cpp?rev=244541&r1=244540&r2=244541&view=diff
==
--- cfe/trunk/test/CodeGen/long_double_fp128.cpp (original)
+++ cfe/trunk/test/CodeGen/long_double_fp128.cpp Mon Aug 10 19:19:53 2015
@@ -10,6 +10,8 @@
 // RUN:| FileCheck %s --check-prefix=G32
 // RUN: %clang_cc1 -triple powerpc-linux-gnu -emit-llvm -o - %s \
 // RUN:| FileCheck %s --check-prefix=P32
+// RUN: %clang_cc1 -triple x86_64-nacl -emit-llvm -o - %s \
+// RUN:| FileCheck %s --check-prefix=N64
 
 // Check mangled name of long double.
 // Android's gcc and llvm use fp128 for long double.
@@ -20,3 +22,4 @@ void test(long, float, double, long doub
 // A32:  define void @_Z4testlfdeCe(i32, float, double, double, { double, 
double }*
 // G32:  define void @_Z4testlfdeCe(i32, float, double, x86_fp80, { x86_fp80, 
x86_fp80 }*
 // P32:  define void @_Z4testlfdgCg(i32, float, double, ppc_fp128, { 
ppc_fp128, ppc_fp128 }*
+// N64: define void @_Z4testlfdeCe(i32, float, double, double, double {{.*}}, 
double


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

Re: r244526 - Append options for vectorization when pointer checking threshold is exceeded.

[Tyler Nowicki via cfe-commits]

Oh, sorry about that! I'll make that change.

Tyler

On Mon, Aug 10, 2015 at 4:35 PM, Hal Finkel  wrote:

> - Original Message -
> > From: "Tyler Nowicki via cfe-commits" 
> > To: cfe-commits@lists.llvm.org
> > Sent: Monday, August 10, 2015 6:05:17 PM
> > Subject: r244526 - Append options for vectorization when pointer
> checking threshold is exceeded.
> >
> > Author: tnowicki
> > Date: Mon Aug 10 18:05:16 2015
> > New Revision: 244526
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=244526&view=rev
> > Log:
> > Append options for vectorization when pointer checking threshold is
> > exceeded.
> >
> > Following one of the appended options will allow the loop to be
> > vectorized. We do not include a command line option for modifying
> > the pointer checking threshold because there is no clang-level
> > interface for this currently.
> >
> > Modified:
> > cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
> > cfe/trunk/lib/CodeGen/CodeGenAction.cpp
> > cfe/trunk/test/Frontend/optimization-remark-options.c
> >
> > Modified: cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
> > URL:
> >
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td?rev=244526&r1=244525&r2=244526&view=diff
> >
> ==
> > --- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
> > (original)
> > +++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td Mon Aug
> > 10 18:05:16 2015
> > @@ -49,6 +49,12 @@ def remark_fe_backend_optimization_remar
> >  "allow commutativity by specifying '#pragma clang loop
> >  vectorize(enable)' "
> >  "before the loop or by providing the compiler option
> >  '-ffast-math'">,
> >  BackendInfo, InGroup;
> > +def remark_fe_backend_optimization_remark_analysis_aliasing :
> > Remark<"%0; "
> > +"avoid runtime pointer checking when you know the arrays will
> > always be "
> > +"independent by specifying '#pragma clang loop
> > vectorize(assume_safety)' "
> > +"before the loop or by specifying 'restrict' on the array
> > arguments. "
>
> Hi Tyler,
>
> Sorry I missed this earlier, but this needs to say '__restrict__' (or
> '__restrict') when compiling in C++ mode because 'restrict' is not a valid
> keyword in C++.
>
> Thanks again,
> Hal
>
> > +"Erroneous results will occur if these options are incorrectly
> > applied!">,
> > +BackendInfo, InGroup;
> >  def warn_fe_backend_optimization_failure : Warning<"%0">,
> >  BackendInfo,
> >  InGroup, DefaultWarn;
> >  def note_fe_backend_optimization_remark_invalid_loc : Note<"could "
> >
> > Modified: cfe/trunk/lib/CodeGen/CodeGenAction.cpp
> > URL:
> >
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenAction.cpp?rev=244526&r1=244525&r2=244526&view=diff
> >
> ==
> > --- cfe/trunk/lib/CodeGen/CodeGenAction.cpp (original)
> > +++ cfe/trunk/lib/CodeGen/CodeGenAction.cpp Mon Aug 10 18:05:16 2015
> > @@ -258,6 +258,8 @@ namespace clang {
> >  const llvm::DiagnosticInfoOptimizationRemarkAnalysis &D);
> >  void OptimizationRemarkHandler(
> >  const
> >  llvm::DiagnosticInfoOptimizationRemarkAnalysisFPCommute
> >  &D);
> > +void OptimizationRemarkHandler(
> > +const llvm::DiagnosticInfoOptimizationRemarkAnalysisAliasing
> > &D);
> >  void OptimizationFailureHandler(
> >  const llvm::DiagnosticInfoOptimizationFailure &D);
> >};
> > @@ -513,6 +515,17 @@ void BackendConsumer::OptimizationRemark
> >  D,
> >  diag::remark_fe_backend_optimization_remark_analysis_fpcommute);
> >  }
> >
> > +void BackendConsumer::OptimizationRemarkHandler(
> > +const llvm::DiagnosticInfoOptimizationRemarkAnalysisAliasing &D)
> > {
> > +  // Optimization analysis remarks are active only if the
> > -Rpass-analysis
> > +  // flag has a regular expression that matches the name of the pass
> > +  // name in \p D.
> > +  if (CodeGenOpts.OptimizationRemarkAnalysisPattern &&
> > +
> >
> CodeGenOpts.OptimizationRemarkAnalysisPattern->match(D.getPassName()))
> > +EmitOptimizationMessage(
> > +D,
> > diag::remark_fe_backend_optimization_remark_analysis_aliasing);
> > +}
> > +
> >  void BackendConsumer::OptimizationFailureHandler(
> >  const llvm::DiagnosticInfoOptimizationFailure &D) {
> >EmitOptimizationMessage(D,
> >diag::warn_fe_backend_optimization_failure);
> > @@ -572,6 +585,12 @@ void BackendConsumer::DiagnosticHandlerI
> >  OptimizationRemarkHandler(
> >  cast(DI));
> >  return;
> > +  case llvm::DK_OptimizationRemarkAnalysisAliasing:
> > +// Optimization remarks are always handled completely by this
> > +// handler. There is no generic way of emitting them.
> > +OptimizationRemarkHandler(
> > +cast(DI));
> > +return;
> >case llvm::DK_OptimizationFailure:
> >  // 

Re: [PATCH] D11922: Add NaCl to long double/fp128 mangling test

[Chih-Hung Hsieh via cfe-commits]

chh added a comment.

If there were only two different types,
we should have mangled name 'd' for double and 'e' for long double,
even if their implementations are the same.

The problem came when g++ has __float80 and __float128 types,
and long double could be implemented as __float80 or __float128.
Then 'e' is used for __float80, 'g' for __float128,
and 'long double' has mangled name 'e' or 'g', depending on whether
it is __float80 or __float128.

Yes, so far I know only Android and powerpc use fp128 for long double on x86_64.


Repository:
  rL LLVM

http://reviews.llvm.org/D11922



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

Re: [libcxx] r244462 - Protect template argument from user interference.

[Marshall Clow via cfe-commits]

On Mon, Aug 10, 2015 at 11:12 AM, Hans Wennborg  wrote:

> On Mon, Aug 10, 2015 at 11:09 AM, Joerg Sonnenberger via cfe-commits
>  wrote:
> > On Mon, Aug 10, 2015 at 04:58:04PM -, Joerg Sonnenberger via
> cfe-commits wrote:
> >> Author: joerg
> >> Date: Mon Aug 10 11:58:04 2015
> >> New Revision: 244462
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=244462&view=rev
> >> Log:
> >> Protect template argument from user interference.
> >
> > Hi Marshall, Hans,
> > can we merge this into 3.7? It fixes a problem with 3rd party software
> > seen in pkgsrc.
>
> I'm OK with merging if Marshall approves it.
>
>
I approve.

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

r244547 - [modules] Don't suggest deleting the module cache on an error if there is no module cache for this build.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Mon Aug 10 19:32:42 2015
New Revision: 244547

URL: http://llvm.org/viewvc/llvm-project?rev=244547&view=rev
Log:
[modules] Don't suggest deleting the module cache on an error if there is no 
module cache for this build.

Modified:
cfe/trunk/test/Modules/explicit-build-missing-files.cpp

Modified: cfe/trunk/test/Modules/explicit-build-missing-files.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/explicit-build-missing-files.cpp?rev=244547&r1=244546&r2=244547&view=diff
==
--- cfe/trunk/test/Modules/explicit-build-missing-files.cpp (original)
+++ cfe/trunk/test/Modules/explicit-build-missing-files.cpp Mon Aug 10 19:32:42 
2015
@@ -29,4 +29,5 @@ int y = b2;
 // CHECK-NEXT: b.h:1:45: error:
 
 // MISSING-B: could not find file '{{.*}}b.h'
+// MISSING-B-NOT: please delete the module cache
 #endif


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

Re: r244488 - [dllimport] A non-imported class with an imported key can't have a key

[Reid Kleckner via cfe-commits]

On Mon, Aug 10, 2015 at 5:00 PM, Richard Smith 
wrote:

> On Mon, Aug 10, 2015 at 12:39 PM, Reid Kleckner via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: rnk
>> Date: Mon Aug 10 14:39:01 2015
>> New Revision: 244488
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=244488&view=rev
>> Log:
>> [dllimport] A non-imported class with an imported key can't have a key
>>
>> Summary:
>> The vtable takes its DLL storage class from the class, not the key
>> function. When they disagree, the vtable won't be exported by the DLL
>> that defines the key function. The easiest way to ensure that importers
>> of the class emit their own vtable is to say that the class has no key
>> function.
>>
>> Reviewers: hans, majnemer
>>
>> Subscribers: cfe-commits
>>
>> Differential Revision: http://reviews.llvm.org/D11913
>>
>> Modified:
>> cfe/trunk/lib/AST/RecordLayoutBuilder.cpp
>> cfe/trunk/test/CodeGenCXX/dllimport-rtti.cpp
>>
>> Modified: cfe/trunk/lib/AST/RecordLayoutBuilder.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/RecordLayoutBuilder.cpp?rev=244488&r1=244487&r2=244488&view=diff
>>
>> ==
>> --- cfe/trunk/lib/AST/RecordLayoutBuilder.cpp (original)
>> +++ cfe/trunk/lib/AST/RecordLayoutBuilder.cpp Mon Aug 10 14:39:01 2015
>> @@ -2008,6 +2008,12 @@ static const CXXMethodDecl *computeKeyFu
>>  continue;
>>  }
>>
>> +// If the key function is dllimport but the class isn't, then the
>> class has
>> +// no key function. The DLL that exports the key function won't
>> export the
>> +// vtable in this case.
>> +if (MD->hasAttr() && !RD->hasAttr())
>> +  return nullptr;
>>
>
> Does the same apply if the key function is DLLExport and the class is not?
> (Presumably this would just lead us to export a vtable that we don't need
> to, which is presumably harmless?)
>

No, there's no issue with dllexport. If the key function is dllexport, then
it must be part of the same DLL as the current TU, and we can rely on it to
provide (potentially non-exported) vtable and RTTI symbols.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxx] r244553 - Merging r244462:

[Hans Wennborg via cfe-commits]

Author: hans
Date: Mon Aug 10 19:55:30 2015
New Revision: 244553

URL: http://llvm.org/viewvc/llvm-project?rev=244553&view=rev
Log:
Merging r244462:

r244462 | joerg | 2015-08-10 09:58:04 -0700 (Mon, 10 Aug 2015) | 2 lines

Protect template argument from user interference.



Modified:
libcxx/branches/release_37/   (props changed)
libcxx/branches/release_37/include/type_traits

Propchange: libcxx/branches/release_37/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Mon Aug 10 19:55:30 2015
@@ -1,2 +1,2 @@
 /libcxx/branches/apple:136569-137939
-/libcxx/trunk:242377,242421,243530,243641
+/libcxx/trunk:242377,242421,243530,243641,244462

Modified: libcxx/branches/release_37/include/type_traits
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/branches/release_37/include/type_traits?rev=244553&r1=244552&r2=244553&view=diff
==
--- libcxx/branches/release_37/include/type_traits (original)
+++ libcxx/branches/release_37/include/type_traits Mon Aug 10 19:55:30 2015
@@ -219,8 +219,8 @@ _LIBCPP_BEGIN_NAMESPACE_STD
 template 
 struct __void_t { typedef void type; };
 
-template 
-struct __identity { typedef T type; };
+template 
+struct __identity { typedef _Tp type; };
 
 template 
 struct _LIBCPP_TYPE_VIS_ONLY __dependent_type : public _Tp {};


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

Re: [libcxx] r244462 - Protect template argument from user interference.

[Hans Wennborg via cfe-commits]

On Mon, Aug 10, 2015 at 5:26 PM, Marshall Clow  wrote:
> On Mon, Aug 10, 2015 at 11:12 AM, Hans Wennborg  wrote:
>>
>> On Mon, Aug 10, 2015 at 11:09 AM, Joerg Sonnenberger via cfe-commits
>>  wrote:
>> > On Mon, Aug 10, 2015 at 04:58:04PM -, Joerg Sonnenberger via
>> > cfe-commits wrote:
>> >> Author: joerg
>> >> Date: Mon Aug 10 11:58:04 2015
>> >> New Revision: 244462
>> >>
>> >> URL: http://llvm.org/viewvc/llvm-project?rev=244462&view=rev
>> >> Log:
>> >> Protect template argument from user interference.
>> >
>> > Hi Marshall, Hans,
>> > can we merge this into 3.7? It fixes a problem with 3rd party software
>> > seen in pkgsrc.
>>
>> I'm OK with merging if Marshall approves it.
>>
>
> I approve.

Merged in r244553.

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

Re: [PATCH] D11700: Added remove taint support to ProgramState.

[Francisco via cfe-commits]

franchiotta updated this revision to Diff 31756.
franchiotta added a comment.

Updated refactoring.


http://reviews.llvm.org/D11700

Files:
  include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h
  lib/StaticAnalyzer/Core/ProgramState.cpp

Index: lib/StaticAnalyzer/Core/ProgramState.cpp
===
--- lib/StaticAnalyzer/Core/ProgramState.cpp
+++ lib/StaticAnalyzer/Core/ProgramState.cpp
@@ -648,17 +648,28 @@
   return true;
 }
 
-ProgramStateRef ProgramState::addTaint(const Stmt *S,
-   const LocationContext *LCtx,
-   TaintTagType Kind) const {
+SymbolRef ProgramState::getSymbolFromStmt(const Stmt *S, const LocationContext
+  *LCtx) const {
   if (const Expr *E = dyn_cast_or_null(S))
 S = E->IgnoreParens();
 
-  SymbolRef Sym = getSVal(S, LCtx).getAsSymbol();
+  return getSVal(S, LCtx).getAsSymbol();
+
+}
+
+const MemRegion* ProgramState::getRegionFromStmt(const Stmt *S, const LocationContext
+ *LCtx) const {
+  return getSVal(S, LCtx).getAsRegion();
+}
+
+ProgramStateRef ProgramState::addTaint(const Stmt *S,
+   const LocationContext *LCtx,
+   TaintTagType Kind) const {
+  SymbolRef Sym = getSymbolFromStmt(S, LCtx);
   if (Sym)
 return addTaint(Sym, Kind);
 
-  const MemRegion *R = getSVal(S, LCtx).getAsRegion();
+  const MemRegion *R = getRegionFromStmt(S, LCtx);
   addTaint(R, Kind);
 
   // Cannot add taint, so just return the state.
@@ -684,6 +695,38 @@
   return NewState;
 }
 
+ProgramStateRef ProgramState::removeTaint(const Stmt *S, const LocationContext
+  *LCtx, TaintTagType Kind) const {
+  SymbolRef Sym = getSymbolFromStmt(S, LCtx);
+  if (Sym)
+return removeTaint(Sym, Kind);
+
+  const MemRegion *R = getRegionFromStmt(S, LCtx);
+  removeTaint(R, Kind);
+
+  // Cannot remove taint, so just return the state.
+  return this;
+}
+
+ProgramStateRef ProgramState::removeTaint(const MemRegion *R, TaintTagType Kind)
+  const {
+  if (const SymbolicRegion *SR = dyn_cast_or_null(R))
+return removeTaint(SR->getSymbol(), Kind);
+  return this;
+}
+
+ProgramStateRef ProgramState::removeTaint(SymbolRef Sym, TaintTagType Kind)
+  const {
+  // If this is a symbol cast, remove the cast before removing the taint. Taint
+  // is cast agnostic.
+  while (const SymbolCast *SC = dyn_cast(Sym))
+Sym = SC->getOperand();
+
+  ProgramStateRef NewState = remove(Sym);
+  assert(NewState);
+  return NewState;
+}
+
 bool ProgramState::isTainted(const Stmt *S, const LocationContext *LCtx,
  TaintTagType Kind) const {
   if (const Expr *E = dyn_cast_or_null(S))
Index: include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h
===
--- include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h
+++ include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h
@@ -330,6 +330,18 @@
   ProgramStateRef addTaint(const MemRegion *R,
TaintTagType Kind = TaintTagGeneric) const;
 
+  /// Create a new state in which the statement is marked as non-tainted.
+  ProgramStateRef removeTaint(const Stmt *S, const LocationContext *LCtx,
+  TaintTagType Kind = TaintTagGeneric) const;
+
+  /// Create a new state in which the symbol is marked as non-tainted.
+  ProgramStateRef removeTaint(SymbolRef S, TaintTagType Kind = TaintTagGeneric)
+  const;
+
+  /// Create a new state in which the region symbol is marked as non-tainted.
+  ProgramStateRef removeTaint(const MemRegion *R, TaintTagType Kind =
+  TaintTagGeneric) const;
+
   /// Check if the statement is tainted in the current state.
   bool isTainted(const Stmt *S, const LocationContext *LCtx,
  TaintTagType Kind = TaintTagGeneric) const;
@@ -428,6 +440,13 @@
 InvalidatedSymbols *IS,
 RegionAndSymbolInvalidationTraits *HTraits,
 const CallEvent *Call) const;
+
+  SymbolRef
+  getSymbolFromStmt(const Stmt *S, const LocationContext *LCtx) const;
+
+  const MemRegion*
+  getRegionFromStmt(const Stmt *S, const LocationContext *LCtx) const;
+
 };
 
 //===--===//
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r244556 - Print vectorization analysis when loop hint is specified.

[Tyler Nowicki via cfe-commits]

Author: tnowicki
Date: Mon Aug 10 20:10:08 2015
New Revision: 244556

URL: http://llvm.org/viewvc/llvm-project?rev=244556&view=rev
Log:
Print vectorization analysis when loop hint is specified.

This patche and a related llvm patch solve the problem of having to explicitly 
enable analysis when specifying a loop hint pragma to get the diagnostics. 
Passing AlwasyPrint as the pass name (see below) causes the front-end to print 
the diagnostic if the user has specified '-Rpass-analysis' without an 
'=’. Users of loop hints can pass that compiler option without 
having to specify the pass and they will get diagnostics for only those loops 
with loop hints.

Added:
cfe/trunk/test/Frontend/optimization-remark-analysis.c
Modified:
cfe/trunk/lib/CodeGen/CodeGenAction.cpp

Modified: cfe/trunk/lib/CodeGen/CodeGenAction.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenAction.cpp?rev=244556&r1=244555&r2=244556&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenAction.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenAction.cpp Mon Aug 10 20:10:08 2015
@@ -495,33 +495,39 @@ void BackendConsumer::OptimizationRemark
 
 void BackendConsumer::OptimizationRemarkHandler(
 const llvm::DiagnosticInfoOptimizationRemarkAnalysis &D) {
-  // Optimization analysis remarks are active only if the -Rpass-analysis
-  // flag has a regular expression that matches the name of the pass
-  // name in \p D.
-  if (CodeGenOpts.OptimizationRemarkAnalysisPattern &&
-  CodeGenOpts.OptimizationRemarkAnalysisPattern->match(D.getPassName()))
+  // Optimization analysis remarks are active if the pass name is set to
+  // llvm::DiagnosticInfo::AlwasyPrint or if the -Rpass-analysis flag has a
+  // regular expression that matches the name of the pass name in \p D.
+
+  if (D.getPassName() == llvm::DiagnosticInfo::AlwaysPrint ||
+  (CodeGenOpts.OptimizationRemarkAnalysisPattern &&
+   CodeGenOpts.OptimizationRemarkAnalysisPattern->match(D.getPassName(
 EmitOptimizationMessage(
 D, diag::remark_fe_backend_optimization_remark_analysis);
 }
 
 void BackendConsumer::OptimizationRemarkHandler(
 const llvm::DiagnosticInfoOptimizationRemarkAnalysisFPCommute &D) {
-  // Optimization analysis remarks are active only if the -Rpass-analysis
-  // flag has a regular expression that matches the name of the pass
-  // name in \p D.
-  if (CodeGenOpts.OptimizationRemarkAnalysisPattern &&
-  CodeGenOpts.OptimizationRemarkAnalysisPattern->match(D.getPassName()))
+  // Optimization analysis remarks are active if the pass name is set to
+  // llvm::DiagnosticInfo::AlwasyPrint or if the -Rpass-analysis flag has a
+  // regular expression that matches the name of the pass name in \p D.
+
+  if (D.getPassName() == llvm::DiagnosticInfo::AlwaysPrint ||
+  (CodeGenOpts.OptimizationRemarkAnalysisPattern &&
+   CodeGenOpts.OptimizationRemarkAnalysisPattern->match(D.getPassName(
 EmitOptimizationMessage(
 D, diag::remark_fe_backend_optimization_remark_analysis_fpcommute);
 }
 
 void BackendConsumer::OptimizationRemarkHandler(
 const llvm::DiagnosticInfoOptimizationRemarkAnalysisAliasing &D) {
-  // Optimization analysis remarks are active only if the -Rpass-analysis
-  // flag has a regular expression that matches the name of the pass
-  // name in \p D.
-  if (CodeGenOpts.OptimizationRemarkAnalysisPattern &&
-  CodeGenOpts.OptimizationRemarkAnalysisPattern->match(D.getPassName()))
+  // Optimization analysis remarks are active if the pass name is set to
+  // llvm::DiagnosticInfo::AlwasyPrint or if the -Rpass-analysis flag has a
+  // regular expression that matches the name of the pass name in \p D.
+
+  if (D.getPassName() == llvm::DiagnosticInfo::AlwaysPrint ||
+  (CodeGenOpts.OptimizationRemarkAnalysisPattern &&
+   CodeGenOpts.OptimizationRemarkAnalysisPattern->match(D.getPassName(
 EmitOptimizationMessage(
 D, diag::remark_fe_backend_optimization_remark_analysis_aliasing);
 }

Added: cfe/trunk/test/Frontend/optimization-remark-analysis.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/optimization-remark-analysis.c?rev=244556&view=auto
==
--- cfe/trunk/test/Frontend/optimization-remark-analysis.c (added)
+++ cfe/trunk/test/Frontend/optimization-remark-analysis.c Mon Aug 10 20:10:08 
2015
@@ -0,0 +1,21 @@
+// RUN: %clang -O1 -fvectorize -emit-llvm -Rpass-analysis -S %s -o - 2>&1 | 
FileCheck %s --check-prefix=RPASS
+// RUN: %clang -O1 -fvectorize -emit-llvm -S %s -o - 2>&1 | FileCheck %s
+
+// RPASS: {{.*}}:21:1: remark: loop not vectorized: loop contains a switch 
statement
+// CHECK-NOT: {{.*}}:21:1: remark: loop not vectorized: loop contains a switch 
statement
+
+double foo(int N, int *Array) {
+  double v = 0.0;
+
+  #pragma clang loop vectorize(enable)
+  for (int i = 0; i < N; 

Re: [PATCH] D11778: Improvements on Diagnostic in Macro Expansions

[Zhengkai Wu via cfe-commits]

zhengkai added a comment.

The helper function checkRangesForMacroArgExpansion is to check if the current 
Loc and Ranges are expansions of a macro's arguments.
If so, the IgnoredEnd will record this position and thus omitting all later 
expanded macros (Later expanded macros are showed on top of the stack though).

Two test cases are added. 
The reduced-diags-macros-backtrace.cpp is to show that my method works 
correctly with the option -fmacro-backtrace-limit
The reduced-diags-macros.cpp is to show that my method reduced verbose 
information printed indeed.

There are still a lot of other cases in which my method still works as the old 
version did. 
And I think there are several bugs in the existing functions like 
"emitDiagnostic" and "mapDiagnosticRanges".
This is issued as a bug, the link is 
https://llvm.org/bugs/show_bug.cgi?id=24423.
Future work will be done to improve the current result.



Comment at: test/Misc/reduced-diags-macros.cpp:14-15
@@ +13,4 @@
+// CHECK-NEXT: #define NO_INITIATION(x) int a = x * 2
+// CHECK-NEXT:  ^
+
+// CHECK: {{.*}}:7:15: error: use of undeclared identifier 'b'

Yes.
This works like the old version, should be improved later


http://reviews.llvm.org/D11778



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

Re: [PATCH] D11778: Improvements on Diagnostic in Macro Expansions

[Richard Trieu via cfe-commits]

rtrieu added a comment.

> There are still a lot of other cases in which my method still works as the 
> old version did. 

>  And I think there are several bugs in the existing functions like 
> "emitDiagnostic" and "mapDiagnosticRanges".

>  This is issued as a bug, the link is 
> https://llvm.org/bugs/show_bug.cgi?id=24423.

>  Future work will be done to improve the current result.


The bug you linked to is a tracking bug for all macro improvements.  File bugs 
on specific examples you encounter and link it to that bug.



Comment at: test/Misc/reduced-diags-macros.cpp:14-15
@@ +13,4 @@
+// CHECK-NEXT: #define NO_INITIATION(x) int a = x * 2
+// CHECK-NEXT:  ^
+
+// CHECK: {{.*}}:7:15: error: use of undeclared identifier 'b'

zhengkai wrote:
> Yes.
> This works like the old version, should be improved later
File this issue as another bug.


http://reviews.llvm.org/D11778



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

Re: [PATCH] D11778: Improvements on Diagnostic in Macro Expansions

[Zhengkai Wu via cfe-commits]

zhengkai added a comment.

The example our method doesn't work: https://llvm.org/bugs/show_bug.cgi?id=24424


http://reviews.llvm.org/D11778



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

Re: r244488 - [dllimport] A non-imported class with an imported key can't have a key

[Richard Smith via cfe-commits]

On Mon, Aug 10, 2015 at 5:43 PM, Reid Kleckner  wrote:

> On Mon, Aug 10, 2015 at 5:00 PM, Richard Smith 
> wrote:
>
>> On Mon, Aug 10, 2015 at 12:39 PM, Reid Kleckner via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: rnk
>>> Date: Mon Aug 10 14:39:01 2015
>>> New Revision: 244488
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=244488&view=rev
>>> Log:
>>> [dllimport] A non-imported class with an imported key can't have a key
>>>
>>> Summary:
>>> The vtable takes its DLL storage class from the class, not the key
>>> function. When they disagree, the vtable won't be exported by the DLL
>>> that defines the key function. The easiest way to ensure that importers
>>> of the class emit their own vtable is to say that the class has no key
>>> function.
>>>
>>> Reviewers: hans, majnemer
>>>
>>> Subscribers: cfe-commits
>>>
>>> Differential Revision: http://reviews.llvm.org/D11913
>>>
>>> Modified:
>>> cfe/trunk/lib/AST/RecordLayoutBuilder.cpp
>>> cfe/trunk/test/CodeGenCXX/dllimport-rtti.cpp
>>>
>>> Modified: cfe/trunk/lib/AST/RecordLayoutBuilder.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/RecordLayoutBuilder.cpp?rev=244488&r1=244487&r2=244488&view=diff
>>>
>>> ==
>>> --- cfe/trunk/lib/AST/RecordLayoutBuilder.cpp (original)
>>> +++ cfe/trunk/lib/AST/RecordLayoutBuilder.cpp Mon Aug 10 14:39:01 2015
>>> @@ -2008,6 +2008,12 @@ static const CXXMethodDecl *computeKeyFu
>>>  continue;
>>>  }
>>>
>>> +// If the key function is dllimport but the class isn't, then the
>>> class has
>>> +// no key function. The DLL that exports the key function won't
>>> export the
>>> +// vtable in this case.
>>> +if (MD->hasAttr() && !RD->hasAttr())
>>> +  return nullptr;
>>>
>>
>> Does the same apply if the key function is DLLExport and the class is
>> not? (Presumably this would just lead us to export a vtable that we don't
>> need to, which is presumably harmless?)
>>
>
> No, there's no issue with dllexport. If the key function is dllexport,
> then it must be part of the same DLL as the current TU, and we can rely on
> it to provide (potentially non-exported) vtable and RTTI symbols.
>

Even if a different compiler is used to compile the other TUs in this DLL?
It seems to me that if the rule really is "the vtable takes its DLL storage
class from the class, not the key function", then the TU with the key
function need not actually provide a vtable symbol if the class is not
dllexport but the key function is.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r244561 - Make the analysis reporting test with x86 to fix the hexagon build.

[Tyler Nowicki via cfe-commits]

Author: tnowicki
Date: Mon Aug 10 20:54:48 2015
New Revision: 244561

URL: http://llvm.org/viewvc/llvm-project?rev=244561&view=rev
Log:
Make the analysis reporting test with x86 to fix the hexagon build.

Modified:
cfe/trunk/test/Frontend/optimization-remark-analysis.c

Modified: cfe/trunk/test/Frontend/optimization-remark-analysis.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/optimization-remark-analysis.c?rev=244561&r1=244560&r2=244561&view=diff
==
--- cfe/trunk/test/Frontend/optimization-remark-analysis.c (original)
+++ cfe/trunk/test/Frontend/optimization-remark-analysis.c Mon Aug 10 20:54:48 
2015
@@ -1,5 +1,5 @@
-// RUN: %clang -O1 -fvectorize -emit-llvm -Rpass-analysis -S %s -o - 2>&1 | 
FileCheck %s --check-prefix=RPASS
-// RUN: %clang -O1 -fvectorize -emit-llvm -S %s -o - 2>&1 | FileCheck %s
+// RUN: %clang -O1 -fvectorize -target x86_64-unknown-unknown -emit-llvm 
-Rpass-analysis -S %s -o - 2>&1 | FileCheck %s --check-prefix=RPASS
+// RUN: %clang -O1 -fvectorize -target x86_64-unknown-unknown -emit-llvm -S %s 
-o - 2>&1 | FileCheck %s
 
 // RPASS: {{.*}}:21:1: remark: loop not vectorized: loop contains a switch 
statement
 // CHECK-NOT: {{.*}}:21:1: remark: loop not vectorized: loop contains a switch 
statement


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

Re: [Patch][LoopVectorize] Print vectorization analysis when loop hint pragma is specified

[Tyler Nowicki via cfe-commits]

Hi Hal, Mark,

These patches solve the problem of having to explicitly enable analysis when 
specifying a loop hint pragma to get the diagnostics. Passing AlwasyPrint as 
the pass name (see below) causes the front-end to print the diagnostic if the 
user has specified '-Rpass-analysis' without an '=’. Users of loop 
hints can pass that compiler option without having to specify the pass and they 
will get diagnostics for only those loops with loop hints.

> const char *Name = Hints.isForced() ? DiagnosticInfo::AlwaysPrint : LV_NAME;

> emitAnalysis(Message, TheFunction, TheLoop, Name);


Mark: Would you be interested in extending this to the loop unroller as well?

> P.S. I assume we should add similar logic to the loop unroller (please add a 
> FIXME if you're not going to do this yourself). Another place where this 
> would be useful is to warn the user when a function marked always_inline is 
> not actually inlined.


Hal: Thanks for the all the reviews Hal!

Committed in r244550, r244552,r244555, and r244556.

Tyler

> On Aug 9, 2015, at 9:59 PM, Hal Finkel  wrote:
> 
> Hi Tyler,
> 
> Thanks for working on this!
> 
> +// If a loop hint is provided the diagnostic is always produced.
> +const char *name = Hints.isForced() ? DiagnosticInfo::AlwaysPrint : 
> LV_NAME;
> 
> name -> Name
> 
> These LGTM.
> 
> P.S. I assume we should add similar logic to the loop unroller (please add a 
> FIXME if you're not going to do this yourself). Another place where this 
> would be useful is to warn the user when a function marked always_inline is 
> not actually inlined.
> 
> -Hal
> 
> - Original Message -
>> From: "Tyler Nowicki" mailto:tnowi...@apple.com>>
>> To: "Gonzalo BG" mailto:gonzalob...@gmail.com>>, 
>> "Hal J. Finkel" mailto:hfin...@anl.gov>>, "Commit Messages 
>> and Patches for LLVM"
>> mailto:llvm-comm...@lists.llvm.org>>, "llvm 
>> cfe" mailto:cfe-commits@lists.llvm.org>>
>> Cc: "Gerolf Hoflehner" mailto:ghofleh...@apple.com>>
>> Sent: Friday, August 7, 2015 4:15:51 PM
>> Subject: [Patch][LoopVectorize] Print vectorization analysis when loop hint 
>> pragma is specified
>> 
>> 
>> Hi,
>> 
>> 
>> 
>> 
>> 
>> Currently, when loop hint is used but vectorization fails we generate
>> a warning. To get the analysis the user needs to provide the command
>> line option -Rpass-analysis= with the correct pass name.
>> BUT we don’t tell the user which pass name they will need to get the
>> analysis message. We should be displaying the analysis without
>> having to request it.
>> 
>> 
>> These patches print the analysis information when vectorization fails
>> on loops with hints when the compiler option ‘-Rpass-analysis’ is
>> provided without ‘='. Users of loop hints can provide the
>> compiler option with their regular debug builds to ensure they
>> always get the analysis when vectorization fails. This approach is
>> preferred because diagnostic printing needs line number tracking
>> which is not enabled by normally. Specifying the option without a
>> pass-target enables line number tracking and makes viewing the
>> messages optional.
>> 
>> 
>> The LLVM patches modify the pass-name of the diagnostic to
>> DiagnosticInfo::AlwaysPrint, which is an empty const char*. The use
>> of DiagnosticInfo::AlwaysPrint is recognized when filtering the
>> diagnostics allowing the message to be printed even if the filter
>> doesn’t match. Note that the analysis of loops with hints will
>> always be printed whenever the compiler option is provided even if
>> ‘=' is specified. This allows both types of analyses to
>> be printed at the same time rather than hiding the analysis on loops
>> with hints with an pass-target is given.
>> 
>> 
>> *These patches build on several previous patches still in review to
>> add late-diagnostics for fp-commut and aliasing. See threads ' Late
>> evaluation of vectorization r equirements’ and ' Late evaluate of
>> runtime pointer check's threshold' .
>> 
>> 
>> Comments and reviews are much appreciated!
>> 
>> 
>> Tyler
>> 
>> 
>> (sorry if you received this twice. I used the wrong mailing list
>> addresses)
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
> -- 
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory

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

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

[Honggyu Kim via cfe-commits]

honggyu.kim added a comment.

In http://reviews.llvm.org/D10305#221121, @zaks.anna wrote:

> honggyu.kim,
>
> You are right, CmpRuns.py does not work with HTML files.
>
> The list of HTML reports is produced by scan-build and there is no facility 
> there to search for newly generated reports.


Thanks for the confirmation.

> It is also not clear that there should be one HTML file per report. This is 
> what we have now but the current approach does not scale well for large files 
> with numerous reports (since we create a copy of the file for each report.) 
> We do not have a proper design for issue uniquing with HTML interface in tree.


Yes, because we generate one HTML file per report, the number of bug reports 
can be hugely increased sometimes. In order to have multiple bug reports in a 
single HTML file just like plist, we need to write JavaScript code per HTML 
report to switch between multiple reports in a single file.

But I think it's not a critical issue as of now and it can be considered at the 
next step.
I hope to have a way to compare bug reports with HTML reports without plist as 
well otherwise we need some facility to match the result of CmpRuns.py with 
HTML reports.

As I mentioned, I think the simplist way of comparing HTML reports is to have 
the BugID in each HTML report so that we can just compare HTML reports whether 
the file exists or not.
In this case, if we don't include BugID in hash info, we can make the HTML file 
name as below:

Before: "report-xx.html"
After: "report--.html"
(even if filename is same in different path dirs, BugID can differentiate the 
HTML file name)

I appreciate all your feedback. Thanks.


http://reviews.llvm.org/D10305



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

patch: clarify diagnostic when returned value doesn't match function return type

[Nick Lewycky via cfe-commits]

This simple-minded patch extends the case where we report "no viable
conversion from 'X' to 'Y'" to emit a more useful diagnostic "no viable
conversion from returned value of type 'X' to function return type 'Y'"
when used in that context.

In lieu of adding tests for this diagnostic explicitly, I've only updated
the tests where the patch changes their result.

Please review!

Nick
Index: include/clang/Basic/DiagnosticSemaKinds.td
===
--- include/clang/Basic/DiagnosticSemaKinds.td	(revision 244522)
+++ include/clang/Basic/DiagnosticSemaKinds.td	(working copy)
@@ -5788,7 +5788,8 @@
 def err_typecheck_ambiguous_condition : Error<
   "conversion %diff{from $ to $|between types}0,1 is ambiguous">;
 def err_typecheck_nonviable_condition : Error<
-  "no viable conversion%diff{ from $ to $|}0,1">;
+  "no viable conversion%select{%diff{ from $ to $|}1,2|"
+  "%diff{ from returned value of type $ to function return type $|}1,2}0">;
 def err_typecheck_nonviable_condition_incomplete : Error<
   "no viable conversion%diff{ from $ to incomplete type $|}0,1">;
 def err_typecheck_deleted_function : Error<
Index: lib/Sema/SemaInit.cpp
===
--- lib/Sema/SemaInit.cpp	(revision 244522)
+++ lib/Sema/SemaInit.cpp	(working copy)
@@ -6943,6 +6943,7 @@
   diag::err_typecheck_nonviable_condition_incomplete,
Args[0]->getType(), Args[0]->getSourceRange()))
 S.Diag(Kind.getLocation(), diag::err_typecheck_nonviable_condition)
+  << (Entity.getKind() == InitializedEntity::EK_Result)
   << Args[0]->getType() << Args[0]->getSourceRange()
   << DestType.getNonReferenceType();
 
Index: lib/Sema/SemaOverload.cpp
===
--- lib/Sema/SemaOverload.cpp	(revision 244522)
+++ lib/Sema/SemaOverload.cpp	(working copy)
@@ -3212,7 +3212,7 @@
  diag::err_typecheck_nonviable_condition_incomplete,
  From->getType(), From->getSourceRange()))
   Diag(From->getLocStart(), diag::err_typecheck_nonviable_condition)
-  << From->getType() << From->getSourceRange() << ToType;
+  << false << From->getType() << From->getSourceRange() << ToType;
   } else
 return false;
   CandidateSet.NoteCandidates(*this, OCD_AllCandidates, From);
Index: test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p3-generic-lambda-1y.cpp
===
--- test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p3-generic-lambda-1y.cpp	(revision 244522)
+++ test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p3-generic-lambda-1y.cpp	(working copy)
@@ -49,7 +49,7 @@
   static double dfi(int i) { return i + 3.14; }
   static Local localfi(int) { return Local{}; }
 };
-auto l4 = [](auto (*fp)(int)) -> int { return fp(3); }; //expected-error{{no viable conversion from 'Local' to 'int'}} 
+auto l4 = [](auto (*fp)(int)) -> int { return fp(3); }; //expected-error{{no viable conversion from returned value of type 'Local' to function return type 'int'}} 
 l4(&Local::ifi);
 l4(&Local::cfi);
 l4(&Local::dfi);
Index: test/CXX/expr/expr.prim/expr.prim.lambda/templates.cpp
===
--- test/CXX/expr/expr.prim/expr.prim.lambda/templates.cpp	(revision 244522)
+++ test/CXX/expr/expr.prim/expr.prim.lambda/templates.cpp	(working copy)
@@ -38,7 +38,7 @@
 template
 int infer_result(T x, T y) {
   auto lambda = [=](bool b) { return x + y; };
-  return lambda(true); // expected-error{{no viable conversion from 'X' to 'int'}}
+  return lambda(true); // expected-error{{no viable conversion from returned value of type 'X' to function return type 'int'}}
 }
 
 template int infer_result(int, int);
Index: test/SemaCXX/rval-references.cpp
===
--- test/SemaCXX/rval-references.cpp	(revision 244522)
+++ test/SemaCXX/rval-references.cpp	(working copy)
@@ -90,5 +90,5 @@
   else if (0) // Copy from reference can't be elided
 return r; // expected-error {{call to deleted constructor}}
   else // Construction from different type can't be elided
-return i; // expected-error {{no viable conversion from 'int' to 'MoveOnly'}}
+return i; // expected-error {{no viable conversion from returned value of type 'int' to function return type 'MoveOnly'}}
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D11859: Generating vptr assume loads

[Piotr Padlewski via cfe-commits]

Prazek marked 9 inline comments as done.
Prazek added a comment.

http://reviews.llvm.org/D11859



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

Re: [PATCH] D11859: Generating vptr assume loads

[Piotr Padlewski via cfe-commits]

Prazek added inline comments.


Comment at: lib/CodeGen/CGClass.cpp:1842
@@ +1841,3 @@
+  CGM.getCXXABI().getVTableAddressPoint(vptr.Base, vptr.VTableClass);
+  if (!VTableGlobal) return;
+

djasper wrote:
> Prazek wrote:
> > majnemer wrote:
> > > The return should be on it's own line, please clang-format this.
> > > Also, under which conditions is this case possible?
> > Unfortunatelly clang-format puts short instructions in the same line
> Not, it doesn't. At least not if you properly configure LLVM style.
So mb I am doing something wrong, but I am using git-clang-format and get 
things like this


http://reviews.llvm.org/D11859



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

r244564 - [MSVC Compat] Implement __is_destructible, __is_nothrow_destructible

[David Majnemer via cfe-commits]

Author: majnemer
Date: Mon Aug 10 22:03:28 2015
New Revision: 244564

URL: http://llvm.org/viewvc/llvm-project?rev=244564&view=rev
Log:
[MSVC Compat] Implement __is_destructible, __is_nothrow_destructible

Our implementations of these type trait intrinsics simply mapped them to
__has_trivial_destructor.  Instead, flesh these intrinsics out with a
full implementation which matches the standard's description.

Modified:
cfe/trunk/lib/Sema/SemaExprCXX.cpp
cfe/trunk/test/SemaCXX/type-traits.cpp

Modified: cfe/trunk/lib/Sema/SemaExprCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExprCXX.cpp?rev=244564&r1=244563&r2=244564&view=diff
==
--- cfe/trunk/lib/Sema/SemaExprCXX.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExprCXX.cpp Mon Aug 10 22:03:28 2015
@@ -3814,8 +3814,47 @@ static bool EvaluateUnaryTypeTrait(Sema
 return false;
   case UTT_IsDestructible:
   case UTT_IsNothrowDestructible:
-// FIXME: Implement UTT_IsDestructible and UTT_IsNothrowDestructible.
-// For now, let's fall through.
+// C++14 [meta.unary.prop]:
+//   For reference types, is_destructible::value is true.
+if (T->isReferenceType())
+  return true;
+
+// Objective-C++ ARC: autorelease types don't require destruction.
+if (T->isObjCLifetimeType() &&
+T.getObjCLifetime() == Qualifiers::OCL_Autoreleasing)
+  return true;
+
+// C++14 [meta.unary.prop]:
+//   For incomplete types and function types, is_destructible::value is
+//   false.
+if (T->isIncompleteType() || T->isFunctionType())
+  return false;
+
+// C++14 [meta.unary.prop]:
+//   For object types and given U equal to remove_all_extents_t, if the
+//   expression std::declval().~U() is well-formed when treated as an
+//   unevaluated operand (Clause 5), then is_destructible::value is true
+if (auto *RD = C.getBaseElementType(T)->getAsCXXRecordDecl()) {
+  CXXDestructorDecl *Destructor = Self.LookupDestructor(RD);
+  if (!Destructor)
+return false;
+  //  C++14 [dcl.fct.def.delete]p2:
+  //A program that refers to a deleted function implicitly or
+  //explicitly, other than to declare it, is ill-formed.
+  if (Destructor->isDeleted())
+return false;
+  if (C.getLangOpts().AccessControl && Destructor->getAccess() != 
AS_public)
+return false;
+  if (UTT == UTT_IsNothrowDestructible) {
+const FunctionProtoType *CPT =
+Destructor->getType()->getAs();
+CPT = Self.ResolveExceptionSpec(KeyLoc, CPT);
+if (!CPT || !CPT->isNothrow(C))
+  return false;
+  }
+}
+return true;
+
   case UTT_HasTrivialDestructor:
 // http://gcc.gnu.org/onlinedocs/gcc/Type-Traits.html
 //   If __is_pod (type) is true or type is a reference type

Modified: cfe/trunk/test/SemaCXX/type-traits.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/type-traits.cpp?rev=244564&r1=244563&r2=244564&view=diff
==
--- cfe/trunk/test/SemaCXX/type-traits.cpp (original)
+++ cfe/trunk/test/SemaCXX/type-traits.cpp Mon Aug 10 22:03:28 2015
@@ -150,6 +150,18 @@ struct VariadicCtor {
   template VariadicCtor(T...);
 };
 
+struct ThrowingDtor {
+  ~ThrowingDtor() throw(int);
+};
+
+struct NoExceptDtor {
+  ~NoExceptDtor() noexcept(true);
+};
+
+struct NoThrowDtor {
+  ~NoThrowDtor() throw();
+};
+
 void is_pod()
 {
   { int arr[T(__is_pod(int))]; }
@@ -2019,3 +2031,34 @@ void array_extent() {
   int t02[T(__array_extent(ConstIntArAr, 0) == 4)];
   int t03[T(__array_extent(ConstIntArAr, 1) == 10)];
 }
+
+void is_destructible_test() {
+  { int arr[T(__is_destructible(int))]; }
+  { int arr[T(__is_destructible(int[2]))]; }
+  { int arr[F(__is_destructible(int[]))]; }
+  { int arr[F(__is_destructible(void))]; }
+  { int arr[T(__is_destructible(int &))]; }
+  { int arr[T(__is_destructible(HasDest))]; }
+  { int arr[F(__is_destructible(AllPrivate))]; }
+  { int arr[T(__is_destructible(SuperNonTrivialStruct))]; }
+  { int arr[T(__is_destructible(AllDefaulted))]; }
+  { int arr[F(__is_destructible(AllDeleted))]; }
+  { int arr[T(__is_destructible(ThrowingDtor))]; }
+  { int arr[T(__is_destructible(NoThrowDtor))]; }
+}
+
+void is_nothrow_destructible_test() {
+  { int arr[T(__is_nothrow_destructible(int))]; }
+  { int arr[T(__is_nothrow_destructible(int[2]))]; }
+  { int arr[F(__is_nothrow_destructible(int[]))]; }
+  { int arr[F(__is_nothrow_destructible(void))]; }
+  { int arr[T(__is_nothrow_destructible(int &))]; }
+  { int arr[T(__is_nothrow_destructible(HasDest))]; }
+  { int arr[F(__is_nothrow_destructible(AllPrivate))]; }
+  { int arr[T(__is_nothrow_destructible(SuperNonTrivialStruct))]; }
+  { int arr[T(__is_nothrow_destructible(AllDefaulted))]; }
+  { int arr[F(__is_nothrow_destructible(AllDeleted))]; }
+  { int arr[F(__is_nothrow_destr

Re: [PATCH] D11859: Generating vptr assume loads

[Piotr Padlewski via cfe-commits]

Prazek added inline comments.


Comment at: lib/CodeGen/CodeGenFunction.h:1328-1334
@@ -1320,8 +1327,9 @@
   typedef llvm::SmallPtrSet VisitedVirtualBasesSetTy;
-  void InitializeVTablePointers(BaseSubobject Base,
-const CXXRecordDecl *NearestVBase,
-CharUnits OffsetFromNearestVBase,
-bool BaseIsNonVirtualPrimaryBase,
-const CXXRecordDecl *VTableClass,
-VisitedVirtualBasesSetTy& VBases);
+  VPtrsVector getVTablePointers(const CXXRecordDecl *VTableClass);
+
+  void getVTablePointers(BaseSubobject Base, const CXXRecordDecl *NearestVBase,
+ CharUnits OffsetFromNearestVBase,
+ bool BaseIsNonVirtualPrimaryBase,
+ const CXXRecordDecl *VTableClass,
+ VisitedVirtualBasesSetTy &VBases, VPtrsVector &vptrs);
 

majnemer wrote:
> Would it make more sense for these to live in `CGClass` ?
What do You mean? These functions are defined in CGClass.cpp 


Comment at: lib/CodeGen/MicrosoftCXXABI.cpp:223-228
@@ +222,8 @@
+  // with the 'novtable' attribute.
+  bool canInitilizeVPtr(const CXXRecordDecl *VTableClass,
+const CXXRecordDecl *Base,
+const CXXRecordDecl *NearestVBase) override {
+return !VTableClass->hasAttr() ||
+   (Base != VTableClass && Base != NearestVBase);
+  }
+

Prazek wrote:
> majnemer wrote:
> > In the MS ABI, derived classes never share vtables with bases.  Why do you 
> > need to do anything other than check that the most derived class doesn't 
> > have the `__declspec(novtable)` ?
> I don't know, I just took previous code assuming it is correct.
ok, I see. I just took code that suposed to work with microsoft and itanium 
abi. You are right


http://reviews.llvm.org/D11859



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

Re: [PATCH] D11757: Propagate SourceLocations through to get a Loc on float_cast_overflow

[Filipe Cabecinhas via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL244568: Propagate SourceLocations through to get a Loc on 
float_cast_overflow (authored by filcab).

Changed prior to commit:
  http://reviews.llvm.org/D11757?vs=31429&id=31765#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D11757

Files:
  cfe/trunk/lib/CodeGen/CGExpr.cpp
  cfe/trunk/lib/CodeGen/CGExprComplex.cpp
  cfe/trunk/lib/CodeGen/CGExprScalar.cpp
  cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
  cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
  cfe/trunk/lib/CodeGen/CodeGenFunction.h
  cfe/trunk/test/CodeGen/catch-undef-behavior.c

Index: cfe/trunk/test/CodeGen/catch-undef-behavior.c
===
--- cfe/trunk/test/CodeGen/catch-undef-behavior.c
+++ cfe/trunk/test/CodeGen/catch-undef-behavior.c
@@ -19,6 +19,17 @@
 // CHECK-UBSAN: @[[LINE_700:.*]] = {{.*}}, i32 700, i32 14 {{.*}} @[[STRUCT_S]], i64 4, i8 3 }
 // CHECK-UBSAN: @[[LINE_800:.*]] = {{.*}}, i32 800, i32 12 {{.*}} @{{.*}} }
 // CHECK-UBSAN: @[[LINE_900:.*]] = {{.*}}, i32 900, i32 11 {{.*}} @{{.*}} }
+// CHECK-UBSAN: @[[LINE_1000:.*]] = {{.*}}, i32 1000, i32 10 {{.*}} @{{.*}} }
+// CHECK-UBSAN: @[[FP16:.*]] = private unnamed_addr constant { i16, i16, [9 x i8] } { i16 1, i16 16, [9 x i8] c"'__fp16'\00" }
+// CHECK-UBSAN: @[[LINE_1100:.*]] = {{.*}}, i32 1100, i32 8 {{.*}} @{{.*}} }
+// CHECK-UBSAN: @[[LINE_1200:.*]] = {{.*}}, i32 1200, i32 10 {{.*}} @{{.*}} }
+// CHECK-UBSAN: @[[LINE_1300:.*]] = {{.*}}, i32 1300, i32 10 {{.*}} @{{.*}} }
+// CHECK-UBSAN: @[[LINE_1400:.*]] = {{.*}}, i32 1400, i32 10 {{.*}} @{{.*}} }
+// Make sure we check the fp16 type_mismatch data so we can easily match the signed char float_cast_overflow
+// CHECK-UBSAN: @[[LINE_1500:.*]] = {{.*}}, i32 1500, i32 10 {{.*}} @[[FP16]], {{.*}} }
+// CHECK-UBSAN: @[[SCHAR:.*]] = private unnamed_addr constant { i16, i16, [14 x i8] } { i16 0, i16 7, [14 x i8] c"'signed char'\00" }
+// CHECK-UBSAN: @[[LINE_1500:.*]] = {{.*}}, i32 1500, i32 10 {{.*}} @[[FP16]], {{.*}} }
+// CHECK-UBSAN: @[[LINE_1600:.*]] = {{.*}}, i32 1600, i32 10 {{.*}} @{{.*}} }
 
 // CHECK-NULL: @[[LINE_100:.*]] = private unnamed_addr global {{.*}}, i32 100, i32 5 {{.*}}
 
@@ -209,10 +220,11 @@
   // CHECK-COMMON: %[[INBOUNDS:.*]] = icmp ule i128 %{{.*}}, -20282409603651670423947251286016
   // CHECK-COMMON-NEXT: br i1 %[[INBOUNDS]]
 
-  // CHECK-UBSAN: call void @__ubsan_handle_float_cast_overflow(
+  // CHECK-UBSAN: call void @__ubsan_handle_float_cast_overflow(i8* bitcast ({{.*}} @[[LINE_1000]] to i8*),
 
   // CHECK-TRAP:  call void @llvm.trap() [[NR_NUW]]
   // CHECK-TRAP-NEXT: unreachable
+#line 1000
   return n;
 }
 
@@ -223,10 +235,11 @@
   // CHECK-COMMON: %[[INBOUNDS:.*]] = and i1 %[[GE]], %[[LE]]
   // CHECK-COMMON-NEXT: br i1 %[[INBOUNDS]]
 
-  // CHECK-UBSAN: call void @__ubsan_handle_float_cast_overflow(
+  // CHECK-UBSAN: call void @__ubsan_handle_float_cast_overflow(i8* bitcast ({{.*}} @[[LINE_1100]] to i8*),
 
   // CHECK-TRAP:  call void @llvm.trap() [[NR_NUW]]
   // CHECK-TRAP-NEXT: unreachable
+#line 1100
   *p = n;
 }
 
@@ -239,10 +252,11 @@
 
   // CHECK-UBSAN: %[[CAST:.*]] = bitcast float %[[F]] to i32
   // CHECK-UBSAN: %[[ARG:.*]] = zext i32 %[[CAST]] to i64
-  // CHECK-UBSAN: call void @__ubsan_handle_float_cast_overflow({{.*}}, i64 %[[ARG]]
+  // CHECK-UBSAN: call void @__ubsan_handle_float_cast_overflow(i8* bitcast ({{.*}} @[[LINE_1200]] to i8*), i64 %[[ARG]]
 
   // CHECK-TRAP:  call void @llvm.trap() [[NR_NUW]]
   // CHECK-TRAP-NEXT: unreachable
+#line 1200
   return f;
 }
 
@@ -257,10 +271,11 @@
 
   // CHECK-UBSAN: store x86_fp80 %[[F]], x86_fp80* %[[ALLOCA:.*]], !nosanitize
   // CHECK-UBSAN: %[[ARG:.*]] = ptrtoint x86_fp80* %[[ALLOCA]] to i64
-  // CHECK-UBSAN: call void @__ubsan_handle_float_cast_overflow({{.*}}, i64 %[[ARG]]
+  // CHECK-UBSAN: call void @__ubsan_handle_float_cast_overflow(i8* bitcast ({{.*}} @[[LINE_1300]] to i8*), i64 %[[ARG]]
 
   // CHECK-TRAP:  call void @llvm.trap() [[NR_NUW]]
   // CHECK-TRAP-NEXT: unreachable
+#line 1300
   return ld;
 }
 
@@ -271,10 +286,11 @@
   // CHECK-COMMON: %[[INBOUNDS:.*]] = and i1 %[[GE]], %[[LE]]
   // CHECK-COMMON-NEXT: br i1 %[[INBOUNDS]]
 
-  // CHECK-UBSAN: call void @__ubsan_handle_float_cast_overflow(
+  // CHECK-UBSAN: call void @__ubsan_handle_float_cast_overflow(i8* bitcast ({{.*}} @[[LINE_1400]] to i8*),
 
   // CHECK-TRAP:  call void @llvm.trap() [[NR_NUW]]
   // CHECK-TRAP-NEXT: unreachable
+#line 1400
   return f;
 }
 
@@ -285,10 +301,11 @@
   // CHECK-COMMON: %[[INBOUNDS:.*]] = and i1 %[[GE]], %[[LE]]
   // CHECK-COMMON-NEXT: br i1 %[[INBOUNDS]]
 
-  // CHECK-UBSAN: call void @__ubsan_handle_float_cast_overflow(
+  // CHECK-UBSAN: call void @__ubsan_handle_float_cast_overflow(i8* bitcast ({{.*}} @[[LINE_1500]] to i8*),
 
   // CHECK-TRAP:  call void @llvm.trap() [[NR_NUW]]
   // CHECK-TRAP-NEXT: unreachable
+#line 1500
   return *p;
 }
 
@@ -301,10 +318

r244568 - Propagate SourceLocations through to get a Loc on float_cast_overflow

[Filipe Cabecinhas via cfe-commits]

Author: filcab
Date: Mon Aug 10 23:19:28 2015
New Revision: 244568

URL: http://llvm.org/viewvc/llvm-project?rev=244568&view=rev
Log:
Propagate SourceLocations through to get a Loc on float_cast_overflow

Summary:
float_cast_overflow is the only UBSan check without a source location attached.
This patch propagates SourceLocations where necessary to get them to the
EmitCheck() call.

Reviewers: rsmith, ABataev, rjmccall

Subscribers: cfe-commits

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

Modified:
cfe/trunk/lib/CodeGen/CGExpr.cpp
cfe/trunk/lib/CodeGen/CGExprComplex.cpp
cfe/trunk/lib/CodeGen/CGExprScalar.cpp
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.h
cfe/trunk/test/CodeGen/catch-undef-behavior.c

Modified: cfe/trunk/lib/CodeGen/CGExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGExpr.cpp?rev=244568&r1=244567&r2=244568&view=diff
==
--- cfe/trunk/lib/CodeGen/CGExpr.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGExpr.cpp Mon Aug 10 23:19:28 2015
@@ -96,10 +96,12 @@ llvm::Value *CodeGenFunction::EvaluateEx
   }
 
   QualType BoolTy = getContext().BoolTy;
+  SourceLocation Loc = E->getExprLoc();
   if (!E->getType()->isAnyComplexType())
-return EmitScalarConversion(EmitScalarExpr(E), E->getType(), BoolTy);
+return EmitScalarConversion(EmitScalarExpr(E), E->getType(), BoolTy, Loc);
 
-  return EmitComplexToScalarConversion(EmitComplexExpr(E), 
E->getType(),BoolTy);
+  return EmitComplexToScalarConversion(EmitComplexExpr(E), E->getType(), 
BoolTy,
+   Loc);
 }
 
 /// EmitIgnoredExpr - Emit code to compute the specified expression,

Modified: cfe/trunk/lib/CodeGen/CGExprComplex.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGExprComplex.cpp?rev=244568&r1=244567&r2=244568&view=diff
==
--- cfe/trunk/lib/CodeGen/CGExprComplex.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGExprComplex.cpp Mon Aug 10 23:19:28 2015
@@ -85,10 +85,10 @@ public:
 
   /// Emit a cast from complex value Val to DestType.
   ComplexPairTy EmitComplexToComplexCast(ComplexPairTy Val, QualType SrcType,
- QualType DestType);
+ QualType DestType, SourceLocation 
Loc);
   /// Emit a cast from scalar value Val to DestType.
   ComplexPairTy EmitScalarToComplexCast(llvm::Value *Val, QualType SrcType,
-QualType DestType);
+QualType DestType, SourceLocation Loc);
 
   
//======//
   //Visitor Methods
@@ -394,7 +394,8 @@ ComplexPairTy ComplexExprEmitter::VisitS
 /// Emit a cast from complex value Val to DestType.
 ComplexPairTy ComplexExprEmitter::EmitComplexToComplexCast(ComplexPairTy Val,
QualType SrcType,
-   QualType DestType) {
+   QualType DestType,
+   SourceLocation Loc) 
{
   // Get the src/dest element type.
   SrcType = SrcType->castAs()->getElementType();
   DestType = DestType->castAs()->getElementType();
@@ -402,17 +403,18 @@ ComplexPairTy ComplexExprEmitter::EmitCo
   // C99 6.3.1.6: When a value of complex type is converted to another
   // complex type, both the real and imaginary parts follow the conversion
   // rules for the corresponding real types.
-  Val.first = CGF.EmitScalarConversion(Val.first, SrcType, DestType);
-  Val.second = CGF.EmitScalarConversion(Val.second, SrcType, DestType);
+  Val.first = CGF.EmitScalarConversion(Val.first, SrcType, DestType, Loc);
+  Val.second = CGF.EmitScalarConversion(Val.second, SrcType, DestType, Loc);
   return Val;
 }
 
 ComplexPairTy ComplexExprEmitter::EmitScalarToComplexCast(llvm::Value *Val,
   QualType SrcType,
-  QualType DestType) {
+  QualType DestType,
+  SourceLocation Loc) {
   // Convert the input element to the element type of the complex.
   DestType = DestType->castAs()->getElementType();
-  Val = CGF.EmitScalarConversion(Val, SrcType, DestType);
+  Val = CGF.EmitScalarConversion(Val, SrcType, DestType, Loc);
 
   // Return (realval, 0).
   return ComplexPairTy(Val, llvm::Constant::getNullValue(Val->getType()));
@@ -488,14 +490,15 @@ ComplexPairTy ComplexExprEmitter::EmitCa
 
   case CK_FloatingRealToComplex:
   case CK_IntegralRealToCompl

Re: [PATCH] D11859: Generating vptr assume loads

[Piotr Padlewski via cfe-commits]

Prazek updated this revision to Diff 31766.

http://reviews.llvm.org/D11859

Files:
  lib/CodeGen/CGCXXABI.h
  lib/CodeGen/CGClass.cpp
  lib/CodeGen/CodeGenFunction.h
  lib/CodeGen/ItaniumCXXABI.cpp
  lib/CodeGen/MicrosoftCXXABI.cpp
  test/CodeGen/available-externally-hidden.cpp
  test/CodeGenCXX/ctor-globalopt.cpp
  test/CodeGenCXX/template-instantiation.cpp
  test/CodeGenCXX/thunks.cpp
  test/CodeGenCXX/virtual-base-ctor.cpp
  test/CodeGenCXX/vtable-assume-load.cpp
  test/CodeGenCXX/vtable-available-externally.cpp

Index: test/CodeGenCXX/vtable-available-externally.cpp
===
--- test/CodeGenCXX/vtable-available-externally.cpp
+++ test/CodeGenCXX/vtable-available-externally.cpp
@@ -182,8 +182,8 @@
 namespace Test9 {
 // all virtual functions are outline, so we can assume that it will
 // be generated in translation unit where foo is defined
-// CHECK-TEST9: @_ZTVN5Test91AE = available_externally unnamed_addr constant
-// CHECK-TEST9: @_ZTVN5Test91BE = available_externally unnamed_addr constant
+// CHECK-TEST9-DAG: @_ZTVN5Test91AE = available_externally unnamed_addr constant
+// CHECK-TEST9-DAG: @_ZTVN5Test91BE = available_externally unnamed_addr constant
 struct A {
   virtual void foo();
   virtual void bar();
@@ -206,39 +206,39 @@
 namespace Test10 {
 
 // because A's key function is defined here, vtable is generated in this TU
-// CHECK-TEST10: @_ZTVN6Test101AE = unnamed_addr constant
+// CHECK-TEST10-DAG: @_ZTVN6Test101AE = unnamed_addr constant
 struct A {
   virtual void foo();
   virtual void bar();
 };
 void A::foo() {}
 
 // Because key function is inline we will generate vtable as linkonce_odr
-// CHECK-TEST10: @_ZTVN6Test101DE = linkonce_odr unnamed_addr constant
+// CHECK-TEST10-DAG: @_ZTVN6Test101DE = linkonce_odr unnamed_addr constant
 struct D : A {
   void bar();
 };
 inline void D::bar() {}
 
 // because B has outline key function then we can refer to
-// CHECK-TEST10: @_ZTVN6Test101BE = available_externally unnamed_addr constant
+// CHECK-TEST10-DAG: @_ZTVN6Test101BE = available_externally unnamed_addr constant
 struct B : A {
   void foo();
   void bar();
 };
 
 // C's key function (car) is outline, but C has inline virtual function so we
 // can't guarantee that we will be able to refer to bar from name
 // so (at the moment) we can't emit vtable available_externally
-// CHECK-TEST10: @_ZTVN6Test101CE = external unnamed_addr constant
+// CHECK-TEST10-DAG: @_ZTVN6Test101CE = external unnamed_addr constant
 struct C : A {
   void bar() {}   // defined in body - not key function
   virtual inline void gar();  // inline in body - not key function
   virtual void car();
 };
 
 // no key function, vtable will be generated everywhere it will be used
-// CHECK-TEST10: @_ZTVN6Test101EE = linkonce_odr unnamed_addr constant
+// CHECK-TEST10-DAG: @_ZTVN6Test101EE = linkonce_odr unnamed_addr constant
 struct E : A {};
 
 void g(A& a) {
Index: test/CodeGenCXX/vtable-assume-load.cpp
===
--- /dev/null
+++ test/CodeGenCXX/vtable-assume-load.cpp
@@ -0,0 +1,170 @@
+// RUN: %clang_cc1 %s -triple x86_64-apple-darwin10 -emit-llvm -o %t.ll -O1 -disable-llvm-optzns -fms-extensions
+// RUN: %clang_cc1 %s -triple i686-pc-win32 -emit-llvm -o %t.ms.ll -O1 -disable-llvm-optzns -fms-extensions
+
+// RUN: FileCheck --check-prefix=CHECK1 --input-file=%t.ll %s
+// RUN: FileCheck --check-prefix=CHECK2 --input-file=%t.ll %s
+// RUN: FileCheck --check-prefix=CHECK3 --input-file=%t.ll %s
+// RUN: FileCheck --check-prefix=CHECK4 --input-file=%t.ll %s
+// RUN: FileCheck --check-prefix=CHECK-MS --input-file=%t.ms.ll %s
+
+namespace test1 {
+
+struct A {
+  A();
+  virtual void foo();
+};
+
+struct B : A {
+  virtual void foo();
+};
+
+void g(A* a) { a->foo(); }
+
+void fooA() {
+  A a;
+  g(&a);
+}
+void fooB() {
+  B b;
+  g(&b);
+}
+// CHECK1-LABEL: define void @_ZN5test14fooAEv()
+// CHECK1: %cmp.vtables = icmp eq i8** %vtable, getelementptr inbounds ([3 x i8*], [3 x i8*]* @_ZTVN5test11AE, i64 0, i64 2)
+// CHECK1: call void @llvm.assume(i1 %cmp.vtables)
+// CHECK1-LABEL: }
+
+// CHECK1-LABEL: define void @_ZN5test14fooBEv()
+// CHECK1: call void @_ZN5test11BC1Ev(%"struct.test1::B"* %b)
+// CHECK1: %vtable = load i8**, i8*** %1, !tbaa !5
+// CHECK1: %cmp.vtables = icmp eq i8** %vtable, getelementptr inbounds ([3 x i8*], [3 x i8*]* @_ZTVN5test11BE, i64 0, i64 2)
+// CHECK1: call void @llvm.assume(i1 %cmp.vtables)
+// CHECK1-LABLE: }
+
+// there should not be any assumes in the ctor that calls base ctor
+// CHECK1-LABEL: define linkonce_odr void @_ZN5test11BC2Ev(%"struct.test1::B"* %this)
+// CHECK1-NOT: @llvm.assume(
+// CHECK1-LABEL: }
+}
+namespace test2 {
+struct A {
+  A();
+  virtual void foo();
+};
+
+struct B {
+  B();
+  virtual void bar();
+};
+
+struct C : A, B {
+  C();
+  virtual void foo();
+};
+void g(A* a) { a->foo(); }
+void h(B* b) { b->bar(); }
+
+// CHECK2-LABEL: defin

[PATCH] D11928: Small fixup

[Piotr Padlewski via cfe-commits]

Prazek created this revision.
Prazek added reviewers: rsmith, majnemer.
Prazek added a subscriber: cfe-commits.

http://reviews.llvm.org/D11928

Files:
  include/clang/AST/VTableBuilder.h

Index: include/clang/AST/VTableBuilder.h
===
--- include/clang/AST/VTableBuilder.h
+++ include/clang/AST/VTableBuilder.h
@@ -384,10 +384,6 @@
   VPtrInfo(const CXXRecordDecl *RD)
   : ReusingBase(RD), BaseWithVPtr(RD), NextBaseToMangle(RD) {}
 
-  // Copy constructor.
-  // FIXME: Uncomment when we've moved to C++11.
-  // VPtrInfo(const VPtrInfo &) = default;
-
   /// The vtable will hold all of the virtual bases or virtual methods of
   /// ReusingBase.  This may or may not be the same class as 
VPtrSubobject.Base.
   /// A derived class will reuse the vptr of the first non-virtual base


Index: include/clang/AST/VTableBuilder.h
===
--- include/clang/AST/VTableBuilder.h
+++ include/clang/AST/VTableBuilder.h
@@ -384,10 +384,6 @@
   VPtrInfo(const CXXRecordDecl *RD)
   : ReusingBase(RD), BaseWithVPtr(RD), NextBaseToMangle(RD) {}
 
-  // Copy constructor.
-  // FIXME: Uncomment when we've moved to C++11.
-  // VPtrInfo(const VPtrInfo &) = default;
-
   /// The vtable will hold all of the virtual bases or virtual methods of
   /// ReusingBase.  This may or may not be the same class as VPtrSubobject.Base.
   /// A derived class will reuse the vptr of the first non-virtual base
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D11859: Generating vptr assume loads

[Piotr Padlewski via cfe-commits]

Prazek updated this revision to Diff 31768.

http://reviews.llvm.org/D11859

Files:
  lib/CodeGen/CGCXXABI.h
  lib/CodeGen/CGClass.cpp
  lib/CodeGen/CodeGenFunction.h
  lib/CodeGen/ItaniumCXXABI.cpp
  lib/CodeGen/MicrosoftCXXABI.cpp
  test/CodeGen/available-externally-hidden.cpp
  test/CodeGenCXX/ctor-globalopt.cpp
  test/CodeGenCXX/template-instantiation.cpp
  test/CodeGenCXX/thunks.cpp
  test/CodeGenCXX/virtual-base-ctor.cpp
  test/CodeGenCXX/vtable-assume-load.cpp
  test/CodeGenCXX/vtable-available-externally.cpp

Index: test/CodeGenCXX/vtable-available-externally.cpp
===
--- test/CodeGenCXX/vtable-available-externally.cpp
+++ test/CodeGenCXX/vtable-available-externally.cpp
@@ -182,8 +182,8 @@
 namespace Test9 {
 // all virtual functions are outline, so we can assume that it will
 // be generated in translation unit where foo is defined
-// CHECK-TEST9: @_ZTVN5Test91AE = available_externally unnamed_addr constant
-// CHECK-TEST9: @_ZTVN5Test91BE = available_externally unnamed_addr constant
+// CHECK-TEST9-DAG: @_ZTVN5Test91AE = available_externally unnamed_addr constant
+// CHECK-TEST9-DAG: @_ZTVN5Test91BE = available_externally unnamed_addr constant
 struct A {
   virtual void foo();
   virtual void bar();
@@ -206,39 +206,39 @@
 namespace Test10 {
 
 // because A's key function is defined here, vtable is generated in this TU
-// CHECK-TEST10: @_ZTVN6Test101AE = unnamed_addr constant
+// CHECK-TEST10-DAG: @_ZTVN6Test101AE = unnamed_addr constant
 struct A {
   virtual void foo();
   virtual void bar();
 };
 void A::foo() {}
 
 // Because key function is inline we will generate vtable as linkonce_odr
-// CHECK-TEST10: @_ZTVN6Test101DE = linkonce_odr unnamed_addr constant
+// CHECK-TEST10-DAG: @_ZTVN6Test101DE = linkonce_odr unnamed_addr constant
 struct D : A {
   void bar();
 };
 inline void D::bar() {}
 
 // because B has outline key function then we can refer to
-// CHECK-TEST10: @_ZTVN6Test101BE = available_externally unnamed_addr constant
+// CHECK-TEST10-DAG: @_ZTVN6Test101BE = available_externally unnamed_addr constant
 struct B : A {
   void foo();
   void bar();
 };
 
 // C's key function (car) is outline, but C has inline virtual function so we
 // can't guarantee that we will be able to refer to bar from name
 // so (at the moment) we can't emit vtable available_externally
-// CHECK-TEST10: @_ZTVN6Test101CE = external unnamed_addr constant
+// CHECK-TEST10-DAG: @_ZTVN6Test101CE = external unnamed_addr constant
 struct C : A {
   void bar() {}   // defined in body - not key function
   virtual inline void gar();  // inline in body - not key function
   virtual void car();
 };
 
 // no key function, vtable will be generated everywhere it will be used
-// CHECK-TEST10: @_ZTVN6Test101EE = linkonce_odr unnamed_addr constant
+// CHECK-TEST10-DAG: @_ZTVN6Test101EE = linkonce_odr unnamed_addr constant
 struct E : A {};
 
 void g(A& a) {
Index: test/CodeGenCXX/vtable-assume-load.cpp
===
--- /dev/null
+++ test/CodeGenCXX/vtable-assume-load.cpp
@@ -0,0 +1,170 @@
+// RUN: %clang_cc1 %s -triple x86_64-apple-darwin10 -emit-llvm -o %t.ll -O1 -disable-llvm-optzns -fms-extensions
+// RUN: %clang_cc1 %s -triple i686-pc-win32 -emit-llvm -o %t.ms.ll -O1 -disable-llvm-optzns -fms-extensions
+
+// RUN: FileCheck --check-prefix=CHECK1 --input-file=%t.ll %s
+// RUN: FileCheck --check-prefix=CHECK2 --input-file=%t.ll %s
+// RUN: FileCheck --check-prefix=CHECK3 --input-file=%t.ll %s
+// RUN: FileCheck --check-prefix=CHECK4 --input-file=%t.ll %s
+// RUN: FileCheck --check-prefix=CHECK-MS --input-file=%t.ms.ll %s
+
+namespace test1 {
+
+struct A {
+  A();
+  virtual void foo();
+};
+
+struct B : A {
+  virtual void foo();
+};
+
+void g(A* a) { a->foo(); }
+
+void fooA() {
+  A a;
+  g(&a);
+}
+void fooB() {
+  B b;
+  g(&b);
+}
+// CHECK1-LABEL: define void @_ZN5test14fooAEv()
+// CHECK1: %cmp.vtables = icmp eq i8** %vtable, getelementptr inbounds ([3 x i8*], [3 x i8*]* @_ZTVN5test11AE, i64 0, i64 2)
+// CHECK1: call void @llvm.assume(i1 %cmp.vtables)
+// CHECK1-LABEL: }
+
+// CHECK1-LABEL: define void @_ZN5test14fooBEv()
+// CHECK1: call void @_ZN5test11BC1Ev(%"struct.test1::B"* %b)
+// CHECK1: %vtable = load i8**, i8*** %1, !tbaa !5
+// CHECK1: %cmp.vtables = icmp eq i8** %vtable, getelementptr inbounds ([3 x i8*], [3 x i8*]* @_ZTVN5test11BE, i64 0, i64 2)
+// CHECK1: call void @llvm.assume(i1 %cmp.vtables)
+// CHECK1-LABLE: }
+
+// there should not be any assumes in the ctor that calls base ctor
+// CHECK1-LABEL: define linkonce_odr void @_ZN5test11BC2Ev(%"struct.test1::B"* %this)
+// CHECK1-NOT: @llvm.assume(
+// CHECK1-LABEL: }
+}
+namespace test2 {
+struct A {
+  A();
+  virtual void foo();
+};
+
+struct B {
+  B();
+  virtual void bar();
+};
+
+struct C : A, B {
+  C();
+  virtual void foo();
+};
+void g(A* a) { a->foo(); }
+void h(B* b) { b->bar(); }
+
+// CHECK2-LABEL: defin

Re: [PATCH] D11859: Generating vptr assume loads

[Nathan Wilson via cfe-commits]

nwilson added a subscriber: nwilson.


Comment at: lib/CodeGen/CGClass.cpp:1862
@@ +1861,3 @@
+if (CGM.getCXXABI().canInitializeVPtr(vptr.VTableClass, 
vptr.Base.getBase(),
+ vptr.NearestVBase))
+  EmitVTableAssumptionLoad(vptr, This);

Looks like another formatting/tab issue here.


Comment at: lib/CodeGen/CGClass.cpp:2155
@@ +2154,3 @@
+if (CGM.getCXXABI().canInitializeVPtr(Vptr.VTableClass, 
Vptr.Base.getBase(),
+ Vptr.NearestVBase))
+  InitializeVTablePointer(Vptr);

Looks like the same formatting/tab as above.

This is what I've done when using clang-format, maybe it will fix the issues 
you've had:
./clang-format -style=llvm -lines="N:M"  > tmp && cp tmp 


(Just don't include the less than and greater around the FileToFormat.)



http://reviews.llvm.org/D11859



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

r244569 - This patch fixes the assert in emitting captured code in the target data construct.

[Michael Wong via cfe-commits]

Author: fraggamuffin
Date: Mon Aug 10 23:52:01 2015
New Revision: 244569

URL: http://llvm.org/viewvc/llvm-project?rev=244569&view=rev
Log:
This patch fixes the assert in emitting captured code in the target data 
construct.
This is on behalf of Kelvin Li.
http://reviews.llvm.org/D11475

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

Modified: cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp?rev=244569&r1=244568&r2=244569&view=diff
==
--- cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp Mon Aug 10 23:52:01 2015
@@ -2156,5 +2156,7 @@ void CodeGenFunction::EmitOMPTargetDataD
 
   // emit the code inside the construct for now
   auto CS = cast(S.getAssociatedStmt());
-  EmitStmt(CS->getCapturedStmt());
+  CGM.getOpenMPRuntime().emitInlinedDirective(
+  *this, OMPD_target_data,
+  [&CS](CodeGenFunction &CGF) { CGF.EmitStmt(CS->getCapturedStmt()); });
 }


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

Re: [PATCH] D11475: [OPENMP] fix the assert in emitting captured code inside the target data construct

[Michael Wong via cfe-commits]

fraggamuffin added a comment.

This patch has landed.
Commit
C:\llvmtrunk\tools\clang\lib\CodeGen\CGStmtOpenMP.cpp
C:\llvmtrunk\tools\clang\lib\CodeGen\CGStmtOpenMP.cpp
At revision: 244569


http://reviews.llvm.org/D11475



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

Re: [PATCH] D11859: Generating vptr assume loads

[Daniel Jasper via cfe-commits]

djasper added inline comments.


Comment at: lib/CodeGen/CGClass.cpp:2155
@@ +2154,3 @@
+if (CGM.getCXXABI().canInitializeVPtr(Vptr.VTableClass, 
Vptr.Base.getBase(),
+ Vptr.NearestVBase))
+  InitializeVTablePointer(Vptr);

nwilson wrote:
> Looks like the same formatting/tab as above.
> 
> This is what I've done when using clang-format, maybe it will fix the issues 
> you've had:
> ./clang-format -style=llvm -lines="N:M"  > tmp && cp tmp 
> 
> 
> (Just don't include the less than and greater around the FileToFormat.)
> 
You shouldn't need to do this by "hand". There is clang-format-diff.py / 
git-clang-format for that.


http://reviews.llvm.org/D11859



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

Re: [PATCH] D11859: Generating vptr assume loads

[Nathan Wilson via cfe-commits]

nwilson added inline comments.


Comment at: lib/CodeGen/CGClass.cpp:2155
@@ +2154,3 @@
+if (CGM.getCXXABI().canInitializeVPtr(Vptr.VTableClass, 
Vptr.Base.getBase(),
+ Vptr.NearestVBase))
+  InitializeVTablePointer(Vptr);

djasper wrote:
> nwilson wrote:
> > Looks like the same formatting/tab as above.
> > 
> > This is what I've done when using clang-format, maybe it will fix the 
> > issues you've had:
> > ./clang-format -style=llvm -lines="N:M"  > tmp && cp tmp 
> > 
> > 
> > (Just don't include the less than and greater around the FileToFormat.)
> > 
> You shouldn't need to do this by "hand". There is clang-format-diff.py / 
> git-clang-format for that.
Good to know. Thanks!


http://reviews.llvm.org/D11859



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

Re: [PATCH] D11784: [PATCH] clang-tidy check for incorrect move constructor initializers

[Alexander Kornienko via cfe-commits]

alexfh added a comment.

In http://reviews.llvm.org/D11784#220654, @aaron.ballman wrote:

> Ping?


Sorry for the delay. I'm on vacation currently. Will be back tomorrow.

- Alex


http://reviews.llvm.org/D11784



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

Re: [PATCH] D11752: [X86] Pre-define __MOVBE__ when the target supports it.

[Craig Topper via cfe-commits]

craig.topper added a comment.

What utility does __MOVBE__ serve? We don't have an instrinsic headers that 
needs this like the others. As far as I can tell gcc doesn't define this.


http://reviews.llvm.org/D11752



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

r244433 - [tests] Remove calls to grep

[Filipe Cabecinhas via cfe-commits]

Author: filcab
Date: Mon Aug 10 02:01:11 2015
New Revision: 244433

URL: http://llvm.org/viewvc/llvm-project?rev=244433&view=rev
Log:
[tests] Remove calls to grep

Modified:
cfe/trunk/test/Index/warning-flags.c

Modified: cfe/trunk/test/Index/warning-flags.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Index/warning-flags.c?rev=244433&r1=244432&r2=244433&view=diff
==
--- cfe/trunk/test/Index/warning-flags.c (original)
+++ cfe/trunk/test/Index/warning-flags.c Mon Aug 10 02:01:11 2015
@@ -5,9 +5,9 @@ int *bar(float *f) { return f; }
 // RUN: c-index-test -test-load-source-reparse 5 all %s 2>&1|FileCheck 
-check-prefix=CHECK-BOTH-WARNINGS %s
 // RUN: c-index-test -test-load-source all -Wno-return-type  %s 2>&1|FileCheck 
-check-prefix=CHECK-SECOND-WARNING %s
 // RUN: c-index-test -test-load-source-reparse 5 all -Wno-return-type %s 
2>&1|FileCheck -check-prefix=CHECK-SECOND-WARNING %s
-// RUN: c-index-test -test-load-source all -w %s 2>&1|not grep warning:
-// RUN: c-index-test -test-load-source-reparse 5 all -w %s 2>&1|not grep 
warning:
-// RUN: c-index-test -test-load-source all -w -O4 %s 2>&1|not grep warning:
+// RUN: c-index-test -test-load-source all -w %s 2>&1 | FileCheck 
-check-prefix=NOWARNINGS %s
+// RUN: c-index-test -test-load-source-reparse 5 all -w %s 2>&1 | FileCheck 
-check-prefix=NOWARNINGS %s
+// RUN: c-index-test -test-load-source all -w -O4 %s 2>&1 | FileCheck 
-check-prefix=NOWARNINGS %s
 
 // CHECK-BOTH-WARNINGS: warning: control reaches end of non-void function
 // CHECK-BOTH-WARNINGS: warning: incompatible pointer types returning 'float 
*' from a function with result type 'int *'
@@ -15,3 +15,4 @@ int *bar(float *f) { return f; }
 // CHECK-SECOND-WARNING-NOT:control reaches end of non-void
 // CHECK-SECOND-WARNING: warning: incompatible pointer types returning 'float 
*' from a function with result type 'int *'
 
+// NOWARNINGS-NOT: warning:


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

r244435 - [Static Analyzer] Warn when inner and outer conditions are identical. The inner condition is always true.

[Daniel Marjamaki via cfe-commits]

Author: danielmarjamaki
Date: Mon Aug 10 02:18:29 2015
New Revision: 244435

URL: http://llvm.org/viewvc/llvm-project?rev=244435&view=rev
Log:
[Static Analyzer] Warn when inner and outer conditions are identical. The inner 
condition is always true.

Reviewed in http://reviews.llvm.org/D10892.


Modified:
cfe/trunk/lib/StaticAnalyzer/Checkers/IdenticalExprChecker.cpp
cfe/trunk/test/Analysis/identical-expressions.cpp

Modified: cfe/trunk/lib/StaticAnalyzer/Checkers/IdenticalExprChecker.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Checkers/IdenticalExprChecker.cpp?rev=244435&r1=244434&r2=244435&view=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Checkers/IdenticalExprChecker.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Checkers/IdenticalExprChecker.cpp Mon Aug 10 
02:18:29 2015
@@ -108,6 +108,24 @@ bool FindIdenticalExprVisitor::VisitIfSt
   const Stmt *Stmt1 = I->getThen();
   const Stmt *Stmt2 = I->getElse();
 
+  // Check for identical inner condition:
+  //
+  // if (x<10) {
+  //   if (x<10) {
+  //   ..
+  if (const CompoundStmt *CS = dyn_cast(Stmt1)) {
+if (!CS->body_empty()) {
+  const IfStmt *InnerIf = dyn_cast(*CS->body_begin());
+  if (InnerIf && isIdenticalStmt(AC->getASTContext(), I->getCond(), 
InnerIf->getCond(), /*ignoreSideEffects=*/ false)) {
+PathDiagnosticLocation ELoc(InnerIf->getCond(), BR.getSourceManager(), 
AC);
+BR.EmitBasicReport(AC->getDecl(), Checker, "Identical conditions",
+  categories::LogicError,
+  "conditions of the inner and outer statements are identical",
+  ELoc);
+  }
+}
+  }
+
   // Check for identical conditions:
   //
   // if (b) {

Modified: cfe/trunk/test/Analysis/identical-expressions.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/identical-expressions.cpp?rev=244435&r1=244434&r2=244435&view=diff
==
--- cfe/trunk/test/Analysis/identical-expressions.cpp (original)
+++ cfe/trunk/test/Analysis/identical-expressions.cpp Mon Aug 10 02:18:29 2015
@@ -1530,3 +1530,35 @@ void test_nowarn_long() {
 c = 0LL;
   }
 }
+
+// Identical inner conditions
+
+void test_warn_inner_if_1(int x) {
+  if (x == 1) {
+if (x == 1) // expected-warning {{conditions of the inner and outer 
statements are identical}}
+  ;
+  }
+
+  // FIXME: Should warn here. The warning is currently not emitted because 
there
+  // is code between the conditions.
+  if (x == 1) {
+int y = x;
+if (x == 1)
+  ;
+  }
+}
+
+void test_nowarn_inner_if_1(int x) {
+  // Don't warn when condition has side effects.
+  if (x++ == 1) {
+if (x++ == 1)
+  ;
+  }
+
+  // Don't warn when x is changed before inner condition.
+  if (x < 10) {
+x++;
+if (x < 10)
+  ;
+  }
+}


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

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

[Babati Bence via cfe-commits]

babati updated this revision to Diff 31636.
babati added a comment.

Removed filename.
Updated to the latest trunk.


http://reviews.llvm.org/D10305

Files:
  include/clang/StaticAnalyzer/Core/BugId.h
  lib/StaticAnalyzer/Core/BugId.cpp
  lib/StaticAnalyzer/Core/CMakeLists.txt
  lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
  lib/StaticAnalyzer/Core/PlistDiagnostics.cpp

Index: lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
===
--- lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
+++ lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
@@ -11,12 +11,13 @@
 //
 //===--===//
 
-#include "clang/StaticAnalyzer/Core/AnalyzerOptions.h"
+#include "clang/StaticAnalyzer/Core/BugId.h"
 #include "clang/Basic/FileManager.h"
 #include "clang/Basic/PlistSupport.h"
 #include "clang/Basic/SourceManager.h"
 #include "clang/Basic/Version.h"
 #include "clang/Lex/Preprocessor.h"
+#include "clang/StaticAnalyzer/Core/AnalyzerOptions.h"
 #include "clang/StaticAnalyzer/Core/BugReporter/PathDiagnostic.h"
 #include "clang/StaticAnalyzer/Core/PathDiagnosticConsumers.h"
 #include "llvm/ADT/DenseMap.h"
@@ -210,7 +211,7 @@
unsigned depth) {
   
   IntrusiveRefCntPtr callEnter =
-P.getCallEnterEvent();  
+P.getCallEnterEvent(); 
 
   if (callEnter)
 ReportPiece(o, *callEnter, FM, SM, LangOpts, indent, depth, true,
@@ -224,7 +225,7 @@
   if (callEnterWithinCaller)
 ReportPiece(o, *callEnterWithinCaller, FM, SM, LangOpts,
 indent, depth, true);
-  
+
   for (PathPieces::const_iterator I = P.path.begin(), E = P.path.end();I!=E;++I)
 ReportPiece(o, **I, FM, SM, LangOpts, indent, depth, true);
 
@@ -296,8 +297,8 @@
 
   if (!Diags.empty())
 SM = &(*(*Diags.begin())->path.begin())->getLocation().getManager();
-
   
+
   for (std::vector::iterator DI = Diags.begin(),
DE = Diags.end(); DI != DE; ++DI) {
 
@@ -390,6 +391,14 @@
 o << "   check_name";
 EmitString(o, D->getCheckName()) << '\n';
  
+o << "   bug_id_1";
+PathDiagnosticLocation UPDLoc = D->getUniqueingLoc();
+FullSourceLoc UL(SM->getExpansionLoc(UPDLoc.asLocation()), *SM);
+FullSourceLoc L(SM->getExpansionLoc(D->getLocation().asLocation()), *SM);
+const Decl *DeclWithIssue = D->getDeclWithIssue();
+EmitString(o, GetIssueHash(SM, UPDLoc.isValid() ? UL : L, D->getCheckName(),
+   D->getBugType(), DeclWithIssue).str()) << '\n';
+
 // Output information about the semantic context where
 // the issue occurred.
 if (const Decl *DeclWithIssue = D->getDeclWithIssue()) {
Index: lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
===
--- lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
+++ lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
@@ -11,6 +11,7 @@
 //
 //===--===//
 
+#include "clang/StaticAnalyzer/Core/BugId.h"
 #include "clang/StaticAnalyzer/Core/PathDiagnosticConsumers.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/AST/Decl.h"
@@ -236,6 +237,11 @@
 if (!BugType.empty())
   os << "\n\n";
 
+PathDiagnosticLocation UPDLoc = D.getUniqueingLoc();
+FullSourceLoc UL(SMgr.getExpansionLoc(UPDLoc.asLocation()), SMgr);
+FullSourceLoc L(SMgr.getExpansionLoc(D.getLocation().asLocation()), SMgr);
+const Decl *DeclWithIssue = D.getDeclWithIssue();
+
 StringRef BugCategory = D.getCategory();
 if (!BugCategory.empty())
   os << "\n\n";
@@ -246,6 +252,10 @@
 
 os  << "\n\n";
 
+os  << "\n\n";
+
 os << "\n\n";
Index: lib/StaticAnalyzer/Core/CMakeLists.txt
===
--- lib/StaticAnalyzer/Core/CMakeLists.txt
+++ lib/StaticAnalyzer/Core/CMakeLists.txt
@@ -6,6 +6,7 @@
   AnalyzerOptions.cpp
   BasicValueFactory.cpp
   BlockCounter.cpp
+  BugId.cpp
   BugReporter.cpp
   BugReporterVisitors.cpp
   CallEvent.cpp
Index: lib/StaticAnalyzer/Core/BugId.cpp
===
--- lib/StaticAnalyzer/Core/BugId.cpp
+++ lib/StaticAnalyzer/Core/BugId.cpp
@@ -0,0 +1,198 @@
+//===-- BugId.cpp - Unique bugid utility *- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+#include "clang/StaticAnalyzer/Core/BugId.h"
+#include "clang/AST/Decl.h"
+#include "clang/AST/DeclCXX.h"
+#include "clang/Lex/Lexer.h"
+#include "clang/Basic/Specifiers.h"
+#include "clang/Basic/SourceManager.h"
+#include "llvm/Support/LineIterator.h"
+#include "llvm/Support/Path.h"
+#include "llvm/Support/MD5.h"
+#include "llvm/ADT/Twine.h"
+#include "llvm/ADT/SmallVector.h"
+#include "llvm/AD

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

[Babati Bence via cfe-commits]

babati added a comment.

We wanted to include the filename without path in the hash. This would allow us 
to compare two runs of the same project (located in different directories) 
purely based on the hashes.
This gives good enough results when comparing different versions of the same 
project, or storing bug suppression for a single project.
(Limitation: You would not be able to detect a new bug if it appaers in a new 
file with same name and same content as an existing one. (for example a copied 
main.c) But we think this is a rare case.)

If the filename is not part of the hash, then the comparison script can get 
somewhat slower, as you need to compare also the extra file field. But this is 
acceptable.

So finally, I agree that leaving out the filename from the hash allows for 
greater flexibility at post processing.

Do you think we need any other improvements to this patch?


http://reviews.llvm.org/D10305



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

Re: [PATCH] D11851: clang-format: Add "AllowShortNamespacesOnASingleLine" option

[Daniel Jasper via cfe-commits]

djasper added inline comments.


Comment at: include/clang/Format/Format.h:115
@@ -114,1 +114,3 @@
 
+  /// \brief If \c true,  namespace a { class b; }  can be put
+  /// on a single line

Don't use markup here. Use a \code block instead.


Comment at: lib/Format/UnwrappedLineFormatter.cpp:204
@@ +203,3 @@
+ TheLine->First->is(tok::kw_namespace)) {
+if (unsigned result = tryMergeNamespace(I, E, Limit)) {
+  return result;

No braces.


Comment at: lib/Format/UnwrappedLineFormatter.cpp:267
@@ -260,1 +266,3 @@
 
+  unsigned tryMergeNamespace(
+  SmallVectorImpl::const_iterator I,

How is this different from tryMergeSimpleBlock, in particular, which behavior 
differences do you want?


Comment at: unittests/Format/FormatTest.cpp:10441
@@ +10440,3 @@
+  verifyFormat("namespace foo { class bar; }", style);
+  verifyFormat("namespace foo {\nclass bar;\nclass baz;\n}", style);
+  verifyFormat("namespace foo {\nint f() { return 5; }\n}", style);

Please insert a pair of quotes ("") after each '\n' and format, so that this 
becomes a concatenated multiline string.

What about:
  namespace A { namespace B { class C; }}

I think this is what many people would use. It's fine not to fix this in this 
patch, but at least denote the behavior with a corresponding test.


Repository:
  rL LLVM

http://reviews.llvm.org/D11851



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

Re: [PATCH] D11837: Add Qt brace style configuration option.

[Daniel Jasper via cfe-commits]

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

Looks good. Do you have commit access?



Comment at: include/clang/Format/Format.h:180
@@ +179,3 @@
+BS_GNU,
+/// Like ``Attach``, but break before braces on functions, and classes.
+BS_Qt

Remove the second comma (and regenerate the docs)


http://reviews.llvm.org/D11837



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

Re: [PATCH] D10892: warning when inner condition is identical

[Daniel Marjamäki via cfe-commits]

danielmarjamaki accepted this revision.
danielmarjamaki added a reviewer: danielmarjamaki.
danielmarjamaki marked 6 inline comments as done.
This revision is now accepted and ready to land.


Comment at: lib/StaticAnalyzer/Checkers/IdenticalExprChecker.cpp:120
@@ +119,3 @@
+  if (InnerIf && isIdenticalStmt(AC->getASTContext(), I->getCond(), 
InnerIf->getCond(), /*ignoreSideEffects=*/ false)) {
+PathDiagnosticLocation ELoc(InnerIf->getCond(), BR.getSourceManager(), 
AC);
+BR.EmitBasicReport(AC->getDecl(), Checker, "Identical conditions",

Removed


Comment at: lib/StaticAnalyzer/Checkers/IdenticalExprChecker.cpp:125
@@ +124,3 @@
+  ELoc);
+  }
+}

I removed Sr


http://reviews.llvm.org/D10892



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

Re: [PATCH] D10833: Retrieve BinaryOperator::getOpcode and BinaryOperator::getOpcodeStr via libclang and its python interface

[guibufolo+l...@gmail.com via cfe-commits]

RedX2501 added a reviewer: doug.gregor.
RedX2501 added a comment.

The code owners file says you are the owner of all parts that do not belong to 
somebody else. So i hope it is ok if i attach you as reviewer to this.


http://reviews.llvm.org/D10833



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

Re: [PATCH] D10834: Added functions to retrieve information about variable storage in libclang and its python bindings.

[guibufolo+l...@gmail.com via cfe-commits]

RedX2501 added a reviewer: doug.gregor.
RedX2501 added a comment.

The code owners file says you are the owner of all parts that do not belong to 
somebody else. So i hope it is ok if i attach you as reviewer to this.


http://reviews.llvm.org/D10834



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

Re: [PATCH] D10834: Added functions to retrieve information about variable storage in libclang and its python bindings.

[guibufolo+l...@gmail.com via cfe-commits]

RedX2501 added a comment.

Ping


http://reviews.llvm.org/D10834



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

Re: [PATCH] D10833: Retrieve BinaryOperator::getOpcode and BinaryOperator::getOpcodeStr via libclang and its python interface

[guibufolo+l...@gmail.com via cfe-commits]

RedX2501 added a comment.

Ping


http://reviews.llvm.org/D10833



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

Re: [PATCH] D5538: Added function to retrieve storage class in libclang.

[guibufolo+l...@gmail.com via cfe-commits]

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

This was accepted into r219809.


http://reviews.llvm.org/D5538



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

Re: [PATCH] D5538: Added function to retrieve storage class in libclang.

[guibufolo+l...@gmail.com via cfe-commits]

RedX2501 closed this revision.
RedX2501 added a comment.

Accepted into r219809.


http://reviews.llvm.org/D5538



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

Re: [PATCH] D11837: Add Qt brace style configuration option.

[Manuel Klimek via cfe-commits]

klimek added a comment.

Hm, the referenced style guide doesn't say anything about namespaces. I also 
couldn't find anything in the qt source repo (just took a quick look though). 
Do you have an example of why Qt projects shouldn't just use BS_Linux?


http://reviews.llvm.org/D11837



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

[PATCH] D11896: [clang-cl] Add support for CL and _CL_ environment variables

[David Majnemer via cfe-commits]

majnemer created this revision.
majnemer added reviewers: hansw, rnk.
majnemer added a subscriber: cfe-commits.

cl uses 'CL' and '_CL_' to prepend and append command line options to
the given argument vector.  There is an additional quirk whereby '#' is
transformed into '='.

http://reviews.llvm.org/D11896

Files:
  test/Driver/cl-options.c
  tools/driver/driver.cpp

Index: tools/driver/driver.cpp
===
--- tools/driver/driver.cpp
+++ tools/driver/driver.cpp
@@ -445,6 +445,38 @@
 }
   }
 
+  // Handle CL and _CL_ which permits additional command line options to be
+  // prepended or appended.
+  if (Tokenizer == &llvm::cl::TokenizeWindowsCommandLine) {
+// The first instance of '#' should be replaced with '='.
+auto AdjustOpt = [] (const char *Opt) {
+  if (char *NumberSignPtr = const_cast(::strchr(Opt, '#')))
+*NumberSignPtr = '=';
+  return Opt;
+};
+
+// Arguments in "CL" are prepended.
+llvm::Optional OptCL = llvm::sys::Process::GetEnv("CL");
+if (OptCL.hasValue()) {
+  SmallVector PrependedOpts;
+  llvm::cl::TokenizeWindowsCommandLine(OptCL.getValue(), Saver,
+   PrependedOpts);
+  // Insert right after the program name to prepend to the argument list.
+  for (const char *PrependedOpt : PrependedOpts)
+argv.insert(argv.begin() + 1, AdjustOpt(PrependedOpt));
+}
+// Arguments in "CL" are appended.
+llvm::Optional Opt_CL_ = llvm::sys::Process::GetEnv("_CL_");
+if (Opt_CL_.hasValue()) {
+  SmallVector AppendedOpts;
+  llvm::cl::TokenizeWindowsCommandLine(Opt_CL_.getValue(), Saver,
+   AppendedOpts);
+  // Insert at the end of the argument list to append.
+  for (const char *AppendedOpt : AppendedOpts)
+argv.push_back(AdjustOpt(AppendedOpt));
+}
+  }
+
   std::set SavedStrings;
   // Handle CCC_OVERRIDE_OPTIONS, used for editing a command line behind the
   // scenes.
Index: test/Driver/cl-options.c
===
--- test/Driver/cl-options.c
+++ test/Driver/cl-options.c
@@ -379,6 +379,12 @@
 // RUN: %clang_cl -fmsc-version=1900 -TP -### -- %s 2>&1 | FileCheck 
-check-prefix=CXX14 %s
 // CXX14: -std=c++14
 
+// RUN: env CL="/Gy" %clang_cl -### -- %s 2>&1 | FileCheck 
-check-prefix=ENV-CL %s
+// ENV-CL: "-ffunction-sections"
+
+// RUN: env CL="/Gy" _CL_="/Gy- -- %s" %clang_cl -### 2>&1 | FileCheck 
-check-prefix=ENV-_CL_ %s
+// ENV-_CL_-NOT: "-ffunction-sections"
+
 // Accept "core" clang options.
 // (/Zs is for syntax-only, -Werror makes it fail hard on unknown options)
 // RUN: %clang_cl \


Index: tools/driver/driver.cpp
===
--- tools/driver/driver.cpp
+++ tools/driver/driver.cpp
@@ -445,6 +445,38 @@
 }
   }
 
+  // Handle CL and _CL_ which permits additional command line options to be
+  // prepended or appended.
+  if (Tokenizer == &llvm::cl::TokenizeWindowsCommandLine) {
+// The first instance of '#' should be replaced with '='.
+auto AdjustOpt = [] (const char *Opt) {
+  if (char *NumberSignPtr = const_cast(::strchr(Opt, '#')))
+*NumberSignPtr = '=';
+  return Opt;
+};
+
+// Arguments in "CL" are prepended.
+llvm::Optional OptCL = llvm::sys::Process::GetEnv("CL");
+if (OptCL.hasValue()) {
+  SmallVector PrependedOpts;
+  llvm::cl::TokenizeWindowsCommandLine(OptCL.getValue(), Saver,
+   PrependedOpts);
+  // Insert right after the program name to prepend to the argument list.
+  for (const char *PrependedOpt : PrependedOpts)
+argv.insert(argv.begin() + 1, AdjustOpt(PrependedOpt));
+}
+// Arguments in "CL" are appended.
+llvm::Optional Opt_CL_ = llvm::sys::Process::GetEnv("_CL_");
+if (Opt_CL_.hasValue()) {
+  SmallVector AppendedOpts;
+  llvm::cl::TokenizeWindowsCommandLine(Opt_CL_.getValue(), Saver,
+   AppendedOpts);
+  // Insert at the end of the argument list to append.
+  for (const char *AppendedOpt : AppendedOpts)
+argv.push_back(AdjustOpt(AppendedOpt));
+}
+  }
+
   std::set SavedStrings;
   // Handle CCC_OVERRIDE_OPTIONS, used for editing a command line behind the
   // scenes.
Index: test/Driver/cl-options.c
===
--- test/Driver/cl-options.c
+++ test/Driver/cl-options.c
@@ -379,6 +379,12 @@
 // RUN: %clang_cl -fmsc-version=1900 -TP -### -- %s 2>&1 | FileCheck -check-prefix=CXX14 %s
 // CXX14: -std=c++14
 
+// RUN: env CL="/Gy" %clang_cl -### -- %s 2>&1 | FileCheck -check-prefix=ENV-CL %s
+// ENV-CL: "-ffunction-sections"
+
+// RUN: env CL="/Gy" _CL_="/Gy- -- %s" %clang_cl -### 2>&1 | FileCheck -check-prefix=ENV-_CL_ %s
+// ENV-_CL_-NOT: "-ffunction-sections"
+
 // Accept "cor

Re: [PATCH] D11837: Add Qt brace style configuration option.

[Roman Kashitsyn via cfe-commits]

lifted added a comment.

> Hm, the referenced style guide doesn't say anything about namespaces.


You're right. Futhermore, it's hard to find any namespaces in qt repos at all - 
Qt uses a macro for conditional compilation with namespaces.

> I also couldn't find anything in the qt source repo (just took a quick look 
> though).


Hm, I've just browsed through the qtcore and seen no evidence that qt uses 
attached braces everywhere but after classes and function. Qt use of style is 
inconsistent (sometimes even within a single file), and few examples I've 
looked at actually use something close to Mozilla style - they break on 
structs, enums, classes, and functions 
(http://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/tools/qchar.h?id=13c16bbd06e0034210ba2164f1be208c49a6e3a7).

My bad, I read the Qt Brace style description and decided that it could fit my 
current project style (we break after functions, and some people also break 
after classes). But it turned out that Qt style is not as well defined as I 
thought, so I'm out of luck.

I believe it's better to abandon this patch.

I hope I will find some time to introduce extra configuration options to 
override pre-defined brace styles, as it was discussed long time ago.


http://reviews.llvm.org/D11837



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

Re: [PATCH] D11739: Add new llvm.loop.unroll.enable metadata

[hfin...@anl.gov via cfe-commits]

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

LGTM.


http://reviews.llvm.org/D11739



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