- 10 May, 2021 1 commit
-
-
Clemens Backes authored
After updating our bots to use GCC 7.4, we do not need to support incomplete C++14 support any more. In particular, we can assume complete c++14 constexpr support now. This CL removes the V8_HAS_CXX14_CONSTEXPR and CONSTEXPR_DCHECK macros. The CONSTEXPR_DCHECKs are replaced by DCHECK and friend, or STATIC_ASSERT where possible. R=jgruber@chromium.org, leszeks@chromium.org, mlippautz@chromium.org Bug: v8:9686, v8:11384 Change-Id: I3a8769a0f54da7eb2cacc37ee23e5c97092e3051 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876847Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#74486}
-
- 23 Mar, 2021 1 commit
-
-
Seth Brenith authored
This is a reland of ef808d3b Original change's description: > [torque] Protect against printing Type* pointers > > I've noticed a frequent mistake within Torque is to use Type* pointers > with ostream's operator<<, which causes it to print a hex pointer rather > than a descriptive string. This can cause confusing error messages for > users of the Torque compiler. This change is an idea to prevent future > incidences of that problem by adding a template overload that will cause > a compilation failure if anybody tries to use Type* in this way. It > found two incorrect uses of Type*, which I've corrected. > > Bug: v8:7793 > Change-Id: I85fafb333a89f8a3fed4346bdd154d70846a63d1 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2748936 > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#73574} Bug: v8:7793 Change-Id: Id775c88d67c2fb4fbef38ef889c39dff3b6ff6b7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2778727Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#73608}
-
- 22 Mar, 2021 2 commits
-
-
Deepti Gandluri authored
This reverts commit ef808d3b. Reason for revert: Failures on TSAN: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20no-concurrent-marking/2981? Original change's description: > [torque] Protect against printing Type* pointers > > I've noticed a frequent mistake within Torque is to use Type* pointers > with ostream's operator<<, which causes it to print a hex pointer rather > than a descriptive string. This can cause confusing error messages for > users of the Torque compiler. This change is an idea to prevent future > incidences of that problem by adding a template overload that will cause > a compilation failure if anybody tries to use Type* in this way. It > found two incorrect uses of Type*, which I've corrected. > > Bug: v8:7793 > Change-Id: I85fafb333a89f8a3fed4346bdd154d70846a63d1 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2748936 > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#73574} Bug: v8:7793 Change-Id: Ieee470aa3cd176b9e1ad21fe39b9939edcef5bd6 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2778722 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Reviewed-by:
Seth Brenith <seth.brenith@microsoft.com> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#73576}
-
Seth Brenith authored
I've noticed a frequent mistake within Torque is to use Type* pointers with ostream's operator<<, which causes it to print a hex pointer rather than a descriptive string. This can cause confusing error messages for users of the Torque compiler. This change is an idea to prevent future incidences of that problem by adding a template overload that will cause a compilation failure if anybody tries to use Type* in this way. It found two incorrect uses of Type*, which I've corrected. Bug: v8:7793 Change-Id: I85fafb333a89f8a3fed4346bdd154d70846a63d1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2748936Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#73574}
-
- 16 Mar, 2021 1 commit
-
-
Ross McIlroy authored
Release-official builds strip error messages from CHECK messages. This can make it difficult to distinguish a CHECK crash location in crash reports. As such, instead of using V8_FatalNoContext, import the IMMEDIATE_CRASH macro from chromium and use that instead, which should cause a crash directly in the instruction stream so that the top stackframe on the crash report directly identifies the CHECK location that failed. More details here: https://docs.google.com/document/d/1tyMwzxUNH8BctM_urSQIYdcbwmzP4kTnwEjnFamBpKY Change-Id: I5b8175f19571834f790060d641db08d0b9c2c17b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2756223Reviewed-by:
Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#73430}
-
- 12 Mar, 2021 1 commit
-
-
Clemens Backes authored
We still get e.g. ClusterFuzz reports with enums printed as non-printable single-character strings (see linked bug). This CL fixes this, and also includes the integral enum value for enum that come with their own output operator. This makes error messages strictly better, at the cost of some more code per enum which is being used in a CHECK/DCHECK. Note that binary size of release builds is not affected, since we do not print the values there. R=nicohartmann@chromium.org Bug: v8:11384, chromium:1187484 Change-Id: I066b32f68440096babed9b629c7ffe3f2285cba8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2756226Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73373}
-
- 18 Jun, 2020 1 commit
-
-
Jakob Gruber authored
... in regexp bytecode {length,name} accessors and in peephole optimization. Bug: chromium:1095866 Change-Id: I78c89d35d796776b61eabf82b921f7582e431be7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250243Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#68400}
-
- 10 Jan, 2020 1 commit
-
-
Clemens Backes authored
When comparing objects which get printed to very long strings (e.g. collections like vectors), it's much more readable if they get printed to individual lines. Differences are much easier to spot then. This CL refactors the CHECK/DCHECK macros to print the left hand side and right-hand side in individual lines if any of them is longer than 50 characters. To that end, the {PrintCheckOperand} method (only used from {MakeCheckOpString}) is changed to return the string directly instead of printing to an output stream. R=mlippautz@chromium.org Change-Id: I6e24a5cbfeb1af53fa0aca2828e23f642b15569c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1991866Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#65705}
-
- 12 Nov, 2019 1 commit
-
-
Clemens Backes authored
This allows us to use them in constexpr contexts, just as DCHECK. There were some "constexpr" keywords missing, and we cannot have explicit template instantiations for constexpr. R=jkummerow@chromium.org Bug: v8:9810 Change-Id: Iba7c6ed4a16ea5077324880f59f7f0e17d1757a4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1910956Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64921}
-
- 13 May, 2019 1 commit
-
-
Peter Marshall authored
The FATAL macro (without arguments) is used by some other libraries e.g. protobuf and this causes conflicts. We only declared FATAL() previously, so go back to that behavior by declaring arguments for FATAL every time we define it. Change-Id: Ia4c280fd7a1f27c2031de2fb691d60083f361a9a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1607649 Auto-Submit: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#61440}
-
- 10 May, 2019 1 commit
-
-
Andrew Grieve authored
FATAL() calls with more than one argument are preserved. The rest of chrome does this as well. Stack traces and minidumps should be sufficient for analyzing the reason for crashes. This saves 110kb for Android arm32. Bug: chromium:958807 Change-Id: I88a1ec82f1ed7bd5e7dbccf6d645d5584f16de82 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1598159 Commit-Queue: Andrew Grieve <agrieve@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#61426}
-
- 20 Sep, 2018 1 commit
-
-
Florian Sattler authored
Fixing clang-tidy warning. Bug: v8:8015 Change-Id: I5686fa0c1ed73b17f592a012b00c08c575ae5387 Reviewed-on: https://chromium-review.googlesource.com/1234234Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Florian Sattler <sattlerf@google.com> Cr-Commit-Position: refs/heads/master@{#56062}
-
- 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}
-
- 13 Feb, 2018 1 commit
-
-
Camillo Bruni authored
FATAL(...) avoid creating literal strings for line number in release mode. Bug: v8:7310 Change-Id: I6a3e329adce36b0efcc240068f6a241d1cca4b6f Reviewed-on: https://chromium-review.googlesource.com/915066Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#51277}
-
- 19 Dec, 2017 1 commit
-
-
Clemens Hammacher authored
Remove comment about usage of FATAL, UNREACHABLE and UNIMPLEMENTED, which was deprecated since https://crrev.com/1410713006. Also, refactor the FATAL macro and use it for implementing UNREACHABLE and UNIMPLEMENTED, and in more code. The benefit over printf + CHECK(false) is that the compiler knows that FATAL will never return. R=bmeurer@chromium.org Change-Id: I8c2ab3b4e6edfe8eff5ec6fdf3d92b15d0ed7126 Reviewed-on: https://chromium-review.googlesource.com/832726Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#50183}
-
- 16 Oct, 2017 1 commit
-
-
Leszek Swirski authored
Bug: v8:6921 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: I3294568a550b829b0ec90147a4cdaefe169bb7cb Reviewed-on: https://chromium-review.googlesource.com/718206Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#48587}
-
- 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}
-
- 15 Sep, 2017 1 commit
-
-
Sigurdur Asgeirsson authored
Bug: chromium:763010 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I7d479f8abb16ffd7ffc19d3a6b58da01f5feddd0 Reviewed-on: https://chromium-review.googlesource.com/661054Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Sigurður Ásgeirsson <siggi@chromium.org> Cr-Commit-Position: refs/heads/master@{#48038}
-
- 31 Aug, 2017 1 commit
-
-
Clemens Hammacher authored
They violate the style guide, and cause problems for jumbo builds. This CL removes all occurrences in src/wasm except for the file wasm-objects.cc, which is a bit more involved and will be fixed in a separate CL. R=titzer@chromium.org CC=mostynb@opera.com Bug: chromium:746958 Change-Id: If5d9c03e0d6fa364e1d21feda49773468a48fba6 Reviewed-on: https://chromium-review.googlesource.com/645707 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47743}
-
- 28 Aug, 2017 1 commit
-
-
Yang Guo authored
We now only require API references to be provided when we actually deserialize them. Also changed the internal implementation to avoid copying API references into V8. R=petermarshall@chromium.org Bug: v8:6448 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Iddb0465ff6e95020006d41b5e87614dce8f0140b Reviewed-on: https://chromium-review.googlesource.com/632098Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#47649}
-
- 24 Aug, 2017 1 commit
-
-
Camillo Bruni authored
Several stack traces from crash reports in https://crbug.com/754490 have wrong magic signatures. Even though we're supposed to be failing in a V8_Fatal the signature doesn't show up on the stack trace. Change-Id: I35c8f27e36fd2a0ec474095a6cf5557a76fe7d26 Reviewed-on: https://chromium-review.googlesource.com/631878Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#47575}
-
- 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}
-
- 12 Jul, 2017 1 commit
-
-
Daniel Clifford authored
This makes it possible for automated tests to distinguish between CHECK failures and DCHECK failures, the latter of which will continue to run in release builds after the assertion failure point. Change-Id: Ie26978c0342d401a8c85f3261749739195087579 Reviewed-on: https://chromium-review.googlesource.com/565515 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by:
Jochen Eisinger <jochen@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#46596}
-
- 26 Jun, 2017 1 commit
-
-
Clemens Hammacher authored
There were only two uses. Replace them by [[noreturn]] directly. R=jarin@chromium.org BUG=v8:6474 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I965f74f5b3493cfef9efd698f24bf00216442fd8 Reviewed-on: https://chromium-review.googlesource.com/544845Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#46205}
-
- 22 Jun, 2017 1 commit
-
-
Clemens Hammacher authored
Why I want to fix this: I got a CL to replace V8_NORETURN by [[noreturn]], but clang-format formats this as extern "C"[[noreturn]] PRINT_FORMAT... (i.e. missing whitespace). Also, this is the only extern "C" function in our code base, so if we do not need to call it from C, we should just get rid of it. R=jochen@chromium.org BUG=v8:6474 Change-Id: I950bdc505822eb37a107c58e63c82a61907ba515 Reviewed-on: https://chromium-review.googlesource.com/539341Reviewed-by:
Jochen Eisinger <jochen@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#46149}
-
- 13 Jun, 2017 1 commit
-
-
Clemens Hammacher authored
Since we require C++11 support now, there is no need to use __attribute__ or __declspec, all compilers should support the [[noreturn]] attribute. R=jarin@chromium.org BUG=v8:6474 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I6c478c69658fd23c1c8ca468fbf3c6a36474ef66 Reviewed-on: https://chromium-review.googlesource.com/529072Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#45909}
-
- 31 May, 2017 1 commit
-
-
Clemens Hammacher authored
When checking {const char*} (or similar) against each other, don't print them as c strings on failure. Just print the pointer value. In wasm, where we use byte pointers into wasm wire bytes, this was sometimes hiding check failures behind segfaults which happened when trying to output invalid pointers as c strings. Anyway, it's more useful to see the raw pointer values in these cases. Other use cases, where we really compare against c string pointers should be rare in our code base. R=ishell@chromium.org Change-Id: I92a13221d18c987a97cf2a29ac8f454178ff2bb5 Reviewed-on: https://chromium-review.googlesource.com/517166 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#45642}
-
- 30 May, 2017 2 commits
-
-
Clemens Hammacher authored
The problem with enums is that neither is_integral, nor is_signed or is_unsigned is true for them. Thus, comparison with our CHECK/DCHECK macros always just uses the default comparison, which fails if the signedness of the underlying integer types does not match. This CL fixes this by considering the underlying integer type of an enum to choose the right comparison operator. R=ishell@chromium.org CC=ahaas@chromium.org Change-Id: I5ef56d1b86228e879f5866967ab7e709f1e97f0b Reviewed-on: https://chromium-review.googlesource.com/518123 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#45593}
-
Wiktor Garbacz authored
Non-printable characters will are printed as escapes. NUL won't terminate error message prematurely now. Change-Id: Ie24b34e377221e9b99d2268f8dfb5ce26d064cc2 Reviewed-on: https://chromium-review.googlesource.com/509490Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Wiktor Garbacz <wiktorg@google.com> Cr-Commit-Position: refs/heads/master@{#45586}
-
- 12 May, 2017 1 commit
-
-
Clemens Hammacher authored
The current implementation failed when comparing an integral type to a reference to an integral type of different signedness (see updated unittest). This CL fixes the checks to actually test the std::decay<T>::type, i.e. with all references, const or volatile modifiers stripped. R=jochen@chromium.org, ishell@chromium.org TEST=unittests/LoggingTest.CompareWithReferenceType Change-Id: Ib0ac077a91e0409ada7a80b68150cb98cbdd32f1 Reviewed-on: https://chromium-review.googlesource.com/502814Reviewed-by:
Jochen Eisinger <jochen@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#45271}
-
- 17 Mar, 2017 1 commit
-
-
Jochen Eisinger authored
BUG=none R=yangguo@chromium.org Change-Id: I53811859efacee9126ba1bdbe5690793833c96e1 Reviewed-on: https://chromium-review.googlesource.com/456338 Commit-Queue: Jochen Eisinger <jochen@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#43892}
-
- 20 Jan, 2017 1 commit
-
-
clemensh authored
In this particular case, we just did a (lhs)op(rhs), ignoring the case that lhs and rhs might have different signedness. This CL changes that to use the proper Cmp##op##Impl implementation, which does two comparisions for signed-vs-unsigned checks, avoiding compiler errors. R=ishell@chromium.org Review-Url: https://codereview.chromium.org/2642383002 Cr-Commit-Position: refs/heads/master@{#42566}
-
- 01 Dec, 2016 1 commit
-
-
clemensh authored
The current CHECK/DCHECK implementation fails statically if a signed value is compared against an unsigned value. The common solution is to cast on each caller, which is tedious and error-prone (might hide bugs). This CL implements signed vs. unsigned comparisons by executing up to two comparisons. For example, if i is int32_t and u is uint_32_t, a DCHECK_LE(i, u) would create the check i <= 0 || static_cast<uint32_t>(i) <= u. For checks against constants, at least one of the checks can be removed by compiler optimizations. The tradeoff we have to make is to sometimes silently execute an additional comparison. And we increase code complexity of course, even though the usage is just as easy (or even easier) as before. The compile time impact seems to be minimal: I ran 3 full compilations for Optdebug on my local machine, one time on the current ToT, one time with this CL plus http://crrev.com/2524093002. Before: 143.72 +- 1.21 seconds Now: 144.18 +- 0.67 seconds In order to check that the new comparisons are working, I refactored some DCHECKs in wasm to use the new magic, and added unit test cases. R=ishell@chromium.org, titzer@chromium.org CC=ahaas@chromium.org, bmeurer@chromium.org Committed: https://crrev.com/5925074a9dab5a8577766545b91b62f2c531d3dc Review-Url: https://codereview.chromium.org/2526783002 Cr-Original-Commit-Position: refs/heads/master@{#41275} Cr-Commit-Position: refs/heads/master@{#41411}
-
- 29 Nov, 2016 1 commit
-
-
clemensh authored
This not only potentially improves performance, but also avoids weird linker errors, like the one below, where I used Smi::kMinValue in a DCHECK_LE. > [421/649] LINK ./mksnapshot > FAILED: mksnapshot > src/base/logging.h|178| error: undefined reference to 'v8::internal::Smi::kMinValue' R=bmeurer@chromium.org, ishell@chromium.org Committed: https://crrev.com/76723502528c5af003fdffc3520632ea2a13fef3 Review-Url: https://codereview.chromium.org/2524093002 Cr-Original-Commit-Position: refs/heads/master@{#41273} Cr-Commit-Position: refs/heads/master@{#41363}
-
- 24 Nov, 2016 4 commits
-
-
clemensh authored
Revert of [base] Pass scalar arguments by value in CHECK/DCHECK (patchset #3 id:40001 of https://codereview.chromium.org/2524093002/ ) Reason for revert: Seems to cause compile errors on Android. Will investigate on Monday. Original issue's description: > [base] Pass scalar arguments by value in CHECK/DCHECK > > This not only potentially improves performance, but also avoids weird > linker errors, like the one below, where I used Smi::kMinValue in a > DCHECK_EQ. > > > [421/649] LINK ./mksnapshot > > FAILED: mksnapshot > > src/base/logging.h|178| error: undefined reference to > 'v8::internal::Smi::kMinValue' > > R=bmeurer@chromium.org, ishell@chromium.org > > Committed: https://crrev.com/76723502528c5af003fdffc3520632ea2a13fef3 > Cr-Commit-Position: refs/heads/master@{#41273} TBR=bmeurer@chromium.org,ishell@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review-Url: https://codereview.chromium.org/2527883004 Cr-Commit-Position: refs/heads/master@{#41278}
-
clemensh authored
Revert of [base] Define CHECK comparison for signed vs. unsigned (patchset #5 id:80001 of https://codereview.chromium.org/2526783002/ ) Reason for revert: Need to revert previous CL because of Android compile error, and this one depends in it. Original issue's description: > [base] Define CHECK comparison for signed vs. unsigned > > The current CHECK/DCHECK implementation fails statically if a signed > value is compared against an unsigned value. The common solution is to > cast on each caller, which is tedious and error-prone (might hide bugs). > This CL implements signed vs. unsigned comparisons by executing up to > two comparisons. For example, if i is int32_t and u is uint_32_t, a > DCHECK_LE(i, u) would create the check > i <= 0 || static_cast<uint32_t>(i) <= u. > For checks against constants, at least one of the checks can be removed > by compiler optimizations. > > The tradeoff we have to make is to sometimes silently execute an > additional comparison. And we increase code complexity of course, even > though the usage is just as easy (or even easier) as before. > > The compile time impact seems to be minimal: > I ran 3 full compilations for Optdebug on my local machine, one time on > the current ToT, one time with this CL plus http://crrev.com/2524093002. > Before: 143.72 +- 1.21 seconds > Now: 144.18 +- 0.67 seconds > > In order to check that the new comparisons are working, I refactored > some DCHECKs in wasm to use the new magic. > > R=bmeurer@chromium.org, titzer@chromium.org > > Committed: https://crrev.com/5925074a9dab5a8577766545b91b62f2c531d3dc > Cr-Commit-Position: refs/heads/master@{#41275} TBR=ishell@chromium.org,titzer@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review-Url: https://codereview.chromium.org/2531533003 Cr-Commit-Position: refs/heads/master@{#41277}
-
clemensh authored
The current CHECK/DCHECK implementation fails statically if a signed value is compared against an unsigned value. The common solution is to cast on each caller, which is tedious and error-prone (might hide bugs). This CL implements signed vs. unsigned comparisons by executing up to two comparisons. For example, if i is int32_t and u is uint_32_t, a DCHECK_LE(i, u) would create the check i <= 0 || static_cast<uint32_t>(i) <= u. For checks against constants, at least one of the checks can be removed by compiler optimizations. The tradeoff we have to make is to sometimes silently execute an additional comparison. And we increase code complexity of course, even though the usage is just as easy (or even easier) as before. The compile time impact seems to be minimal: I ran 3 full compilations for Optdebug on my local machine, one time on the current ToT, one time with this CL plus http://crrev.com/2524093002. Before: 143.72 +- 1.21 seconds Now: 144.18 +- 0.67 seconds In order to check that the new comparisons are working, I refactored some DCHECKs in wasm to use the new magic. R=bmeurer@chromium.org, titzer@chromium.org Review-Url: https://codereview.chromium.org/2526783002 Cr-Commit-Position: refs/heads/master@{#41275}
-
clemensh authored
This not only potentially improves performance, but also avoids weird linker errors, like the one below, where I used Smi::kMinValue in a DCHECK_EQ. > [421/649] LINK ./mksnapshot > FAILED: mksnapshot > src/base/logging.h|178| error: undefined reference to 'v8::internal::Smi::kMinValue' R=bmeurer@chromium.org, ishell@chromium.org Review-Url: https://codereview.chromium.org/2524093002 Cr-Commit-Position: refs/heads/master@{#41273}
-
- 23 Nov, 2016 1 commit
-
-
clemensh authored
The implementation was removed in http://crrev.com/2248393002. R=rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/2522983004 Cr-Commit-Position: refs/heads/master@{#41219}
-
- 07 Oct, 2016 1 commit
-
-
jochen authored
Reland of land "Turn libbase into a component" (patchset #1 id:1 of https://codereview.chromium.org/2396933002/ ) Reason for revert: let's see whether it sticks this time Original issue's description: > Revert of Reland "Turn libbase into a component" (patchset #1 id:1 of https://codereview.chromium.org/2395553002/ ) > > Reason for revert: > Speculative revert due to very strange-looking win/dbg failures > which reference SignedDivisionByConstant: > > https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20debug/builds/12736 > > Original issue's description: > > Reland "Turn libbase into a component" > > > > Original issue's description: > > > Turn libbase into a component > > > > > > This is a precondition for turning libplatform into a component > > > > > > BUG=v8:5412 > > > R=jgruber@chromium.org,machenbach@chromium.org > > > CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_ > > dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe > > > > > > Committed: https://crrev.com/614e615775f732d71b5ee94ed29737d8de687104 > > > Cr-Commit-Position: refs/heads/master@{#39950} > > > > BUG=v8:5412 > > TBR=jgruber@chromium.org,machenbach@chromium.org > > CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe;master.tryserver.chromium.mac:mac_chromium_compile_dbg_ng > > > > Committed: https://crrev.com/17cb51254cafa932025e9980b60f89f756d411cb > > Cr-Commit-Position: refs/heads/master@{#39969} > > TBR=jgruber@chromium.org,machenbach@chromium.org,jochen@chromium.org > # Skipping CQ checks because original CL landed less than 1 days ago. > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=v8:5412 > > Committed: https://crrev.com/e75b9f6ed5da39e6c7a8d70cf48afbc9958afc85 > Cr-Commit-Position: refs/heads/master@{#40009} TBR=jgruber@chromium.org,machenbach@chromium.org,adamk@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=v8:5412 Review-Url: https://codereview.chromium.org/2399323002 Cr-Commit-Position: refs/heads/master@{#40068}
-