[PATCH] D44559: [Sema] Wrong width of result of mul operation

[Andrew V. Tischenko via Phabricator via cfe-commits]

avt77 added a comment.

> That's an interesting question.  In general, these warnings do try to ignore 
> the effects of implicit promotion.  We would not want -Wsign-conversion to 
> fire on `unsigned short x = an_unsigned_short + 1;` (or `- 1`, for that 
> matter), even though formally this coerces a `signed int` to `unsigned 
> short`.  Similarly, -Wsign-conversion *should* warn on `signed short x = 
> an_unsigned_short + 1;`, even though formally the promotion from `unsigned 
> short` to `signed int` is not problematic and the final conversion from 
> `signed int` to `signed short` is not a signedness change.  (This second 
> example should also generate a -Wconversion warning, but the questions are 
> independent.)  Applying that strictly here would say that the user is 
> entitled to think of this as an operation on `unsigned char` that then gets 
> losslessly promoted to `signed short`, even though arithmetically that's not 
> what happens.  On the other hand, I do think there's some room for 
> -Wsign-conversion to be more aggressive than -Wconversion about this sort of 
> thing; -Wsign-conversion should generally fire for any changes in signedness 
> from the original operand types (with the usual complexities around constant 
> values), and there's just an exception for computations whose value is known 
> to fit within the expressible range of the result type, which is not true of 
> this multiplication.  So I think it would be acceptable to warn on this.
> 
> John.

OK, is it LGTM?


https://reviews.llvm.org/D44559



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

Re: [PATCH] D44691: [CUDA] Disable LTO for device-side compilations.

[Yvan Roux via cfe-commits]

Hi Artem,

On 21 March 2018 at 23:25, Artem Belevich via Phabricator via
cfe-commits  wrote:
> This revision was automatically updated to reflect the committed changes.
> Closed by commit rL328161: [CUDA] Disable LTO for device-side compilations. 
> (authored by tra, committed by ).
> Herald added a subscriber: llvm-commits.
>
> Changed prior to commit:
>   https://reviews.llvm.org/D44691?vs=139151&id=139381#toc
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D44691
>
> Files:
>   cfe/trunk/include/clang/Driver/Driver.h
>   cfe/trunk/lib/Driver/Driver.cpp
>   cfe/trunk/lib/Driver/ToolChains/Clang.cpp
>   cfe/trunk/test/Driver/lto.cu
>   cfe/trunk/test/Driver/thinlto.cu

This patch broke ARM/AArch64 bots, see:
http://lab.llvm.org:8011/builders/clang-cmake-armv8-full/builds/841/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Athinlto.cu

Thanks
Yvan

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

[PATCH] D44765: PR36643 Make clang-format support more generic TMarcos

[Alexander Kornienko via Phabricator via cfe-commits]

alexfh requested changes to this revision.
alexfh added a comment.
This revision now requires changes to proceed.

We can't just treat `anything("")` like the _T macro. There should be a 
whitelist configurable with an option. By default only _T should be handled.


Repository:
  rC Clang

https://reviews.llvm.org/D44765



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

[PATCH] D44773: [CMake] Use custom command and target to install libc++ headers

[Petr Hosek via Phabricator via cfe-commits]

phosek created this revision.
phosek added reviewers: EricWF, beanz.
Herald added subscribers: cfe-commits, christof, fedor.sergeev, mgorny, srhines.

Using file(COPY FILE...) has several downsides. Since the file command
is only executed at configuration time, any changes to headers made
after the initial CMake execution are ignored. This can lead to subtle
errors since the just built Clang will be using stale libc++ headers.
Furthermore, since the headers are copied prior to executing the build
system, this may hide missing dependencies on libc++ from other LLVM
components.

This changes replaces the use of file(COPY FILE...) command with a
custom command and target which addresses all aforementioned issues and
matches the implementation already used by other LLVM components that
also install headers like Clang builtin headers.


Repository:
  rCXX libc++

https://reviews.llvm.org/D44773

Files:
  libcxx/cmake/Modules/HandleLibCXXABI.cmake
  libcxx/include/CMakeLists.txt
  libcxx/lib/CMakeLists.txt

Index: libcxx/lib/CMakeLists.txt
===
--- libcxx/lib/CMakeLists.txt
+++ libcxx/lib/CMakeLists.txt
@@ -283,7 +283,8 @@
 endif()
 
 # Add a meta-target for both libraries.
