In terms of re-basing, I've been addressing the comments, re-basing, running
make quickcheck and then uploading. On my current machine quickcheck is a
5-6
hour run so the re-base will always be a number of hours old. I'm just
running
that now on the patch to address the latest comments
https://codereview.chromium.org/866843003/diff/1/src/assembler.cc
File src/assembler.cc (right):
https://codereview.chromium.org/866843003/diff/1/src/assembler.cc#newcode1461
src/assembler.cc:1461: #elif V8_OS_AIX
On 2015/01/29 09:54:33, Sven Panne wrote:
We don't test MINGW builds, either, it was just part of an external
contribution
IIRC. Just use your AIX code for the MINGW stuff above, too, and let's
see if
somebody complains. >:-) Having weird conditional untested code around
is
definitely worse.
ok will do
https://codereview.chromium.org/866843003/diff/1/src/base/platform/platform-aix.cc
File src/base/platform/platform-aix.cc (right):
https://codereview.chromium.org/866843003/diff/1/src/base/platform/platform-aix.cc#newcode46
src/base/platform/platform-aix.cc:46: // converted to double precision
numbers.
On 2015/01/29 09:54:33, Sven Panne wrote:
On 2015/01/29 00:08:29, michael_dawson wrote:
> [...] Having discussed this with the team we'll remove as the right
answer is
more likely to
> fix the test or exclude the test than to try and force the addresses
we use.
Exactly, this seems to be the right approach. Let's fix the root cause
and don't
silence the symptoms in an ugly way. :-)
You can just blacklist the test on AIX for now and open a v8 issue for
it. Then
I can try to find somebody who understands the test and can fix it, I
don't even
have the slightest clue what EquivalenceOfLoggingAndTraversal is
trying to test
and what it is doing in detail.
I found an existing
issue(2857-https://code.google.com/p/v8/issues/detail?can=1&start=0&num=100&q=EquivalenceOfLoggingAndTraversal&colspec=ID%20Type%20Status%20Priority%20Owner%20Summary%20HW%20OS%20Area%20Stars&groupby=&sort=&id=2857)
and added a comment to that issue. I will exclude the test for PPC 64
referencing that issue
https://codereview.chromium.org/866843003/diff/1/src/d8.cc
File src/d8.cc (right):
https://codereview.chromium.org/866843003/diff/1/src/d8.cc#newcode66
src/d8.cc:66: #define malloc __linux_malloc
On 2015/01/29 09:54:33, Sven Panne wrote:
Hmmm, if I see this correctly, malloc(0) only happens via the
MockArrayBufferAllocator. I would prefer to leave out this #ifdef and
change
MockArrayBufferAllocator to allocate a single byte instead. This
should
hopefully work, if not, we learn something. :-)
As a side note, this would probably be more correct, anyway: POSIX
explicitly
states that malloc(0) has implementation-defined behavior (either
returning NULL
or a unique pointer).
Will do
https://codereview.chromium.org/866843003/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
