If the input range is positive and the shift count is constant
we can replace >>> with >> to compute the output range.
For negative inputs, we can only compute a range if the
result always fits into a signed int32.
BUG=v8:1510
Review URL: http://codereview.chromium.org/7489043
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8735 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Loading the map within the stub already implies a check for an undetectable
object, so there is no need to record this separately. Furthermore, this brings
the size of the type info to record down to 8 bits, removing the need to find a
place for the ninth bit in the Code object. ;-)
Review URL: http://codereview.chromium.org/7484022
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8722 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The IC records the set of types it has seen, e.g. {String} or {Boolean,
Undefined}, etc. Note that in theory this could lead to a large number of
different ToBoolean ICs (512, to be exact, because we distinguish 9 types),
but in practice only a small handful of them are actually generated.
Currently the type recording part is only implemented on ia32, other platforms
continue to work like they did before, though.
Removed some dead code on the way.
Review URL: http://codereview.chromium.org/7473028
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8716 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- 32-bit Linux already seems to scatter the mmap() chunks around;
64-bit didn't.
- Seed the system random number generator a little better (we needlessly trunctaed microsecond resolution to millisecond resolution).
- Will automatically take advantage of better entropy when V8::RandomPrivate uses it.
R=fschneider@chromium.org,cevans@chromium.org
BUG=v8:805
TEST=
Review URL: http://codereview.chromium.org/7464022
Patch from Chris Evans <cevans@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8705 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- 32-bit Linux already seems to scatter the mmap() chunks around; 64-bit didn't.
- Seed the system random number generator a little better (we needlessly
trunctaed microsecond resolution to millisecond resolution).
- Will automatically take advantage of better entropy when V8::RandomPrivate
uses it.
BUG=v8:805
Review URL: http://codereview.chromium.org/7377008
Patch from Chris Evans <cevans@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8702 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
There was an ICU cleanup (removing all C++ style enums and replacing them with plain C enums). NumberFormat::EStyle had a draft status (from ICU 4.2) and it was cut. Confusion came up because DateFormat::EStyle is stable and won't be removed.
TEST=Compile Chromium with ICU 4.6 and ICU 4.8
BUG=1561
Review URL: http://codereview.chromium.org/7421003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8701 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* src/third_party/valgrind/valgrind.h: Update from upstream valgrind
r11899, so as to get around some unused value warnings. Also adds
support for darwin.
This version of valgrind.h differs from the original in that all
instances of "unsigned long long int" have been replaced with
"uint64_t", as the former is not allowed in ISO C++ 89.
See https://bugs.kde.org/show_bug.cgi?id=211926 for the upstream bug
report.
* src/x64/cpu-x64.cc:
* src/builtins.cc:
* src/conversions-inl.h:
* src/debug.cc:
* src/frames.cc:
* src/full-codegen.cc:
* src/jsregexp.cc:
* src/objects.cc:
* src/parser.cc:
* src/platform-linux.cc:
* src/x64/code-stubs-x64.cc:
* src/x64/deoptimizer-x64.cc:
* src/x64/full-codegen-x64.cc:
* src/x64/lithium-codegen-x64.cc:
* src/x64/regexp-macro-assembler-x64.cc:
* src/x64/stub-cache-x64.cc: Remove a number of assigned but
unreferenced variables.
* SConstruct (CCTEST_EXTRA_FLAGS): Punt on -Wunused-but-set-variable for
the test suite.
BUG=1291
TEST=A build and tools/test.py passes.
Review URL: http://codereview.chromium.org/7400023
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8688 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When creating a CompilationInfo we always have the script and can
determine if it is a natives script.
Now that all natives functions are recognized as such, many of them
are called with undefined as the receiver. We have to use different
filtering for builtins functions when printing stack traces.
Also, fixed one call of CALL_NON_FUNCTION to be correctly marked as a
method call (with fixed receiver). Now that CALL_NON_FUNCTION is
marked as a native function this caused the receiver to be undefined.
R=svenpanne@chromium.org
BUG=
TEST=
Review URL: http://codereview.chromium.org/7395030
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8680 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
undefined is passed unchanged as the receiver for strict-mode
functions through call and apply. Also, if a strict-mode function is
called without an explicit receiver, undefined is passed as the
receiver (not the global object as for other functions).
R=vegorov@chromium.org
BUG=89236
TEST=mjsunit/debug-scopes.js
Review URL: http://codereview.chromium.org/7388011
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8675 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
