1. 13 Feb, 2019 1 commit
  2. 28 Feb, 2018 1 commit
    • Nico Weber's avatar
      Make v8 build with -Wmicrosoft-cast under clang-cl. · 58b386c4
      Nico Weber authored
      gcc and clang (and the standard) don't allow implicit conversion of
      function pointers to object pointers. MSVC does allow that, and since
      system headers require this to work, clang-cl allows it too -- but
      it emits a -Wmicrosoft-cast warning (which we currently suppress in
      the Chromium build, but which we want to enable.)
      
      As a side effect, when printing a function pointer to a stream, MSVC
      (and clang-cl) will pick the operator<<(void*) overload, while gcc
      and clang will pick operator<<(bool) since the best allowed conversion
      they find is from function pointer to bool.
      
      To prevent the clang-cl warning, we need to make sure that we never
      directly print a function pointer to a stream. In v8, this requires
      two changes:
      
      1. Give PrintCheckOperand() an explicit specialization for function
         pointers and explicitly cast to void* there.  This ports
         https://codereview.chromium.org/2515283002/ to V8, and also fixes a
         bug on non-Windows where DCHECK() of function pointers would print
         "(1 vs 1)" instead of the function's addresses.
         (The bug remains with member function pointers,
         where it's not clear what to print instead of the 1.)
      
      2. has_output_operator<T> must not use operator<< on its argument
         in an evaluated context if T is a function pointer.  This patch
         modifies has_output_operator<> to use an unevaluated context instead,
         which is simpler than the current approach (and matches what Chromium's
         base does), but changes behavior    in minor (boring) ways
         (see template-utils-unittest.cc), since operator<<() is now
         called with a temporary and only operator<<() implementations callable
         with a temporary are considered.
         A more complicated but behavior-preserving alternative would be to
         add an explicit specialization for function pointers. You can see
         this variant in patch set 1 on gerrit.
      
      Bug: chromium:550065
      Change-Id: Idc2854d6c258b7fc0b959604006d8952a79eca3d
      Reviewed-on: https://chromium-review.googlesource.com/940004
      Commit-Queue: Nico Weber <thakis@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51636}
      58b386c4
  3. 24 Oct, 2017 1 commit
    • Clemens Hammacher's avatar
      Allow constexpr RegList construction from Registers · fd306a06
      Clemens Hammacher authored
      Before, the standard way to create a RegList was either:
      RegList list = (1 << 0) | (1 << 1) | ...
      or
      RegList list = rax.bit() | rdx.bit() | ...
      
      The first way allows to make the RegList constexpr, but needs comments
      to document which registers you are referring to, and it has no checks
      that all bits you set on the RegList actually belong to valid registers.
      The second one uses the symbolic names, hence is much more readable and
      makes it harder to construct invalid RegLists. It's not constexpr
      though, since the {bit()} method on the register types is not constexpr.
      
      This CL adds a constexpr accessor to get the code and bit of a
      constexpr Register, and adds a helper method to create a constexpr
      RegList like this:
      constexpr RegList list = Register::ListOf<rax, rdx, rdi>();
      
      This new method is used in a number of places to test its
      applicability. Other uses of the old pattern remain and can be cleaned
      up later.
      
      R=tebbi@chromium.org
      
      Change-Id: Ie7b1d6342dc5f316dcfedd0363b3540ad5e7f413
      Reviewed-on: https://chromium-review.googlesource.com/728026
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48887}
      fd306a06
  4. 28 Sep, 2017 1 commit
  5. 21 Sep, 2017 1 commit
    • Clemens Hammacher's avatar
      [base] Allow comparing enums in (D)CHECKs · 3a063911
      Clemens Hammacher authored
      In the current implementation, compilation would fail because
      operator<< is not defined for enum classes. For others, the compiler
      finds more than one operator<<, so it fails because it's ambiguous.
      
      This CL fixes this by printing the integer value for enums, uses the
      operator<< for all values that support it, and prints "<unprintable>"
      otherwise.
      
      Also, lots of unit tests.
      
      R=ishell@chromium.org
      
      Bug: v8:6837
      Change-Id: I895ed226672aa07213f9605e094b87af186ec2e4
      Reviewed-on: https://chromium-review.googlesource.com/671016
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48110}
      3a063911
  6. 07 Aug, 2017 1 commit
    • Clemens Hammacher's avatar
      Move helper struct from logging.h to template-utils.h · 84dc3679
      Clemens Hammacher authored
      I want to reuse the PassType helper in another CL, thus move it from
      logging.h to template-utils.h, and rename it to pass_value_or_ref to
      match other helpers there.
      Also, add a boolean template parameter to declare whether array
      dimensions should be removed. The default is to do so, which helps to
      reduce the number of template instantiations by always passing arrays
      as pointers.
      
      Also, fix the usages in logging.h to actually use that helper when
      instantiating other template functions. This will reduce the number of
      instantiations.
      
      And finally, we now have unit tests for the template utils, to document
      what we expect, and test that this works on all architectures.
      
      R=ishell@chromium.org, tebbi@chromium.org
      
      Change-Id: I1ef5d2a489a5cfc7601c5ab13748674e3aa86cd6
      Reviewed-on: https://chromium-review.googlesource.com/594247
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47191}
      84dc3679