X87: Handle the case when derived constructor is [[Call]]ed with 0 args.

port cf53fed (r28242).

original commit message:

    ArgumentsAdaptorStub for derived constructor (the one that needs
    new.target) works in this way:
     - If the constructor is invoked via the Construct stub, we know that
       actual arguments always include new.target. ``arguments`` object
       however should not include a new.target, therefore we remove it.
       We achieve this by decrementing the argument count.
     - If the constructor is invoked as a call, we do not care for a correct
       ``arguments`` array since the constructor will immediately throw on
       entrance.
    The bug is that the call could actually pass 0 actual arguments, but I
    decrement unconditionally :(. The fix is to detect this case and avoid
    decrementing. ``arguments`` is bogus, but it is ok as constructor
    throws.

    Long-term we should just remove mucking about with arguments for
    new.target and just get it from the stack.

BUG=

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

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

src/x87/code-stubs-x87.cc

@@ -760,8 +760,15 @@ void ArgumentsAccessStub::GenerateNewStrict(MacroAssembler* masm) {
   __ mov(ecx, Operand(edx, ArgumentsAdaptorFrameConstants::kLengthOffset));
 
   if (has_new_target()) {
+    // If the constructor was [[Call]]ed, the call will not push a new.target
+    // onto the stack. In that case the arguments array we construct is bogus,
+    // bu we do not care as the constructor throws immediately.
+    __ cmp(ecx, Immediate(Smi::FromInt(0)));
+    Label skip_decrement;
+    __ j(equal, &skip_decrement);
     // Subtract 1 from smi-tagged arguments count.
     __ sub(ecx, Immediate(2));
+    __ bind(&skip_decrement);
   }
 
   __ lea(edx, Operand(edx, ecx, times_2,