-add_custom_target(cxx DEPENDS ${LIBCXX_TARGETS} ${generated_config_deps})
+add_custom_target(cxx DEPENDS ${LIBCXX_TARGETS})
+add_dependencies(cxx cxx-headers)
 
 if (LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY)
   file(GLOB LIBCXX_EXPERIMENTAL_SOURCES ../src/experimental/*.cpp)
Index: libcxx/include/CMakeLists.txt
===
--- libcxx/include/CMakeLists.txt
+++ libcxx/include/CMakeLists.txt
@@ -1,5 +1,187 @@
-if (NOT LIBCXX_INSTALL_SUPPORT_HEADERS)
-  set(LIBCXX_SUPPORT_HEADER_PATTERN PATTERN "support" EXCLUDE)
+set(files
+  cfenv
+  array
+  sstream
+  csetjmp
+  cwchar
+  algorithm
+  string_view
+  cstdint
+  utility
+  __split_buffer
+  ext/hash_map
+  ext/hash_set
+  ext/__hash
+  functional
+  initializer_list
+  ciso646
+  cstdio
+  cstdarg
+  math.h
+  string
+  type_traits
+  __functional_base_03
+  iostream
+  unordered_map
+  queue
+  variant
+  cstring
+  ratio
+  cinttypes
+  system_error
+  __tree
+  stdio.h
+  __locale
+  __tuple
+  wchar.h
+  __functional_03
+  __bsd_locale_defaults.h
+  condition_variable
+  stdlib.h
+  cassert
+  limits
+  limits.h
+  module.modulemap
+  list
+  cfloat
+  vector
+  chrono
+  __bit_reference
+  new
+  typeinfo
+  any
+  cerrno
+  thread
+  cmath
+  cctype
+  memory
+  scoped_allocator
+  ios
+  map
+  valarray
+  cstdbool
+  ccomplex
+  __hash_table
+  csignal
+  clocale
+  forward_list
+  __mutex_base
+  climits
+  future
+  tuple
+  __threading_support
+  __bsd_locale_fallbacks.h
+  strstream
+  locale.h
+  set
+  ctime
+  stdexcept
+  streambuf
+  string.h
+  optional
+  float.h
+  wctype.h
+  complex.h
+  setjmp.h
+  __nullptr
+  inttypes.h
+  iterator
+  codecvt
+  stack
+  stdint.h
+  ctype.h
+  random
+  cstdlib
+  istream
+  numeric
+  regex
+  __string
+  errno.h
+  cstddef
+  __functional_base
+  cwctype
+  __undef_macros
+  fstream
+  tgmath.h
+  deque
+  unordered_set
+  complex
+  typeindex
+  mutex
+  stddef.h
+  iomanip
+  iosfwd
+  ostream
+  __std_stream
+  __debug
+  locale
+  ctgmath
+  bitset
+  __libcpp_version
+  stdbool.h
+  __sso_allocator
+  shared_mutex
+  atomic
+  exception
+  )
+
+if(LIBCXX_INSTALL_SUPPORT_HEADERS)
+  set(files
+${files}
+support/solaris/wchar.h
+support/solaris/floatingpoint.h
+support/solaris/xlocale.h
+support/fuchsia/xlocale.h
+support/xlocale/__posix_l_fallback.h
+support/xlocale/__strtonum_fallback.h
+support/xlocale/__nop_locale_mgmt.h
+support/xlocale/xlocale.h
+support/ibm/locale_mgmt_aix.h
+support/ibm/limits.h
+support/ibm/support.h
+support/ibm/xlocale.h
+support/android/locale_bionic.h
+support/musl/xlocale.h
+support/win32/locale_win32.h
+support/win32/limits_msvc_win32.h
+support/newlib/xlocale.h
+)
+endif()
+
+if(LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY)
+  set(files
+${files}
+experimental/__config
+experimental/dynarray
+experimental/algorithm
+experimental/string_view
+experimental/utility
+experimental/functional
+experimental/string
+experimental/type_traits
+experimental/propagate_const
+experimental/unordered_map
+experimental/ratio
+experimental/system_error
+experimental/filesystem
+experimental/__memory
+experimental/list
+experimental/vector
+experimental/chrono
+experimental/any
+experimental/memory_resource
+experimental/map
+experimental/forward_list
+experimental/tuple
+experimental/set
+experimental/coroutine
+experimental/optional
+experimental/iterator
+experimental/numeric
+experimental/regex
+experimental/deque
+experimental/unordered_set
+)
 endif()
 
 if (LIBCXX_NEEDS_SITE_CONFIG)
@@ -17,39 +199,48 @@
   

[PATCH] D44773: [CMake] Use custom command and target to install libc++ headers

[Petr Hosek via Phabricator via cfe-commits]

phosek added a comment.

This changes has already revealed some missing libc++ dependencies in 
sanitizers which were masked by the use of `file(COPY FILE...)`.


Repository:
  rCXX libc++

https://reviews.llvm.org/D44773



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

[libcxx] r328186 - commit temporary workaround for new Clang exception warning

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Thu Mar 22 00:53:47 2018
New Revision: 328186

URL: http://llvm.org/viewvc/llvm-project?rev=328186&view=rev
Log:
commit temporary workaround for new Clang exception warning

Modified:
libcxx/trunk/utils/libcxx/test/config.py

Modified: libcxx/trunk/utils/libcxx/test/config.py
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/utils/libcxx/test/config.py?rev=328186&r1=328185&r2=328186&view=diff
==
--- libcxx/trunk/utils/libcxx/test/config.py (original)
+++ libcxx/trunk/utils/libcxx/test/config.py Thu Mar 22 00:53:47 2018
@@ -918,6 +918,11 @@ class Configuration(object):
 self.cxx.addWarningFlagIfSupported('-Wno-user-defined-literals')
 self.cxx.addWarningFlagIfSupported('-Wno-noexcept-type')
 
self.cxx.addWarningFlagIfSupported('-Wno-aligned-allocation-unavailable')
+# FIXME: Remove this work-around. It is a temporary hack to get the
+# throwing debug tests passing. For example:
+#  * 
test/libcxx/experimental/filesystem/class.path/path.itr/iterator_db.pass.cpp
+#  * test/libcxx/thread/futures/futures.promise/set_exception.pass.cpp
+self.cxx.addWarningFlagIfSupported("-Wno-exceptions")
 # These warnings should be enabled in order to support the MSVC
 # team using the test suite; They enable the warnings below and
 # expect the test suite to be clean.


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

[PATCH] D44765: PR36643 Make clang-format support more generic TMarcos

[Francois Ferrand via Phabricator via cfe-commits]

Typz added a comment.

A generic (or at least extandable) approach to specifying macro behaviors was 
introduced here: https://reviews.llvm.org/D33440

But this change seem to be on hold, as a configuration based on providing 
"macro definitions" seem to be preferable and kind-of in the pipe, though with 
no defined timeline...


Repository:
  rC Clang

https://reviews.llvm.org/D44765



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

Re: r327959 - [ms] Parse #pragma optimize and ignore it behind its own flag

[Hans Wennborg via cfe-commits]

This is a bit confusing, I think. We use -Wignored-pragmas for pragmas
that clang doesn't parse, and also for ignored #pragma intrinsics.

-Wunknown-pragmas isn't used that much, but there is e.g. "pragma STDC
FENV_ACCESS ON is not supported, ignoring pragma". Note that the text
says it's unsupported and ignored, not that it's unknown.

In terms of warning name, -Wignored-pragmas, seems a better fit, so
maybe we should leave it as is.

On Wed, Mar 21, 2018 at 9:56 PM, Hans Wennborg  wrote:
> Not sure either, but I think the ignored warning is used for pragmas
> that clang fails to parse, so maybe unsupported is better.
>
> On Wed, Mar 21, 2018 at 9:33 PM, Nico Weber  wrote:
>> Ah! Hm, maybe that's the better group for this anyway? Not sure.
>>
>> On Wed, Mar 21, 2018, 9:03 PM Hans Wennborg  wrote:
>>>
>>> Aw, rats. I put it under -Wignored-pragmas rather than
>>> -Wunsupported-pragmas, because I was looking at #pragma intrinsic.
>>>
>>> I'll take a look at this again tomorrow.
>>>
>>> On Wed, Mar 21, 2018 at 5:18 PM, Nico Weber via cfe-commits
>>>  wrote:
>>> > From the bot changes, it seems that -Wunknown-pragma doesn't disable
>>> > this
>>> > new warning. Shouldn't it do that?
>>> >
>>> > On Tue, Mar 20, 2018, 9:55 AM Hans Wennborg via cfe-commits
>>> >  wrote:
>>> >>
>>> >> Author: hans
>>> >> Date: Tue Mar 20 01:53:11 2018
>>> >> New Revision: 327959
>>> >>
>>> >> URL: http://llvm.org/viewvc/llvm-project?rev=327959&view=rev
>>> >> Log:
>>> >> [ms] Parse #pragma optimize and ignore it behind its own flag
>>> >>
>>> >> This allows users to turn off warnings about this pragma specifically,
>>> >> while still receiving warnings about other ignored pragmas.
>>> >>
>>> >> Differential Revision: https://reviews.llvm.org/D44630
>>> >>
>>> >> Modified:
>>> >> cfe/trunk/include/clang/Basic/DiagnosticGroups.td
>>> >> cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
>>> >> cfe/trunk/include/clang/Parse/Parser.h
>>> >> cfe/trunk/lib/Parse/ParsePragma.cpp
>>> >> cfe/trunk/test/Preprocessor/pragma_microsoft.c
>>> >>
>>> >> Modified: cfe/trunk/include/clang/Basic/DiagnosticGroups.td
>>> >> URL:
>>> >>
>>> >> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticGroups.td?rev=327959&r1=327958&r2=327959&view=diff
>>> >>
>>> >>
>>> >> ==
>>> >> --- cfe/trunk/include/clang/Basic/DiagnosticGroups.td (original)
>>> >> +++ cfe/trunk/include/clang/Basic/DiagnosticGroups.td Tue Mar 20
>>> >> 01:53:11
>>> >> 2018
>>> >> @@ -515,8 +515,13 @@ def UninitializedStaticSelfInit : DiagGr
>>> >>  def Uninitialized  : DiagGroup<"uninitialized",
>>> >> [UninitializedSometimes,
>>> >>
>>> >> UninitializedStaticSelfInit]>;
>>> >>  def IgnoredPragmaIntrinsic : DiagGroup<"ignored-pragma-intrinsic">;
>>> >> +// #pragma optimize is often used to avoid to work around MSVC codegen
>>> >> bugs or
>>> >> +// to disable inlining. It's not completely clear what alternative to
>>> >> suggest
>>> >> +// (#pragma clang optimize, noinline) so suggest nothing for now.
>>> >> +def IgnoredPragmaOptimize : DiagGroup<"ignored-pragma-optimize">;
>>> >>  def UnknownPragmas : DiagGroup<"unknown-pragmas">;
>>> >> -def IgnoredPragmas : DiagGroup<"ignored-pragmas",
>>> >> [IgnoredPragmaIntrinsic]>;
>>> >> +def IgnoredPragmas : DiagGroup<"ignored-pragmas",
>>> >> +[IgnoredPragmaIntrinsic, IgnoredPragmaOptimize]>;
>>> >>  def PragmaClangAttribute : DiagGroup<"pragma-clang-attribute">;
>>> >>  def PragmaPackSuspiciousInclude :
>>> >> DiagGroup<"pragma-pack-suspicious-include">;
>>> >>  def PragmaPack : DiagGroup<"pragma-pack",
>>> >> [PragmaPackSuspiciousInclude]>;
>>> >>
>>> >> Modified: cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
>>> >> URL:
>>> >>
>>> >> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td?rev=327959&r1=327958&r2=327959&view=diff
>>> >>
>>> >>
>>> >> ==
>>> >> --- cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td (original)
>>> >> +++ cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td Tue Mar 20
>>> >> 01:53:11 2018
>>> >> @@ -895,6 +895,12 @@ def warn_pragma_expected_rparen : Warnin
>>> >>"missing ')' after '#pragma %0' - ignoring">,
>>> >> InGroup;
>>> >>  def warn_pragma_expected_identifier : Warning<
>>> >>"expected identifier in '#pragma %0' - ignored">,
>>> >> InGroup;
>>> >> +def warn_pragma_expected_string : Warning<
>>> >> +  "expected string literal in '#pragma %0' - ignoring">,
>>> >> InGroup;
>>> >> +def warn_pragma_missing_argument : Warning<
>>> >> +  "missing argument to '#pragma %0'%select{|; expected %2}1">,
>>> >> InGroup;
>>> >> +def warn_pragma_invalid_argument : Warning<
>>> >> +  "unexpected argument '%0' to '#pragma %1'%select{|; expected %3}2">,
>>> >> InGroup;
>>> >>
>>> >>  // '#pragma clang section' related errors
>>> >>  def err_pragma_expected_clang_section_

[PATCH] D41458: [libc++][C++17] Elementary string conversions for integral types

[Zhihao Yuan via Phabricator via cfe-commits]

lichray marked 3 inline comments as done.
lichray added inline comments.



Comment at: include/charconv:234
+to_chars(char* __first, char* __last, _Tp __value, int __base)
+-> to_chars_result
+{

mclow.lists wrote:
> Why use the trailing return type here?
> I don't see any advantage - it doesn't depend on the parameters (template or 
> runtime).
> 
> 
Because clang-format doesn't distinguish storage specifiers and 
simple-type-specifiers, and I want to format return types along with function 
signatures rather than letting hanging somewhere.



Comment at: src/support/itoa/itoa.cpp:35
+
+#define APPEND1(i)  \
+do  \

mclow.lists wrote:
> lichray wrote:
> > EricWF wrote:
> > > Any reason these can't be `static` functions? The compiler should 
> > > optimize them away nicely.
> > Although yes, but that's what the author provides.  It's an implementation 
> > file, so it doesn't matter I guess.
> It *does* matter, since we'll have to maintain this.
> 
> It would also be nice if they had meaningful names.
I tried (template + forceinline), and the binary was optimized differently 
(emitted ~100 more instructions).  The author have tuned these really well.  A 
syntax like `buffer = append1(buffer, v)` may work better, I guess, but that 
adds lots of noises.

These macros are not complex.  They just emit a integer of width 1234 to digits.


Repository:
  rCXX libc++

https://reviews.llvm.org/D41458



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

[PATCH] D41458: [libc++][C++17] Elementary string conversions for integral types

[Zhihao Yuan via Phabricator via cfe-commits]

lichray updated this revision to Diff 139422.
lichray added a comment.

Reorganize files


Repository:
  rCXX libc++

https://reviews.llvm.org/D41458

Files:
  .gitignore
  include/charconv
  src/charconv.cpp
  test/std/utilities/charconv/
  test/std/utilities/charconv/charconv.from.chars/
  test/std/utilities/charconv/charconv.from.chars/integral.bool.fail.cpp
  test/std/utilities/charconv/charconv.from.chars/integral.pass.cpp
  test/std/utilities/charconv/charconv.to.chars/
  test/std/utilities/charconv/charconv.to.chars/integral.bool.fail.cpp
  test/std/utilities/charconv/charconv.to.chars/integral.pass.cpp
  test/support/charconv_test_helpers.h

Index: test/support/charconv_test_helpers.h
===
--- /dev/null
+++ test/support/charconv_test_helpers.h
@@ -0,0 +1,233 @@
+//===--===//
+//
+// 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.
+//
+//===--===//
+
+#ifndef SUPPORT_CHARCONV_TEST_HELPERS_H
+#define SUPPORT_CHARCONV_TEST_HELPERS_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "test_macros.h"
+
+using std::false_type;
+using std::true_type;
+
+template 
+constexpr auto
+is_non_narrowing(From a) -> decltype(To{a}, true_type())
+{
+return {};
+}
+
+template 
+constexpr auto
+is_non_narrowing(...) -> false_type
+{
+return {};
+}
+
+template 
+constexpr bool
+_fits_in(T, true_type /* non-narrowing*/, ...)
+{
+return true;
+}
+
+template >
+constexpr bool
+_fits_in(T v, false_type, true_type /* T signed*/, true_type /* X signed */)
+{
+return xl::lowest() <= v && v <= (xl::max)();
+}
+
+template >
+constexpr bool
+_fits_in(T v, false_type, true_type /* T signed */, false_type /* X unsigned*/)
+{
+return 0 <= v && typename std::make_unsigned::type(v) <= (xl::max)();
+}
+
+template >
+constexpr bool
+_fits_in(T v, false_type, false_type /* T unsigned */, ...)
+{
+return v <= typename std::make_unsigned::type((xl::max)());
+}
+
+template 
+constexpr bool
+fits_in(T v)
+{
+return _fits_in(v, is_non_narrowing(v), std::is_signed(),
+   std::is_signed());
+}
+
+template 
+struct to_chars_test_base
+{
+template 
+void test(T v, char const (&expect)[N], Ts... args)
+{
+using std::to_chars;
+std::to_chars_result r;
+
+constexpr size_t len = N - 1;
+static_assert(len > 0, "expected output won't be empty");
+
+if (!fits_in(v))
+return;
+
+r = to_chars(buf, buf + len - 1, X(v), args...);
+assert(r.ptr == buf + len - 1);
+assert(r.ec == std::errc::value_too_large);
+
+r = to_chars(buf, buf + sizeof(buf), X(v), args...);
+assert(r.ptr == buf + len);
+assert(r.ec == std::errc{});
+assert(memcmp(buf, expect, len) == 0);
+}
+
+template 
+void test_value(X v, Ts... args)
+{
+using std::to_chars;
+std::to_chars_result r;
+
+r = to_chars(buf, buf + sizeof(buf), v, args...);
+assert(r.ec == std::errc{});
+*r.ptr = '\0';
+
+auto a = fromchars(buf, r.ptr, args...);
+assert(v == a);
+
+auto ep = r.ptr - 1;
+r = to_chars(buf, ep, v, args...);
+assert(r.ptr == ep);
+assert(r.ec == std::errc::value_too_large);
+}
+
+private:
+using max_t = typename std::conditional::value, long long,
+unsigned long long>::type;
+
+static auto fromchars(char const* p, char const* ep, int base, true_type)
+-> long long
+{
+char* last;
+auto r = strtoll(p, &last, base);
+assert(last == ep);
+
+return r;
+}
+
+static auto fromchars(char const* p, char const* ep, int base, false_type)
+-> unsigned long long
+{
+char* last;
+auto r = strtoull(p, &last, base);
+assert(last == ep);
+
+return r;
+}
+
+static auto fromchars(char const* p, char const* ep, int base = 10) -> max_t
+{
+return fromchars(p, ep, base, std::is_signed());
+}
+
+char buf[100];
+};
+
+template 
+struct roundtrip_test_base
+{
+template 
+void test(T v, Ts... args)
+{
+using std::from_chars;
+using std::to_chars;
+std::from_chars_result r2;
+std::to_chars_result r;
+X x = 0xc;
+
+if (fits_in(v))
+{
+r = to_chars(buf, buf + sizeof(buf), v, args...);
+assert(r.ec == std::errc{});
+
+r2 = from_chars(buf, r.ptr, x, args...);
+assert(r2.ptr == r.ptr);
+assert(x == X(v));
+}
+else
+{
+r = to_chars(buf, buf + sizeof(buf), v, args...);
+

[PATCH] D44774: [Driver] Allow use of -fsyntax-only together with -MJ

[David Stenberg via Phabricator via cfe-commits]

dstenb created this revision.
dstenb added reviewers: joerg, klimek, rsmith.
Herald added a subscriber: cfe-commits.

When using -MJ together with -fsyntax-only, clang would hit an assert in
DumpCompilationDatabase() when trying to get the filename for the output
field. This patch fixes that by amending DumpCompilationDatabase() so
that it accepts the `nothing' output class, and it will in that case
simply omit the output field.

The JSON Compilation Database Format Specification specifies that the
output field is optional.


Repository:
  rC Clang

https://reviews.llvm.org/D44774

Files:
  lib/Driver/ToolChains/Clang.cpp
  test/Driver/compilation_database.c


Index: test/Driver/compilation_database.c
===
--- test/Driver/compilation_database.c
+++ test/Driver/compilation_database.c
@@ -1,10 +1,12 @@
 // RUN: mkdir -p %t && cd %t
 // RUN: %clang -MD -MP --sysroot=somewhere -c -x c %s -xc++ %s -Wall -MJ - 
-no-canonical-prefixes 2>&1 | FileCheck %s
 // RUN: not %clang -c -x c %s -MJ %s/non-existant -no-canonical-prefixes 2>&1 
| FileCheck --check-prefix=ERROR %s
+// RUN: %clang %s --sysroot=somewhere -MJ - -fsyntax-only 
-no-canonical-prefixes 2>&1 | FileCheck --check-prefix=FSYNTAX-ONLY %s
 
 // CHECK: { "directory": "{{.*}}",  "file": 
"[[SRC:[^"]+[/|\\]compilation_database.c]]", "output": 
"compilation_database.o", "arguments": ["{{[^"]*}}clang{{[^"]*}}", "-xc", 
"[[SRC]]", "--sysroot=somewhere", "-c", "-Wall",{{.*}} "--target={{[^"]+}}"]},
 // CHECK: { "directory": "{{.*}}",  "file": 
"[[SRC:[^"]+[/|\\]compilation_database.c]]", "output": 
"compilation_database.o", "arguments": ["{{[^"]*}}clang{{[^"]*}}", "-xc++", 
"[[SRC]]", "--sysroot=somewhere", "-c", "-Wall",{{.*}} "--target={{[^"]+}}"]},
 // ERROR: error: compilation database '{{.*}}/non-existant' could not be 
opened:
+// FSYNTAX-ONLY: { "directory": "{{.*}}",  "file": 
"[[SRC:[^"]+[/|\\]compilation_database.c]]", "arguments": 
["{{[^"]*}}clang{{[^"]*}}", "-xc", "[[SRC]]", "--sysroot=somewhere", {{.*}} 
"--target={{[^"]+}}"]},
 
 int main(void) {
   return 0;
Index: lib/Driver/ToolChains/Clang.cpp
===
--- lib/Driver/ToolChains/Clang.cpp
+++ lib/Driver/ToolChains/Clang.cpp
@@ -1856,7 +1856,8 @@
 Buf = ".";
   CDB << "{ \"directory\": \"" << escape(Buf) << "\"";
   CDB << ", \"file\": \"" << escape(Input.getFilename()) << "\"";
-  CDB << ", \"output\": \"" << escape(Output.getFilename()) << "\"";
+  if (!Output.isNothing())
+CDB << ", \"output\": \"" << escape(Output.getFilename()) << "\"";
   CDB << ", \"arguments\": [\"" << escape(D.ClangExecutable) << "\"";
   Buf = "-x";
   Buf += types::getTypeName(Input.getType());


Index: test/Driver/compilation_database.c
===
--- test/Driver/compilation_database.c
+++ test/Driver/compilation_database.c
@@ -1,10 +1,12 @@
 // RUN: mkdir -p %t && cd %t
 // RUN: %clang -MD -MP --sysroot=somewhere -c -x c %s -xc++ %s -Wall -MJ - -no-canonical-prefixes 2>&1 | FileCheck %s
 // RUN: not %clang -c -x c %s -MJ %s/non-existant -no-canonical-prefixes 2>&1 | FileCheck --check-prefix=ERROR %s
+// RUN: %clang %s --sysroot=somewhere -MJ - -fsyntax-only -no-canonical-prefixes 2>&1 | FileCheck --check-prefix=FSYNTAX-ONLY %s
 
 // CHECK: { "directory": "{{.*}}",  "file": "[[SRC:[^"]+[/|\\]compilation_database.c]]", "output": "compilation_database.o", "arguments": ["{{[^"]*}}clang{{[^"]*}}", "-xc", "[[SRC]]", "--sysroot=somewhere", "-c", "-Wall",{{.*}} "--target={{[^"]+}}"]},
 // CHECK: { "directory": "{{.*}}",  "file": "[[SRC:[^"]+[/|\\]compilation_database.c]]", "output": "compilation_database.o", "arguments": ["{{[^"]*}}clang{{[^"]*}}", "-xc++", "[[SRC]]", "--sysroot=somewhere", "-c", "-Wall",{{.*}} "--target={{[^"]+}}"]},
 // ERROR: error: compilation database '{{.*}}/non-existant' could not be opened:
+// FSYNTAX-ONLY: { "directory": "{{.*}}",  "file": "[[SRC:[^"]+[/|\\]compilation_database.c]]", "arguments": ["{{[^"]*}}clang{{[^"]*}}", "-xc", "[[SRC]]", "--sysroot=somewhere", {{.*}} "--target={{[^"]+}}"]},
 
 int main(void) {
   return 0;
Index: lib/Driver/ToolChains/Clang.cpp
===
--- lib/Driver/ToolChains/Clang.cpp
+++ lib/Driver/ToolChains/Clang.cpp
@@ -1856,7 +1856,8 @@
 Buf = ".";
   CDB << "{ \"directory\": \"" << escape(Buf) << "\"";
   CDB << ", \"file\": \"" << escape(Input.getFilename()) << "\"";
-  CDB << ", \"output\": \"" << escape(Output.getFilename()) << "\"";
+  if (!Output.isNothing())
+CDB << ", \"output\": \"" << escape(Output.getFilename()) << "\"";
   CDB << ", \"arguments\": [\"" << escape(D.ClangExecutable) << "\"";
   Buf = "-x";
   Buf += types::getTypeName(Input.getType());
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D44189: [RISCV] Verify the input value of -march=

[Alex Bradbury via Phabricator via cfe-commits]

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

Thanks for this Kito. A tiny formatting nit, but otherwise this looks good to 
me.




Comment at: lib/Driver/ToolChains/Arch/RISCV.cpp:70
+  while (StdExtsItr != StdExts.end() && *StdExtsItr != c)
+ ++StdExtsItr;
+

Indent should be 2 spaces rather than 3.


Repository:
  rC Clang

https://reviews.llvm.org/D44189



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

[PATCH] D43821: [SemaCXX] _Pragma("clang optimize off") not affecting lambda.

[Carlos Alberto Enciso via Phabricator via cfe-commits]

CarlosAlbertoEnciso added a comment.

Ping.

Thanks


Repository:
  rC Clang

https://reviews.llvm.org/D43821



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

[PATCH] D44602: [clang-tidy] readability-function-size: add VariableThreshold param.

[Jonas Toth via Phabricator via cfe-commits]

JonasToth added inline comments.



Comment at: test/clang-tidy/readability-function-size.cpp:207-212
+void variables_8() {
+  int a, b;
+  struct A {
+A(int c, int d);
+  };
+}

lebedev.ri wrote:
> aaron.ballman wrote:
> > lebedev.ri wrote:
> > > aaron.ballman wrote:
> > > > lebedev.ri wrote:
> > > > > aaron.ballman wrote:
> > > > > > lebedev.ri wrote:
> > > > > > > aaron.ballman wrote:
> > > > > > > > I think the current behavior here is correct and the previous 
> > > > > > > > behavior was incorrect. However, it brings up an interesting 
> > > > > > > > question about what to do here:
> > > > > > > > ```
> > > > > > > > void f() {
> > > > > > > >   struct S {
> > > > > > > > void bar() {
> > > > > > > >   int a, b;
> > > > > > > > }
> > > > > > > >   };
> > > > > > > > }
> > > > > > > > ```
> > > > > > > > Does `f()` contain zero variables or two? I would contend that 
> > > > > > > > it has no variables because S::bar() is a different scope than 
> > > > > > > > f(). But I can see a case being made about the complexity of 
> > > > > > > > f() being increased by the presence of the local class 
> > > > > > > > definition. Perhaps this is a different facet of the test about 
> > > > > > > > number of types?
> > > > > > > As previously briefly discussed in IRC, i **strongly** believe 
> > > > > > > that the current behavior is correct, and 
> > > > > > > `readability-function-size`
> > > > > > > should analyze/diagnose the function as a whole, including all 
> > > > > > > sub-classes/sub-functions.
> > > > > > Do you know of any coding standards related to this check that 
> > > > > > weigh in on this?
> > > > > > 
> > > > > > What do you think about this:
> > > > > > ```
> > > > > > #define SWAP(x, y) ({__typeof__(x) temp = x; x = y; y = x;})
> > > > > > 
> > > > > > void f() {
> > > > > >   int a = 10, b = 12;
> > > > > >   SWAP(a, b);
> > > > > > }
> > > > > > ```
> > > > > > Does f() have two variables or three? Should presence of the `SWAP` 
> > > > > > macro cause this code to be more complex due to having too many 
> > > > > > variables?
> > > > > Datapoint: the doc 
> > > > > (`docs/clang-tidy/checks/readability-function-size.rst`) actually 
> > > > > already states that macros *are* counted.
> > > > > 
> > > > > ```
> > > > > .. option:: StatementThreshold
> > > > > 
> > > > >Flag functions exceeding this number of statements. This may differ
> > > > >significantly from the number of lines for macro-heavy code. The 
> > > > > default is
> > > > >`800`.
> > > > > ```
> > > > > ```
> > > > > .. option:: NestingThreshold
> > > > > 
> > > > > Flag compound statements which create next nesting level after
> > > > > `NestingThreshold`. This may differ significantly from the 
> > > > > expected value
> > > > > for macro-heavy code. The default is `-1` (ignore the nesting 
> > > > > level).
> > > > > ```
> > > > My concerns relate to what's considered a "variable declared in the 
> > > > body" (per the documentation) in relation to function complexity. To 
> > > > me, if the variable is not accessible lexically within the body of the 
> > > > function, it's not adding to the function's complexity *for local 
> > > > variables*. It may certainly be adding other complexity, of course.
> > > > 
> > > > I would have a very hard time explaining to a user that variables they 
> > > > cannot see or change (assuming the macro is in a header file out of 
> > > > their control) contribute to their function's complexity. Similarly, I 
> > > > would have difficulty explaining that variables in an locally declared 
> > > > class member function contribute to the number of variables in the 
> > > > outer function body, but the class data members somehow do not.
> > > > 
> > > > (per the documentation) 
> > > 
> > > Please note that the word `complexity` is not used in the 
> > > **documentation**, only `size` is.
> > > 
> > > There also is the other side of the coin:
> > > 
> > > ```
> > > #define simple_macro_please_ignore \
> > >   the; \
> > >   actual; \
> > >   content; \
> > >   of; \
> > >   the; \
> > >   foo();
> > > 
> > > // Very simple function, nothing to see.
> > > void foo() {
> > >   simple_macro_please_ignore();
> > > }
> > > 
> > > #undef simple_macro_please_ignore
> > > ```
> > > 
> > > In other words, if we ignore macros, it would be possible to abuse them 
> > > to artificially reduce complexity, by hiding it in the macros.
> > > I agree that it's total abuse of macros, but macros are in general not 
> > > nice, and it would not be good to give such things a pass.
> > > 
> > > 
> > > > My concerns relate to what's considered a "variable declared in the 
> > > > body" (per the documentation) in relation to function complexity.
> > > 
> > > Could you please clarify, at this point, your concerns are only about 
> > > this new part of the check (variables), or for the entire check?
> > > In other words, if we ignore macros, it wo

[PATCH] D44602: [clang-tidy] readability-function-size: add VariableThreshold param.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: test/clang-tidy/readability-function-size.cpp:207-212
+void variables_8() {
+  int a, b;
+  struct A {
+A(int c, int d);
+  };
+}

JonasToth wrote:
> lebedev.ri wrote:
> > aaron.ballman wrote:
> > > lebedev.ri wrote:
> > > > aaron.ballman wrote:
> > > > > lebedev.ri wrote:
> > > > > > aaron.ballman wrote:
> > > > > > > lebedev.ri wrote:
> > > > > > > > aaron.ballman wrote:
> > > > > > > > > I think the current behavior here is correct and the previous 
> > > > > > > > > behavior was incorrect. However, it brings up an interesting 
> > > > > > > > > question about what to do here:
> > > > > > > > > ```
> > > > > > > > > void f() {
> > > > > > > > >   struct S {
> > > > > > > > > void bar() {
> > > > > > > > >   int a, b;
> > > > > > > > > }
> > > > > > > > >   };
> > > > > > > > > }
> > > > > > > > > ```
> > > > > > > > > Does `f()` contain zero variables or two? I would contend 
> > > > > > > > > that it has no variables because S::bar() is a different 
> > > > > > > > > scope than f(). But I can see a case being made about the 
> > > > > > > > > complexity of f() being increased by the presence of the 
> > > > > > > > > local class definition. Perhaps this is a different facet of 
> > > > > > > > > the test about number of types?
> > > > > > > > As previously briefly discussed in IRC, i **strongly** believe 
> > > > > > > > that the current behavior is correct, and 
> > > > > > > > `readability-function-size`
> > > > > > > > should analyze/diagnose the function as a whole, including all 
> > > > > > > > sub-classes/sub-functions.
> > > > > > > Do you know of any coding standards related to this check that 
> > > > > > > weigh in on this?
> > > > > > > 
> > > > > > > What do you think about this:
> > > > > > > ```
> > > > > > > #define SWAP(x, y) ({__typeof__(x) temp = x; x = y; y = x;})
> > > > > > > 
> > > > > > > void f() {
> > > > > > >   int a = 10, b = 12;
> > > > > > >   SWAP(a, b);
> > > > > > > }
> > > > > > > ```
> > > > > > > Does f() have two variables or three? Should presence of the 
> > > > > > > `SWAP` macro cause this code to be more complex due to having too 
> > > > > > > many variables?
> > > > > > Datapoint: the doc 
> > > > > > (`docs/clang-tidy/checks/readability-function-size.rst`) actually 
> > > > > > already states that macros *are* counted.
> > > > > > 
> > > > > > ```
> > > > > > .. option:: StatementThreshold
> > > > > > 
> > > > > >Flag functions exceeding this number of statements. This may 
> > > > > > differ
> > > > > >significantly from the number of lines for macro-heavy code. The 
> > > > > > default is
> > > > > >`800`.
> > > > > > ```
> > > > > > ```
> > > > > > .. option:: NestingThreshold
> > > > > > 
> > > > > > Flag compound statements which create next nesting level after
> > > > > > `NestingThreshold`. This may differ significantly from the 
> > > > > > expected value
> > > > > > for macro-heavy code. The default is `-1` (ignore the nesting 
> > > > > > level).
> > > > > > ```
> > > > > My concerns relate to what's considered a "variable declared in the 
> > > > > body" (per the documentation) in relation to function complexity. To 
> > > > > me, if the variable is not accessible lexically within the body of 
> > > > > the function, it's not adding to the function's complexity *for local 
> > > > > variables*. It may certainly be adding other complexity, of course.
> > > > > 
> > > > > I would have a very hard time explaining to a user that variables 
> > > > > they cannot see or change (assuming the macro is in a header file out 
> > > > > of their control) contribute to their function's complexity. 
> > > > > Similarly, I would have difficulty explaining that variables in an 
> > > > > locally declared class member function contribute to the number of 
> > > > > variables in the outer function body, but the class data members 
> > > > > somehow do not.
> > > > > 
> > > > > (per the documentation) 
> > > > 
> > > > Please note that the word `complexity` is not used in the 
> > > > **documentation**, only `size` is.
> > > > 
> > > > There also is the other side of the coin:
> > > > 
> > > > ```
> > > > #define simple_macro_please_ignore \
> > > >   the; \
> > > >   actual; \
> > > >   content; \
> > > >   of; \
> > > >   the; \
> > > >   foo();
> > > > 
> > > > // Very simple function, nothing to see.
> > > > void foo() {
> > > >   simple_macro_please_ignore();
> > > > }
> > > > 
> > > > #undef simple_macro_please_ignore
> > > > ```
> > > > 
> > > > In other words, if we ignore macros, it would be possible to abuse them 
> > > > to artificially reduce complexity, by hiding it in the macros.
> > > > I agree that it's total abuse of macros, but macros are in general not 
> > > > nice, and it would not be good to give such things a pass.
> > > > 
> > > > 
> > > > > My concerns relate to what's considered a "variable declared in the 
> > > > > 

[PATCH] D44602: [clang-tidy] readability-function-size: add VariableThreshold param.

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added inline comments.



Comment at: test/clang-tidy/readability-function-size.cpp:207-212
+void variables_8() {
+  int a, b;
+  struct A {
+A(int c, int d);
+  };
+}

aaron.ballman wrote:
> JonasToth wrote:
> > lebedev.ri wrote:
> > > aaron.ballman wrote:
> > > > lebedev.ri wrote:
> > > > > aaron.ballman wrote:
> > > > > > lebedev.ri wrote:
> > > > > > > aaron.ballman wrote:
> > > > > > > > lebedev.ri wrote:
> > > > > > > > > aaron.ballman wrote:
> > > > > > > > > > I think the current behavior here is correct and the 
> > > > > > > > > > previous behavior was incorrect. However, it brings up an 
> > > > > > > > > > interesting question about what to do here:
> > > > > > > > > > ```
> > > > > > > > > > void f() {
> > > > > > > > > >   struct S {
> > > > > > > > > > void bar() {
> > > > > > > > > >   int a, b;
> > > > > > > > > > }
> > > > > > > > > >   };
> > > > > > > > > > }
> > > > > > > > > > ```
> > > > > > > > > > Does `f()` contain zero variables or two? I would contend 
> > > > > > > > > > that it has no variables because S::bar() is a different 
> > > > > > > > > > scope than f(). But I can see a case being made about the 
> > > > > > > > > > complexity of f() being increased by the presence of the 
> > > > > > > > > > local class definition. Perhaps this is a different facet 
> > > > > > > > > > of the test about number of types?
> > > > > > > > > As previously briefly discussed in IRC, i **strongly** 
> > > > > > > > > believe that the current behavior is correct, and 
> > > > > > > > > `readability-function-size`
> > > > > > > > > should analyze/diagnose the function as a whole, including 
> > > > > > > > > all sub-classes/sub-functions.
> > > > > > > > Do you know of any coding standards related to this check that 
> > > > > > > > weigh in on this?
> > > > > > > > 
> > > > > > > > What do you think about this:
> > > > > > > > ```
> > > > > > > > #define SWAP(x, y) ({__typeof__(x) temp = x; x = y; y = x;})
> > > > > > > > 
> > > > > > > > void f() {
> > > > > > > >   int a = 10, b = 12;
> > > > > > > >   SWAP(a, b);
> > > > > > > > }
> > > > > > > > ```
> > > > > > > > Does f() have two variables or three? Should presence of the 
> > > > > > > > `SWAP` macro cause this code to be more complex due to having 
> > > > > > > > too many variables?
> > > > > > > Datapoint: the doc 
> > > > > > > (`docs/clang-tidy/checks/readability-function-size.rst`) actually 
> > > > > > > already states that macros *are* counted.
> > > > > > > 
> > > > > > > ```
> > > > > > > .. option:: StatementThreshold
> > > > > > > 
> > > > > > >Flag functions exceeding this number of statements. This may 
> > > > > > > differ
> > > > > > >significantly from the number of lines for macro-heavy code. 
> > > > > > > The default is
> > > > > > >`800`.
> > > > > > > ```
> > > > > > > ```
> > > > > > > .. option:: NestingThreshold
> > > > > > > 
> > > > > > > Flag compound statements which create next nesting level after
> > > > > > > `NestingThreshold`. This may differ significantly from the 
> > > > > > > expected value
> > > > > > > for macro-heavy code. The default is `-1` (ignore the nesting 
> > > > > > > level).
> > > > > > > ```
> > > > > > My concerns relate to what's considered a "variable declared in the 
> > > > > > body" (per the documentation) in relation to function complexity. 
> > > > > > To me, if the variable is not accessible lexically within the body 
> > > > > > of the function, it's not adding to the function's complexity *for 
> > > > > > local variables*. It may certainly be adding other complexity, of 
> > > > > > course.
> > > > > > 
> > > > > > I would have a very hard time explaining to a user that variables 
> > > > > > they cannot see or change (assuming the macro is in a header file 
> > > > > > out of their control) contribute to their function's complexity. 
> > > > > > Similarly, I would have difficulty explaining that variables in an 
> > > > > > locally declared class member function contribute to the number of 
> > > > > > variables in the outer function body, but the class data members 
> > > > > > somehow do not.
> > > > > > 
> > > > > > (per the documentation) 
> > > > > 
> > > > > Please note that the word `complexity` is not used in the 
> > > > > **documentation**, only `size` is.
> > > > > 
> > > > > There also is the other side of the coin:
> > > > > 
> > > > > ```
> > > > > #define simple_macro_please_ignore \
> > > > >   the; \
> > > > >   actual; \
> > > > >   content; \
> > > > >   of; \
> > > > >   the; \
> > > > >   foo();
> > > > > 
> > > > > // Very simple function, nothing to see.
> > > > > void foo() {
> > > > >   simple_macro_please_ignore();
> > > > > }
> > > > > 
> > > > > #undef simple_macro_please_ignore
> > > > > ```
> > > > > 
> > > > > In other words, if we ignore macros, it would be possible to abuse 
> > > > > them to artificially reduce complexity, by hiding it in the macros.
> > >

[PATCH] D44727: [RISCV] Implement getTargetDefines, handleTargetFeatures and hasFeature for RISCVTargetInfo

[Alex Bradbury via Phabricator via cfe-commits]

asb added subscribers: doug.gregor, rsmith.
asb added a comment.

Thanks Kito. I've added some comments inline.

Nitpicking: the patch description would be more accurate to say it "extends 
getTargetDefines", as obviously an initial implementation was already present




Comment at: lib/Basic/Targets/RISCV.cpp:62-65
+  // TODO: Define __riscv_flen, __riscv_fdiv and __riscv_fsqrt after
+  // F and D code gen upstream.
+
+  // TODO: Define __riscv_atomic after A code gen upstream.

I'd go ahead and define these. At this point, Clang has already accepted a/f/d 
in the march string, and even in the case where codegen isn't yet implemented, 
MC layer support will be enabled allowing usage in inline assembly. Plus by 
doing it now it means we won't forget to come back to this and add those 
defines later!



Comment at: lib/Basic/Targets/RISCV.cpp:68
+
+bool RISCVTargetInfo::hasFeature(StringRef Feature) const {
+  return llvm::StringSwitch(Feature)

It seems a number of other targets also return true for the archname, e.g. 
"riscv".

Is it the case that hasFeature should always support at least everything 
detected by handleTargetFeatures? If so, a comment to document this would be 
helpful.

I can see this method was introduced in rC149227 and is primarily motivated by 
module requirements.

@doug.gregor / @rsmith : could you please advise on the implementation and 
testing of this function? Which features should be hasFeature check for? I note 
that e.g. lib/Basic/Targets/ARM.cpp only supports a subset of the features in 
hasFeature compared to handleTargetFeatures.



Comment at: lib/Basic/Targets/RISCV.cpp:78
+
+/// handleTargetFeatures - Perform initialization based on the user
+/// configured set of features.

Nit: current guidance is not to duplicate the method name in the comment 
https://llvm.org/docs/CodingStandards.html#doxygen-use-in-documentation-comments
 (i.e. you should just comment `Perform initialization based on the user 
configured set of features.`



Comment at: lib/Basic/Targets/RISCV.cpp:83
+  for (const auto &Feature : Features) {
+if (Feature == "+m") {
+  HasM = true;

You could get away without the brackets for these if/else if.


Repository:
  rC Clang

https://reviews.llvm.org/D44727



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

[PATCH] D34260: [StaticAnalyzer] Completely unrolling specific loops with known bound option

[Henry Wong via Phabricator via cfe-commits]

MTC added inline comments.
Herald added subscribers: dkrupp, rnkovacs.
Herald added a reviewer: george.karpenkov.



Comment at: lib/StaticAnalyzer/Core/LoopUnrolling.cpp:107
+  equalsBoundNode("initVarName"),
+  hasRHS(integerLiteral(),
+ // Incrementation should be a simple increment or decrement

Hi Peter, sorry to bother you! 

I have some confusion here. Whether `hasRHS(integerLiteral())` needs to added 
with `ignoringParenImpCasts`? 

The given code below does not unroll the loop because `i = 0;` has a 
`ImplicitCastExpr` for `0`. But if I change `unsigned i = 0` to `int i = 0`, 
loop unrolling will happen. So I don't know if this is intentional. 
```
int func() {
  int sum = 0;
  unsigned i;
  for (i = 0; i < 10; ++i) {
sum++;
  }
  return sum;
}
```

Hope you can help me, thank you!


https://reviews.llvm.org/D34260



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

[PATCH] D44602: [clang-tidy] readability-function-size: add VariableThreshold param.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: test/clang-tidy/readability-function-size.cpp:207-212
+void variables_8() {
+  int a, b;
+  struct A {
+A(int c, int d);
+  };
+}

lebedev.ri wrote:
> aaron.ballman wrote:
> > JonasToth wrote:
> > > lebedev.ri wrote:
> > > > aaron.ballman wrote:
> > > > > lebedev.ri wrote:
> > > > > > aaron.ballman wrote:
> > > > > > > lebedev.ri wrote:
> > > > > > > > aaron.ballman wrote:
> > > > > > > > > lebedev.ri wrote:
> > > > > > > > > > aaron.ballman wrote:
> > > > > > > > > > > I think the current behavior here is correct and the 
> > > > > > > > > > > previous behavior was incorrect. However, it brings up an 
> > > > > > > > > > > interesting question about what to do here:
> > > > > > > > > > > ```
> > > > > > > > > > > void f() {
> > > > > > > > > > >   struct S {
> > > > > > > > > > > void bar() {
> > > > > > > > > > >   int a, b;
> > > > > > > > > > > }
> > > > > > > > > > >   };
> > > > > > > > > > > }
> > > > > > > > > > > ```
> > > > > > > > > > > Does `f()` contain zero variables or two? I would contend 
> > > > > > > > > > > that it has no variables because S::bar() is a different 
> > > > > > > > > > > scope than f(). But I can see a case being made about the 
> > > > > > > > > > > complexity of f() being increased by the presence of the 
> > > > > > > > > > > local class definition. Perhaps this is a different facet 
> > > > > > > > > > > of the test about number of types?
> > > > > > > > > > As previously briefly discussed in IRC, i **strongly** 
> > > > > > > > > > believe that the current behavior is correct, and 
> > > > > > > > > > `readability-function-size`
> > > > > > > > > > should analyze/diagnose the function as a whole, including 
> > > > > > > > > > all sub-classes/sub-functions.
> > > > > > > > > Do you know of any coding standards related to this check 
> > > > > > > > > that weigh in on this?
> > > > > > > > > 
> > > > > > > > > What do you think about this:
> > > > > > > > > ```
> > > > > > > > > #define SWAP(x, y) ({__typeof__(x) temp = x; x = y; y = x;})
> > > > > > > > > 
> > > > > > > > > void f() {
> > > > > > > > >   int a = 10, b = 12;
> > > > > > > > >   SWAP(a, b);
> > > > > > > > > }
> > > > > > > > > ```
> > > > > > > > > Does f() have two variables or three? Should presence of the 
> > > > > > > > > `SWAP` macro cause this code to be more complex due to having 
> > > > > > > > > too many variables?
> > > > > > > > Datapoint: the doc 
> > > > > > > > (`docs/clang-tidy/checks/readability-function-size.rst`) 
> > > > > > > > actually already states that macros *are* counted.
> > > > > > > > 
> > > > > > > > ```
> > > > > > > > .. option:: StatementThreshold
> > > > > > > > 
> > > > > > > >Flag functions exceeding this number of statements. This may 
> > > > > > > > differ
> > > > > > > >significantly from the number of lines for macro-heavy code. 
> > > > > > > > The default is
> > > > > > > >`800`.
> > > > > > > > ```
> > > > > > > > ```
> > > > > > > > .. option:: NestingThreshold
> > > > > > > > 
> > > > > > > > Flag compound statements which create next nesting level 
> > > > > > > > after
> > > > > > > > `NestingThreshold`. This may differ significantly from the 
> > > > > > > > expected value
> > > > > > > > for macro-heavy code. The default is `-1` (ignore the 
> > > > > > > > nesting level).
> > > > > > > > ```
> > > > > > > My concerns relate to what's considered a "variable declared in 
> > > > > > > the body" (per the documentation) in relation to function 
> > > > > > > complexity. To me, if the variable is not accessible lexically 
> > > > > > > within the body of the function, it's not adding to the 
> > > > > > > function's complexity *for local variables*. It may certainly be 
> > > > > > > adding other complexity, of course.
> > > > > > > 
> > > > > > > I would have a very hard time explaining to a user that variables 
> > > > > > > they cannot see or change (assuming the macro is in a header file 
> > > > > > > out of their control) contribute to their function's complexity. 
> > > > > > > Similarly, I would have difficulty explaining that variables in 
> > > > > > > an locally declared class member function contribute to the 
> > > > > > > number of variables in the outer function body, but the class 
> > > > > > > data members somehow do not.
> > > > > > > 
> > > > > > > (per the documentation) 
> > > > > > 
> > > > > > Please note that the word `complexity` is not used in the 
> > > > > > **documentation**, only `size` is.
> > > > > > 
> > > > > > There also is the other side of the coin:
> > > > > > 
> > > > > > ```
> > > > > > #define simple_macro_please_ignore \
> > > > > >   the; \
> > > > > >   actual; \
> > > > > >   content; \
> > > > > >   of; \
> > > > > >   the; \
> > > > > >   foo();
> > > > > > 
> > > > > > // Very simple function, nothing to see.
> > > > > > void foo() {
> > > > > >   simple_macro_please_ignore();
> > > >

[PATCH] D44778: [clang-format] Wildcard expansion on Windows.

[Alexander Kornienko via Phabricator via cfe-commits]

alexfh created this revision.
alexfh added reviewers: klimek, djasper.
Herald added a subscriber: mgorny.

Add support for wildcard expansion in command line arguments on Windows.
See https://docs.microsoft.com/en-us/cpp/c-language/expanding-wildcard-arguments

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


Repository:
  rC Clang

https://reviews.llvm.org/D44778

Files:
  tools/clang-format/CMakeLists.txt


Index: tools/clang-format/CMakeLists.txt
===
--- tools/clang-format/CMakeLists.txt
+++ tools/clang-format/CMakeLists.txt
@@ -4,6 +4,14 @@
   ClangFormat.cpp
   )
 
+if( PURE_WINDOWS )
+  # Add support for wildcard expansion in command-line arguments on Windows.
+  # See
+  # 
https://docs.microsoft.com/en-us/cpp/c-language/expanding-wildcard-arguments
+  set_property(TARGET clang-format APPEND_STRING PROPERTY
+LINK_FLAGS " setargv.obj")
+endif()
+
 set(CLANG_FORMAT_LIB_DEPS
   clangBasic
   clangFormat


Index: tools/clang-format/CMakeLists.txt
===
--- tools/clang-format/CMakeLists.txt
+++ tools/clang-format/CMakeLists.txt
@@ -4,6 +4,14 @@
   ClangFormat.cpp
   )
 
+if( PURE_WINDOWS )
+  # Add support for wildcard expansion in command-line arguments on Windows.
+  # See
+  # https://docs.microsoft.com/en-us/cpp/c-language/expanding-wildcard-arguments
+  set_property(TARGET clang-format APPEND_STRING PROPERTY
+LINK_FLAGS " setargv.obj")
+endif()
+
 set(CLANG_FORMAT_LIB_DEPS
   clangBasic
   clangFormat
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D44764: [clangd] Move GTest printers to separate file

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov accepted this revision.
ilya-biryukov added a comment.
This revision is now accepted and ready to land.

LGTM.
I wonder if there's a mechanism to always include the printers when including 
`gtest.h`, but having a convention to always include them seems ok for now.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D44764



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

[PATCH] D44272: [clangd] Support incremental document syncing

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added a comment.

Thanks for addressing the comments. I have just one comment left, about the LSP 
versions and sanity-checking.




Comment at: clangd/DraftStore.h:36
   /// Replace contents of the draft for \p File with \p Contents.
-  void updateDraft(PathRef File, StringRef Contents);
+  void addDraft(PathRef File, StringRef Contents);
+

ilya-biryukov wrote:
> simark wrote:
> > ilya-biryukov wrote:
> > > Could we add versions from LSP's `VersionedTextDocumentIdentifier` here 
> > > and make the relevant sanity checks?
> > > Applying diffs to the wrong version will cause everything to fall apart, 
> > > so we should detect this error and signal it to the client as soon as 
> > > possible.
> > I agree that applying diffs to the wrong version will break basically 
> > everything, but even if we detect a version mismatch, I don't see what we 
> > could do, since we don't have a mean to report the error to the client.  
> > The only thing we could do is log it (which we already do.
> If we couldn't apply a diff, we should return errors from all future 
> operations on this file until it gets closed and reopened. Otherwise clangd 
> and the editor would see inconsistent contents for the file and results 
> provided by clangd would be unreliable.
> The errors from any actions on the invalid file would actually be visible to 
> the users.
> 
> The simplest way to achieve that is to remove the file from `DraftStore` and 
> `ClangdServer` on errors from `updateDraft`.
> This will give "calling action on non-tracked file" errors for future 
> operations and the actual root cause can be figured out from the logs.
We still ignore version numbers from the LSP.
Is this another change that didn't get in?


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D44272



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

[PATCH] D43821: [SemaCXX] _Pragma("clang optimize off") not affecting lambda.

[Carlos Alberto Enciso via Phabricator via cfe-commits]

CarlosAlbertoEnciso added a comment.

Thanks @erichkeane for your review.


Repository:
  rC Clang

https://reviews.llvm.org/D43821



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

[PATCH] D44749: [OpenMP][Clang] Add call to global data sharing stack initialization on the workers side

[Alexey Bataev via Phabricator via cfe-commits]

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

LG


Repository:
  rC Clang

https://reviews.llvm.org/D44749



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

r328196 - [CodeGen] Emit DWARF "constructor" calling convention

[Jonas Devlieghere via cfe-commits]

Author: jdevlieghere
Date: Thu Mar 22 06:53:30 2018
New Revision: 328196

URL: http://llvm.org/viewvc/llvm-project?rev=328196&view=rev
Log:
[CodeGen] Emit DWARF "constructor" calling convention

Now that LLVM has support for emitting calling conventions in DWARF (see
r328191) have clang emit them.

Patch by: Adrien Guinet

Differential revision: https://reviews.llvm.org/D42351

Added:
cfe/trunk/test/CodeGen/debug-info-cc.c
Modified:
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=328196&r1=328195&r2=328196&view=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Thu Mar 22 06:53:30 2018
@@ -1000,20 +1000,28 @@ static unsigned getDwarfCC(CallingConv C
 return llvm::dwarf::DW_CC_LLVM_vectorcall;
   case CC_X86Pascal:
 return llvm::dwarf::DW_CC_BORLAND_pascal;
-
-  // FIXME: Create new DW_CC_ codes for these calling conventions.
   case CC_Win64:
+return llvm::dwarf::DW_CC_LLVM_Win64;
   case CC_X86_64SysV:
+return llvm::dwarf::DW_CC_LLVM_X86_64SysV;
   case CC_AAPCS:
+return llvm::dwarf::DW_CC_LLVM_AAPCS;
   case CC_AAPCS_VFP:
+return llvm::dwarf::DW_CC_LLVM_AAPCS_VFP;
   case CC_IntelOclBicc:
+return llvm::dwarf::DW_CC_LLVM_IntelOclBicc;
   case CC_SpirFunction:
+return llvm::dwarf::DW_CC_LLVM_SpirFunction;
   case CC_OpenCLKernel:
+return llvm::dwarf::DW_CC_LLVM_OpenCLKernel;
   case CC_Swift:
+return llvm::dwarf::DW_CC_LLVM_Swift;
   case CC_PreserveMost:
+return llvm::dwarf::DW_CC_LLVM_PreserveMost;
   case CC_PreserveAll:
+return llvm::dwarf::DW_CC_LLVM_PreserveAll;
   case CC_X86RegCall:
-return 0;
+return llvm::dwarf::DW_CC_LLVM_X86RegCall;
   }
   return 0;
 }

Added: cfe/trunk/test/CodeGen/debug-info-cc.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/debug-info-cc.c?rev=328196&view=auto
==
--- cfe/trunk/test/CodeGen/debug-info-cc.c (added)
+++ cfe/trunk/test/CodeGen/debug-info-cc.c Thu Mar 22 06:53:30 2018
@@ -0,0 +1,120 @@
+// RUN: %clang_cc1 -triple x86_64-pc-linux-gnu -o - -emit-llvm 
-debug-info-kind=limited %s | FileCheck %s --check-prefix=LINUX
+// RUN: %clang_cc1 -triple x86_64-unknown-windows-msvc -o - -emit-llvm 
-debug-info-kind=limited %s | FileCheck %s --check-prefix=WINDOWS
+// RUN: %clang_cc1 -triple i386-pc-linux-gnu -o - -emit-llvm 
-debug-info-kind=limited %s | FileCheck %s --check-prefix=LINUX32
+// RUN: %clang_cc1 -triple armv7--linux-gnueabihf -o - -emit-llvm 
-debug-info-kind=limited %s | FileCheck %s --check-prefix=ARM
+
+//  enum CallingConv {
+//CC_C,   // __attribute__((cdecl))
+//CC_X86StdCall,  // __attribute__((stdcall))
+//CC_X86FastCall, // __attribute__((fastcall))
+//CC_X86ThisCall, // __attribute__((thiscall))
+//CC_X86VectorCall, // __attribute__((vectorcall))
+//CC_X86Pascal,   // __attribute__((pascal))
+//CC_Win64,   // __attribute__((ms_abi))
+//CC_X86_64SysV,  // __attribute__((sysv_abi))
+//CC_X86RegCall, // __attribute__((regcall))
+//CC_AAPCS,   // __attribute__((pcs("aapcs")))
+//CC_AAPCS_VFP,   // __attribute__((pcs("aapcs-vfp")))
+//CC_IntelOclBicc, // __attribute__((intel_ocl_bicc))
+//CC_SpirFunction, // default for OpenCL functions on SPIR target
+//CC_OpenCLKernel, // inferred for OpenCL kernels
+//CC_Swift,// __attribute__((swiftcall))
+//CC_PreserveMost, // __attribute__((preserve_most))
+//CC_PreserveAll,  // __attribute__((preserve_all))
+//  };
+
+#ifdef __x86_64__
+
+#ifdef __linux__
+// LINUX: !DISubprogram({{.*}}"add_msabi", {{.*}}type: ![[FTY:[0-9]+]]
+// LINUX: ![[FTY]] = !DISubroutineType({{.*}}cc: DW_CC_LLVM_Win64,
+__attribute__((ms_abi)) int add_msabi(int a, int b) {
+  return a+b;
+}
+
+// LINUX: !DISubprogram({{.*}}"add_regcall", {{.*}}type: ![[FTY:[0-9]+]]
+// LINUX: ![[FTY]] = !DISubroutineType({{.*}}cc: DW_CC_LLVM_X86RegCall,
+__attribute__((regcall)) int add_regcall(int a, int b) {
+  return a+b;
+}
+
+// LINUX: !DISubprogram({{.*}}"add_preserve_most", {{.*}}type: ![[FTY:[0-9]+]]
+// LINUX: ![[FTY]] = !DISubroutineType({{.*}}cc: DW_CC_LLVM_PreserveMost,
+__attribute__((preserve_most)) int add_preserve_most(int a, int b) {
+  return a+b;
+}
+
+// LINUX: !DISubprogram({{.*}}"add_preserve_all", {{.*}}type: ![[FTY:[0-9]+]]
+// LINUX: ![[FTY]] = !DISubroutineType({{.*}}cc: DW_CC_LLVM_PreserveAll,
+__attribute__((preserve_all)) int add_preserve_all(int a, int b) {
+  return a+b;
+}
+
+// LINUX: !DISubprogram({{.*}}"add_swiftcall", {{.*}}type: ![[FTY:[0-9]+]]
+// LINUX: ![[FTY]] = !DISubroutineType({{.*}}cc: DW_CC_LLVM_Swift,
+__attribute__((swiftcall)) int add_swiftcall(int a, int b) {
+  return a+b;
+}
+
+// LINUX: !DISubprogram({{.*}}"add_intel

[PATCH] D44602: [clang-tidy] readability-function-size: add VariableThreshold param.

[Eugene Zelenko via Phabricator via cfe-commits]

Eugene.Zelenko added inline comments.



Comment at: docs/ReleaseNotes.rst:127
 
+- Added `VariableThreshold` option to `readability-function-size
+  
`_
 check

Please rebase from trunk and use //:doc:// for link.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D44602



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

[PATCH] D42351: Emit DWARF "constructor" calling convention for every supported Clang CC

[Jonas Devlieghere via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL328196: [CodeGen] Emit DWARF "constructor" calling 
convention (authored by JDevlieghere, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D42351?vs=133745&id=139436#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D42351

Files:
  cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
  cfe/trunk/test/CodeGen/debug-info-cc.c

Index: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
===
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
@@ -1000,20 +1000,28 @@
 return llvm::dwarf::DW_CC_LLVM_vectorcall;
   case CC_X86Pascal:
 return llvm::dwarf::DW_CC_BORLAND_pascal;
-
-  // FIXME: Create new DW_CC_ codes for these calling conventions.
   case CC_Win64:
+return llvm::dwarf::DW_CC_LLVM_Win64;
   case CC_X86_64SysV:
+return llvm::dwarf::DW_CC_LLVM_X86_64SysV;
   case CC_AAPCS:
+return llvm::dwarf::DW_CC_LLVM_AAPCS;
   case CC_AAPCS_VFP:
+return llvm::dwarf::DW_CC_LLVM_AAPCS_VFP;
   case CC_IntelOclBicc:
+return llvm::dwarf::DW_CC_LLVM_IntelOclBicc;
   case CC_SpirFunction:
+return llvm::dwarf::DW_CC_LLVM_SpirFunction;
   case CC_OpenCLKernel:
+return llvm::dwarf::DW_CC_LLVM_OpenCLKernel;
   case CC_Swift:
+return llvm::dwarf::DW_CC_LLVM_Swift;
   case CC_PreserveMost:
+return llvm::dwarf::DW_CC_LLVM_PreserveMost;
   case CC_PreserveAll:
+return llvm::dwarf::DW_CC_LLVM_PreserveAll;
   case CC_X86RegCall:
-return 0;
+return llvm::dwarf::DW_CC_LLVM_X86RegCall;
   }
   return 0;
 }
Index: cfe/trunk/test/CodeGen/debug-info-cc.c
===
--- cfe/trunk/test/CodeGen/debug-info-cc.c
+++ cfe/trunk/test/CodeGen/debug-info-cc.c
@@ -0,0 +1,120 @@
+// RUN: %clang_cc1 -triple x86_64-pc-linux-gnu -o - -emit-llvm -debug-info-kind=limited %s | FileCheck %s --check-prefix=LINUX
+// RUN: %clang_cc1 -triple x86_64-unknown-windows-msvc -o - -emit-llvm -debug-info-kind=limited %s | FileCheck %s --check-prefix=WINDOWS
+// RUN: %clang_cc1 -triple i386-pc-linux-gnu -o - -emit-llvm -debug-info-kind=limited %s | FileCheck %s --check-prefix=LINUX32
+// RUN: %clang_cc1 -triple armv7--linux-gnueabihf -o - -emit-llvm -debug-info-kind=limited %s | FileCheck %s --check-prefix=ARM
+
+//  enum CallingConv {
+//CC_C,   // __attribute__((cdecl))
+//CC_X86StdCall,  // __attribute__((stdcall))
+//CC_X86FastCall, // __attribute__((fastcall))
+//CC_X86ThisCall, // __attribute__((thiscall))
+//CC_X86VectorCall, // __attribute__((vectorcall))
+//CC_X86Pascal,   // __attribute__((pascal))
+//CC_Win64,   // __attribute__((ms_abi))
+//CC_X86_64SysV,  // __attribute__((sysv_abi))
+//CC_X86RegCall, // __attribute__((regcall))
+//CC_AAPCS,   // __attribute__((pcs("aapcs")))
+//CC_AAPCS_VFP,   // __attribute__((pcs("aapcs-vfp")))
+//CC_IntelOclBicc, // __attribute__((intel_ocl_bicc))
+//CC_SpirFunction, // default for OpenCL functions on SPIR target
+//CC_OpenCLKernel, // inferred for OpenCL kernels
+//CC_Swift,// __attribute__((swiftcall))
+//CC_PreserveMost, // __attribute__((preserve_most))
+//CC_PreserveAll,  // __attribute__((preserve_all))
+//  };
+
+#ifdef __x86_64__
+
+#ifdef __linux__
+// LINUX: !DISubprogram({{.*}}"add_msabi", {{.*}}type: ![[FTY:[0-9]+]]
+// LINUX: ![[FTY]] = !DISubroutineType({{.*}}cc: DW_CC_LLVM_Win64,
+__attribute__((ms_abi)) int add_msabi(int a, int b) {
+  return a+b;
+}
+
+// LINUX: !DISubprogram({{.*}}"add_regcall", {{.*}}type: ![[FTY:[0-9]+]]
+// LINUX: ![[FTY]] = !DISubroutineType({{.*}}cc: DW_CC_LLVM_X86RegCall,
+__attribute__((regcall)) int add_regcall(int a, int b) {
+  return a+b;
+}
+
+// LINUX: !DISubprogram({{.*}}"add_preserve_most", {{.*}}type: ![[FTY:[0-9]+]]
+// LINUX: ![[FTY]] = !DISubroutineType({{.*}}cc: DW_CC_LLVM_PreserveMost,
+__attribute__((preserve_most)) int add_preserve_most(int a, int b) {
+  return a+b;
+}
+
+// LINUX: !DISubprogram({{.*}}"add_preserve_all", {{.*}}type: ![[FTY:[0-9]+]]
+// LINUX: ![[FTY]] = !DISubroutineType({{.*}}cc: DW_CC_LLVM_PreserveAll,
+__attribute__((preserve_all)) int add_preserve_all(int a, int b) {
+  return a+b;
+}
+
+// LINUX: !DISubprogram({{.*}}"add_swiftcall", {{.*}}type: ![[FTY:[0-9]+]]
+// LINUX: ![[FTY]] = !DISubroutineType({{.*}}cc: DW_CC_LLVM_Swift,
+__attribute__((swiftcall)) int add_swiftcall(int a, int b) {
+  return a+b;
+}
+
+// LINUX: !DISubprogram({{.*}}"add_inteloclbicc", {{.*}}type: ![[FTY:[0-9]+]]
+// LINUX: ![[FTY]] = !DISubroutineType({{.*}}cc: DW_CC_LLVM_IntelOclBicc,
+__attribute__((intel_ocl_bicc)) int add_inteloclbicc(int a, int b) {
+  return a+b;
+}
+#endif
+
+#ifdef _WIN64
+// WINDOWS: !DISubprogram({{.*}}"add_sysvabi", {{.*}}type: ![[FTY:[0-9]+]]
+// WINDOWS: ![[FTY]] = !DISubroutineType({{.*}}cc: DW_CC_LLVM_X86_64SysV,

[PATCH] D44765: PR36643 Make clang-format support more generic TMarcos

[Alexander Kornienko via Phabricator via cfe-commits]

alexfh added a comment.

In https://reviews.llvm.org/D44765#1045394, @Typz wrote:

> A generic (or at least extandable) approach to specifying macro behaviors was 
> introduced here: https://reviews.llvm.org/D33440


I believe, that patch solves a significantly different problem and it won't 
make it much easier to implement correct handling of _T(x)-like macros (which 
expand to either x or L ## x depending on some other macro and thus have to be 
repeated for each fragment of the string literal after splitting).

The most extensible solution I see is to make the list of _T-like macro 
spellings configurable via an option.


Repository:
  rC Clang

https://reviews.llvm.org/D44765



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

[PATCH] D44765: PR36643 Make clang-format support more generic TMarcos

[Francois Ferrand via Phabricator via cfe-commits]

Typz added a comment.

You are right, I did not mean it would help with the handling of these macros; 
but it may be related on the configuration-side of things : adding an option 
for listing these macros may hit the same limitation, and the same mean of 
storing (in the code) the list of these macros may be used.


Repository:
  rC Clang

https://reviews.llvm.org/D44765



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

[clang-tools-extra] r328199 - clang-tidy, modularize: return non-zero exit code on errors

[Alexander Kornienko via cfe-commits]

Author: alexfh
Date: Thu Mar 22 07:18:20 2018
New Revision: 328199

URL: http://llvm.org/viewvc/llvm-project?rev=328199&view=rev
Log:
clang-tidy, modularize: return non-zero exit code on errors

When no inputs given, the tools should not only produce the help message, but
also return a non-zero exit code. Fixed tests accordingly.

Modified:
clang-tools-extra/trunk/clang-tidy/tool/ClangTidyMain.cpp
clang-tools-extra/trunk/modularize/Modularize.cpp
clang-tools-extra/trunk/test/clang-tidy/select-checks.cpp
clang-tools-extra/trunk/test/modularize/NoProblemsNamespace.modularize

Modified: clang-tools-extra/trunk/clang-tidy/tool/ClangTidyMain.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/tool/ClangTidyMain.cpp?rev=328199&r1=328198&r2=328199&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/tool/ClangTidyMain.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/tool/ClangTidyMain.cpp Thu Mar 22 
07:18:20 2018
@@ -424,13 +424,13 @@ static int clangTidyMain(int argc, const
   if (EnabledChecks.empty()) {
 llvm::errs() << "Error: no checks enabled.\n";
 llvm::cl::PrintHelpMessage(/*Hidden=*/false, /*Categorized=*/true);
-return 0;
+return 1;
   }
 
   if (PathList.empty()) {
 llvm::errs() << "Error: no input files specified.\n";
 llvm::cl::PrintHelpMessage(/*Hidden=*/false, /*Categorized=*/true);
-return 0;
+return 1;
   }
   llvm::IntrusiveRefCntPtr BaseFS(
   VfsOverlay.empty() ? vfs::getRealFileSystem()

Modified: clang-tools-extra/trunk/modularize/Modularize.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/modularize/Modularize.cpp?rev=328199&r1=328198&r2=328199&view=diff
==
--- clang-tools-extra/trunk/modularize/Modularize.cpp (original)
+++ clang-tools-extra/trunk/modularize/Modularize.cpp Thu Mar 22 07:18:20 2018
@@ -825,7 +825,7 @@ int main(int Argc, const char **Argv) {
   // No go if we have no header list file.
   if (ListFileNames.size() == 0) {
 cl::PrintHelpMessage();
-return 0;
+return 1;
   }
 
   std::unique_ptr ModUtil;

Modified: clang-tools-extra/trunk/test/clang-tidy/select-checks.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/select-checks.cpp?rev=328199&r1=328198&r2=328199&view=diff
==
--- clang-tools-extra/trunk/test/clang-tidy/select-checks.cpp (original)
+++ clang-tools-extra/trunk/test/clang-tidy/select-checks.cpp Thu Mar 22 
07:18:20 2018
@@ -1,5 +1,5 @@
 // RUN: clang-tidy %s -checks='-*,llvm-namespace-*' -- 2>&1 | FileCheck 
-implicit-check-not='{{warning:|error:}}' %s
-// RUN: clang-tidy %s -checks='-*,an-unknown-check' -- 2>&1 | FileCheck 
-implicit-check-not='{{warning:|error:}}' -check-prefix=CHECK2 %s
+// RUN: not clang-tidy %s -checks='-*,an-unknown-check' -- 2>&1 | FileCheck 
-implicit-check-not='{{warning:|error:}}' -check-prefix=CHECK2 %s
 
 // CHECK2: Error: no checks enabled.
 

Modified: clang-tools-extra/trunk/test/modularize/NoProblemsNamespace.modularize
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/modularize/NoProblemsNamespace.modularize?rev=328199&r1=328198&r2=328199&view=diff
==
--- clang-tools-extra/trunk/test/modularize/NoProblemsNamespace.modularize 
(original)
+++ clang-tools-extra/trunk/test/modularize/NoProblemsNamespace.modularize Thu 
Mar 22 07:18:20 2018
@@ -1,3 +1,3 @@
-# RUN: modularize -block-check-header-list-only
+# RUN: modularize -block-check-header-list-only %s
 
 Inputs/IncludeInNamespace.h


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

r328200 - clang-format: Fix SpacesInParentheses with fully qualified names.

[Daniel Jasper via cfe-commits]

Author: djasper
Date: Thu Mar 22 07:30:28 2018
New Revision: 328200

URL: http://llvm.org/viewvc/llvm-project?rev=328200&view=rev
Log:
clang-format: Fix SpacesInParentheses with fully qualified names.

When SpacesInParentheses is set to true clang-format does not add a
space before fully qualified names. For example:

  do_something(::globalVar );

Fix by Darby Payne. Thank you!

Modified:
cfe/trunk/lib/Format/TokenAnnotator.cpp
cfe/trunk/unittests/Format/FormatTest.cpp

Modified: cfe/trunk/lib/Format/TokenAnnotator.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/TokenAnnotator.cpp?rev=328200&r1=328199&r2=328200&view=diff
==
--- cfe/trunk/lib/Format/TokenAnnotator.cpp (original)
+++ cfe/trunk/lib/Format/TokenAnnotator.cpp Thu Mar 22 07:30:28 2018
@@ -2692,7 +2692,8 @@ bool TokenAnnotator::spaceRequiredBefore
 Style.Standard == FormatStyle::LS_Cpp03) ||
!(Left.isOneOf(tok::l_paren, tok::r_paren, tok::l_square,
   tok::kw___super, TT_TemplateCloser,
-  TT_TemplateOpener));
+  TT_TemplateOpener)) ||
+   (Left.is(tok ::l_paren) && Style.SpacesInParentheses);
   if ((Left.is(TT_TemplateOpener)) != (Right.is(TT_TemplateCloser)))
 return Style.SpacesInAngles;
   // Space before TT_StructuredBindingLSquare.

Modified: cfe/trunk/unittests/Format/FormatTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTest.cpp?rev=328200&r1=328199&r2=328200&view=diff
==
--- cfe/trunk/unittests/Format/FormatTest.cpp (original)
+++ cfe/trunk/unittests/Format/FormatTest.cpp Thu Mar 22 07:30:28 2018
@@ -8827,6 +8827,7 @@ TEST_F(FormatTest, ConfigurableSpacesInP
   FormatStyle Spaces = getLLVMStyle();
 
   Spaces.SpacesInParentheses = true;
+  verifyFormat("do_something( ::globalVar );", Spaces);
   verifyFormat("call( x, y, z );", Spaces);
   verifyFormat("call();", Spaces);
   verifyFormat("std::function callback;", Spaces);


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

Re: [PATCH] D44778: [clang-format] Wildcard expansion on Windows.

[Zachary Turner via cfe-commits]

Never seen this PURE_WINDOWS CMake variable. How is it different than MSVC?
On Thu, Mar 22, 2018 at 5:30 AM Alexander Kornienko via Phabricator <
revi...@reviews.llvm.org> wrote:

> alexfh created this revision.
> alexfh added reviewers: klimek, djasper.
> Herald added a subscriber: mgorny.
>
> Add support for wildcard expansion in command line arguments on Windows.
> See
> https://docs.microsoft.com/en-us/cpp/c-language/expanding-wildcard-arguments
>
> Fixes https://bugs.llvm.org/show_bug.cgi?id=17217
>
>
> Repository:
>   rC Clang
>
> https://reviews.llvm.org/D44778
>
> Files:
>   tools/clang-format/CMakeLists.txt
>
>
> Index: tools/clang-format/CMakeLists.txt
> ===
> --- tools/clang-format/CMakeLists.txt
> +++ tools/clang-format/CMakeLists.txt
> @@ -4,6 +4,14 @@
>ClangFormat.cpp
>)
>
> +if( PURE_WINDOWS )
> +  # Add support for wildcard expansion in command-line arguments on
> Windows.
> +  # See
> +  #
> https://docs.microsoft.com/en-us/cpp/c-language/expanding-wildcard-arguments
> +  set_property(TARGET clang-format APPEND_STRING PROPERTY
> +LINK_FLAGS " setargv.obj")
> +endif()
> +
>  set(CLANG_FORMAT_LIB_DEPS
>clangBasic
>clangFormat
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D44778: [clang-format] Wildcard expansion on Windows.

[Zachary Turner via Phabricator via cfe-commits]

zturner added subscribers: alexfh, zturner.
zturner added a comment.

Never seen this PURE_WINDOWS CMake variable. How is it different than MSVC?


Repository:
  rC Clang

https://reviews.llvm.org/D44778



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

r328201 - clang-format: Narrow down raw string literal line break exception.

[Daniel Jasper via cfe-commits]

Author: djasper
Date: Thu Mar 22 07:43:54 2018
New Revision: 328201

URL: http://llvm.org/viewvc/llvm-project?rev=328201&view=rev
Log:
clang-format: Narrow down raw string literal line break exception.

For multiline raw string literals, we generally want to respect the
author's choice of linebreak before the 'R"(' as the rest of the raw
string might be aligned to it and we cannot (commonly) modify the
content.

For single-line raw string literals, this doesn't make any sense and so
we should just treat them as regular string literals in this regard.

Modified:
cfe/trunk/lib/Format/TokenAnnotator.cpp
cfe/trunk/unittests/Format/FormatTest.cpp

Modified: cfe/trunk/lib/Format/TokenAnnotator.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/TokenAnnotator.cpp?rev=328201&r1=328200&r2=328201&view=diff
==
--- cfe/trunk/lib/Format/TokenAnnotator.cpp (original)
+++ cfe/trunk/lib/Format/TokenAnnotator.cpp Thu Mar 22 07:43:54 2018
@@ -2830,10 +2830,10 @@ bool TokenAnnotator::mustBreakBefore(con
   if (Style.BreakBeforeInheritanceComma && Right.is(TT_InheritanceComma))
 return true;
   if (Right.is(tok::string_literal) && Right.TokenText.startswith("R\""))
-// Raw string literals are special wrt. line breaks. The author has made a
-// deliberate choice and might have aligned the contents of the string
-// literal accordingly. Thus, we try keep existing line breaks.
-return Right.NewlinesBefore > 0;
+// Multiline raw string literals are special wrt. line breaks. The author
+// has made a deliberate choice and might have aligned the contents of the
+// string literal accordingly. Thus, we try keep existing line breaks.
+return Right.IsMultiline && Right.NewlinesBefore > 0;
   if ((Right.Previous->is(tok::l_brace) ||
(Right.Previous->is(tok::less) && Right.Previous->Previous &&
 Right.Previous->Previous->is(tok::equal))) &&

Modified: cfe/trunk/unittests/Format/FormatTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTest.cpp?rev=328201&r1=328200&r2=328201&view=diff
==
--- cfe/trunk/unittests/Format/FormatTest.cpp (original)
+++ cfe/trunk/unittests/Format/FormatTest.cpp Thu Mar 22 07:43:54 2018
@@ -8106,6 +8106,9 @@ TEST_F(FormatTest, CountsCharactersInMul
"multiline raw string literal xx\n"
")x\" + bb);",
getGoogleStyleWithColumns(20)));
+  EXPECT_EQ("fff(R\"(single line raw string)\" + bb);",
+format("fff(\n"
+   " R\"(single line raw string)\" + bb);"));
 }
 
 TEST_F(FormatTest, SkipsUnknownStringLiterals) {


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

[PATCH] D33844: terminating continue check

[Daniel Kolozsvari via Phabricator via cfe-commits]

koldaniel added a comment.

In https://reviews.llvm.org/D33844#798900, @alexfh wrote:

> Please don't forget to add cfe-commits to `Subscribers:` when initially 
> sending the patch for review. Otherwise nobody on the list will see it.
>
> Could you run the check on LLVM+Clang and post a summary of your findings 
> here?


Hi,

Result of a clang-tidy run on LLVM+Clang with only misc-terminating-continue 
turned on:

1 Warning:
llvm/tools/clang/lib/Parse/ParseTentative.cpp:1678:7: warning: terminating 
'continue' [misc-terminating-continue]

  continue;
  ^
  break


https://reviews.llvm.org/D33844



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

[PATCH] D39739: [HCC] Add flag to Import Weak Functions in Function Importer

[Aaron En Ye Shi via Phabricator via cfe-commits]

ashi1 added a comment.
Herald added a subscriber: llvm-commits.

Is first one encountered a poor design?


Repository:
  rL LLVM

https://reviews.llvm.org/D39739



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

[PATCH] D43290: clang-format: tweak formatting of variable initialization blocks

[Francois Ferrand via Phabricator via cfe-commits]

Typz added a comment.

@djasper : ping?


Repository:
  rC Clang

https://reviews.llvm.org/D43290



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

[PATCH] D40988: Clang-format: add finer-grained options for putting all arguments on one line

[Russell McClellan via Phabricator via cfe-commits]

russellmcc added a comment.

Bump again!  Any feedback would be quite appreciated.


https://reviews.llvm.org/D40988



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

[PATCH] D43015: clang-format: Introduce BreakInheritanceList option

[Francois Ferrand via Phabricator via cfe-commits]

Typz added a comment.

@djasper : ping?


Repository:
  rC Clang

https://reviews.llvm.org/D43015



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

[PATCH] D42684: clang-format: Allow optimizer to break template declaration.

[Francois Ferrand via Phabricator via cfe-commits]

Typz added a comment.

@djasper : ping?


Repository:
  rC Clang

https://reviews.llvm.org/D42684



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

[PATCH] D43290: clang-format: tweak formatting of variable initialization blocks

[Daniel Jasper via Phabricator via cfe-commits]

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

Generally looks good.




Comment at: lib/Format/TokenAnnotator.cpp:2183
   return 0;
+if (Left.Previous && Left.Previous->is(tok::equal) &&
+!Style.Cpp11BracedListStyle)

Typz wrote:
> djasper wrote:
> > Why is this necessary?
> Otherwise the `PenaltyBreakBeforeFirstCallParameter` is used, which is not 
> consistent with the concept of !Cpp11BraceListStyle (e.g. consider this is an 
> initializer), and gives the following format, which is certainly not the 
> expected result:
> 
>   const std::unordered_map
>   MyHashTable = { { \"a\", 0 },
>   { \"b\", 1 },
>   { \"c\", 2 } };
> 
> (again, the issue only happens when `PenaltyBreakBeforeFirstCallParameter` is 
> increased, e.g. 200 in my case. The default value is 19, so formatting is not 
> affected)
I think PenaltyBreakBeforeFirstCallParameter should not be applied with 
!Cpp11BracedListStyle whenever a brace is found. Cpp11BracedList style means 
that braces are to be treated like function calls, but without it, this doesn't 
make sense. I think this is in some ways better than looking for the "= {".



Comment at: unittests/Format/FormatTest.cpp:6655
+  FormatStyle AvoidBreakingFirstArgument = getLLVMStyle();
+  AvoidBreakingFirstArgument.PenaltyBreakBeforeFirstCallParameter = 200;
+  verifyFormat("const std::unordered_map MyHashTable =\n"

Typz wrote:
> djasper wrote:
> > How does this penalty influence the test?
> Because breaking after the opening brace is affected by the 
> `PenaltyBreakBeforeFirstCallParameter` : this is an init braced-list, but it 
> is considered as any function.
> 
> Specifically, my patch needs (see prev. comment) to change the penalty for 
> breaking after the brace, but this applies only when 
> `Cpp11BracedListStyle=false`, as per your earlier comment. So this test just 
> verify that the behavior is indeed not affected.
I see.


Repository:
  rC Clang

https://reviews.llvm.org/D43290



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

[PATCH] D39739: [HCC] Add flag to Import Weak Functions in Function Importer

[Brian Sumner via Phabricator via cfe-commits]

b-sumner added a comment.

In https://reviews.llvm.org/D39739#1045611, @ashi1 wrote:

> Is first one encountered a poor design?


Strong or first weak is the standard behavior for ISA level linkers.


Repository:
  rL LLVM

https://reviews.llvm.org/D39739



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

[PATCH] D44764: [clangd] Move GTest printers to separate file

[Simon Marchi via Phabricator via cfe-commits]

simark added a comment.

We could create a file `ClangdTesting.h" which includes everything tested 
related (gtest, gmock, printers, syncapi, etc). The convention would be that 
test files would just include that.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D44764



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

[PATCH] D44783: [Targets] Adjust ARM data layout

[Mikhail Maltsev via Phabricator via cfe-commits]

miyuki created this revision.
miyuki added a reviewer: hfinkel.
Herald added subscribers: kristof.beyls, javed.absar, dschuff.

The DataLayout structure now includes function pointer alignment, on
ARM targets it is set to 8 bits. The front end needs to be adjusted
to produce matching data layout strings.


https://reviews.llvm.org/D44783

Files:
  lib/Basic/Targets/ARM.cpp
  test/CodeGen/armv7k-abi.c
  test/CodeGen/target-data.c

Index: test/CodeGen/target-data.c
===
--- test/CodeGen/target-data.c
+++ test/CodeGen/target-data.c
@@ -68,7 +68,7 @@
 
 // RUN: %clang_cc1 -triple arm-nacl -o - -emit-llvm %s | \
 // RUN: FileCheck %s -check-prefix=ARM-NACL
-// ARM-NACL: target datalayout = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S128"
+// ARM-NACL: target datalayout = "e-m:e-p:32:32-F8-i64:64-v128:64:128-a:0:32-n32-S128"
 
 // RUN: %clang_cc1 -triple mipsel-nacl -o - -emit-llvm %s | \
 // RUN: FileCheck %s -check-prefix=MIPS-NACL
@@ -145,19 +145,19 @@
 
 // RUN: %clang_cc1 -triple thumb-unknown-gnueabi -o - -emit-llvm %s | \
 // RUN: FileCheck %s -check-prefix=THUMB
-// THUMB: target datalayout = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
+// THUMB: target datalayout = "e-m:e-p:32:32-F8-i64:64-v128:64:128-a:0:32-n32-S64"
 
 // RUN: %clang_cc1 -triple arm-unknown-gnueabi -o - -emit-llvm %s | \
 // RUN: FileCheck %s -check-prefix=ARM
-// ARM: target datalayout = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
+// ARM: target datalayout = "e-m:e-p:32:32-F8-i64:64-v128:64:128-a:0:32-n32-S64"
 
 // RUN: %clang_cc1 -triple thumb-unknown -o - -emit-llvm -target-abi apcs-gnu \
 // RUN: %s | FileCheck %s -check-prefix=THUMB-GNU
-// THUMB-GNU: target datalayout = "e-m:e-p:32:32-f64:32:64-v64:32:64-v128:32:128-a:0:32-n32-S32"
+// THUMB-GNU: target datalayout = "e-m:e-p:32:32-F8-f64:32:64-v64:32:64-v128:32:128-a:0:32-n32-S32"
 
 // RUN: %clang_cc1 -triple arm-unknown -o - -emit-llvm -target-abi apcs-gnu \
 // RUN: %s | FileCheck %s -check-prefix=ARM-GNU
-// ARM-GNU: target datalayout = "e-m:e-p:32:32-f64:32:64-v64:32:64-v128:32:128-a:0:32-n32-S32"
+// ARM-GNU: target datalayout = "e-m:e-p:32:32-F8-f64:32:64-v64:32:64-v128:32:128-a:0:32-n32-S32"
 
 // RUN: %clang_cc1 -triple hexagon-unknown -o - -emit-llvm %s | \
 // RUN: FileCheck %s -check-prefix=HEXAGON
Index: test/CodeGen/armv7k-abi.c
===
--- test/CodeGen/armv7k-abi.c
+++ test/CodeGen/armv7k-abi.c
@@ -4,7 +4,7 @@
 
 // Make sure 64 and 128 bit types are naturally aligned by the v7k ABI:
 
-// CHECK: target datalayout = "e-m:o-p:32:32-i64:64-a:0:32-n32-S128"
+// CHECK: target datalayout = "e-m:o-p:32:32-F8-i64:64-a:0:32-n32-S128"
 
 typedef struct {
   float arr[4];
Index: lib/Basic/Targets/ARM.cpp
===
--- lib/Basic/Targets/ARM.cpp
+++ lib/Basic/Targets/ARM.cpp
@@ -41,25 +41,26 @@
   // so set preferred for small types to 32.
   if (T.isOSBinFormatMachO()) {
 resetDataLayout(BigEndian
-? "E-m:o-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
-: "e-m:o-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64");
+? "E-m:o-p:32:32-F8-i64:64-v128:64:128-a:0:32-n32-S64"
+: "e-m:o-p:32:32-F8-i64:64-v128:64:128-a:0:32-n32-S64");
   } else if (T.isOSWindows()) {
 assert(!BigEndian && "Windows on ARM does not support big endian");
 resetDataLayout("e"
 "-m:w"
 "-p:32:32"
+"-F8"
 "-i64:64"
 "-v128:64:128"
 "-a:0:32"
 "-n32"
 "-S64");
   } else if (T.isOSNaCl()) {
 assert(!BigEndian && "NaCl on ARM does not support big endian");
-resetDataLayout("e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S128");
+resetDataLayout("e-m:e-p:32:32-F8-i64:64-v128:64:128-a:0:32-n32-S128");
   } else {
 resetDataLayout(BigEndian
-? "E-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
-: "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64");
+? "E-m:e-p:32:32-F8-i64:64-v128:64:128-a:0:32-n32-S64"
+: "e-m:e-p:32:32-F8-i64:64-v128:64:128-a:0:32-n32-S64");
   }
 
   // FIXME: Enumerated types are variable width in straight AAPCS.
@@ -88,17 +89,17 @@
 
   if (T.isOSBinFormatMachO() && IsAAPCS16) {
 assert(!BigEndian && "AAPCS16 does not support big-endian");
-resetDataLayout("e-m:o-p:32:32-i64:64-a:0:32-n32-S128");
+resetDataLayout("e-m:o-p:32:32-F8-i64:64-a:0:32-n32-S128");
   } else if (T.isOSBinFormatMachO())
 resetDataLayout(
 BigEndian
-? "E-m:o-p:32:32-f64:32:64-v64:32:64-v128:32:128-a:0:32-n32-S32"
-: "e-m:o-p:32:32-f64:32:64-v64:32:64-v128:32:128-a:0:32-n32-S32");
+? "E-m:o-p:32:32-F8-f64:32:6

[PATCH] D43967: [ASTImporter] Add test helper Fixture

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

xazax.hun accepted this revision.
xazax.hun added a comment.

Overall looks good, some minor comments inline.




Comment at: unittests/AST/ASTImporterTest.cpp:276
+// This will not create the file more than once.
+createVirtualFile(ToAST.get(), It->FileName, It->Code);
+

Maybe an IfNeeded suffix or something like that rather than a comment?



Comment at: unittests/AST/ASTImporterTest.cpp:289
+for (auto &Tu : FromTUs) {
+  if (Tu.Unit) {
+llvm::errs() << "FromAST:\n";

When can the TU.Unit be nullptr here?  Should this be an assert instead?



Comment at: unittests/AST/ASTImporterTest.cpp:1045
+
+  assert(Check(From));
+  Check(To);

I wonder why we only assert on the first one and if we should use GTEST macros 
here. Same questions below.


Repository:
  rC Clang

https://reviews.llvm.org/D43967



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

[PATCH] D33844: [clang-tidy] terminating continue check

[Jonas Toth via Phabricator via cfe-commits]

JonasToth added a comment.

I think this check could land in the `bugprone` module.

Given this situation won't appear a lot in codebases, did you check other 
codebases than LLVM?




Comment at: clang-tidy/misc/TerminatingContinueCheck.h:19
+
+/// Checks if a 'continue' statement terminates the loop. It does if the loop
+/// has false condition.

I think you can make one sentence out of both.



Comment at: docs/clang-tidy/checks/misc-terminating-continue.rst:6
+
+Detects `do while` loops with `false` conditions that have `continue` statement
+as this `continue` terminates the loop effectively.

Maybe rephrase a little:

`loops with a condition always evaluating to false` or something like it.



Comment at: docs/clang-tidy/checks/misc-terminating-continue.rst:21
+ConsumeToken();
+continue;
+  }

Please emphasize this location, so that it is absolutly clear what you mean.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D33844



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

[PATCH] D44764: [clangd] Move GTest printers to separate file

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added subscribers: sammccall, hokein, bkramer.
ilya-biryukov added a comment.

In https://reviews.llvm.org/D44764#1045648, @simark wrote:

> We could create a file `ClangdTesting.h" which includes everything tested 
> related (gtest, gmock, printers, syncapi, etc). The convention would be that 
> test files would just include that.


Yeah, sounds good. I would exclude syncapi from the list, though. Not all tests 
should necessarily depend on `ClangdServer`.
@sammccall , @ioeric , @hokein, @bkramer are you on board with the idea to have 
an umbrella header for gtest+gmock+printers?


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D44764



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

[PATCH] D44787: Migrate dockerfiles to use multi-stage builds.

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov created this revision.
ilya-biryukov added reviewers: mehdi_amini, klimek.
Herald added a subscriber: llvm-commits.

We previously emulated multi-staged builds using two dockerfiles,
native support from Docker allows us to merge them into one,
simplifying our scripts.

For more details about multi-stage builds, see:
https://docs.docker.com/develop/develop-images/multistage-build/


Repository:
  rL LLVM

https://reviews.llvm.org/D44787

Files:
  docs/Docker.rst
  utils/docker/build_docker_image.sh
  utils/docker/debian8/Dockerfile
  utils/docker/debian8/build/Dockerfile
  utils/docker/debian8/release/Dockerfile
  utils/docker/example/Dockerfile
  utils/docker/example/build/Dockerfile
  utils/docker/example/release/Dockerfile
  utils/docker/nvidia-cuda/Dockerfile
  utils/docker/nvidia-cuda/build/Dockerfile
  utils/docker/nvidia-cuda/release/Dockerfile
  utils/docker/scripts/build_install_llvm.sh

Index: utils/docker/scripts/build_install_llvm.sh
===
--- utils/docker/scripts/build_install_llvm.sh
+++ utils/docker/scripts/build_install_llvm.sh
@@ -16,8 +16,8 @@
 
 Checkout svn sources and run cmake with the specified arguments. Used
 inside docker container.
-Passes additional -DCMAKE_INSTALL_PREFIX and archives the contents of
-the directory to /tmp/clang.tar.gz.
+Passes additional -DCMAKE_INSTALL_PREFIX and puts the build results into
+/tmp/clang-install/ directory.
 
 Available options:
   -h|--help   show this help message
@@ -244,12 +244,7 @@
 
 popd
 
-# Pack the installed clang into an archive.
-echo "Archiving clang installation to /tmp/clang.tar.gz"
-cd "$CLANG_INSTALL_DIR"
-tar -czf /tmp/clang.tar.gz *
-
 # Cleanup.
-rm -rf "$CLANG_BUILD_DIR" "$CLANG_INSTALL_DIR"
+rm -rf "$CLANG_BUILD_DIR"
 
 echo "Done"
Index: utils/docker/nvidia-cuda/release/Dockerfile
===
--- utils/docker/nvidia-cuda/release/Dockerfile
+++ /dev/null
@@ -1,23 +0,0 @@
-#===- llvm/utils/docker/nvidia-cuda/release/Dockerfile ---===//
-#
-# The LLVM Compiler Infrastructure
-#
-# This file is distributed under the University of Illinois Open Source
-# License. See LICENSE.TXT for details.
-#
-#===--===//
-# This is an example Dockerfile that copies a clang installation, compiled
-# by the 'build/' container into a fresh docker image to get a container of
-# minimal size.
-# Replace FIXMEs to prepare a new Dockerfile.
-
-# FIXME: Replace 'ubuntu' with your base image.
-FROM nvidia/cuda:8.0-devel
-
-# FIXME: Change maintainer name.
-LABEL maintainer "LLVM Developers"
-
-# Unpack clang installation into this container.
-ADD clang.tar.gz /usr/local/
-
-# C++ standard library and binutils are already included in the base package.
Index: utils/docker/nvidia-cuda/Dockerfile
===
--- utils/docker/nvidia-cuda/Dockerfile
+++ utils/docker/nvidia-cuda/Dockerfile
@@ -6,26 +6,26 @@
 # License. See LICENSE.TXT for details.
 #
 #===--===//
-# Produces an image that compiles and archives clang, based on nvidia/cuda
-# image.
-FROM nvidia/cuda:8.0-devel
-
+# Stage 1. Check out LLVM source code and run the build.
+FROM nvidia/cuda:8.0-devel as builder
 LABEL maintainer "LLVM Developers"
-
-# Arguments to pass to build_install_clang.sh.
-ARG buildscript_args
-
 # Install llvm build dependencies.
 RUN apt-get update && \
 apt-get install -y --no-install-recommends ca-certificates cmake python \
-		subversion ninja-build && \
+subversion ninja-build && \
 rm -rf /var/lib/apt/lists/*
 
 ADD checksums /tmp/checksums
 ADD scripts /tmp/scripts
-
 # Arguments passed to build_install_clang.sh.
 ARG buildscript_args
-
-# Run the build. Results of the build will be available as /tmp/clang.tar.gz.
+# Run the build. Results of the build will be available at /tmp/clang-install/.
 RUN /tmp/scripts/build_install_llvm.sh ${buildscript_args}
+
+
+# Stage 2. Produce a minimal release image with build results.
+FROM nvidia/cuda:8.0-devel
+LABEL maintainer "LLVM Developers"
+# Copy clang installation into this container.
+COPY --from=builder /tmp/clang-install/ /usr/local/
+# C++ standard library and binutils are already included in the base package.
Index: utils/docker/example/release/Dockerfile
===
--- utils/docker/example/release/Dockerfile
+++ /dev/null
@@ -1,24 +0,0 @@
-#===- llvm/utils/docker/example/release/Dockerfile ---===//
-#
-# The LLVM Compiler Infrastructure
-#
-# This file is distributed under the University of Illinois Open Source
-# License. See LICENSE.TXT for details.
-#
-#===--===//
-# An 

Re: [PATCH] D44691: [CUDA] Disable LTO for device-side compilations.

[Artem Belevich via cfe-commits]

On Thu, Mar 22, 2018 at 12:02 AM Yvan Roux  wrote:

> This patch broke ARM/AArch64 bots, see:
>
> http://lab.llvm.org:8011/builders/clang-cmake-armv8-full/builds/841/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Athinlto.cu
>
>
​Sorry about that. I'll fix it ASAP.
​

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

[PATCH] D42684: clang-format: Allow optimizer to break template declaration.

[Daniel Jasper via Phabricator via cfe-commits]

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

Some last comments, but basically looks good.




Comment at: include/clang/Format/Format.h:352
 
-  /// \brief If ``true``, always break after the ``template<...>`` of a 
template
-  /// declaration.
-  /// \code
-  ///true:  false:
-  ///template   vs. template  class C 
{};
-  ///class C {};
-  /// \endcode
-  bool AlwaysBreakTemplateDeclarations;
+  /// \brief Different ways to break after the template declaration.
+  enum BreakTemplateDeclarationsStyle {

Don't forget to run docs/tools/dump_format_style.py to update the docs.



Comment at: include/clang/Format/Format.h:355
+  /// Do not force break before declaration.
+  /// ``PenaltyBreakTemplateDeclaration`` is taken into account.
+  /// \code

I think it'd be worth having a case here that would actually be formatted 
differently with BTDS_MultiLine.



Comment at: lib/Format/TokenAnnotator.cpp:2248
+  if (Left.ClosesTemplateDeclaration)
+  return Style.PenaltyBreakTemplateDeclaration;
   if (Left.is(TT_ConditionalExpr))

Indentation is off


Repository:
  rC Clang

https://reviews.llvm.org/D42684



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

[PATCH] D44788: Add an option to support debug fission on implicit ThinLTO.

[Yunlian Jiang via Phabricator via cfe-commits]

yunlian created this revision.
yunlian added reviewers: tejohnson, dblaikie, pcc.
Herald added subscribers: cfe-commits, inglorion, mehdi_amini.

This adds an option -gthinlto-dwo-dir=. LLVM can create .dwo files in the 
given directory
during the implicit ThinLTO link stage.


Repository:
  rC Clang

https://reviews.llvm.org/D44788

Files:
  docs/ClangCommandLineReference.rst
  include/clang/Driver/Options.td
  lib/Driver/ToolChains/CommonArgs.cpp


Index: lib/Driver/ToolChains/CommonArgs.cpp
===
--- lib/Driver/ToolChains/CommonArgs.cpp
+++ lib/Driver/ToolChains/CommonArgs.cpp
@@ -415,6 +415,16 @@
   if (IsThinLTO)
 CmdArgs.push_back("-plugin-opt=thinlto");
 
+  if (Arg *A = Args.getLastArg(options::OPT_gthinlto_dwo_dir_EQ)) {
+const char *Objcopy =
+Args.MakeArgString(ToolChain.GetProgramPath(CLANG_DEFAULT_OBJCOPY));
+CmdArgs.push_back(
+Args.MakeArgString(Twine("-plugin-opt=objcopy=") + Objcopy));
+StringRef DWO_Dir = A->getValue();
+CmdArgs.push_back(
+Args.MakeArgString(Twine("-plugin-opt=dwo_dir=") + DWO_Dir));
+  }
+
   if (unsigned Parallelism = getLTOParallelism(Args, D))
 CmdArgs.push_back(
 Args.MakeArgString("-plugin-opt=jobs=" + Twine(Parallelism)));
Index: include/clang/Driver/Options.td
===
--- include/clang/Driver/Options.td
+++ include/clang/Driver/Options.td
@@ -1700,6 +1700,7 @@
 def gcolumn_info : Flag<["-"], "gcolumn-info">, Group, 
Flags<[CoreOption]>;
 def gno_column_info : Flag<["-"], "gno-column-info">, Group, 
Flags<[CoreOption]>;
 def gsplit_dwarf : Flag<["-"], "gsplit-dwarf">, Group;
+def gthinlto_dwo_dir_EQ : Joined<["-"], "gthinlto-dwo-dir=">, 
Group;
 def ggnu_pubnames : Flag<["-"], "ggnu-pubnames">, Group, 
Flags<[CC1Option]>;
 def gdwarf_aranges : Flag<["-"], "gdwarf-aranges">, Group;
 def gmodules : Flag <["-"], "gmodules">, Group,
Index: docs/ClangCommandLineReference.rst
===
--- docs/ClangCommandLineReference.rst
+++ docs/ClangCommandLineReference.rst
@@ -2587,6 +2587,8 @@
 
 .. option:: -gstrict-dwarf, -gno-strict-dwarf
 
+.. option:: -gthinlto-dwo-dir=
+
 .. option:: -gz
 
 DWARF debug sections compression type


Index: lib/Driver/ToolChains/CommonArgs.cpp
===
--- lib/Driver/ToolChains/CommonArgs.cpp
+++ lib/Driver/ToolChains/CommonArgs.cpp
@@ -415,6 +415,16 @@
   if (IsThinLTO)
 CmdArgs.push_back("-plugin-opt=thinlto");
 
+  if (Arg *A = Args.getLastArg(options::OPT_gthinlto_dwo_dir_EQ)) {
+const char *Objcopy =
+Args.MakeArgString(ToolChain.GetProgramPath(CLANG_DEFAULT_OBJCOPY));
+CmdArgs.push_back(
+Args.MakeArgString(Twine("-plugin-opt=objcopy=") + Objcopy));
+StringRef DWO_Dir = A->getValue();
+CmdArgs.push_back(
+Args.MakeArgString(Twine("-plugin-opt=dwo_dir=") + DWO_Dir));
+  }
+
   if (unsigned Parallelism = getLTOParallelism(Args, D))
 CmdArgs.push_back(
 Args.MakeArgString("-plugin-opt=jobs=" + Twine(Parallelism)));
Index: include/clang/Driver/Options.td
===
--- include/clang/Driver/Options.td
+++ include/clang/Driver/Options.td
@@ -1700,6 +1700,7 @@
 def gcolumn_info : Flag<["-"], "gcolumn-info">, Group, Flags<[CoreOption]>;
 def gno_column_info : Flag<["-"], "gno-column-info">, Group, Flags<[CoreOption]>;
 def gsplit_dwarf : Flag<["-"], "gsplit-dwarf">, Group;
+def gthinlto_dwo_dir_EQ : Joined<["-"], "gthinlto-dwo-dir=">, Group;
 def ggnu_pubnames : Flag<["-"], "ggnu-pubnames">, Group, Flags<[CC1Option]>;
 def gdwarf_aranges : Flag<["-"], "gdwarf-aranges">, Group;
 def gmodules : Flag <["-"], "gmodules">, Group,
Index: docs/ClangCommandLineReference.rst
===
--- docs/ClangCommandLineReference.rst
+++ docs/ClangCommandLineReference.rst
@@ -2587,6 +2587,8 @@
 
 .. option:: -gstrict-dwarf, -gno-strict-dwarf
 
+.. option:: -gthinlto-dwo-dir=
+
 .. option:: -gz
 
 DWARF debug sections compression type
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D44778: [clang-format] Wildcard expansion on Windows.

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

PURE_WINDOWS is all Windows except Cygwin. It's an LLVM thing, not a CMake 
thing.

I don't know if setargv.obj is available on MinGW, and even if it is it's 
probably not gonna have the .obj extension, so this should probably be limited 
to MSVC.


Repository:
  rC Clang

https://reviews.llvm.org/D44778



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

r328213 - [CUDA] add REQUIRES fields for CUDA variants of LTO tests.

[Artem Belevich via cfe-commits]

Author: tra
Date: Thu Mar 22 09:47:41 2018
New Revision: 328213

URL: http://llvm.org/viewvc/llvm-project?rev=328213&view=rev
Log:
[CUDA] add REQUIRES fields for CUDA variants of LTO tests.

Also relax checking for nvptx triple. This should avoid test failure if
the test is executed on 32-bit platform.

Modified:
cfe/trunk/test/Driver/lto.cu
cfe/trunk/test/Driver/thinlto.cu

Modified: cfe/trunk/test/Driver/lto.cu
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/lto.cu?rev=328213&r1=328212&r2=328213&view=diff
==
--- cfe/trunk/test/Driver/lto.cu (original)
+++ cfe/trunk/test/Driver/lto.cu Thu Mar 22 09:47:41 2018
@@ -1,3 +1,7 @@
+// REQUIRES: clang-driver
+// REQUIRES: x86-registered-target
+// REQUIRES: nvptx-registered-target
+
 // -flto causes a switch to llvm-bc object files.
 // RUN: %clangxx -nocudainc -nocudalib -ccc-print-phases -c %s -flto 2> %t
 // RUN: FileCheck -check-prefix=CHECK-COMPILE-ACTIONS < %t %s
@@ -17,8 +21,8 @@
 // CHECK-COMPILELINK-ACTIONS: 5: compiler, {4}, ir, (device-cuda, sm_20)
 // CHECK-COMPILELINK-ACTIONS: 6: backend, {5}, assembler, (device-cuda, sm_20)
 // CHECK-COMPILELINK-ACTIONS: 7: assembler, {6}, object, (device-cuda, sm_20)
-// CHECK-COMPILELINK-ACTIONS: 8: offload, "device-cuda 
(nvptx64-nvidia-cuda:sm_20)" {7}, object
-// CHECK-COMPILELINK-ACTIONS: 9: offload, "device-cuda 
(nvptx64-nvidia-cuda:sm_20)" {6}, assembler
+// CHECK-COMPILELINK-ACTIONS: 8: offload, "device-cuda 
(nvptx{{.*}}-nvidia-cuda:sm_20)" {7}, object
+// CHECK-COMPILELINK-ACTIONS: 9: offload, "device-cuda 
(nvptx{{.*}}-nvidia-cuda:sm_20)" {6}, assembler
 // CHECK-COMPILELINK-ACTIONS: 10: linker, {8, 9}, cuda-fatbin, (device-cuda)
 // CHECK-COMPILELINK-ACTIONS: 11: offload, "host-cuda {{.*}}" {2}, 
"device-cuda{{.*}}" {10}, ir
 // CHECK-COMPILELINK-ACTIONS: 12: backend, {11}, lto-bc, (host-cuda)

Modified: cfe/trunk/test/Driver/thinlto.cu
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/thinlto.cu?rev=328213&r1=328212&r2=328213&view=diff
==
--- cfe/trunk/test/Driver/thinlto.cu (original)
+++ cfe/trunk/test/Driver/thinlto.cu Thu Mar 22 09:47:41 2018
@@ -1,3 +1,7 @@
+// REQUIRES: clang-driver
+// REQUIRES: x86-registered-target
+// REQUIRES: nvptx-registered-target
+
 // -flto=thin causes a switch to llvm-bc object files.
 // RUN: %clangxx -ccc-print-phases -nocudainc -nocudalib -c %s -flto=thin 2> %t
 // RUN: FileCheck -check-prefix=CHECK-COMPILE-ACTIONS < %t %s
@@ -17,8 +21,8 @@
 // CHECK-COMPILELINK-ACTIONS: 5: compiler, {4}, ir, (device-cuda, sm_20)
 // CHECK-COMPILELINK-ACTIONS: 6: backend, {5}, assembler, (device-cuda, sm_20)
 // CHECK-COMPILELINK-ACTIONS: 7: assembler, {6}, object, (device-cuda, sm_20)
-// CHECK-COMPILELINK-ACTIONS: 8: offload, "device-cuda 
(nvptx64-nvidia-cuda:sm_20)" {7}, object
-// CHECK-COMPILELINK-ACTIONS: 9: offload, "device-cuda 
(nvptx64-nvidia-cuda:sm_20)" {6}, assembler
+// CHECK-COMPILELINK-ACTIONS: 8: offload, "device-cuda 
(nvptx{{.*}}-nvidia-cuda:sm_20)" {7}, object
+// CHECK-COMPILELINK-ACTIONS: 9: offload, "device-cuda 
(nvptx{{.*}}-nvidia-cuda:sm_20)" {6}, assembler
 // CHECK-COMPILELINK-ACTIONS: 10: linker, {8, 9}, cuda-fatbin, (device-cuda)
 // CHECK-COMPILELINK-ACTIONS: 11: offload, "host-cuda {{.*}}" {2}, 
"device-cuda{{.*}}" {10}, ir
 // CHECK-COMPILELINK-ACTIONS: 12: backend, {11}, lto-bc, (host-cuda)


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

[PATCH] D44691: [CUDA] Disable LTO for device-side compilations.

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

The test failure should be fixed by r328213.


Repository:
  rL LLVM

https://reviews.llvm.org/D44691



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

[PATCH] D44559: [Sema] Wrong width of result of mul operation

[John McCall via Phabricator via cfe-commits]

rjmccall requested changes to this revision.
rjmccall added a comment.
This revision now requires changes to proceed.

No, I still oppose this patch.


https://reviews.llvm.org/D44559



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

[PATCH] D44745: [HWASan] Port HWASan to Linux x86-64 (clang)

[Aleksey Shlyapnikov via Phabricator via cfe-commits]

alekseyshl added inline comments.



Comment at: test/Driver/asan.c:12
-// RUN: %clang -O2 -target aarch64-unknown-linux -fsanitize=hwaddress %s -S 
-emit-llvm -o - | FileCheck %s --check-prefix=CHECK-HWASAN
-// RUN: %clang -O3 -target aarch64-unknown-linux -fsanitize=hwaddress %s -S 
-emit-llvm -o - | FileCheck %s --check-prefix=CHECK-HWASAN
 // Verify that -fsanitize={address,kernel-address} invoke ASan and KASan 
instrumentation.

eugenis wrote:
> Don't replace existing tests!
> Add new ones.
> 
I am not replacing them, I am making it consistent with all other sanitizers, 
which also support many more platforms than just x86_64-linux-gnu or 
*-unknown-linux, but have tests for that one platform only.


Repository:
  rC Clang

https://reviews.llvm.org/D44745



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

[PATCH] D33844: [clang-tidy] terminating continue check

[Arthur O'Dwyer via Phabricator via cfe-commits]

Quuxplusone added inline comments.



Comment at: clang-tidy/misc/TerminatingContinueCheck.cpp:42
+
+  auto Diag = diag(ContStmt->getLocStart(), "terminating 'continue'");
+  Diag << FixItHint::CreateReplacement(ContStmt->getSourceRange(), "break");

It was not clear to me what a "terminating 'continue'" was, just from seeing 
this error message. Wouldn't it make more sense to emit a self-explanatory 
diagnostic, such as

'continue', in loop with false condition, is equivalent to 'break'

? And then you could even suggest a fixit of replacing 'continue' with 
'break'... oh, which you already do. :)



Comment at: test/clang-tidy/misc-terminating-continue.cpp:7
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: terminating 'continue' 
[misc-terminating-continue]
+  } while(false);
+

I initially expected to see tests also for

goto L1;
while (false) {
L1:
continue;  // 'continue' is equivalent to 'break'
}

int v = 0;
goto L1;
for (; false; ++v) {
L1:
continue;  // 'continue' is NOT equivalent to 'break'
}

although I assume your current patch doesn't actually diagnose the former, and 
that's probably fine.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D33844



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

[PATCH] D43322: Diagnose cases of "return x" that should be "return std::move(x)" for efficiency

[Arthur O'Dwyer via Phabricator via cfe-commits]

Quuxplusone added a comment.

@rtrieu gentle ping!

Action items I need help with, cut-and-pasted from above:

- Ideally, test compiling a bunch of (e.g. Google) code with 
https://reviews.llvm.org/D43322, see if there are any rough edges
- Decide if `-Wmove` should imply `-Wreturn-std-move` (I have preemptively done 
this)
- Review and land https://reviews.llvm.org/D43322
- Ideally, some discussion of whether I should write a paper for San Diego 
proposing that C++ //should// move rather than copy in these cases (my default 
plan is to do this)


Repository:
  rC Clang

https://reviews.llvm.org/D43322



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

[PATCH] D44790: [clang-format] Fix ObjC style guesser to also iterate over child lines

[Ben Hamilton via Phabricator via cfe-commits]

benhamilton created this revision.
benhamilton added reviewers: djasper, jolesiak, Wizard.
Herald added subscribers: cfe-commits, klimek.

When I wrote `ObjCHeaderStyleGuesser`, I incorrectly assumed the
correct way to iterate over all tokens in `AnnotatedLine` was to
iterate over the linked list tokens starting with
`AnnotatedLine::First`.

However, `AnnotatedLine` also contains a vector
`AnnotedLine::Children` with child `AnnotedLine`s which have their own
tokens which we need to iterate over.

Because I didn't iterate over the tokens in the children lines, the
ObjC style guesser would fail on syntax like:

  #define FOO ({ NSString *s = ... })

as the statement(s) inside { ... } are child lines.

This fixes the bug and adds a test. I confirmed the test
failed before the fix, and passed after the fix.

Test Plan: New tests added. Ran tests with:

  % make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests


Repository:
  rC Clang

https://reviews.llvm.org/D44790

Files:
  lib/Format/Format.cpp
  unittests/Format/FormatTest.cpp


Index: unittests/Format/FormatTest.cpp
===
--- unittests/Format/FormatTest.cpp
+++ unittests/Format/FormatTest.cpp
@@ -12162,6 +12162,13 @@
   guessLanguage("foo.h", "int(^foo[(kNumEntries + 10)])(char, float);"));
 }
 
+TEST_F(FormatTest, GuessLanguageWithChildLines) {
+  EXPECT_EQ(FormatStyle::LK_Cpp,
+guessLanguage("foo.h", "#define FOO ({ std::string s; })"));
+  EXPECT_EQ(FormatStyle::LK_ObjC,
+guessLanguage("foo.h", "#define FOO ({ NSString *s; })"));
+}
+
 } // end namespace
 } // end namespace format
 } // end namespace clang
Index: lib/Format/Format.cpp
===
--- lib/Format/Format.cpp
+++ lib/Format/Format.cpp
@@ -1514,8 +1514,8 @@
 "UIView",
 };
 
-for (auto &Line : AnnotatedLines) {
-  for (FormatToken *FormatTok = Line->First; FormatTok;
+auto CheckLineTokens = [&Keywords](const AnnotatedLine &Line) {
+  for (const FormatToken *FormatTok = Line.First; FormatTok;
FormatTok = FormatTok->Next) {
 if ((FormatTok->Previous && FormatTok->Previous->is(tok::at) &&
  (FormatTok->isObjCAtKeyword(tok::objc_interface) ||
@@ -1536,6 +1536,15 @@
   return true;
 }
   }
+  return false;
+};
+for (auto Line : AnnotatedLines) {
+  if (CheckLineTokens(*Line))
+return true;
+  for (auto ChildLine : Line->Children) {
+if (CheckLineTokens(*ChildLine))
+  return true;
+  }
 }
 return false;
   }


Index: unittests/Format/FormatTest.cpp
===
--- unittests/Format/FormatTest.cpp
+++ unittests/Format/FormatTest.cpp
@@ -12162,6 +12162,13 @@
   guessLanguage("foo.h", "int(^foo[(kNumEntries + 10)])(char, float);"));
 }
 
+TEST_F(FormatTest, GuessLanguageWithChildLines) {
+  EXPECT_EQ(FormatStyle::LK_Cpp,
+guessLanguage("foo.h", "#define FOO ({ std::string s; })"));
+  EXPECT_EQ(FormatStyle::LK_ObjC,
+guessLanguage("foo.h", "#define FOO ({ NSString *s; })"));
+}
+
 } // end namespace
 } // end namespace format
 } // end namespace clang
Index: lib/Format/Format.cpp
===
--- lib/Format/Format.cpp
+++ lib/Format/Format.cpp
@@ -1514,8 +1514,8 @@
 "UIView",
 };
 
-for (auto &Line : AnnotatedLines) {
-  for (FormatToken *FormatTok = Line->First; FormatTok;
+auto CheckLineTokens = [&Keywords](const AnnotatedLine &Line) {
+  for (const FormatToken *FormatTok = Line.First; FormatTok;
FormatTok = FormatTok->Next) {
 if ((FormatTok->Previous && FormatTok->Previous->is(tok::at) &&
  (FormatTok->isObjCAtKeyword(tok::objc_interface) ||
@@ -1536,6 +1536,15 @@
   return true;
 }
   }
+  return false;
+};
+for (auto Line : AnnotatedLines) {
+  if (CheckLineTokens(*Line))
+return true;
+  for (auto ChildLine : Line->Children) {
+if (CheckLineTokens(*ChildLine))
+  return true;
+  }
 }
 return false;
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D44765: PR36643 Make clang-format support more generic TMarcos

[Teodor Petrov via Phabricator via cfe-commits]

obfuscated added a comment.

In https://reviews.llvm.org/D44765#1045373, @alexfh wrote:

> We can't just treat `anything("")` like the _T macro. There should be a 
> whitelist configurable with an option. By default only _T should be handled.


What cases could break with this version of the patch?
Or you think it is just too dangerous to have this in such generic form?
I'm fine adding an option if this is deemed acceptable.


Repository:
  rC Clang

https://reviews.llvm.org/D44765



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

[PATCH] D44788: Add an option to support debug fission on implicit ThinLTO.

[Peter Collingbourne via Phabricator via cfe-commits]

pcc added a comment.

Does this depend on another patch?


Repository:
  rC Clang

https://reviews.llvm.org/D44788



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

[PATCH] D44745: [HWASan] Port HWASan to Linux x86-64 (clang)

[Aleksey Shlyapnikov via Phabricator via cfe-commits]

alekseyshl updated this revision to Diff 139469.
alekseyshl added a comment.

- Add tests to verify that HWASan requires "-pie".


Repository:
  rC Clang

https://reviews.llvm.org/D44745

Files:
  lib/Driver/SanitizerArgs.cpp
  lib/Driver/ToolChains/Linux.cpp
  test/Driver/Inputs/resource_dir/lib/linux/libclang_rt.hwasan-x86_64.a.syms
  test/Driver/asan.c
  test/Driver/fsanitize-blacklist.c
  test/Driver/fsanitize.c
  test/Driver/sanitizer-ld.c

Index: test/Driver/sanitizer-ld.c
===
--- test/Driver/sanitizer-ld.c
+++ test/Driver/sanitizer-ld.c
@@ -696,54 +696,100 @@
 // CHECK-SCUDO-ANDROID-STATIC: "-lpthread"
 
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
-// RUN: -target aarch64-unknown-linux -fuse-ld=ld -fsanitize=hwaddress \
+// RUN: -target x86_64-unknown-linux -fuse-ld=ld -fsanitize=hwaddress \
 // RUN: -resource-dir=%S/Inputs/resource_dir \
 // RUN: --sysroot=%S/Inputs/basic_linux_tree \
-// RUN:   | FileCheck --check-prefix=CHECK-HWASAN-LINUX %s
+// RUN:   | FileCheck --check-prefix=CHECK-HWASAN-X86-64-LINUX %s
 //
-// CHECK-HWASAN-LINUX: "{{(.*[^-.0-9A-Z_a-z])?}}ld{{(.exe)?}}"
-// CHECK-HWASAN-LINUX-NOT: "-lc"
-// CHECK-HWASAN-LINUX: libclang_rt.hwasan-aarch64.a"
-// CHECK-HWASAN-LINUX-NOT: "--export-dynamic"
-// CHECK-HWASAN-LINUX: "--dynamic-list={{.*}}libclang_rt.hwasan-aarch64.a.syms"
-// CHECK-HWASAN-LINUX-NOT: "--export-dynamic"
-// CHECK-HWASAN-LINUX: "-lpthread"
-// CHECK-HWASAN-LINUX: "-lrt"
-// CHECK-HWASAN-LINUX: "-ldl"
+// CHECK-HWASAN-X86-64-LINUX: "{{(.*[^-.0-9A-Z_a-z])?}}ld{{(.exe)?}}"
+// CHECK-HWASAN-X86-64-LINUX: "-pie"
+// CHECK-HWASAN-X86-64-LINUX-NOT: "-lc"
+// CHECK-HWASAN-X86-64-LINUX: libclang_rt.hwasan-x86_64.a"
+// CHECK-HWASAN-X86-64-LINUX-NOT: "--export-dynamic"
+// CHECK-HWASAN-X86-64-LINUX: "--dynamic-list={{.*}}libclang_rt.hwasan-x86_64.a.syms"
+// CHECK-HWASAN-X86-64-LINUX-NOT: "--export-dynamic"
+// CHECK-HWASAN-X86-64-LINUX: "-lpthread"
+// CHECK-HWASAN-X86-64-LINUX: "-lrt"
+// CHECK-HWASAN-X86-64-LINUX: "-ldl"
 
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
-// RUN: -target aarch64-unknown-linux -fuse-ld=ld -fsanitize=hwaddress -shared-libsan \
-// RUN: -resource-dir=%S/Inputs/resource_dir \
+// RUN: -target x86_64-unknown-linux -fuse-ld=ld -fsanitize=hwaddress \
+// RUN: -shared-libsan -resource-dir=%S/Inputs/resource_dir \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-SHARED-HWASAN-X86-64-LINUX %s
+//
+// CHECK-SHARED-HWASAN-X86-64-LINUX: "{{(.*[^-.0-9A-Z_a-z])?}}ld{{(.exe)?}}"
+// CHECK-SHARED-HWASAN-X86-64-LINUX: "-pie"
+// CHECK-SHARED-HWASAN-X86-64-LINUX-NOT: "-lc"
+// CHECK-SHARED-HWASAN-X86-64-LINUX: libclang_rt.hwasan-x86_64.so"
+// CHECK-SHARED-HWASAN-X86-64-LINUX-NOT: "-lpthread"
+// CHECK-SHARED-HWASAN-X86-64-LINUX-NOT: "-lrt"
+// CHECK-SHARED-HWASAN-X86-64-LINUX-NOT: "-ldl"
+// CHECK-SHARED-HWASAN-X86-64-LINUX-NOT: "--export-dynamic"
+// CHECK-SHARED-HWASAN-X86-64-LINUX-NOT: "--dynamic-list"
+
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.so -shared 2>&1 \
+// RUN: -target x86_64-unknown-linux -fuse-ld=ld -fsanitize=hwaddress \
+// RUN: -shared-libsan -resource-dir=%S/Inputs/resource_dir \
 // RUN: --sysroot=%S/Inputs/basic_linux_tree \
-// RUN:   | FileCheck --check-prefix=CHECK-SHARED-HWASAN-LINUX %s
+// RUN:   | FileCheck --check-prefix=CHECK-DSO-SHARED-HWASAN-X86-64-LINUX %s
+//
+// CHECK-DSO-SHARED-HWASAN-X86-64-LINUX: "{{(.*[^-.0-9A-Z_a-z])?}}ld{{(.exe)?}}"
+// CHECK-DSO_SHARED-HWASAN-X86-64-LINUX: "-pie"
+// CHECK-DSO-SHARED-HWASAN-X86-64-LINUX-NOT: "-lc"
+// CHECK-DSO-SHARED-HWASAN-X86-64-LINUX: libclang_rt.hwasan-x86_64.so"
+// CHECK-DSO-SHARED-HWASAN-X86-64-LINUX-NOT: "-lpthread"
+// CHECK-DSO-SHARED-HWASAN-X86-64-LINUX-NOT: "-lrt"
+// CHECK-DSO-SHARED-HWASAN-X86-64-LINUX-NOT: "-ldl"
+// CHECK-DSO-SHARED-HWASAN-X86-64-LINUX-NOT: "--export-dynamic"
+// CHECK-DSO-SHARED-HWASAN-X86-64-LINUX-NOT: "--dynamic-list"
 
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: -target aarch64-unknown-linux -fuse-ld=ld -fsanitize=hwaddress \
-// RUN: -shared-libsan \
 // RUN: -resource-dir=%S/Inputs/resource_dir \
 // RUN: --sysroot=%S/Inputs/basic_linux_tree \
-// RUN:   | FileCheck --check-prefix=CHECK-SHARED-HWASAN-LINUX %s
+// RUN:   | FileCheck --check-prefix=CHECK-HWASAN-AARCH64-LINUX %s
 //
-// CHECK-SHARED-HWASAN-LINUX: "{{(.*[^-.0-9A-Z_a-z])?}}ld{{(.exe)?}}"
-// CHECK-SHARED-HWASAN-LINUX-NOT: "-lc"
-// CHECK-SHARED-HWASAN-LINUX: libclang_rt.hwasan-aarch64.so"
-// CHECK-SHARED-HWASAN-LINUX-NOT: "-lpthread"
-// CHECK-SHARED-HWASAN-LINUX-NOT: "-lrt"
-// CHECK-SHARED-HWASAN-LINUX-NOT: "-ldl"
-// CHECK-SHARED-HWASAN-LINUX-NOT: "--export-dynamic"
-// CHECK-SHARED-HWASAN-LINUX-NOT: "--dynamic-list"
+// CHECK-HWASAN-AARCH64-LINUX: "{{(.*[^-.0-9A-Z_a-z])?}}ld{{(.exe)?}}"
+// CHECK-HWASAN-AARCH64-LINUX: "-pie"
+// CHECK-HWASAN-AA

[PATCH] D44753: [Preprocessor] Rename __is_{target -> host}_* function-like builtin macros

[John Ericson via Phabricator via cfe-commits]

Ericson2314 added a comment.

OK I'll happily admit that Autoconf's choices of names is terrible, and that, 
yes, the names can be defined from two differing perspectives. And, I actually 
do believe the GCC build system is far inferior, too. But on other points I 
think we're all talking past each other.

I know `__will_be_built_for_*` is incredibly verbose and admitted as much; I 
was just trying to begin finding common ground by using different terminology 
with less baggage. Heck, `__is_*` works for me too, and nothing's more pithy 
than that. If you all wish to stick to preexisting terms and thus one of 
"build" "host" and "target", I'll switch back to arguing why I believe "target" 
is wrong.

I've claimed that `target` is //never// used in preprocessor macros to mean the 
platform where the being-built code is compiled for / platform where it will 
run. I've also linked various examples of code showing `target` used in the way 
I describe. In fact, here is another from LLVM itself: 
https://github.com/llvm-mirror/llvm/blob/master/include/llvm/Config/llvm-config.h.cmake#L23-L33.
 I quote:

  /* Target triple LLVM will generate code for by default */
  #cmakedefine LLVM_DEFAULT_TARGET_TRIPLE "${LLVM_DEFAULT_TARGET_TRIPLE}"

  /* Host triple LLVM will be executed on */
  #cmakedefine LLVM_HOST_TRIPLE "${LLVM_HOST_TRIPLE}"

perfect use of these terms in pre-processor macros as far as I am concerned: 
from the perspective of the program being built (LLVM) and not the compiler 
building it.

Do you all have a counter-example of a CPP macro containing `target` with your 
meaning?


Repository:
  rC Clang

https://reviews.llvm.org/D44753



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

[PATCH] D44790: [clang-format] Fix ObjC style guesser to also iterate over child lines

[Daniel Jasper via Phabricator via cfe-commits]

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

Looks good, thank you!




Comment at: lib/Format/Format.cpp:1517
 
-for (auto &Line : AnnotatedLines) {
-  for (FormatToken *FormatTok = Line->First; FormatTok;
+auto CheckLineTokens = [&Keywords](const AnnotatedLine &Line) {
+  for (const FormatToken *FormatTok = Line.First; FormatTok;

Maybe choose a name that indicates what the bool result value means, e.g. 
LinesContainObjCCode or something.


Repository:
  rC Clang

https://reviews.llvm.org/D44790



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

[PATCH] D44790: [clang-format] Fix ObjC style guesser to also iterate over child lines

[Ben Hamilton via Phabricator via cfe-commits]

benhamilton updated this revision to Diff 139471.
benhamilton added a comment.

CheckLineTokens -> LineContainsObjCCode


Repository:
  rC Clang

https://reviews.llvm.org/D44790

Files:
  lib/Format/Format.cpp
  unittests/Format/FormatTest.cpp


Index: unittests/Format/FormatTest.cpp
===
--- unittests/Format/FormatTest.cpp
+++ unittests/Format/FormatTest.cpp
@@ -12162,6 +12162,13 @@
   guessLanguage("foo.h", "int(^foo[(kNumEntries + 10)])(char, float);"));
 }
 
+TEST_F(FormatTest, GuessLanguageWithChildLines) {
+  EXPECT_EQ(FormatStyle::LK_Cpp,
+guessLanguage("foo.h", "#define FOO ({ std::string s; })"));
+  EXPECT_EQ(FormatStyle::LK_ObjC,
+guessLanguage("foo.h", "#define FOO ({ NSString *s; })"));
+}
+
 } // end namespace
 } // end namespace format
 } // end namespace clang
Index: lib/Format/Format.cpp
===
--- lib/Format/Format.cpp
+++ lib/Format/Format.cpp
@@ -1514,8 +1514,8 @@
 "UIView",
 };
 
-for (auto &Line : AnnotatedLines) {
-  for (FormatToken *FormatTok = Line->First; FormatTok;
+auto LineContainsObjCCode = [&Keywords](const AnnotatedLine &Line) {
+  for (const FormatToken *FormatTok = Line.First; FormatTok;
FormatTok = FormatTok->Next) {
 if ((FormatTok->Previous && FormatTok->Previous->is(tok::at) &&
  (FormatTok->isObjCAtKeyword(tok::objc_interface) ||
@@ -1536,6 +1536,15 @@
   return true;
 }
   }
+  return false;
+};
+for (auto Line : AnnotatedLines) {
+  if (LineContainsObjCCode(*Line))
+return true;
+  for (auto ChildLine : Line->Children) {
+if (LineContainsObjCCode(*ChildLine))
+  return true;
+  }
 }
 return false;
   }


Index: unittests/Format/FormatTest.cpp
===
--- unittests/Format/FormatTest.cpp
+++ unittests/Format/FormatTest.cpp
@@ -12162,6 +12162,13 @@
   guessLanguage("foo.h", "int(^foo[(kNumEntries + 10)])(char, float);"));
 }
 
+TEST_F(FormatTest, GuessLanguageWithChildLines) {
+  EXPECT_EQ(FormatStyle::LK_Cpp,
+guessLanguage("foo.h", "#define FOO ({ std::string s; })"));
+  EXPECT_EQ(FormatStyle::LK_ObjC,
+guessLanguage("foo.h", "#define FOO ({ NSString *s; })"));
+}
+
 } // end namespace
 } // end namespace format
 } // end namespace clang
Index: lib/Format/Format.cpp
===
--- lib/Format/Format.cpp
+++ lib/Format/Format.cpp
@@ -1514,8 +1514,8 @@
 "UIView",
 };
 
-for (auto &Line : AnnotatedLines) {
-  for (FormatToken *FormatTok = Line->First; FormatTok;
+auto LineContainsObjCCode = [&Keywords](const AnnotatedLine &Line) {
+  for (const FormatToken *FormatTok = Line.First; FormatTok;
FormatTok = FormatTok->Next) {
 if ((FormatTok->Previous && FormatTok->Previous->is(tok::at) &&
  (FormatTok->isObjCAtKeyword(tok::objc_interface) ||
@@ -1536,6 +1536,15 @@
   return true;
 }
   }
+  return false;
+};
+for (auto Line : AnnotatedLines) {
+  if (LineContainsObjCCode(*Line))
+return true;
+  for (auto ChildLine : Line->Children) {
+if (LineContainsObjCCode(*ChildLine))
+  return true;
+  }
 }
 return false;
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D44790: [clang-format] Fix ObjC style guesser to also iterate over child lines

[Ben Hamilton via Phabricator via cfe-commits]

benhamilton marked an inline comment as done.
benhamilton added inline comments.



Comment at: lib/Format/Format.cpp:1517
 
-for (auto &Line : AnnotatedLines) {
-  for (FormatToken *FormatTok = Line->First; FormatTok;
+auto CheckLineTokens = [&Keywords](const AnnotatedLine &Line) {
+  for (const FormatToken *FormatTok = Line.First; FormatTok;

djasper wrote:
> Maybe choose a name that indicates what the bool result value means, e.g. 
> LinesContainObjCCode or something.
Done, thanks!


Repository:
  rC Clang

https://reviews.llvm.org/D44790



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

[PATCH] D44749: [OpenMP][Clang] Add call to global data sharing stack initialization on the workers side

[Phabricator via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rC328219: [OpenMP][Clang] Add call to global data sharing 
stack initialization on the… (authored by gbercea, committed by ).

Repository:
  rC Clang

https://reviews.llvm.org/D44749

Files:
  lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
  test/OpenMP/nvptx_data_sharing.cpp


Index: test/OpenMP/nvptx_data_sharing.cpp
===
--- test/OpenMP/nvptx_data_sharing.cpp
+++ test/OpenMP/nvptx_data_sharing.cpp
@@ -27,6 +27,11 @@
   }
 }
 
+/// = In the worker function = ///
+// CK1: {{.*}}define internal void 
@__omp_offloading{{.*}}test_ds{{.*}}_worker()
+// CK1: call void @llvm.nvvm.barrier0()
+// CK1: call void @__kmpc_data_sharing_init_stack
+
 /// = In the kernel function = ///
 
 // CK1: {{.*}}define void @__omp_offloading{{.*}}test_ds{{.*}}()
Index: lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
===
--- lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
+++ lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
@@ -801,6 +801,11 @@
   // Wait for parallel work
   syncCTAThreads(CGF);
 
+  // For data sharing, we need to initialize the stack for workers.
+  CGF.EmitRuntimeCall(
+  createNVPTXRuntimeFunction(
+  OMPRTL_NVPTX__kmpc_data_sharing_init_stack));
+
   Address WorkFn =
   CGF.CreateDefaultAlignTempAlloca(CGF.Int8PtrTy, /*Name=*/"work_fn");
   Address ExecStatus =


Index: test/OpenMP/nvptx_data_sharing.cpp
===
--- test/OpenMP/nvptx_data_sharing.cpp
+++ test/OpenMP/nvptx_data_sharing.cpp
@@ -27,6 +27,11 @@
   }
 }
 
+/// = In the worker function = ///
+// CK1: {{.*}}define internal void @__omp_offloading{{.*}}test_ds{{.*}}_worker()
+// CK1: call void @llvm.nvvm.barrier0()
+// CK1: call void @__kmpc_data_sharing_init_stack
+
 /// = In the kernel function = ///
 
 // CK1: {{.*}}define void @__omp_offloading{{.*}}test_ds{{.*}}()
Index: lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
===
--- lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
+++ lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
@@ -801,6 +801,11 @@
   // Wait for parallel work
   syncCTAThreads(CGF);
 
+  // For data sharing, we need to initialize the stack for workers.
+  CGF.EmitRuntimeCall(
+  createNVPTXRuntimeFunction(
+  OMPRTL_NVPTX__kmpc_data_sharing_init_stack));
+
   Address WorkFn =
   CGF.CreateDefaultAlignTempAlloca(CGF.Int8PtrTy, /*Name=*/"work_fn");
   Address ExecStatus =
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r328219 - [OpenMP][Clang] Add call to global data sharing stack initialization on the workers side

[Gheorghe-Teodor Bercea via cfe-commits]

Author: gbercea
Date: Thu Mar 22 10:33:27 2018
New Revision: 328219

URL: http://llvm.org/viewvc/llvm-project?rev=328219&view=rev
Log:
[OpenMP][Clang] Add call to global data sharing stack initialization on the 
workers side

Summary: The workers also need to initialize the global stack. The call to the 
initialization function needs to happen after the kernel_init() function is 
called by the master. This ensures that the per-team data structures of the 
runtime have been initialized.

Reviewers: ABataev, grokos, carlo.bertolli, caomhin

Reviewed By: ABataev

Subscribers: jholewinski, guansong, cfe-commits

Differential Revision: https://reviews.llvm.org/D44749

Modified:
cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
cfe/trunk/test/OpenMP/nvptx_data_sharing.cpp

Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp?rev=328219&r1=328218&r2=328219&view=diff
==
--- cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp Thu Mar 22 10:33:27 2018
@@ -801,6 +801,11 @@ void CGOpenMPRuntimeNVPTX::emitWorkerLoo
   // Wait for parallel work
   syncCTAThreads(CGF);
 
+  // For data sharing, we need to initialize the stack for workers.
+  CGF.EmitRuntimeCall(
+  createNVPTXRuntimeFunction(
+  OMPRTL_NVPTX__kmpc_data_sharing_init_stack));
+
   Address WorkFn =
   CGF.CreateDefaultAlignTempAlloca(CGF.Int8PtrTy, /*Name=*/"work_fn");
   Address ExecStatus =

Modified: cfe/trunk/test/OpenMP/nvptx_data_sharing.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/nvptx_data_sharing.cpp?rev=328219&r1=328218&r2=328219&view=diff
==
--- cfe/trunk/test/OpenMP/nvptx_data_sharing.cpp (original)
+++ cfe/trunk/test/OpenMP/nvptx_data_sharing.cpp Thu Mar 22 10:33:27 2018
@@ -27,6 +27,11 @@ void test_ds(){
   }
 }
 
+/// = In the worker function = ///
+// CK1: {{.*}}define internal void 
@__omp_offloading{{.*}}test_ds{{.*}}_worker()
+// CK1: call void @llvm.nvvm.barrier0()
+// CK1: call void @__kmpc_data_sharing_init_stack
+
 /// = In the kernel function = ///
 
 // CK1: {{.*}}define void @__omp_offloading{{.*}}test_ds{{.*}}()


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

r328220 - [clang-format] Fix ObjC style guesser to also iterate over child lines

[Ben Hamilton via cfe-commits]

Author: benhamilton
Date: Thu Mar 22 10:37:19 2018
New Revision: 328220

URL: http://llvm.org/viewvc/llvm-project?rev=328220&view=rev
Log:
[clang-format] Fix ObjC style guesser to also iterate over child lines

Summary:
When I wrote `ObjCHeaderStyleGuesser`, I incorrectly assumed the
correct way to iterate over all tokens in `AnnotatedLine` was to
iterate over the linked list tokens starting with
`AnnotatedLine::First`.

However, `AnnotatedLine` also contains a vector
`AnnotedLine::Children` with child `AnnotedLine`s which have their own
tokens which we need to iterate over.

Because I didn't iterate over the tokens in the children lines, the
ObjC style guesser would fail on syntax like:

  #define FOO ({ NSString *s = ... })

as the statement(s) inside { ... } are child lines.

This fixes the bug and adds a test. I confirmed the test
failed before the fix, and passed after the fix.

Test Plan: New tests added. Ran tests with:
  % make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests

Reviewers: djasper, jolesiak, Wizard

Reviewed By: djasper

Subscribers: klimek, cfe-commits

Differential Revision: https://reviews.llvm.org/D44790

Modified:
cfe/trunk/lib/Format/Format.cpp
cfe/trunk/unittests/Format/FormatTest.cpp

Modified: cfe/trunk/lib/Format/Format.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/Format.cpp?rev=328220&r1=328219&r2=328220&view=diff
==
--- cfe/trunk/lib/Format/Format.cpp (original)
+++ cfe/trunk/lib/Format/Format.cpp Thu Mar 22 10:37:19 2018
@@ -1514,8 +1514,8 @@ private:
 "UIView",
 };
 
-for (auto &Line : AnnotatedLines) {
-  for (FormatToken *FormatTok = Line->First; FormatTok;
+auto LineContainsObjCCode = [&Keywords](const AnnotatedLine &Line) {
+  for (const FormatToken *FormatTok = Line.First; FormatTok;
FormatTok = FormatTok->Next) {
 if ((FormatTok->Previous && FormatTok->Previous->is(tok::at) &&
  (FormatTok->isObjCAtKeyword(tok::objc_interface) ||
@@ -1536,6 +1536,15 @@ private:
   return true;
 }
   }
+  return false;
+};
+for (auto Line : AnnotatedLines) {
+  if (LineContainsObjCCode(*Line))
+return true;
+  for (auto ChildLine : Line->Children) {
+if (LineContainsObjCCode(*ChildLine))
+  return true;
+  }
 }
 return false;
   }

Modified: cfe/trunk/unittests/Format/FormatTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTest.cpp?rev=328220&r1=328219&r2=328220&view=diff
==
--- cfe/trunk/unittests/Format/FormatTest.cpp (original)
+++ cfe/trunk/unittests/Format/FormatTest.cpp Thu Mar 22 10:37:19 2018
@@ -12166,6 +12166,13 @@ TEST_F(FormatTest, GuessLanguageWithCare
   guessLanguage("foo.h", "int(^foo[(kNumEntries + 10)])(char, float);"));
 }
 
+TEST_F(FormatTest, GuessLanguageWithChildLines) {
+  EXPECT_EQ(FormatStyle::LK_Cpp,
+guessLanguage("foo.h", "#define FOO ({ std::string s; })"));
+  EXPECT_EQ(FormatStyle::LK_ObjC,
+guessLanguage("foo.h", "#define FOO ({ NSString *s; })"));
+}
+
 } // end namespace
 } // end namespace format
 } // end namespace clang


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

[PATCH] D44790: [clang-format] Fix ObjC style guesser to also iterate over child lines

[Ben Hamilton via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
benhamilton marked an inline comment as done.
Closed by commit rL328220: [clang-format] Fix ObjC style guesser to also 
iterate over child lines (authored by benhamilton, committed by ).
Herald added a subscriber: llvm-commits.

Repository:
  rL LLVM

https://reviews.llvm.org/D44790

Files:
  cfe/trunk/lib/Format/Format.cpp
  cfe/trunk/unittests/Format/FormatTest.cpp


Index: cfe/trunk/lib/Format/Format.cpp
===
--- cfe/trunk/lib/Format/Format.cpp
+++ cfe/trunk/lib/Format/Format.cpp
@@ -1514,8 +1514,8 @@
 "UIView",
 };
 
-for (auto &Line : AnnotatedLines) {
-  for (FormatToken *FormatTok = Line->First; FormatTok;
+auto LineContainsObjCCode = [&Keywords](const AnnotatedLine &Line) {
+  for (const FormatToken *FormatTok = Line.First; FormatTok;
FormatTok = FormatTok->Next) {
 if ((FormatTok->Previous && FormatTok->Previous->is(tok::at) &&
  (FormatTok->isObjCAtKeyword(tok::objc_interface) ||
@@ -1536,6 +1536,15 @@
   return true;
 }
   }
+  return false;
+};
+for (auto Line : AnnotatedLines) {
+  if (LineContainsObjCCode(*Line))
+return true;
+  for (auto ChildLine : Line->Children) {
+if (LineContainsObjCCode(*ChildLine))
+  return true;
+  }
 }
 return false;
   }
Index: cfe/trunk/unittests/Format/FormatTest.cpp
===
--- cfe/trunk/unittests/Format/FormatTest.cpp
+++ cfe/trunk/unittests/Format/FormatTest.cpp
@@ -12166,6 +12166,13 @@
   guessLanguage("foo.h", "int(^foo[(kNumEntries + 10)])(char, float);"));
 }
 
+TEST_F(FormatTest, GuessLanguageWithChildLines) {
+  EXPECT_EQ(FormatStyle::LK_Cpp,
+guessLanguage("foo.h", "#define FOO ({ std::string s; })"));
+  EXPECT_EQ(FormatStyle::LK_ObjC,
+guessLanguage("foo.h", "#define FOO ({ NSString *s; })"));
+}
+
 } // end namespace
 } // end namespace format
 } // end namespace clang


Index: cfe/trunk/lib/Format/Format.cpp
===
--- cfe/trunk/lib/Format/Format.cpp
+++ cfe/trunk/lib/Format/Format.cpp
@@ -1514,8 +1514,8 @@
 "UIView",
 };
 
-for (auto &Line : AnnotatedLines) {
-  for (FormatToken *FormatTok = Line->First; FormatTok;
+auto LineContainsObjCCode = [&Keywords](const AnnotatedLine &Line) {
+  for (const FormatToken *FormatTok = Line.First; FormatTok;
FormatTok = FormatTok->Next) {
 if ((FormatTok->Previous && FormatTok->Previous->is(tok::at) &&
  (FormatTok->isObjCAtKeyword(tok::objc_interface) ||
@@ -1536,6 +1536,15 @@
   return true;
 }
   }
+  return false;
+};
+for (auto Line : AnnotatedLines) {
+  if (LineContainsObjCCode(*Line))
+return true;
+  for (auto ChildLine : Line->Children) {
+if (LineContainsObjCCode(*ChildLine))
+  return true;
+  }
 }
 return false;
   }
Index: cfe/trunk/unittests/Format/FormatTest.cpp
===
--- cfe/trunk/unittests/Format/FormatTest.cpp
+++ cfe/trunk/unittests/Format/FormatTest.cpp
@@ -12166,6 +12166,13 @@
   guessLanguage("foo.h", "int(^foo[(kNumEntries + 10)])(char, float);"));
 }
 
+TEST_F(FormatTest, GuessLanguageWithChildLines) {
+  EXPECT_EQ(FormatStyle::LK_Cpp,
+guessLanguage("foo.h", "#define FOO ({ std::string s; })"));
+  EXPECT_EQ(FormatStyle::LK_ObjC,
+guessLanguage("foo.h", "#define FOO ({ NSString *s; })"));
+}
+
 } // end namespace
 } // end namespace format
 } // end namespace clang
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D44788: Add an option to support debug fission on implicit ThinLTO.

[Yunlian Jiang via Phabricator via cfe-commits]

yunlian added a comment.

I have another one https://reviews.llvm.org/D44792 on LLVM side.


Repository:
  rC Clang

https://reviews.llvm.org/D44788



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

Re: r328134 - [Builtins] Overload __builtin_operator_new/delete to allow forwarding to usual allocation/deallocation functions.

[Galina Kistanova via cfe-commits]

Hello Eric,

One of added tests fails on the next builder:
http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/8624

. . .
Failing Tests:
   . . .
Clang :: SemaCXX/builtin-operator-new-delete.cpp

Please have a look?

It is not good idea to keep the bot red for too long. This hides new
problem which later hard to track down.

Thanks

Galina


On Wed, Mar 21, 2018 at 12:19 PM, Eric Fiselier via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: ericwf
> Date: Wed Mar 21 12:19:48 2018
> New Revision: 328134
>
> URL: http://llvm.org/viewvc/llvm-project?rev=328134&view=rev
> Log:
> [Builtins] Overload __builtin_operator_new/delete to allow forwarding to
> usual allocation/deallocation functions.
>
> Summary:
> Libc++'s default allocator uses `__builtin_operator_new` and
> `__builtin_operator_delete` in order to allow the calls to new/delete to be
> ellided. However, libc++ now needs to support over-aligned types in the
> default allocator. In order to support this without disabling the existing
> optimization Clang needs to support calling the aligned new overloads from
> the builtins.
>
> See llvm.org/PR22634 for more information about the libc++ bug.
>
> This patch changes `__builtin_operator_new`/`__builtin_operator_delete`
> to call any usual `operator new`/`operator delete` function. It does this
> by performing overload resolution with the arguments passed to the builtin
> to determine which allocation function to call. If the selected function is
> not a usual allocation function a diagnostic is issued.
>
> One open issue is if the `align_val_t` overloads should be considered
> "usual" when `LangOpts::AlignedAllocation` is disabled.
>
>
> In order to allow libc++ to detect this new behavior the value for
> `__has_builtin(__builtin_operator_new)` has been updated to `201802`.
>
> Reviewers: rsmith, majnemer, aaron.ballman, erik.pilkington, bogner,
> ahatanak
>
> Reviewed By: rsmith
>
> Subscribers: cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D43047
>
> Added:
> cfe/trunk/test/CodeGenCXX/builtin-operator-new-delete.cpp
> cfe/trunk/test/SemaCXX/builtin-operator-new-delete.cpp
> Modified:
> cfe/trunk/include/clang/Basic/Builtins.def
> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> cfe/trunk/include/clang/Sema/Sema.h
> cfe/trunk/lib/CodeGen/CGBuiltin.cpp
> cfe/trunk/lib/CodeGen/CGExprCXX.cpp
> cfe/trunk/lib/CodeGen/CodeGenFunction.h
> cfe/trunk/lib/Lex/PPMacroExpansion.cpp
> cfe/trunk/lib/Sema/SemaChecking.cpp
> cfe/trunk/lib/Sema/SemaExprCXX.cpp
>
> Modified: cfe/trunk/include/clang/Basic/Builtins.def
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Basic/Builtins.def?rev=328134&r1=328133&r2=328134&view=diff
> 
> ==
> --- cfe/trunk/include/clang/Basic/Builtins.def (original)
> +++ cfe/trunk/include/clang/Basic/Builtins.def Wed Mar 21 12:19:48 2018
> @@ -1371,8 +1371,8 @@ BUILTIN(__builtin_smulll_overflow, "bSLL
>
>  // Clang builtins (not available in GCC).
>  BUILTIN(__builtin_addressof, "v*v&", "nct")
> -BUILTIN(__builtin_operator_new, "v*z", "c")
> -BUILTIN(__builtin_operator_delete, "vv*", "n")
> +BUILTIN(__builtin_operator_new, "v*z", "tc")
> +BUILTIN(__builtin_operator_delete, "vv*", "tn")
>  BUILTIN(__builtin_char_memchr, "c*cC*iz", "n")
>
>  // Safestack builtins
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/
> DiagnosticSemaKinds.td?rev=328134&r1=328133&r2=328134&view=diff
> 
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Wed Mar 21
> 12:19:48 2018
> @@ -7627,6 +7627,11 @@ def err_destroying_operator_delete_not_u
>"alignment parameter">;
>  def note_implicit_delete_this_in_destructor_here : Note<
>"while checking implicit 'delete this' for virtual destructor">;
> +def err_builtin_operator_new_delete_not_usual : Error<
> +  "call to '%select{__builtin_operator_new|__builtin_operator_delete}0' "
> +  "selects non-usual %select{allocation|deallocation}0 function">;
> +def note_non_usual_function_declared_here : Note<
> +  "non-usual %0 declared here">;
>
>  // C++ literal operators
>  def err_literal_operator_outside_namespace : Error<
>
> Modified: cfe/trunk/include/clang/Sema/Sema.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Sema/Sema.h?rev=328134&r1=328133&r2=328134&view=diff
> 
> ==
> --- cfe/trunk/include/clang/Sema/Sema.h (original)
> +++ cfe/trunk/include/clang/Sema/Sema.h Wed Mar 21 12:19:48 2018
> @@ -10376,6 +10376,8 @@ private:
>ExprResult SemaBuiltinNontemporalOverloaded(ExprResult TheCallResult);
>ExprResult SemaA

Re: r328134 - [Builtins] Overload __builtin_operator_new/delete to allow forwarding to usual allocation/deallocation functions.

[Eric Fiselier via cfe-commits]

Sorry, I didn't see the failure yesterday.

I'll get on it or revert it.

On Thu, Mar 22, 2018 at 11:51 AM, Galina Kistanova 
wrote:

> Hello Eric,
>
> One of added tests fails on the next builder:
> http://lab.llvm.org:8011/builders/llvm-clang-x86_64-
> expensive-checks-win/builds/8624
>
> . . .
> Failing Tests:
>. . .
> Clang :: SemaCXX/builtin-operator-new-delete.cpp
>
> Please have a look?
>
> It is not good idea to keep the bot red for too long. This hides new
> problem which later hard to track down.
>
> Thanks
>
> Galina
>
>
> On Wed, Mar 21, 2018 at 12:19 PM, Eric Fiselier via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: ericwf
>> Date: Wed Mar 21 12:19:48 2018
>> New Revision: 328134
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=328134&view=rev
>> Log:
>> [Builtins] Overload __builtin_operator_new/delete to allow forwarding to
>> usual allocation/deallocation functions.
>>
>> Summary:
>> Libc++'s default allocator uses `__builtin_operator_new` and
>> `__builtin_operator_delete` in order to allow the calls to new/delete to be
>> ellided. However, libc++ now needs to support over-aligned types in the
>> default allocator. In order to support this without disabling the existing
>> optimization Clang needs to support calling the aligned new overloads from
>> the builtins.
>>
>> See llvm.org/PR22634 for more information about the libc++ bug.
>>
>> This patch changes `__builtin_operator_new`/`__builtin_operator_delete`
>> to call any usual `operator new`/`operator delete` function. It does this
>> by performing overload resolution with the arguments passed to the builtin
>> to determine which allocation function to call. If the selected function is
>> not a usual allocation function a diagnostic is issued.
>>
>> One open issue is if the `align_val_t` overloads should be considered
>> "usual" when `LangOpts::AlignedAllocation` is disabled.
>>
>>
>> In order to allow libc++ to detect this new behavior the value for
>> `__has_builtin(__builtin_operator_new)` has been updated to `201802`.
>>
>> Reviewers: rsmith, majnemer, aaron.ballman, erik.pilkington, bogner,
>> ahatanak
>>
>> Reviewed By: rsmith
>>
>> Subscribers: cfe-commits
>>
>> Differential Revision: https://reviews.llvm.org/D43047
>>
>> Added:
>> cfe/trunk/test/CodeGenCXX/builtin-operator-new-delete.cpp
>> cfe/trunk/test/SemaCXX/builtin-operator-new-delete.cpp
>> Modified:
>> cfe/trunk/include/clang/Basic/Builtins.def
>> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
>> cfe/trunk/include/clang/Sema/Sema.h
>> cfe/trunk/lib/CodeGen/CGBuiltin.cpp
>> cfe/trunk/lib/CodeGen/CGExprCXX.cpp
>> cfe/trunk/lib/CodeGen/CodeGenFunction.h
>> cfe/trunk/lib/Lex/PPMacroExpansion.cpp
>> cfe/trunk/lib/Sema/SemaChecking.cpp
>> cfe/trunk/lib/Sema/SemaExprCXX.cpp
>>
>> Modified: cfe/trunk/include/clang/Basic/Builtins.def
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/
>> Basic/Builtins.def?rev=328134&r1=328133&r2=328134&view=diff
>> 
>> ==
>> --- cfe/trunk/include/clang/Basic/Builtins.def (original)
>> +++ cfe/trunk/include/clang/Basic/Builtins.def Wed Mar 21 12:19:48 2018
>> @@ -1371,8 +1371,8 @@ BUILTIN(__builtin_smulll_overflow, "bSLL
>>
>>  // Clang builtins (not available in GCC).
>>  BUILTIN(__builtin_addressof, "v*v&", "nct")
>> -BUILTIN(__builtin_operator_new, "v*z", "c")
>> -BUILTIN(__builtin_operator_delete, "vv*", "n")
>> +BUILTIN(__builtin_operator_new, "v*z", "tc")
>> +BUILTIN(__builtin_operator_delete, "vv*", "tn")
>>  BUILTIN(__builtin_char_memchr, "c*cC*iz", "n")
>>
>>  // Safestack builtins
>>
>> Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/
>> Basic/DiagnosticSemaKinds.td?rev=328134&r1=328133&r2=328134&view=diff
>> 
>> ==
>> --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
>> +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Wed Mar 21
>> 12:19:48 2018
>> @@ -7627,6 +7627,11 @@ def err_destroying_operator_delete_not_u
>>"alignment parameter">;
>>  def note_implicit_delete_this_in_destructor_here : Note<
>>"while checking implicit 'delete this' for virtual destructor">;
>> +def err_builtin_operator_new_delete_not_usual : Error<
>> +  "call to '%select{__builtin_operator_new|__builtin_operator_delete}0'
>> "
>> +  "selects non-usual %select{allocation|deallocation}0 function">;
>> +def note_non_usual_function_declared_here : Note<
>> +  "non-usual %0 declared here">;
>>
>>  // C++ literal operators
>>  def err_literal_operator_outside_namespace : Error<
>>
>> Modified: cfe/trunk/include/clang/Sema/Sema.h
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/
>> Sema/Sema.h?rev=328134&r1=328133&r2=328134&view=diff
>> ==

r328224 - Set dso_local on builtin functions.

[Rafael Espindola via cfe-commits]

Author: rafael
Date: Thu Mar 22 11:03:13 2018
New Revision: 328224

URL: http://llvm.org/viewvc/llvm-project?rev=328224&view=rev
Log:
Set dso_local on builtin functions.

The difference between CreateRuntimeFunction and CreateBuiltinFunction
is that CreateBuiltinFunction would not set dllimport or dso_local.

To keep the current semantics, just forward to CreateRuntimeFunction
with Local=true so it doesn't add dllimport.

Modified:
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/test/CodeGen/mingw-long-double.c

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=328224&r1=328223&r2=328224&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Thu Mar 22 11:03:13 2018
@@ -2640,13 +2640,7 @@ CodeGenModule::CreateRuntimeFunction(llv
 llvm::Constant *
 CodeGenModule::CreateBuiltinFunction(llvm::FunctionType *FTy, StringRef Name,
  llvm::AttributeList ExtraAttrs) {
-  llvm::Constant *C =
-  GetOrCreateLLVMFunction(Name, FTy, GlobalDecl(), /*ForVTable=*/false,
-  /*DontDefer=*/false, /*IsThunk=*/false, 
ExtraAttrs);
-  if (auto *F = dyn_cast(C))
-if (F->empty())
-  F->setCallingConv(getRuntimeCC());
-  return C;
+  return CreateRuntimeFunction(FTy, Name, ExtraAttrs, true);
 }
 
 /// isTypeConstant - Determine whether an object of this type can be emitted

Modified: cfe/trunk/test/CodeGen/mingw-long-double.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/mingw-long-double.c?rev=328224&r1=328223&r2=328224&view=diff
==
--- cfe/trunk/test/CodeGen/mingw-long-double.c (original)
+++ cfe/trunk/test/CodeGen/mingw-long-double.c Thu Mar 22 11:03:13 2018
@@ -42,6 +42,6 @@ long double _Complex TestLDC(long double
 // GNU64: define dso_local void @TestLDC({ x86_fp80, x86_fp80 }* noalias sret 
%agg.result, { x86_fp80, x86_fp80 }* %x)
 // MSC64: define dso_local void @TestLDC({ double, double }* noalias sret 
%agg.result, { double, double }* %x)
 
-// GNU32: declare void @__mulxc3
-// GNU64: declare void @__mulxc3
-// MSC64: declare void @__muldc3
+// GNU32: declare dso_local void @__mulxc3
+// GNU64: declare dso_local void @__mulxc3
+// MSC64: declare dso_local void @__muldc3


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

[PATCH] D44710: Set dso_local on builtin functions

[Rafael Avila de Espindola via Phabricator via cfe-commits]

espindola closed this revision.
espindola added a comment.

328224


https://reviews.llvm.org/D44710



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

[libcxx] r328225 - Fix improperly failing test - and the code it was testing. Thanks to Stephan Lavavej for the catch.

[Marshall Clow via cfe-commits]

Author: marshall
Date: Thu Mar 22 11:27:28 2018
New Revision: 328225

URL: http://llvm.org/viewvc/llvm-project?rev=328225&view=rev
Log:
Fix improperly failing test - and the code it was testing. Thanks to Stephan 
Lavavej for the catch.

Modified:
libcxx/trunk/include/ostream

libcxx/trunk/test/std/utilities/memory/unique.ptr/unique.ptr.special/io.fail.cpp

Modified: libcxx/trunk/include/ostream
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/ostream?rev=328225&r1=328224&r2=328225&view=diff
==
--- libcxx/trunk/include/ostream (original)
+++ libcxx/trunk/include/ostream Thu Mar 22 11:27:28 2018
@@ -1071,19 +1071,17 @@ operator<<(basic_ostream<_CharT, _Traits
 return __os << __p.get();
 }
 
-#ifndef _LIBCPP_HAS_NO_DECLTYPE
 template
 inline _LIBCPP_INLINE_VISIBILITY
 typename enable_if
 <
-is_same&>() << declval<_Yp>())>::type>::value,
+is_same&>() << declval::pointer>()))>::type>::value,
 basic_ostream<_CharT, _Traits>&
 >::type
 operator<<(basic_ostream<_CharT, _Traits>& __os, unique_ptr<_Yp, _Dp> const& 
__p)
 {
 return __os << __p.get();
 }
-#endif
 
 template 
 basic_ostream<_CharT, _Traits>&

Modified: 
libcxx/trunk/test/std/utilities/memory/unique.ptr/unique.ptr.special/io.fail.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/utilities/memory/unique.ptr/unique.ptr.special/io.fail.cpp?rev=328225&r1=328224&r2=328225&view=diff
==
--- 
libcxx/trunk/test/std/utilities/memory/unique.ptr/unique.ptr.special/io.fail.cpp
 (original)
+++ 
libcxx/trunk/test/std/utilities/memory/unique.ptr/unique.ptr.special/io.fail.cpp
 Thu Mar 22 11:27:28 2018
@@ -24,11 +24,12 @@
 #include 
 #include 
 
-class A {};
+#include "min_allocator.h"
+#include "deleter_types.h"
 
 int main()
 {
-std::unique_ptr p(new A);
+std::unique_ptr> p;
 std::ostringstream os;
-os << p;
+os << p; // expected-error {{invalid operands to binary expression}}
 }


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

[PATCH] D44539: [Sema][Objective-C] Add check to warn when property of objc type has assign attribute

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

We added the `unsafe_unretained` property attribute as part of ARC because we 
were introducing `__unsafe_retained` as a type qualifier and we wanted all the 
type qualifiers to have corresponding attribute spellings.  `assign` is the 
much-older attribute, and its non-owning behavior was widely understood.  In 
fact, we briefly considered naming the qualifier `__assign`, but we quickly 
decided that that we wanted a more explicit name for the ARC age.

I like the idea of this warning, but I need to float it to our internal 
Objective-C language group before we can accept it.


Repository:
  rC Clang

https://reviews.llvm.org/D44539



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

[PATCH] D44796: Set dso_local on vtables

[Rafael Avila de Espindola via Phabricator via cfe-commits]

espindola created this revision.
espindola added reviewers: rnk, echristo.

https://reviews.llvm.org/D44796

Files:
  lib/CodeGen/ItaniumCXXABI.cpp
  test/CodeGenCXX/dllexport.cpp


Index: test/CodeGenCXX/dllexport.cpp
===
--- test/CodeGenCXX/dllexport.cpp
+++ test/CodeGenCXX/dllexport.cpp
@@ -41,6 +41,8 @@
 // GNU-NOT: @ExternGlobalDecl
 __declspec(dllexport) extern int ExternGlobalDecl;
 
+// GNU-DAG: @_ZTVN10__cxxabiv117__class_type_infoE = external dso_local global
+
 // dllexport implies a definition.
 // MSC-DAG: @"?GlobalDef@@3HA" = dso_local dllexport global i32 0, align 4
 // GNU-DAG: @GlobalDef= dso_local dllexport global i32 0, align 4
Index: lib/CodeGen/ItaniumCXXABI.cpp
===
--- lib/CodeGen/ItaniumCXXABI.cpp
+++ lib/CodeGen/ItaniumCXXABI.cpp
@@ -2848,6 +2848,7 @@
 
   const char *VTableName = nullptr;
 
+  const CXXRecordDecl *RD = nullptr;
   switch (Ty->getTypeClass()) {
 #define TYPE(Class, Base)
 #define ABSTRACT_TYPE(Class, Base)
@@ -2899,8 +2900,7 @@
 break;
 
   case Type::Record: {
-const CXXRecordDecl *RD =
-  cast(cast(Ty)->getDecl());
+RD = cast(cast(Ty)->getDecl());
 
 if (!RD->hasDefinition() || !RD->getNumBases()) {
   VTableName = ClassTypeInfo;
@@ -2948,6 +2948,7 @@
 
   llvm::Constant *VTable =
 CGM.getModule().getOrInsertGlobal(VTableName, CGM.Int8PtrTy);
+  CGM.setGVProperties(cast(VTable->stripPointerCasts()), 
RD);
 
   llvm::Type *PtrDiffTy =
 CGM.getTypes().ConvertType(CGM.getContext().getPointerDiffType());


Index: test/CodeGenCXX/dllexport.cpp
===
--- test/CodeGenCXX/dllexport.cpp
+++ test/CodeGenCXX/dllexport.cpp
@@ -41,6 +41,8 @@
 // GNU-NOT: @ExternGlobalDecl
 __declspec(dllexport) extern int ExternGlobalDecl;
 
+// GNU-DAG: @_ZTVN10__cxxabiv117__class_type_infoE = external dso_local global
+
 // dllexport implies a definition.
 // MSC-DAG: @"?GlobalDef@@3HA" = dso_local dllexport global i32 0, align 4
 // GNU-DAG: @GlobalDef= dso_local dllexport global i32 0, align 4
Index: lib/CodeGen/ItaniumCXXABI.cpp
===
--- lib/CodeGen/ItaniumCXXABI.cpp
+++ lib/CodeGen/ItaniumCXXABI.cpp
@@ -2848,6 +2848,7 @@
 
   const char *VTableName = nullptr;
 
+  const CXXRecordDecl *RD = nullptr;
   switch (Ty->getTypeClass()) {
 #define TYPE(Class, Base)
 #define ABSTRACT_TYPE(Class, Base)
@@ -2899,8 +2900,7 @@
 break;
 
   case Type::Record: {
-const CXXRecordDecl *RD =
-  cast(cast(Ty)->getDecl());
+RD = cast(cast(Ty)->getDecl());
 
 if (!RD->hasDefinition() || !RD->getNumBases()) {
   VTableName = ClassTypeInfo;
@@ -2948,6 +2948,7 @@
 
   llvm::Constant *VTable =
 CGM.getModule().getOrInsertGlobal(VTableName, CGM.Int8PtrTy);
+  CGM.setGVProperties(cast(VTable->stripPointerCasts()), RD);
 
   llvm::Type *PtrDiffTy =
 CGM.getTypes().ConvertType(CGM.getContext().getPointerDiffType());
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D44798: [libFuzzer] Use OptForFuzzing attribute with -fsanitize=fuzzer.

[Matt Morehouse via Phabricator via cfe-commits]

morehouse created this revision.
morehouse added reviewers: kcc, vitalybuka.

Disables certain CMP optimizations to improve fuzzing signal under -O1
and -O2.

Switches all fuzzer tests to -O2 except for a few leak tests where the
leak is optimized out under -O2.


https://reviews.llvm.org/D44798

Files:
  clang/lib/CodeGen/CodeGenFunction.cpp
  compiler-rt/test/fuzzer/SimpleCmpTest.cpp
  compiler-rt/test/fuzzer/SwapCmpTest.cpp
  compiler-rt/test/fuzzer/fuzzer-leak.test
  compiler-rt/test/fuzzer/lit.cfg
  compiler-rt/test/fuzzer/trace-malloc-threaded.test

Index: compiler-rt/test/fuzzer/trace-malloc-threaded.test
===
--- compiler-rt/test/fuzzer/trace-malloc-threaded.test
+++ compiler-rt/test/fuzzer/trace-malloc-threaded.test
@@ -2,7 +2,9 @@
 // printing a stack trace repeatedly
 UNSUPPORTED: darwin
 
-RUN: %cpp_compiler %S/TraceMallocThreadedTest.cpp -o %t-TraceMallocThreadedTest
+// Avoid optimizing since it causes the malloc to go away.
+RUN: %no_opt_cpp_compiler %S/TraceMallocThreadedTest.cpp -o \
+RUN:   %t-TraceMallocThreadedTest
 
 RUN: %t-TraceMallocThreadedTest -trace_malloc=2 -runs=1 2>&1 | FileCheck %s
 CHECK: {{MALLOC\[[0-9]+] +0x[0-9]+ 5639}}
Index: compiler-rt/test/fuzzer/lit.cfg
===
--- compiler-rt/test/fuzzer/lit.cfg
+++ compiler-rt/test/fuzzer/lit.cfg
@@ -49,23 +49,25 @@
 libfuzzer_src_root = os.path.join(config.compiler_rt_src_root, "lib", "fuzzer")
 config.substitutions.append(('%libfuzzer_src', libfuzzer_src_root))
 
-def generate_compiler_cmd(is_cpp=True, fuzzer_enabled=True):
+def generate_compiler_cmd(is_cpp=True, fuzzer_enabled=True, optimize=True):
   compiler_cmd = config.c_compiler
   if config.clang and config.stdlib == 'libc++':
 link_cmd = '-stdlib=libc++ -Wl,-rpath=%s' % config.llvm_library_dir
   elif config.clang and config.stdlib == 'static-libc++':
 link_cmd = '-stdlib=libc++ -lc++abi -static-libstdc++ -Wl,-rpath=%s' % config.llvm_library_dir
   else:
 link_cmd = '-lc++' if any(x in config.target_triple for x in ('darwin', 'freebsd')) else '-lstdc++'
   std_cmd = '--driver-mode=g++ -std=c++11' if is_cpp else ''
+  opt_cmd = '-O2' if optimize else '-O0'
   sanitizers = ['address']
   if fuzzer_enabled:
 sanitizers.append('fuzzer')
   sanitizers_cmd = ('-fsanitize=%s' % ','.join(sanitizers))
   isysroot_cmd = config.osx_sysroot_flag if config.osx_sysroot_flag else ''
   include_cmd = '-I%s' % libfuzzer_src_root
-  return '%s %s %s -gline-tables-only %s %s %s' % (
-  compiler_cmd, std_cmd, link_cmd, isysroot_cmd, sanitizers_cmd, include_cmd)
+  return '%s %s %s %s -gline-tables-only %s %s %s' % (
+  compiler_cmd, std_cmd, opt_cmd, link_cmd, isysroot_cmd, sanitizers_cmd,
+  include_cmd)
 
 config.substitutions.append(('%cpp_compiler',
   generate_compiler_cmd(is_cpp=True, fuzzer_enabled=True)
@@ -82,3 +84,11 @@
 config.substitutions.append(('%no_fuzzer_c_compiler',
   generate_compiler_cmd(is_cpp=False, fuzzer_enabled=False)
   ))
+
+config.substitutions.append(('%no_opt_cpp_compiler',
+  generate_compiler_cmd(is_cpp=True, fuzzer_enabled=True, optimize=False)
+  ))
+
+config.substitutions.append(('%no_opt_c_compiler',
+  generate_compiler_cmd(is_cpp=False, fuzzer_enabled=True, optimize=False)
+  ))
Index: compiler-rt/test/fuzzer/fuzzer-leak.test
===
--- compiler-rt/test/fuzzer/fuzzer-leak.test
+++ compiler-rt/test/fuzzer/fuzzer-leak.test
@@ -1,6 +1,9 @@
 REQUIRES: lsan
-RUN: %cpp_compiler %S/LeakTest.cpp -o %t-LeakTest
-RUN: %cpp_compiler %S/ThreadedLeakTest.cpp -o %t-ThreadedLeakTest
+
+// Avoid optimizing since it causes these leaks to go away.
+RUN: %no_opt_cpp_compiler %S/LeakTest.cpp -o %t-LeakTest
+RUN: %no_opt_cpp_compiler %S/ThreadedLeakTest.cpp -o %t-ThreadedLeakTest
+
 RUN: %cpp_compiler %S/LeakTimeoutTest.cpp -o %t-LeakTimeoutTest
 
 RUN: rm -rf %t-corpus && mkdir -p %t-corpus
Index: compiler-rt/test/fuzzer/SwapCmpTest.cpp
===
--- compiler-rt/test/fuzzer/SwapCmpTest.cpp
+++ compiler-rt/test/fuzzer/SwapCmpTest.cpp
@@ -11,22 +11,22 @@
   if (Size < 14) return 0;
   uint64_t x = 0;
   uint32_t y = 0;
-  uint16_t z = 0;
+  uint32_t z = 0;
   memcpy(&x, Data, sizeof(x));
   memcpy(&y, Data + Size / 2, sizeof(y));
   memcpy(&z, Data + Size - sizeof(z), sizeof(z));
 
   x = __builtin_bswap64(x);
   y = __builtin_bswap32(y);
-  z = __builtin_bswap16(z);
+  z = __builtin_bswap32(z);
   const bool k32bit = sizeof(void*) == 4;
 
   if ((k32bit || x == 0x46555A5A5A5A5546ULL) &&
   z == 0x4F4B &&
   y == 0x66757A7A &&
   true
   ) {
-if (Data[Size - 3] == 'z') {
+if (Data[Size - 5] == 'z') {
   fprintf(stderr, "BINGO; Found the target\n");
   exit(1);
 }
Index: compiler-rt/test/fuzzer/SimpleCmpTest.cpp

[PATCH] D44798: [libFuzzer] Use OptForFuzzing attribute with -fsanitize=fuzzer.

[Matt Morehouse via Phabricator via cfe-commits]

morehouse added a comment.

16-bit variables are switched to 32-bit variables in SwapCmpTest.cpp and 
SimpleCmpTest.cpp.  This is because those tests rely on libFuzzer's TraceCMP 
heuristic to pass, but 16-bit compares are not considered for the heuristic.

The only reason the test used to pass was because under `-O0` 16-bit compares 
are promoted to 32-bit compares.


https://reviews.llvm.org/D44798



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

[libcxx] r328229 - Un-XFAIL a test under new GCC version; the GCC bug has been fixed

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Thu Mar 22 12:18:08 2018
New Revision: 328229

URL: http://llvm.org/viewvc/llvm-project?rev=328229&view=rev
Log:
Un-XFAIL a test under new GCC version; the GCC bug has been fixed

Modified:

libcxx/trunk/test/std/utilities/function.objects/comparisons/constexpr_init.pass.cpp

Modified: 
libcxx/trunk/test/std/utilities/function.objects/comparisons/constexpr_init.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/utilities/function.objects/comparisons/constexpr_init.pass.cpp?rev=328229&r1=328228&r2=328229&view=diff
==
--- 
libcxx/trunk/test/std/utilities/function.objects/comparisons/constexpr_init.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/utilities/function.objects/comparisons/constexpr_init.pass.cpp
 Thu Mar 22 12:18:08 2018
@@ -9,7 +9,7 @@
 
 // UNSUPPORTED: c++98, c++03, c++11
 
-// XFAIL: gcc-7, gcc-8
+// XFAIL: gcc-7
 
 // 
 


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

[PATCH] D44764: [clangd] Move GTest printers to separate file

[Marc-Andre Laperle via Phabricator via cfe-commits]

malaperle added a comment.

In https://reviews.llvm.org/D44764#1045682, @ilya-biryukov wrote:

> In https://reviews.llvm.org/D44764#1045648, @simark wrote:
>
> > We could create a file `ClangdTesting.h" which includes everything tested 
> > related (gtest, gmock, printers, syncapi, etc). The convention would be 
> > that test files would just include that.
>
>
> Yeah, sounds good. I would exclude syncapi from the list, though. Not all 
> tests should necessarily depend on `ClangdServer`.
>  @sammccall , @ioeric , @hokein, @bkramer are you on board with the idea to 
> have an umbrella header for gtest+gmock+printers?


Sounds good to me too. I can update the patch once there is an agreement.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D44764



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

Re: r328040 - Set dso_local on string literals.

[Joerg Sonnenberger via cfe-commits]

On Tue, Mar 20, 2018 at 05:01:24PM -0700, Rafael Avila de Espindola wrote:
> Joerg Sonnenberger via cfe-commits  writes:
> 
> > On Tue, Mar 20, 2018 at 08:42:55PM -, Rafael Espindola via cfe-commits 
> > wrote:
> >> Author: rafael
> >> Date: Tue Mar 20 13:42:55 2018
> >> New Revision: 328040
> >> 
> >> URL: http://llvm.org/viewvc/llvm-project?rev=328040&view=rev
> >> Log:
> >> Set dso_local on string literals.
> >
> > I wonder if unnamed_addr shouldn't imply that in general?
> 
> I don't think so. For example, a language where functions cannot be
> compared for equality could mark all functions unnamed_addr. It could
> still support interposition, which requires that they are not dso_local.

I don't think that argument makes sense. The address is not named, that
strongly implies that can't be interpositioned either.

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

[PATCH] D44796: Set dso_local on vtables

[Reid Kleckner via Phabricator via cfe-commits]

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

lgtm


https://reviews.llvm.org/D44796



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

[PATCH] D44801: Add the -fsanitize=shadow-call-stack flag

[Vlad Tsyrklevich via Phabricator via cfe-commits]

vlad.tsyrklevich created this revision.
vlad.tsyrklevich added a reviewer: pcc.
Herald added a subscriber: cfe-commits.

Add support for the -fsanitize=shadow-call-stack flag which causes clang
to add ShadowCallStack attribute to functions compiled with that flag
enabled.


Repository:
  rC Clang

https://reviews.llvm.org/D44801

Files:
  docs/ShadowCallStack.rst
  docs/index.rst
  include/clang/Basic/Sanitizers.def
  lib/CodeGen/CGDeclCXX.cpp
  lib/CodeGen/CodeGenFunction.cpp
  lib/Driver/SanitizerArgs.cpp
  lib/Driver/ToolChain.cpp
  lib/Lex/PPMacroExpansion.cpp
  test/CodeGen/shadowcallstack-attr.c

Index: test/CodeGen/shadowcallstack-attr.c
===
--- /dev/null
+++ test/CodeGen/shadowcallstack-attr.c
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -triple x86_64-linux-unknown -emit-llvm -o - %s -fsanitize=shadow-call-stack | FileCheck %s
+
+__attribute__((no_sanitize("shadow-call-stack")))
+int foo(int *a) { return *a; }
+
+ int bar(int *a) { return *a; }
+
+// CHECK: define i32 @foo(i32* %a) #[[FOO_ATTR:[0-9]+]] {
+// CHECK: define i32 @bar(i32* %a) #[[BAR_ATTR:[0-9]+]] {
+
+// CHECK-NOT: attributes #[[FOO_ATTR]] = { {{.*}}shadowcallstack{{.*}} }
+// CHECK: attributes #[[BAR_ATTR]] = { {{.*}}shadowcallstack{{.*}} }
Index: lib/Lex/PPMacroExpansion.cpp
===
--- lib/Lex/PPMacroExpansion.cpp
+++ lib/Lex/PPMacroExpansion.cpp
@@ -1275,6 +1275,8 @@
   .Case("is_union", LangOpts.CPlusPlus)
   .Case("modules", LangOpts.Modules)
   .Case("safe_stack", LangOpts.Sanitize.has(SanitizerKind::SafeStack))
+  .Case("shadow_call_stack",
+LangOpts.Sanitize.has(SanitizerKind::ShadowCallStack))
   .Case("tls", PP.getTargetInfo().isTLSSupported())
   .Case("underlying_type", LangOpts.CPlusPlus)
   .Default(false);
Index: lib/Driver/ToolChain.cpp
===
--- lib/Driver/ToolChain.cpp
+++ lib/Driver/ToolChain.cpp
@@ -814,6 +814,8 @@
   getTriple().getArch() == llvm::Triple::wasm32 ||
   getTriple().getArch() == llvm::Triple::wasm64)
 Res |= CFIICall;
+  if (getTriple().getArch() == llvm::Triple::x86_64)
+Res |= ShadowCallStack;
   return Res;
 }
 
Index: lib/Driver/SanitizerArgs.cpp
===
--- lib/Driver/SanitizerArgs.cpp
+++ lib/Driver/SanitizerArgs.cpp
@@ -343,7 +343,10 @@
   std::make_pair(Scudo, Address | HWAddress | Leak | Thread | Memory |
 KernelAddress | Efficiency),
   std::make_pair(SafeStack, Address | HWAddress | Leak | Thread | Memory |
-KernelAddress | Efficiency)};
+KernelAddress | Efficiency),
+  std::make_pair(ShadowCallStack, Address | HWAddress | Leak | Thread |
+  Memory | KernelAddress | Efficiency |
+  SafeStack)};
 
   // Enable toolchain specific default sanitizers if not explicitly disabled.
   SanitizerMask Default = TC.getDefaultSanitizers() & ~AllRemove;
Index: lib/CodeGen/CodeGenFunction.cpp
===
--- lib/CodeGen/CodeGenFunction.cpp
+++ lib/CodeGen/CodeGenFunction.cpp
@@ -861,6 +861,8 @@
 Fn->addFnAttr(llvm::Attribute::SanitizeMemory);
   if (SanOpts.has(SanitizerKind::SafeStack))
 Fn->addFnAttr(llvm::Attribute::SafeStack);
+  if (SanOpts.has(SanitizerKind::ShadowCallStack))
+Fn->addFnAttr(llvm::Attribute::ShadowCallStack);
 
   // Ignore TSan memory acesses from within ObjC/ObjC++ dealloc, initialize,
   // .cxx_destruct, __destroy_helper_block_ and all of their calees at run time.
Index: lib/CodeGen/CGDeclCXX.cpp
===
--- lib/CodeGen/CGDeclCXX.cpp
+++ lib/CodeGen/CGDeclCXX.cpp
@@ -343,6 +343,10 @@
   !isInSanitizerBlacklist(SanitizerKind::SafeStack, Fn, Loc))
 Fn->addFnAttr(llvm::Attribute::SafeStack);
 
+  if (getLangOpts().Sanitize.has(SanitizerKind::ShadowCallStack) &&
+  !isInSanitizerBlacklist(SanitizerKind::ShadowCallStack, Fn, Loc))
+Fn->addFnAttr(llvm::Attribute::ShadowCallStack);
+
   return Fn;
 }
 
Index: include/clang/Basic/Sanitizers.def
===
--- include/clang/Basic/Sanitizers.def
+++ include/clang/Basic/Sanitizers.def
@@ -110,6 +110,9 @@
 // Safe Stack
 SANITIZER("safe-stack", SafeStack)
 
+// Shadow Call Stack
+SANITIZER("shadow-call-stack", ShadowCallStack)
+
 // -fsanitize=undefined includes all the sanitizers which have low overhead, no
 // ABI or address space layout implications, and only catch undefined behavior.
 SANITIZER_GROUP("undefined", Undefined,
Index: docs/index.rst
===
--- docs/index.rst
+++ docs/index.rst
@@ -36,

[PATCH] D44295: [clang-tidy] Detects and fixes calls to grand-...parent virtual methods instead of calls to parent's virtual methods

[Zinovy Nis via Phabricator via cfe-commits]

zinovy.nis updated this revision to Diff 139496.
zinovy.nis added a comment.

Aaron, I applied the changes you suggest.

I also found and fixed a new case when grandparent method is called via 
'typedef'ed or 'using' type. There's also a new test (class C2) for it.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D44295

Files:
  clang-tidy/bugprone/BugproneTidyModule.cpp
  clang-tidy/bugprone/CMakeLists.txt
  clang-tidy/bugprone/ParentVirtualCallCheck.cpp
  clang-tidy/bugprone/ParentVirtualCallCheck.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/bugprone-parent-virtual-call.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/bugprone-parent-virtual-call.cpp

Index: test/clang-tidy/bugprone-parent-virtual-call.cpp
===
--- /dev/null
+++ test/clang-tidy/bugprone-parent-virtual-call.cpp
@@ -0,0 +1,150 @@
+// RUN: %check_clang_tidy %s bugprone-parent-virtual-call %t
+
+extern int foo();
+
+class A {
+public:
+  A() = default;
+  virtual ~A() = default;
+
+  virtual int virt_1() { return foo() + 1; }
+  virtual int virt_2() { return foo() + 2; }
+
+  int non_virt() { return foo() + 3; }
+  static int stat() { return foo() + 4; }
+};
+
+class B : public A {
+public:
+  B() = default;
+
+  // Nothing to fix: calls to direct parent.
+  int virt_1() override { return A::virt_1() + 3; }
+  int virt_2() override { return A::virt_2() + 4; }
+};
+
+class C : public B {
+public:
+  int virt_1() override { return A::virt_1() + B::virt_1(); }
+  // CHECK-MESSAGES: :[[@LINE-1]]:34: warning: qualified name 'A::virt_1' refers to a member which was overridden in subclass 'B' [bugprone-parent-virtual-call]
+  // CHECK-FIXES:  int virt_1() override { return B::virt_1() + B::virt_1(); }
+  int virt_2() override { return A::virt_1() + B::virt_1(); }
+  // CHECK-MESSAGES: :[[@LINE-1]]:34: warning: qualified name 'A::virt_1' refers to a member which was overridden in subclass 'B' [bugprone-parent-virtual-call]
+  // CHECK-FIXES:  int virt_2() override { return B::virt_1() + B::virt_1(); }
+
+  // Test that non-virtual and static methods are not affected by this cherker.
+  int method_c() { return A::stat() + A::non_virt(); }
+};
+
+// Check aliased type names
+using A1 = A;
+typedef A A2;
+
+class C2 : public B {
+public:
+  int virt_1() override { return A1::virt_1() + A2::virt_1(); }
+  // CHECK-MESSAGES: :[[@LINE-1]]:34: warning: qualified name 'A::virt_1' refers to a member which was overridden in subclass 'B' [bugprone-parent-virtual-call]
+  // CHECK-MESSAGES: :[[@LINE-2]]:49: warning: qualified name 'A::virt_1' refers to a member which was overridden in subclass 'B' [bugprone-parent-virtual-call]
+  // CHECK-FIXES:  int virt_1() override { return B::virt_1() + B::virt_1(); }
+};
+
+// Test that the check affects grand-grand..-parent calls too.
+class D : public C {
+public:
+  int virt_1() override { return A::virt_1() + B::virt_1() + D::virt_1(); }
+  // CHECK-MESSAGES: :[[@LINE-1]]:34: warning: qualified name 'A::virt_1' refers to a member which was overridden in subclass 'C' [bugprone-parent-virtual-call]
+  // CHECK-MESSAGES: :[[@LINE-2]]:48: warning: qualified name 'B::virt_1' refers to a member which was overridden in subclass 'C' [bugprone-parent-virtual-call]
+  // CHECK-FIXES:  int virt_1() override { return C::virt_1() + C::virt_1() + D::virt_1(); }
+  int virt_2() override { return A::virt_1() + B::virt_1() + D::virt_1(); }
+  // CHECK-MESSAGES: :[[@LINE-1]]:34: warning: qualified name 'A::virt_1' refers to a member which was overridden in subclass 'C' [bugprone-parent-virtual-call]
+  // CHECK-MESSAGES: :[[@LINE-2]]:48: warning: qualified name 'B::virt_1' refers to a member which was overridden in subclass 'C' [bugprone-parent-virtual-call]
+  // CHECK-FIXES:  int virt_2() override { return C::virt_1() + C::virt_1() + D::virt_1(); }
+};
+
+// Test classes in anonymous namespaces.
+namespace {
+class BN : public A {
+public:
+  int virt_1() override { return A::virt_1() + 3; }
+  int virt_2() override { return A::virt_2() + 4; }
+};
+} // namespace N
+
+class CN : public BN {
+public:
+  int virt_1() override { return A::virt_1() + BN::virt_1(); }
+  // CHECK-MESSAGES: :[[@LINE-1]]:34: warning: qualified name 'A::virt_1' refers to a member which was overridden in subclass 'BN' [bugprone-parent-virtual-call]
+  // CHECK-FIXES:  int virt_1() override { return BN::virt_1() + BN::virt_1(); }
+  int virt_2() override { return A::virt_1() + BN::virt_1(); }
+  // CHECK-MESSAGES: :[[@LINE-1]]:34: warning: qualified name 'A::virt_1' refers to a member which was overridden in subclass 'BN' [bugprone-parent-virtual-call]
+  // CHECK-FIXES:  int virt_2() override { return BN::virt_1() + BN::virt_1(); }
+};
+
+// Test multiple inheritance fixes
+class AA {
+public:
+  AA() = default;
+  virtual ~AA() = default;
+
+  virtual int virt_1() { return foo() + 1; }
+  virtual int virt_2() { return foo() + 2; }
+
+  int non_virt() { return foo() + 

[PATCH] D44272: [clangd] Support incremental document syncing

[Simon Marchi via Phabricator via cfe-commits]

simark added inline comments.



Comment at: clangd/DraftStore.h:36
   /// Replace contents of the draft for \p File with \p Contents.
-  void updateDraft(PathRef File, StringRef Contents);
+  void addDraft(PathRef File, StringRef Contents);
+

ilya-biryukov wrote:
> ilya-biryukov wrote:
> > simark wrote:
> > > ilya-biryukov wrote:
> > > > Could we add versions from LSP's `VersionedTextDocumentIdentifier` here 
> > > > and make the relevant sanity checks?
> > > > Applying diffs to the wrong version will cause everything to fall 
> > > > apart, so we should detect this error and signal it to the client as 
> > > > soon as possible.
> > > I agree that applying diffs to the wrong version will break basically 
> > > everything, but even if we detect a version mismatch, I don't see what we 
> > > could do, since we don't have a mean to report the error to the client.  
> > > The only thing we could do is log it (which we already do.
> > If we couldn't apply a diff, we should return errors from all future 
> > operations on this file until it gets closed and reopened. Otherwise clangd 
> > and the editor would see inconsistent contents for the file and results 
> > provided by clangd would be unreliable.
> > The errors from any actions on the invalid file would actually be visible 
> > to the users.
> > 
> > The simplest way to achieve that is to remove the file from `DraftStore` 
> > and `ClangdServer` on errors from `updateDraft`.
> > This will give "calling action on non-tracked file" errors for future 
> > operations and the actual root cause can be figured out from the logs.
> We still ignore version numbers from the LSP.
> Is this another change that didn't get in?
The more I think about it, the less sure I am that this is the intended usage 
of the version.  The spec doesn't even say what the initial version of a file 
should be, 0 or 1?  Then, it just says that the version optionally contained in 
the `VersionedTextDocumentIdentifier` reflects the version of the document 
after having applied the edit.  But I don't think we can predict and validate 
what that version should be.  Most clients will probably just use a sequence 
number, but I guess they don't have to...

Also, I initially assumed that having N changes in the `contentChanges` array 
would mean that the version number would be bumped by N.  But now that I 
re-read it, there's really nothing that says it should behave like this.

I think that we should just record the version number and treat it as opaque, 
so that we can use it later when sending text edits to the client, for example. 
 The client can then verify that the edit is for the same version of the 
document that it has at the moment.

Therefore, I don't think it would really be useful in this patch.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D44272



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

[PATCH] D44295: [clang-tidy] Detects and fixes calls to grand-...parent virtual methods instead of calls to parent's virtual methods

[Zinovy Nis via Phabricator via cfe-commits]

zinovy.nis updated this revision to Diff 139499.
zinovy.nis marked an inline comment as done.
zinovy.nis added a comment.

camelCase last minute fix.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D44295

Files:
  clang-tidy/bugprone/BugproneTidyModule.cpp
  clang-tidy/bugprone/CMakeLists.txt
  clang-tidy/bugprone/ParentVirtualCallCheck.cpp
  clang-tidy/bugprone/ParentVirtualCallCheck.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/bugprone-parent-virtual-call.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/bugprone-parent-virtual-call.cpp

Index: test/clang-tidy/bugprone-parent-virtual-call.cpp
===
--- /dev/null
+++ test/clang-tidy/bugprone-parent-virtual-call.cpp
@@ -0,0 +1,150 @@
+// RUN: %check_clang_tidy %s bugprone-parent-virtual-call %t
+
+extern int foo();
+
+class A {
+public:
+  A() = default;
+  virtual ~A() = default;
+
+  virtual int virt_1() { return foo() + 1; }
+  virtual int virt_2() { return foo() + 2; }
+
+  int non_virt() { return foo() + 3; }
+  static int stat() { return foo() + 4; }
+};
+
+class B : public A {
+public:
+  B() = default;
+
+  // Nothing to fix: calls to direct parent.
+  int virt_1() override { return A::virt_1() + 3; }
+  int virt_2() override { return A::virt_2() + 4; }
+};
+
+class C : public B {
+public:
+  int virt_1() override { return A::virt_1() + B::virt_1(); }
+  // CHECK-MESSAGES: :[[@LINE-1]]:34: warning: qualified name 'A::virt_1' refers to a member which was overridden in subclass 'B' [bugprone-parent-virtual-call]
+  // CHECK-FIXES:  int virt_1() override { return B::virt_1() + B::virt_1(); }
+  int virt_2() override { return A::virt_1() + B::virt_1(); }
+  // CHECK-MESSAGES: :[[@LINE-1]]:34: warning: qualified name 'A::virt_1' refers to a member which was overridden in subclass 'B' [bugprone-parent-virtual-call]
+  // CHECK-FIXES:  int virt_2() override { return B::virt_1() + B::virt_1(); }
+
+  // Test that non-virtual and static methods are not affected by this cherker.
+  int method_c() { return A::stat() + A::non_virt(); }
+};
+
+// Check aliased type names
+using A1 = A;
+typedef A A2;
+
+class C2 : public B {
+public:
+  int virt_1() override { return A1::virt_1() + A2::virt_1(); }
+  // CHECK-MESSAGES: :[[@LINE-1]]:34: warning: qualified name 'A::virt_1' refers to a member which was overridden in subclass 'B' [bugprone-parent-virtual-call]
+  // CHECK-MESSAGES: :[[@LINE-2]]:49: warning: qualified name 'A::virt_1' refers to a member which was overridden in subclass 'B' [bugprone-parent-virtual-call]
+  // CHECK-FIXES:  int virt_1() override { return B::virt_1() + B::virt_1(); }
+};
+
+// Test that the check affects grand-grand..-parent calls too.
+class D : public C {
+public:
+  int virt_1() override { return A::virt_1() + B::virt_1() + D::virt_1(); }
+  // CHECK-MESSAGES: :[[@LINE-1]]:34: warning: qualified name 'A::virt_1' refers to a member which was overridden in subclass 'C' [bugprone-parent-virtual-call]
+  // CHECK-MESSAGES: :[[@LINE-2]]:48: warning: qualified name 'B::virt_1' refers to a member which was overridden in subclass 'C' [bugprone-parent-virtual-call]
+  // CHECK-FIXES:  int virt_1() override { return C::virt_1() + C::virt_1() + D::virt_1(); }
+  int virt_2() override { return A::virt_1() + B::virt_1() + D::virt_1(); }
+  // CHECK-MESSAGES: :[[@LINE-1]]:34: warning: qualified name 'A::virt_1' refers to a member which was overridden in subclass 'C' [bugprone-parent-virtual-call]
+  // CHECK-MESSAGES: :[[@LINE-2]]:48: warning: qualified name 'B::virt_1' refers to a member which was overridden in subclass 'C' [bugprone-parent-virtual-call]
+  // CHECK-FIXES:  int virt_2() override { return C::virt_1() + C::virt_1() + D::virt_1(); }
+};
+
+// Test classes in anonymous namespaces.
+namespace {
+class BN : public A {
+public:
+  int virt_1() override { return A::virt_1() + 3; }
+  int virt_2() override { return A::virt_2() + 4; }
+};
+} // namespace N
+
+class CN : public BN {
+public:
+  int virt_1() override { return A::virt_1() + BN::virt_1(); }
+  // CHECK-MESSAGES: :[[@LINE-1]]:34: warning: qualified name 'A::virt_1' refers to a member which was overridden in subclass 'BN' [bugprone-parent-virtual-call]
+  // CHECK-FIXES:  int virt_1() override { return BN::virt_1() + BN::virt_1(); }
+  int virt_2() override { return A::virt_1() + BN::virt_1(); }
+  // CHECK-MESSAGES: :[[@LINE-1]]:34: warning: qualified name 'A::virt_1' refers to a member which was overridden in subclass 'BN' [bugprone-parent-virtual-call]
+  // CHECK-FIXES:  int virt_2() override { return BN::virt_1() + BN::virt_1(); }
+};
+
+// Test multiple inheritance fixes
+class AA {
+public:
+  AA() = default;
+  virtual ~AA() = default;
+
+  virtual int virt_1() { return foo() + 1; }
+  virtual int virt_2() { return foo() + 2; }
+
+  int non_virt() { return foo() + 3; }
+  static int stat() { return foo() + 4; }
+};
+
+class BB_1 : virtual public AA {
+public:
+  BB_1() = default

[PATCH] D44295: [clang-tidy] Detects and fixes calls to grand-...parent virtual methods instead of calls to parent's virtual methods

[Zinovy Nis via Phabricator via cfe-commits]

zinovy.nis marked 9 inline comments as done.
zinovy.nis added inline comments.



Comment at: docs/clang-tidy/checks/bugprone-parent-virtual-call.rst:6
+
+Detects and fixes calls to grand-...parent virtual methods instead of calls
+to parent's virtual methods.

aaron.ballman wrote:
> This formulation is a bit odd because of the `grand-...parent` part. I would 
> reword to be more along the lines of: detects calls to qualified function 
> names that refer to a function that is not explicitly declared by a direct 
> base class.
>  that is not explicitly declared by a direct base class.

In fact, it detects calls to qualified function names

> that explicitly overridden in subclasses.




Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D44295



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

[PATCH] D44295: [clang-tidy] Detects and fixes calls to grand-...parent virtual methods instead of calls to parent's virtual methods

[Eugene Zelenko via Phabricator via cfe-commits]

Eugene.Zelenko added inline comments.



Comment at: docs/ReleaseNotes.rst:73
 
+- New `bugprone-parent-virtual-call
+  
`_
 check

Please rebase from trunk and use //:doc:// for link.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D44295



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

[PATCH] D44295: [clang-tidy] Detects and fixes calls to grand-...parent virtual methods instead of calls to parent's virtual methods

[Malcolm Parsons via Phabricator via cfe-commits]

malcolm.parsons added a comment.

Please add a test where the parent class is in a differently named namespace.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D44295



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

[PATCH] D44804: [StaticAnalyzer] Silence an unused variable warning. NFC.

[Mandeep Singh Grang via Phabricator via cfe-commits]

mgrang created this revision.
mgrang added reviewers: george.karpenkov, dcoughlin, dergachev.a.
Herald added subscribers: a.sidorin, szepet.

Repository:
  rC Clang

https://reviews.llvm.org/D44804

Files:
  lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp


Index: lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
===
--- lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
+++ lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
@@ -1930,7 +1930,7 @@
 }
 
 static Optional describeRegion(const MemRegion *MR) {
-  if (const auto *VR = dyn_cast_or_null(MR))
+  if (dyn_cast_or_null(MR))
 return std::string(cast(MR)->getDecl()->getName());
   // Once we support more storage locations for bindings,
   // this would need to be improved.


Index: lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
===
--- lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
+++ lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
@@ -1930,7 +1930,7 @@
 }
 
 static Optional describeRegion(const MemRegion *MR) {
-  if (const auto *VR = dyn_cast_or_null(MR))
+  if (dyn_cast_or_null(MR))
 return std::string(cast(MR)->getDecl()->getName());
   // Once we support more storage locations for bindings,
   // this would need to be improved.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D44804: [StaticAnalyzer] Silence an unused variable warning. NFC.

[George Karpenkov via Phabricator via cfe-commits]

george.karpenkov added a comment.

Actually, a better change would be to simply change `cast(MR)` to 
`VR`


Repository:
  rC Clang

https://reviews.llvm.org/D44804



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

Re: r328134 - [Builtins] Overload __builtin_operator_new/delete to allow forwarding to usual allocation/deallocation functions.

[Eric Fiselier via cfe-commits]

Just waiting on a build. It should be fixed shortly.
Sorry about the breakage.

/Eric

On Thu, Mar 22, 2018 at 11:56 AM, Eric Fiselier  wrote:

> Sorry, I didn't see the failure yesterday.
>
> I'll get on it or revert it.
>
> On Thu, Mar 22, 2018 at 11:51 AM, Galina Kistanova 
> wrote:
>
>> Hello Eric,
>>
>> One of added tests fails on the next builder:
>> http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensiv
>> e-checks-win/builds/8624
>>
>> . . .
>> Failing Tests:
>>. . .
>> Clang :: SemaCXX/builtin-operator-new-delete.cpp
>>
>> Please have a look?
>>
>> It is not good idea to keep the bot red for too long. This hides new
>> problem which later hard to track down.
>>
>> Thanks
>>
>> Galina
>>
>>
>> On Wed, Mar 21, 2018 at 12:19 PM, Eric Fiselier via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: ericwf
>>> Date: Wed Mar 21 12:19:48 2018
>>> New Revision: 328134
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=328134&view=rev
>>> Log:
>>> [Builtins] Overload __builtin_operator_new/delete to allow forwarding to
>>> usual allocation/deallocation functions.
>>>
>>> Summary:
>>> Libc++'s default allocator uses `__builtin_operator_new` and
>>> `__builtin_operator_delete` in order to allow the calls to new/delete to be
>>> ellided. However, libc++ now needs to support over-aligned types in the
>>> default allocator. In order to support this without disabling the existing
>>> optimization Clang needs to support calling the aligned new overloads from
>>> the builtins.
>>>
>>> See llvm.org/PR22634 for more information about the libc++ bug.
>>>
>>> This patch changes `__builtin_operator_new`/`__builtin_operator_delete`
>>> to call any usual `operator new`/`operator delete` function. It does this
>>> by performing overload resolution with the arguments passed to the builtin
>>> to determine which allocation function to call. If the selected function is
>>> not a usual allocation function a diagnostic is issued.
>>>
>>> One open issue is if the `align_val_t` overloads should be considered
>>> "usual" when `LangOpts::AlignedAllocation` is disabled.
>>>
>>>
>>> In order to allow libc++ to detect this new behavior the value for
>>> `__has_builtin(__builtin_operator_new)` has been updated to `201802`.
>>>
>>> Reviewers: rsmith, majnemer, aaron.ballman, erik.pilkington, bogner,
>>> ahatanak
>>>
>>> Reviewed By: rsmith
>>>
>>> Subscribers: cfe-commits
>>>
>>> Differential Revision: https://reviews.llvm.org/D43047
>>>
>>> Added:
>>> cfe/trunk/test/CodeGenCXX/builtin-operator-new-delete.cpp
>>> cfe/trunk/test/SemaCXX/builtin-operator-new-delete.cpp
>>> Modified:
>>> cfe/trunk/include/clang/Basic/Builtins.def
>>> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
>>> cfe/trunk/include/clang/Sema/Sema.h
>>> cfe/trunk/lib/CodeGen/CGBuiltin.cpp
>>> cfe/trunk/lib/CodeGen/CGExprCXX.cpp
>>> cfe/trunk/lib/CodeGen/CodeGenFunction.h
>>> cfe/trunk/lib/Lex/PPMacroExpansion.cpp
>>> cfe/trunk/lib/Sema/SemaChecking.cpp
>>> cfe/trunk/lib/Sema/SemaExprCXX.cpp
>>>
>>> Modified: cfe/trunk/include/clang/Basic/Builtins.def
>>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/
>>> Basic/Builtins.def?rev=328134&r1=328133&r2=328134&view=diff
>>> 
>>> ==
>>> --- cfe/trunk/include/clang/Basic/Builtins.def (original)
>>> +++ cfe/trunk/include/clang/Basic/Builtins.def Wed Mar 21 12:19:48 2018
>>> @@ -1371,8 +1371,8 @@ BUILTIN(__builtin_smulll_overflow, "bSLL
>>>
>>>  // Clang builtins (not available in GCC).
>>>  BUILTIN(__builtin_addressof, "v*v&", "nct")
>>> -BUILTIN(__builtin_operator_new, "v*z", "c")
>>> -BUILTIN(__builtin_operator_delete, "vv*", "n")
>>> +BUILTIN(__builtin_operator_new, "v*z", "tc")
>>> +BUILTIN(__builtin_operator_delete, "vv*", "tn")
>>>  BUILTIN(__builtin_char_memchr, "c*cC*iz", "n")
>>>
>>>  // Safestack builtins
>>>
>>> Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
>>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/
>>> Basic/DiagnosticSemaKinds.td?rev=328134&r1=328133&r2=328134&view=diff
>>> 
>>> ==
>>> --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
>>> +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Wed Mar 21
>>> 12:19:48 2018
>>> @@ -7627,6 +7627,11 @@ def err_destroying_operator_delete_not_u
>>>"alignment parameter">;
>>>  def note_implicit_delete_this_in_destructor_here : Note<
>>>"while checking implicit 'delete this' for virtual destructor">;
>>> +def err_builtin_operator_new_delete_not_usual : Error<
>>> +  "call to '%select{__builtin_operator_new|__builtin_operator_delete}0'
>>> "
>>> +  "selects non-usual %select{allocation|deallocation}0 function">;
>>> +def note_non_usual_function_declared_here : Note<
>>> +  "non-usual %0 declared here">;
>>>
>>>  // C++ literal operators
>>>  def err_literal_

[PATCH] D44804: [StaticAnalyzer] Silence an unused variable warning. NFC.

[Mandeep Singh Grang via Phabricator via cfe-commits]

mgrang updated this revision to Diff 139503.
mgrang added a comment.

Addressed comment.


Repository:
  rC Clang

https://reviews.llvm.org/D44804

Files:
  lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp


Index: lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
===
--- lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
+++ lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
@@ -1931,7 +1931,7 @@
 
 static Optional describeRegion(const MemRegion *MR) {
   if (const auto *VR = dyn_cast_or_null(MR))
-return std::string(cast(MR)->getDecl()->getName());
+return std::string(VR->getDecl()->getName());
   // Once we support more storage locations for bindings,
   // this would need to be improved.
   return None;


Index: lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
===
--- lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
+++ lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
@@ -1931,7 +1931,7 @@
 
 static Optional describeRegion(const MemRegion *MR) {
   if (const auto *VR = dyn_cast_or_null(MR))
-return std::string(cast(MR)->getDecl()->getName());
+return std::string(VR->getDecl()->getName());
   // Once we support more storage locations for bindings,
   // this would need to be improved.
   return None;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D44788: Add an option to support debug fission on implicit ThinLTO.

[Paul Robinson via Phabricator via cfe-commits]

probinson added a comment.

I don't think requiring a new option is a great user interface.  In existing 
use cases the location of the .dwo file matches the location of the output 
file.  Why is this one different?


Repository:
  rC Clang

https://reviews.llvm.org/D44788



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

[PATCH] D44804: [StaticAnalyzer] Silence an unused variable warning. NFC.

[George Karpenkov via Phabricator via cfe-commits]

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

LGTM, provided it compiles and tests run (`ninja check-clang`)


Repository:
  rC Clang

https://reviews.llvm.org/D44804



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

Re: [PATCH] D44788: Add an option to support debug fission on implicit ThinLTO.

[David Blaikie via cfe-commits]

In implicit ThinLTO, the object files are only temporary.

Sort of similar to using -gsplit-dwarf when compiling straight to an
executable (without using -c): "clang++ x.cpp y.cpp -o a.out" - where
should the .dwo files go then? If they go where the .o files go, then
they'll be in /tmp/ and get deleted either when the ocmpiler ends after it
runs the linker, or perhaps at some uncertain point in the future when the
temp space is reclaimed.
(granted, I'm not suggesting we support that actual case - it's not
terribly common for anyone who'd actually need -gsplit-dwarf - but the
implicit ThinLTO case looks quite similar for demonstration purposes)


On Thu, Mar 22, 2018 at 1:22 PM Paul Robinson via Phabricator <
revi...@reviews.llvm.org> wrote:

> probinson added a comment.
>
> I don't think requiring a new option is a great user interface.  In
> existing use cases the location of the .dwo file matches the location of
> the output file.  Why is this one different?
>
>
> Repository:
>   rC Clang
>
> https://reviews.llvm.org/D44788
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D44788: Add an option to support debug fission on implicit ThinLTO.

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a subscriber: yunlian.
dblaikie added a comment.

In implicit ThinLTO, the object files are only temporary.

Sort of similar to using -gsplit-dwarf when compiling straight to an
executable (without using -c): "clang++ x.cpp y.cpp -o a.out" - where
should the .dwo files go then? If they go where the .o files go, then
they'll be in /tmp/ and get deleted either when the ocmpiler ends after it
runs the linker, or perhaps at some uncertain point in the future when the
temp space is reclaimed.
(granted, I'm not suggesting we support that actual case - it's not
terribly common for anyone who'd actually need -gsplit-dwarf - but the
implicit ThinLTO case looks quite similar for demonstration purposes)


Repository:
  rC Clang

https://reviews.llvm.org/D44788



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

[PATCH] D44804: [StaticAnalyzer] Silence an unused variable warning. NFC.

[Mandeep Singh Grang via Phabricator via cfe-commits]

mgrang added a comment.

In https://reviews.llvm.org/D44804#1046086, @george.karpenkov wrote:

> LGTM, provided it compiles and tests run (`ninja check-clang`)


Thanks! Yes, I have already verified it compiles and ninja check-clang is clean.


Repository:
  rC Clang

https://reviews.llvm.org/D44804



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