Fixing a memory leak in CompileAndRunModule.

BUG= https://code.google.com/p/v8/issues/detail?id=4203
TEST=wasm-fuzzer
R=jochen@chromium.org,jarin@chromium.org,kcc@chromium.org,machenbach@chromium.org,titzer@chromium.org
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#34415}

This is a reland of: http://crrev.com/1746063003

R=binji@chromium.org,ahaas@chromium.org
BUG=

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

Cr-Commit-Position: refs/heads/master@{#34414}

This will be used for generating the Atomics builtins.

BUG=v8:4614
R=jarin@chromium.org
LOG=y

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

Cr-Commit-Position: refs/heads/master@{#34413}

This should land after the chromium CL that starts using the new AddTraceEvent lands
(https://codereview.chromium.org/1742603004/)

BUG=4565
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#34412}

BUG=
R=bmeurer@chromium.org,verwaest@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34411}

Marks additional generator tests as failing.

BUG=V8:4680
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#34410}

R=vogelheim@chromium.org
BUG=v8:4690,v8:4765
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#34409}

TBR=machenbach@chromium.org
NOTRY=true

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

Cr-Commit-Position: refs/heads/master@{#34408}

Revert of [wasm] Add support for 64-bit LEB encodings. (patchset #6 id:100001 of https://codereview.chromium.org/1746063003/ )

Reason for revert:
[Sheriff] Seems to break chromium win compile:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Win/builds/3800/steps/compile/logs/stdio

Original issue's description:
> [wasm] Add support for 64-bit LEB encodings.
>
> R=binji@chromium.org,ahaas@chromium.org
> BUG=
>
> Committed: https://crrev.com/616f05496e9867cfa934098a76826cfde7feeaa2
> Cr-Commit-Position: refs/heads/master@{#34406}

TBR=ahaas@chromium.org,binji@chromium.org,titzer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

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

Cr-Commit-Position: refs/heads/master@{#34407}

R=binji@chromium.org,ahaas@chromium.org
BUG=

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

Cr-Commit-Position: refs/heads/master@{#34406}

e.g.,

for (var k in o) {
  if (!o.hasOwnProperty(k)) continue;
  ...
}

without enumerable properties on the prototype chain of o.

BUG=

Committed: https://crrev.com/dec80752eb344dfeb85588e61ac0afd22b11aadb
Cr-Commit-Position: refs/heads/master@{#34379}

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

Cr-Commit-Position: refs/heads/master@{#34405}

BUG= https://code.google.com/p/v8/issues/detail?id=4203
TEST=mjsunit/asm-wasm
R=titzer@chromium.org,aseemgarg@chromium.org
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#34404}

Fixes a bug in the constant pool padding calculation.

BUG=v8:4680
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#34403}

This means we can't cache templates that have object properties. Disable
caching for those.

BUG=
R=verwaest@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34402}

Runtime asserts are were previously a bit annoying to debug, due to
the lack of a useful error message, even in debug mode. This patch
prints out some more information in debug mode for runtime assert
failures while preserving their exception-throwing semantics. While
we're at it, it requires a semicolon after RUNTIME_ASSERT macro
invocations.

```
$ rlwrap out/Debug/d8 --allow-natives-syntax
V8 version 5.1.0 (candidate)
d8> %ArrayBufferNeuter(1)

#
# Runtime error in ../../src/runtime/runtime-typedarray.cc, line 52
#
# args[0]->IsJSArrayBuffer()

==== C stack trace ===============================

 1: 0xf70ab5
 2: 0xadeebf
 3: 0xadedd4
 4: 0x2ef17630693b
(d8):1: illegal access
%ArrayBufferNeuter(1)
^

d8>
```

Also give the other 'illegal access' case (a special SyntaxError type) a more
descriptive error message for its sole usage.

R=adamk

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

Cr-Commit-Position: refs/heads/master@{#34401}

Initial implementation of S390 specific debug and IC functions.

R=danno@chromium.org,jkummerow@chromium.org,jochen@chromium.org,jyan@ca.ibm.com,michael_dawson@ca.ibm.com,mbrandy@us.ibm.com
BUG=

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

Cr-Commit-Position: refs/heads/master@{#34400}

BUG=v8:4663, v8:4725
LOG=N
R=littledan@chromium.org, adamk@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34399}

R=bmeurer@chromium.org
BUG=v8:3956
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#34398}

In ia32 PushArgsAndConstruct builtin, we run out of registers and need to
temporarily store the data in the stack. In the earlier implementation,
a location outside the esp was used. This causes a problem if there is a
interrupt/signals which would use the same stack and corrupt the data that
is above the esp. This cl fixes it by pushing it onto the stack so that
the stack pointer is updated and hence the corruption will not happen. We
reuse the slot meant for receiver as a temporary store.

TBR=rmcilroy@chromium.org
BUG=v8:4280
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#34397}

When we try to optimize a function with Crankshaft, but compilation
bails out, don't disable optimization for that function entirely,
just disable Crankshaft, so TurboFan will be used for the next attempt.

Thereby this widens the TurboFan intake valve.

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

Cr-Commit-Position: refs/heads/master@{#34396}

R=rossberg@chromium.org, ulan@chromium.org, vogelheim@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34395}

R=mstarzinger@chromium.org, vogelheim@chromium.org
BUG=v8:4690
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#34394}

Adds the translation from optimized frame to bytecode offset
in FrameSummary. For interpreter, the bailout id represents the bytecode
array offset. So we can directly use the bailout id as the code offset
in the FrameSummary. Also updates mjsunit.status with more information
about failing tests.

BUG=v8:4280, v8:4689
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#34393}

The preparser should ignore "use strong" if the --strong_mode flag
is not turned on, but this should not stop processing subsequent
directives.

R=rossberg@chromium.org
BUG=
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#34392}

Similar to fullcodegen, Ignition now also marks a for-in statement as
slow (via the TypeFeedbackVector) when we have to call %ForInFilter,
i.e. we either have no enumeration cache or the receiver map changes
during an iteration of the for-in map.

R=mstarzinger@chromium.org
BUG=v8:3650
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#34391}

BUG=
R=yangguo@chromium.org, machenbach@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34390}

R=rmcilroy@chromium.org
BUG=v8:4680
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#34389}

We used to emit debug break location on block entry. This cannot be
ported to the interpreted as we do not emit bytecode for block entry.
This made no sense to begin with though, but accidentally added
break locations for var declarations.

With this change, the debugger no longer breaks at var declarations
without initialization. This is in accordance with the fact that the
interpreter does not emit bytecode for uninitialized var declarations.

Also fix the bytecode to match full-codegen's behavior wrt return
positions:
- there is a break location before the return statement, with the source
  position of the return statement.
- right before the actual return, there is another break location. The
  source position points to the end of the function.

R=rmcilroy@chromium.org, vogelheim@chromium.org
TBR=rossberg@chromium.org
BUG=v8:4690
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#34388}

We must not use for-of since that could be observed.

R=yangguo@chromium.org
BUG=v8:4769
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#34387}

ArrayIteratorPrototype must not provide Symbol.iterator.

R=rossberg
BUG=

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

Cr-Commit-Position: refs/heads/master@{#34386}

Runtime errors will be suppressed in --rebaseline mode, unless the
--verbose flag is passed.

The reasoning behind (rebaseline && !verbose) and not just (verbose)
is to suppress harmless noise while updating the expectation for
existing, known good snippets, without hiding actually relevant
errors when the tool is used to write new expectation files.

In fact, some tests are supposed to produce a runtime error, which
might nevertheless alarm a developer who is just --rebaseline'ing.

BUG=v8:4280
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#34385}

The for-of-finalization CL incorrectly removed the input argument from
BuildIteratorClose.  I'm reverting this, adding a regression test, and fixing an
existing test that was wrong.

BUG=
R=rossberg

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

Cr-Commit-Position: refs/heads/master@{#34384}

The code used to [[Get]] the first element twice instead of once, which can be
observed (one of the kangax tests does so).

R=rossberg
BUG=

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

Cr-Commit-Position: refs/heads/master@{#34383}

R=rossberg@chromium.org
BUG=v8:4783
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#34382}

BUG=
R=yangguo@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34381}

Revert of [crankshaft] Inline hasOwnProperty when used in fast-case for-in (patchset #1 id:40001 of https://codereview.chromium.org/1742253002/ )

Reason for revert:
ARM64 GCStress failure

Original issue's description:
> [crankshaft] Inline hasOwnProperty when used in fast-case for-in
>
> e.g.,
>
> for (var k in o) {
>   if (!o.hasOwnProperty(k)) continue;
>   ...
> }
>
> without enumerable properties on the prototype chain of o.
>
> BUG=
>
> Committed: https://crrev.com/dec80752eb344dfeb85588e61ac0afd22b11aadb
> Cr-Commit-Position: refs/heads/master@{#34379}

TBR=bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

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

Cr-Commit-Position: refs/heads/master@{#34380}

e.g.,

for (var k in o) {
  if (!o.hasOwnProperty(k)) continue;
  ...
}

without enumerable properties on the prototype chain of o.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#34379}

Operations on word size data must be word sized, and not word32.
Currently this only generates worse code, but in the future, it
might even generate wrong code, so we should better get this right
from the beginning.

R=yangguo@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34378}

The only place in fullcodegen, where we know for sure that a for-in loop
entered the slow-path is right before the potential call to %ForInFilter.
So there's no point in also updating the mode eagerly during ForInPrepare.

R=yangguo@chromium.org
BUG=v8:3650
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#34377}

BUG=575466
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#34376}