- 09 Aug, 2018 1 commit
-
-
Clemens Hammacher authored
This allows to have only one version of {AreAliased} which has a clean implementation. R=mstarzinger@chromium.org Bug: v8:8015 Change-Id: I25c64a8c2077383129548773319799fac768521e Reviewed-on: https://chromium-review.googlesource.com/1167290 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#55007}
-
- 04 May, 2018 1 commit
-
-
Clemens Hammacher authored
macros.h already not only defines macros, but also templatized helpers like {bit_cast} and {arraysize}. Thus {implicit_cast} also belongs there. R=tebbi@chromium.org Bug: v8:7570 Change-Id: Iaea6075dad359d62498453575f22d73ca84e2323 Reviewed-on: https://chromium-review.googlesource.com/1042401 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52991}
-
- 28 Feb, 2018 1 commit
-
-
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: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#51636}
-
- 02 Feb, 2018 1 commit
-
-
jgruber authored
This check verifies that all .h files in the src/ directory have an include guard of the form #ifndef V8_PATH_TO_FILE_H_ #define V8_PATH_TO_FILE_H_ // ... #endif // V8_PATH_TO_FILE_H_ The check can be skipped with a magic comment: // PRESUBMIT_INTENTIONALLY_MISSING_INCLUDE_GUARD Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I0a7b96abec289ad60f64ba8418f1892a6969596d Reviewed-on: https://chromium-review.googlesource.com/897487Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#51079}
-
- 24 Oct, 2017 1 commit
-
-
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: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#48887}
-
- 21 Sep, 2017 1 commit
-
-
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: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#48110}
-
- 07 Aug, 2017 1 commit
-
-
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: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#47191}
-
- 04 Aug, 2017 1 commit
-
-
Tobias Tebbi authored
Bug: Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: I2e1b36303f8b9ad4a3dc4e488123e6e4ce8b02ec Reviewed-on: https://chromium-review.googlesource.com/533033 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#47149}
-
- 31 Jul, 2017 1 commit
-
-
Clemens Hammacher authored
R=ahaas@chromium.org Change-Id: Ie46dce0e417ce528bbd81aa6ef87ca63a9fcc869 Reviewed-on: https://chromium-review.googlesource.com/593613Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#47005}
-
- 09 Jun, 2017 1 commit
-
-
Clemens Hammacher authored
Introduce base::make_unique as a replacement for std::make_unique, introduced in C++14. Use it in the wasm code base to construct new objects and wrap them in a unique_ptr, making the code more compact and readable. R=ahaas@chromium.org BUG=v8:6474 Change-Id: I2b9c800edc456021b057f1e69d3c144889b1c9f4 Reviewed-on: https://chromium-review.googlesource.com/529167Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#45822}
-
- 30 May, 2017 1 commit
-
-
Clemens Hammacher authored
Both lazy initialization and static initialization (via static initializer) are bad. Fortunately, the arrays we are constructing are constant anyway, so we can just compute them at compile time. This is enforced by making them constexpr. This also saves all code needed for the initialization, and makes accesses to the tables faster, as they don't need any atomic operations (via LazyInstance). R=ahaas@chromium.org Change-Id: I7d3ba9b0f2602f596a6c71c8c567e0d1bc306268 Reviewed-on: https://chromium-review.googlesource.com/517083 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#45589}
-