- 28 Jan, 2019 1 commit
-
-
Jakob Kummerow authored
Numeric conversions are defined behavior iff the value is in the range of what the target type can represent. Bug: v8:3770 Change-Id: Ic6f2276c64cb39345a45d8e37e604c28ecca34c2 Reviewed-on: https://chromium-review.googlesource.com/c/1436216 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#59144}
-
- 10 Jan, 2019 1 commit
-
-
Jakob Kummerow authored
Mostly signed integer overflows, and a few cases of double division by zero (which is defined by IEEE-754 to return Infinity (or NaN for 0/0) but is UB in C++). In base/ieee754.cc, use constants for NaN and Infinity instead of computing these values. In spaces-unittest.cc, ensure that a large enough allocation is used. Bug: v8:3770 Change-Id: I50d9a77dc860ef9993b7b269a5f8c117b0f62f9d Reviewed-on: https://chromium-review.googlesource.com/c/1403454 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#58701}
-
- 26 Dec, 2018 1 commit
-
-
Jakob Kummerow authored
Tbr: ahaas@chromium.org,leszeks@chromium.org,verwaest@chromium.org Bug: v8:3770 Change-Id: Ia6530fbb70dac05e9972283781c3550d8b50e1eb Reviewed-on: https://chromium-review.googlesource.com/c/1390116 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Alexei Filippov <alph@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#58470}
-
- 17 Dec, 2018 1 commit
-
-
Jakob Kummerow authored
Along with HeapNumberBase and MutableHeapNumber, of course. Bug: v8:5402 Change-Id: I14a7f8052de3839cad36bb7e4ebb6da38b2ac096 Reviewed-on: https://chromium-review.googlesource.com/c/1379884 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#58293}
-
- 17 Apr, 2018 1 commit
-
-
Jakob Kummerow authored
Casting from a floating-point type to an integer type is undefined behavior if the integral part of the float cannot be represented in the range of the int. Bug: v8:3770, chromium:831145 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I2e85ea8b0f09bbeeb3e0dcc1135fc747fa312f6d Reviewed-on: https://chromium-review.googlesource.com/1011651 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#52631}
-
- 14 Apr, 2018 1 commit
-
-
Jakob Kummerow authored
The "Address" type is V8's general-purpose type for manipulating memory addresses. Per the C++ spec, pointer arithmetic and pointer comparisons are undefined behavior except within the same array; since we generally don't operate within a C++ array, our general-purpose type shouldn't be a pointer type. Bug: v8:3770 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ib96016c24a0f18bcdba916dabd83e3f24a1b5779 Reviewed-on: https://chromium-review.googlesource.com/988657 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#52601}
-
- 05 Feb, 2018 1 commit
-
-
Yang Guo authored
Patch by Rumeet Dhindsa <rdhindsa@google.com>. R=jkummerow@chromium.org Change-Id: Ibff1af58bbdae52c6fb24b3d98d25e52cee0b63c Reviewed-on: https://chromium-review.googlesource.com/899006 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#51096}
-
- 09 Jan, 2018 1 commit
-
-
jgruber authored
There were two separate bugs here. First, a signed/unsigned mismatch where we took the result of PositiveNumberToUint32 and treated it as a signed int. Second, AdvanceStringIndex did not handle large input values correctly. Both are fixed by using uint64_t consistently. Bug: chromium:799813, v8:7258 Change-Id: If2819f87986d0ca732bc24df290f6dc7614083e8 Reviewed-on: https://chromium-review.googlesource.com/854272 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#50432}
-
- 26 Sep, 2017 1 commit
-
-
Jakob Kummerow authored
- Move things to conversions.cc that don't need to be in headers - Turn InternalStringToInt into a subclassable helper class so we can re-use it for BigInt.parseInt - Bonus: play a round of IWYU with all the .cc files who thought that #including conversions-inl.h would give them nice Unicode things Bug: v8:6791 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I64022543a9b83002e2b78416c7e87b40a1a016e6 Reviewed-on: https://chromium-review.googlesource.com/673725 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#48174}
-
- 03 Aug, 2017 1 commit
-
-
Andreas Rossberg authored
R=titzer@chromium.org Bug: Change-Id: Ib1a13b5131ec1b5a155c893de3c5ceb376bd33a3 Reviewed-on: https://chromium-review.googlesource.com/600227 Commit-Queue: Andreas Rossberg <rossberg@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47139}
-
- 02 Aug, 2017 1 commit
-
-
Julien Brianceau authored
Bug: chromium:750830 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Icab7b5a1c469d5e77d04df8bfca8319784e92af4 Reviewed-on: https://chromium-review.googlesource.com/595655 Commit-Queue: Julien Brianceau <jbriance@cisco.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#47072}
-
- 13 Jul, 2017 1 commit
-
-
Clemens Hammacher authored
There is just one version now, called IsPowerOfTwo. It accepts any integral type. There is one slight semantical change: Called with kMinInt, it previously returned true, because the argument was implicitly casted to an unsigned. It's now (correctly) returning false, so I had to add special handlings of kMinInt in machine-operator-reducer before calling IsPowerOfTwo on that value. R=mlippautz@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org,ishell@chromium.org,yangguo@chromium.org Change-Id: Idc112a89034cdc8c03365b778b33b1c29fefb38d Reviewed-on: https://chromium-review.googlesource.com/568140Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#46627}
-
- 10 Jul, 2017 1 commit
-
-
jgruber authored
This adds a convenience method for the common Smi to int conversion pattern. Bug: Change-Id: I7d7b171c36cfec5f6d10c60f1d9c3e06e3aed0fa Reviewed-on: https://chromium-review.googlesource.com/563205 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Andreas Rossberg <rossberg@chromium.org> Cr-Commit-Position: refs/heads/master@{#46516}
-
- 17 Jan, 2017 1 commit
-
-
leszeks authored
Uses the structure of an IEEE float to speed up DoubleToUint32IfEqualToSelf, similar to FastD2UI. Micro-benchmarks show a ~1.2x-2x speed-up, depending on the input. Review-Url: https://codereview.chromium.org/2636453003 Cr-Commit-Position: refs/heads/master@{#42420}
-
- 16 Jan, 2017 1 commit
-
-
leszeks authored
Moves constant element/property array building to be deferred for igition and on-demand for the other compilers, and splits off the object/array literal depth/flag initialisation from the array building. BUG=v8:5832 Review-Url: https://codereview.chromium.org/2625873009 Cr-Commit-Position: refs/heads/master@{#42362}
-
- 19 Dec, 2016 1 commit
-
-
cbruni authored
BUG= Review-Url: https://codereview.chromium.org/2577143002 Cr-Commit-Position: refs/heads/master@{#41801}
-
- 08 Dec, 2016 1 commit
-
-
qiuyi.zqy authored
Currently when the number passed to TryNumberToSize is 1 << 64, it gets away with a bug caused by rounding of mantissa. Then the number will be casted to 0 and TryNumberToSize will return true. This patch fix this by making the range check more accurate. BUG=v8:5712 Review-Url: https://codereview.chromium.org/2548243004 Cr-Commit-Position: refs/heads/master@{#41578}
-
- 08 Aug, 2016 1 commit
-
-
mlippautz authored
BUG= Review-Url: https://codereview.chromium.org/2225013002 Cr-Commit-Position: refs/heads/master@{#38449}
-
- 21 Jul, 2016 1 commit
-
-
rmcilroy authored
Move VisitLiteral to decide what type of literal is being emitted by checking the raw ASTValue type, instead of the internalized on-heap value. This is required for concurrent bytecode generation. As part of this change, the NUMBER AstValue constructor is modified to try to convert numbers without a dot to SMIs where possible. This is to maintain the behavior in NewNumber where such numbers are internalized as SMIs, and ensures that we still emit LdaSmi bytecodes for these values in the generated bytecode. BUG=v8:5203 Review-Url: https://codereview.chromium.org/2152853002 Cr-Commit-Position: refs/heads/master@{#37931}
-
- 29 Jun, 2016 1 commit
-
-
mlippautz authored
This function should also be callable from a concurrent thread, so we cannot use the scope here. Instead, provide a test that checks that no handles are created. R=ulan@chromium.org TEST=cctest/test-conversions/NoHandlesForTryNumberToSize BUG= Review-Url: https://codereview.chromium.org/2106083002 Cr-Commit-Position: refs/heads/master@{#37381}
-
- 06 Feb, 2016 1 commit
-
-
ishell authored
[api] Make ObjectTemplate::SetNativeDataProperty() work even if the ObjectTemplate does not have a constructor. Previously ObjectTemplate::New() logic relied on the fact that all the accessor properties are already installed in the initial map of the function object of the constructor FunctionTemplate. When the FunctionTemplate were instantiated the accessors of the instance templates from the whole inheritance chain were accumulated and added to the initial map. ObjectTemplate::SetSetAccessor() used to explicitly ensure that the ObjectTemplate has a constructor and therefore an initial map to add all accessors to. The new approach is to add all the accessors and data properties to the object exactly when the ObjectTemplate is instantiated. In order to keep it fast we now cache the object boilerplates in the Isolate::template_instantiations_cache (the former function_cache), so the object creation turns to be a deep copying of the boilerplate object. BUG=chromium:579009 LOG=Y Committed: https://crrev.com/6a118774244d087b5979e9291d628a994f21d59d Cr-Commit-Position: refs/heads/master@{#33674} Review URL: https://codereview.chromium.org/1642223003 Cr-Commit-Position: refs/heads/master@{#33798}
-
- 03 Feb, 2016 1 commit
-
-
hablich authored
Revert of [api] Make ObjectTemplate::SetNativeDataProperty() work even if the ObjectTemplate does not have a … (patchset #3 id:80001 of https://codereview.chromium.org/1642223003/ ) Reason for revert: Fails a lot of layout tests and blocks the roll. Can be easily reproduced with a local Chromium checkout. Reference: https://codereview.chromium.org/1652413003/ Original issue's description: > [api] Make ObjectTemplate::SetNativeDataProperty() work even if the ObjectTemplate does not have a constructor. > > Previously ObjectTemplate::New() logic relied on the fact that all the accessor properties are already installed in the initial map of the function object of the constructor FunctionTemplate. > When the FunctionTemplate were instantiated the accessors of the instance templates from the whole inheritance chain were accumulated and added to the initial map. > ObjectTemplate::SetSetAccessor() used to explicitly ensure that the ObjectTemplate has a constructor and therefore an initial map to add all accessors to. > > The new approach is to add all the accessors and data properties to the object exactly when the ObjectTemplate is instantiated. In order to keep it fast we now cache the object boilerplates in the Isolate::template_instantiations_cache (the former function_cache), so the object creation turns to be a deep copying of the boilerplate object. > > This CL also prohibits non-primitive properties in ObjectTemplate to avoid potential cross-context leaks. > > BUG=chromium:579009 > LOG=Y > > Committed: https://crrev.com/6a118774244d087b5979e9291d628a994f21d59d > Cr-Commit-Position: refs/heads/master@{#33674} TBR=verwaest@chromium.org,ishell@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:579009 Review URL: https://codereview.chromium.org/1660263003 Cr-Commit-Position: refs/heads/master@{#33698}
-
- 02 Feb, 2016 1 commit
-
-
ishell authored
[api] Make ObjectTemplate::SetNativeDataProperty() work even if the ObjectTemplate does not have a constructor. Previously ObjectTemplate::New() logic relied on the fact that all the accessor properties are already installed in the initial map of the function object of the constructor FunctionTemplate. When the FunctionTemplate were instantiated the accessors of the instance templates from the whole inheritance chain were accumulated and added to the initial map. ObjectTemplate::SetSetAccessor() used to explicitly ensure that the ObjectTemplate has a constructor and therefore an initial map to add all accessors to. The new approach is to add all the accessors and data properties to the object exactly when the ObjectTemplate is instantiated. In order to keep it fast we now cache the object boilerplates in the Isolate::template_instantiations_cache (the former function_cache), so the object creation turns to be a deep copying of the boilerplate object. This CL also prohibits non-primitive properties in ObjectTemplate to avoid potential cross-context leaks. BUG=chromium:579009 LOG=Y Review URL: https://codereview.chromium.org/1642223003 Cr-Commit-Position: refs/heads/master@{#33674}
-
- 10 Dec, 2015 1 commit
-
-
cbruni authored
BUG= Review URL: https://codereview.chromium.org/1512903002 Cr-Commit-Position: refs/heads/master@{#32746}
-
- 26 Nov, 2015 1 commit
-
-
rossberg authored
Moves all files related to AST and scopes into ast/, and all files related to scanner & parser to parsing/. Also eliminates a couple of spurious dependencies. R=mstarzinger@chromium.org BUG= Review URL: https://codereview.chromium.org/1481613002 Cr-Commit-Position: refs/heads/master@{#32351}
-
- 15 Oct, 2015 1 commit
-
-
jkummerow authored
Review URL: https://codereview.chromium.org/1404283002 Cr-Commit-Position: refs/heads/master@{#31310}
-
- 30 Sep, 2015 1 commit
-
-
mstarzinger authored
This enables linter checking for "readability/namespace" violations during presubmit and instead marks the few known exceptions that we allow explicitly. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1371083003 Cr-Commit-Position: refs/heads/master@{#31019}
-
- 20 Aug, 2015 1 commit
-
-
mstarzinger authored
This make inclusion of unicode-inl.h in object.h absolete. Now most compilation units don't require that header. It also breaks a cycle within declarations of the scanner.h header. This tries to remove includes of "-inl.h" headers from normal ".h" headers, thereby reducing the chance of any cyclic dependencies and decreasing the average size of our compilation units. Note that this change still leaves 3 violations of that rule in the code, checked with the "tools/check-inline-includes.sh" tool. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1287893006 Cr-Commit-Position: refs/heads/master@{#30268}
-
- 13 Aug, 2015 2 commits
-
-
mstarzinger authored
This tries to remove includes of "-inl.h" headers from normal ".h" headers, thereby reducing the chance of any cyclic dependencies and decreasing the average size of our compilation units. Note that this change still leaves 5 violations of that rule in the code. It only tackles "node.h" including "types-inl.h". R=titzer@chromium.org Review URL: https://codereview.chromium.org/1288053004 Cr-Commit-Position: refs/heads/master@{#30161}
-
mstarzinger authored
This CL us a pure refactoring that makes an empty compilation unit including just "foo.h" but not "foo-inl.h" compile without warnings or errors. This is needed to further reduce the header dependency tangle. R=rossberg@chromium.org Review URL: https://codereview.chromium.org/1290743005 Cr-Commit-Position: refs/heads/master@{#30158}
-
- 20 Dec, 2014 1 commit
-
-
machenbach authored
Revert of Remove obsolete V8_INFINITY macro. (patchset #3 id:40001 of https://codereview.chromium.org/798413003/) Reason for revert: Speculative revert. This seems to block the current roll: https://codereview.chromium.org/819653003/ I retried several times, also with a new roll. The error is internal - but that doesn't make much of a difference. Original issue's description: > Remove obsolete V8_INFINITY macro. > > Use std::numeric_limits consistently. > > R=svenpanne@chromium.org > > Committed: https://crrev.com/31c66e2d53569c4e229d55483d28208491e73612 > Cr-Commit-Position: refs/heads/master@{#25897} TBR=svenpanne@chromium.org,bmeurer@chromium.org NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/813813003 Cr-Commit-Position: refs/heads/master@{#25912}
-
- 19 Dec, 2014 1 commit
-
-
bmeurer authored
Use std::numeric_limits consistently. R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/798413003 Cr-Commit-Position: refs/heads/master@{#25897}
-
- 22 Sep, 2014 1 commit
-
-
bmeurer@chromium.org authored
This adds Float32Constant, ChangeFloat32ToFloat64 and TruncateFloat64ToFloat32 operators. TEST=compiler-unittests BUG=v8:3589 LOG=n R=titzer@chromium.org Review URL: https://codereview.chromium.org/594493002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24112 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 08 Sep, 2014 1 commit
-
-
bmeurer@chromium.org authored
R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/553843002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23767 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 02 Sep, 2014 1 commit
-
-
bmeurer@chromium.org authored
TEST=base-unittests,cctest,mjsunit R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/528993002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23617 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 04 Aug, 2014 1 commit
-
-
bmeurer@chromium.org authored
This way we don't clash with the ASSERT* macros defined by GoogleTest, and we are one step closer to being able to replace our homegrown base/ with base/ from Chrome. R=jochen@chromium.org, svenpanne@chromium.org Review URL: https://codereview.chromium.org/430503007 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22812 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 30 Jun, 2014 1 commit
-
-
jochen@chromium.org authored
Also split v8-core independent methods from checks.h to base/logging.h and merge v8checks with the rest of checks. The CPU::FlushICache method is moved to CpuFeatures::FlushICache RoundUp and related methods are moved to base/macros.h Remove all layering violations from src/libplatform BUG=none R=jkummerow@chromium.org LOG=n Review URL: https://codereview.chromium.org/358363002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22092 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 20 Jun, 2014 1 commit
-
-
mstarzinger@chromium.org authored
R=rossberg@chromium.org Review URL: https://codereview.chromium.org/333013002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21894 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 03 Jun, 2014 1 commit
-
-
jochen@chromium.org authored
- this avoids using relative include paths which are forbidden by the style guide - makes the code more readable since it's clear which header is meant - allows for starting to use checkdeps BUG=none R=jkummerow@chromium.org, danno@chromium.org LOG=n Review URL: https://codereview.chromium.org/304153016 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21625 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 27 May, 2014 1 commit
-
-
jochen@chromium.org authored
MemCopy is only meant for variable size, large (>64bytes) copies, otherwise, it's probably slower than memcpy due to the call overhead and the compiler can't optimize it away. BUG=none R=jkummerow@chromium.org LOG=n Review URL: https://codereview.chromium.org/306453005 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21519 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-