R=hpayer@chromium.org

Review URL: https://codereview.chromium.org/153533003

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19135 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=jkummerow@chromium.org
BUG=

Review URL: https://codereview.chromium.org/132453009

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19132 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=verwaest@chromium.org

BUG=

Review URL: https://codereview.chromium.org/155913002

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19129 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Bumped an assembler buffer on the way, it is necessary for some combinations of debugging flags.

Note that the allocation profiler still leaks, this is handled in a separate CL.

R=bmeurer@chromium.org

Review URL: https://codereview.chromium.org/152643006

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19128 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=yangguo@chromium.org, yurys@chromium.org

Review URL: https://codereview.chromium.org/155513004

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19127 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This resolves many mjsunit failures if long branches are forced to be emitted.

TEST=
BUG=
R=plind44@gmail.com

Review URL: https://codereview.chromium.org/153983002

Patch from Dusan Milosavljevic <Dusan.Milosavljevic@rt-rk.com>.

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19126 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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