- 06 Feb, 2014 1 commit
-
-
machenbach@chromium.org authored
R=jkummerow@chromium.org TBR=jkummerow@chromium.org Review URL: https://codereview.chromium.org/152483005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19123 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 05 Feb, 2014 19 commits
-
-
palfia@homejinni.com authored
Port r19095 (caf48ad) Original commit message: Objects can actually be stored into themselves. This fails when no write barrier is needed (eg, the object was just allocated). BUG= R=plind44@gmail.com Review URL: https://codereview.chromium.org/149343003 Patch from Balazs Kilvady <kilvadyb@homejinni.com>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19122 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
plind44@gmail.com authored
The call to C++ function has to be done through t9 register for the position independent code. The crashes occur only for shared library build. TEST=cctest/test-api/SetFunctionEntryHook BUG= R=plind44@gmail.com Review URL: https://codereview.chromium.org/132113009 Patch from Dusan Milosavljevic <Dusan.Milosavljevic@rt-rk.com>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19121 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
plind44@gmail.com authored
Due to a different NaN representation on MIPS, the canonical nan constant embedded in generated code that comes from snapshot will differ from the one used on MIPS hardware. TEST=mozilla/ecma/Array/15.4.4.2.js BUG= R=plind44@gmail.com Review URL: https://codereview.chromium.org/150663009 Patch from Dusan Milosavljevic <Dusan.Milosavljevic@rt-rk.com>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19118 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
hpayer@chromium.org authored
BUG= R=danno@chromium.org Review URL: https://codereview.chromium.org/149573014 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19115 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
marja@chromium.org authored
We used to have error messages which provide context, like "Variable name may not be eval or arguments in strict mode", but for other illegal words we only have non-context specific error messages like "Unexpected reserved word". Providing the context makes the code unnecessarily complex, since every individual place must remember to check for eval or arguments. This CL produces a unified error message ("Unexpected eval or arguments in strict mode"), and puts the error reporting to (Pre)Parser::ParseIdentifier. Notes: - The module feature is so experimental, that I decided to not allow "eval" or "arguments" as module-related identifiers in the strict mode (even though this check wasn't there before). - Unfortunately, there were some inconsistencies, since it was the responsibility of the caller of ParseIdentifier to check "eval" and "arguments" and some places didn't have the check for no good reason. This CL is supposed to keep backward compatibility and *not* introduce any new errors. - ECMA allows "eval" and "arguments" as labels even in strict mode. (Syntax: "LabelledStatement: Identifier : Statement", and no strict mode restrictions on Identifier are listed.) - Tests which compare error message strings will fail, and need to be updated. BUG=3126 LOG=N R=ulan@chromium.org Review URL: https://codereview.chromium.org/152813005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19112 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
dcarney@chromium.org authored
R=verwaest@chromium.org BUG= Review URL: https://codereview.chromium.org/146023004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19110 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
verwaest@chromium.org authored
BUG= R=dcarney@chromium.org Review URL: https://codereview.chromium.org/149803007 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19109 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
verwaest@chromium.org authored
R=dcarney@chromium.org Review URL: https://codereview.chromium.org/137263021 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19108 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
marja@chromium.org authored
We need a way to assert that for a given source code snippet, an error *is* produced or *is not* produced. Otherwise we might accidentally create new errors or start accepting code which was previously not accepted. Just checking that Parser and PreParser produce the same result doesn't cut it. BUG=3126 LOG=N R=ulan@chromium.org Review URL: https://codereview.chromium.org/154243005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19107 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
verwaest@chromium.org authored
R=dcarney@chromium.org Review URL: https://codereview.chromium.org/150573010 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19106 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
ishell@chromium.org authored
R=verwaest@chromium.org Review URL: https://codereview.chromium.org/149093011 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19105 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
ishell@chromium.org authored
Check elimination improvement: propagation of state through phis is supported, CheckMap narrowing implemented. R=titzer@chromium.org Review URL: https://codereview.chromium.org/141653009 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19102 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yangguo@chromium.org authored
If a function is marked or queued for concurrent compilation, %OptimizeFunctionOnNextCall becomes a no-op. That can be wrong if concurrent recompilation does not complete at the time we expect the function to have been optimized. R=hpayer@chromium.org Review URL: https://codereview.chromium.org/151343006 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19100 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yangguo@chromium.org authored
To avoid race with e.g. StackGuard::RequestInstallCode called from another thread when both access postpone_interrupts_nesting_. R=mvstanton@chromium.org BUG=290964 LOG=N Review URL: https://codereview.chromium.org/138833006 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19099 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
verwaest@chromium.org authored
Objects can actually be stored into themselves. This fails when no write barrier is needed (eg, the object was just allocated). R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/148733005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19095 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
bmeurer@chromium.org authored
R=ishell@chromium.org Review URL: https://codereview.chromium.org/150663005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19094 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yangguo@chromium.org authored
This is what I think is a better solution to the "external strings in old pointer space" problem. Basically, it is an issue because GC scans all fields of objects in old pointer space and if the cached address of the backing store is unaligned, it looks like a heap object, boom. The solution here is to use short external strings when we externalize a string in old pointer space, and when the address is unaligned. Short external strings don't cache the address, so GC has no issues. BUG=268686 LOG=Y R=dcarney@chromium.org Review URL: https://codereview.chromium.org/146183006 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19093 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
marja@chromium.org authored
BUG=3126 LOG=N R=ulan@chromium.org Review URL: https://codereview.chromium.org/154133002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19092 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
machenbach@chromium.org authored
R=jkummerow@chromium.org TBR=jkummerow@chromium.org Review URL: https://codereview.chromium.org/153973003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19087 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 04 Feb, 2014 20 commits
-
-
verwaest@chromium.org authored
TBR=dcarney@chromium.org Review URL: https://codereview.chromium.org/154873002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19086 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
verwaest@chromium.org authored
BUG= R=dcarney@chromium.org Review URL: https://codereview.chromium.org/153933002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19085 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
rafaelw@chromium.org authored
R=rossberg@chromium.org, rossberg BUG= Review URL: https://codereview.chromium.org/131413008 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19084 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
marja@chromium.org authored
In addition: - Fix: PreParser used to report an unexpected token one token too late when ParsePrimaryExpression failed. - Unified identifier handling (PreParser::GetIdentifier is now like Parser::GetIdentifier). - Fix: PreParser used to produce "unexpected_token YIELD" errors when Parser produced "unexpected_token_identifier"; fixed PreParser to match Parser. BUG=3126 LOG=N R=ulan@chromium.org Review URL: https://codereview.chromium.org/151103006 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19082 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
marja@chromium.org authored
This contains the following fixes: - PreParser was using an error "reserved_word" which doesn't exist in messages.js. Changed it to "unexpected_reserved". BUG=3126 LOG=N R=ulan@chromium.org Review URL: https://codereview.chromium.org/153793002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19076 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
palfia@homejinni.com authored
cvt_l_d() and cvt_d_l() instructions are replaced to cvt_w_d() and ctv_d_w() because kernel FPU emulator generates illegal instruction for double <-> long conversions. BUG= R=jkummerow@chromium.org, plind44@gmail.com Review URL: https://codereview.chromium.org/133363005 Patch from Balazs Kilvady <kilvadyb@homejinni.com>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19073 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
jkummerow@chromium.org authored
R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/134643026 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19072 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
marja@chromium.org authored
V8 is changing an error message and Blink will disable this test temporarily, too. This CL will keep the tree green until Blink is rolled into V8. BUG=3126 LOG=N R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/152863004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19071 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
verwaest@chromium.org authored
R=rossberg@chromium.org Review URL: https://codereview.chromium.org/152863002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19069 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
svenpanne@chromium.org authored
Don't access stack-allocated variable when it is out of scope. Enable Isolate cleanup in cctests again. R=ulan@chromium.org Review URL: https://codereview.chromium.org/146973005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19068 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
marja@chromium.org authored
This contains the following fixes: - We had strict_reserved_word and unexpected_strict_reserved, which one to use was totally mixed in Parser and PreParser. Removed strict_reserved_word. - When we saw a strict future reserved word when expecting something completely different (such as "(" in "function foo interface"), Parser reports unexpected identifier, whereas PreParser used to report unexpected strict reserved word. Fixed PreParser to report unexpected identifier too. - Unified parser and preparser error locations when the name of a function is a strict reserved word. Now both point to the name. BUG=3126 LOG=N R=ulan@chromium.org Review URL: https://codereview.chromium.org/149253010 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19067 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
hpayer@chromium.org authored
BUG= R=bmeurer@chromium.org, mvstanton@chromium.org Review URL: https://codereview.chromium.org/152813003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19066 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
alph@chromium.org authored
LOG=Y R=ulan@chromium.org, yurys@chromium.org Review URL: https://codereview.chromium.org/143343006 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19063 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
marja@chromium.org authored
In addition: - Fix a bug in parser discovered by the tests (prefix and postfix confused in an error message); the preparser had it right. - Unify the parser and preparser error locations when the name of a function is "eval" or "arguments. Now both point to the name. BUG=3126 LOG=N R=ulan@chromium.org Review URL: https://codereview.chromium.org/153693002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19062 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
ishell@chromium.org authored
R=dslomov@chromium.org Review URL: https://codereview.chromium.org/134713004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19058 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
ishell@chromium.org authored
R=titzer@chromium.org, verwaest@chromium.org Review URL: https://codereview.chromium.org/149063010 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19057 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
hpayer@chromium.org authored
BUG= R=ishell@chromium.org Review URL: https://codereview.chromium.org/148253004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19056 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
hpayer@chromium.org authored
BUG= R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/148943004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19054 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
marja@chromium.org authored
Reason: The fixed error message broke some tests. This reverts r19050. BUG= TBR=ulan@chromium.org Review URL: https://codereview.chromium.org/153673002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19053 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
jkummerow@chromium.org authored
R=danno@chromium.org Review URL: https://codereview.chromium.org/148923003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19052 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-