Reproducing OSX buildbot failures.

[Pierre Langlois]

Hi all,

For the past few weeks I have been working on some tests for TurboFan's
code generator. But sadly, it appears the x64 OSX buildbots are not
happy about them and I am having trouble reproducing the issue
locally. So far I've built V8 on a Macbook running 10.12.6 and the tests
are OK as far as I can see.

The CL in question is:
https://chromium-review.googlesource.com/c/v8/v8/+/645868
And the failing bots:
- https://build.chromium.org/p/tryserver.v8/builders/v8_mac64_rel/builds/151
- https://build.chromium.org/p/tryserver.v8/builders/v8_mac64_dbg/builds/138
- https://build.chromium.org/p/tryserver.v8/builders/v8_mac64_asan_rel/builds/162

Is it possible to run the buildbot recipes locally?

For reference, the new tests target the `AssembleMove` and
`AssembleSwap` methods which generate native code to perform moves
generated by the gap resolver. In a nutshell, the tests generate stub
functions which allocate a lot of spill slots, perform a long list of
randomly generated moves on those slots, and then return. For the time
being, we only make sure that these functions execute. We've already
found a few bugs thanks to these tests.

The bots show a segfault, does this ring a bell to anybody? I'm not
familiar with OSX as a platform, maybe this is doing something forbidden
on this platform?

Thanks a lot,
Pierre

[Jakob Kummerow]

Using tools/dev/v8gen.py it should be possible to replicate the bot's exact build configuration. I haven't done this for Mac in a while though.

Wild guess: the bot runs OSX 10.9, which might be too old for some fancy new C++11 features requiring library support?

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups "v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Pierre Langlois]

Hi Jakob,

Ooops, I had missed your reply, thank you!

Replicating the bot's configuration didn't help, however I found what
the problem was yesterday and it appears to be a bug in the x64
backend. If anyone can confirm it that would be great as I'm not
familiar with x64.

The test was crashing is generated code, when performing a Simd128 slot
swap. In this case we emit the following:

~~~
// Use the XOR trick to swap without a temporary. The xorps may read
// from or write to an unaligned address, causing a slowdown, but swaps
// between slots should be rare.
__ Movups(kScratchDoubleReg, src);
__ Xorps(kScratchDoubleReg, dst); // scratch contains src ^ dst.
__ Movups(src, kScratchDoubleReg);
__ Xorps(kScratchDoubleReg, dst); // scratch contains src.
__ Movups(dst, kScratchDoubleReg);
__ Xorps(kScratchDoubleReg, src); // scratch contains dst.
__ Movups(src, kScratchDoubleReg);
~~~

However, if one disables AVX (--no-enable-avx), the above causes a
crash. The reason seems to be that if AVX is not supported, we fallback
to using the SSE "xorps" instruction instead of "vxorps". And the former
doesn't allow for unaligned addresses:

~~~
void TurboAssembler::Xorps(XMMRegister dst, XMMRegister src) {
if (CpuFeatures::IsSupported(AVX)) {
CpuFeatureScope scope(this, AVX);
vxorps(dst, dst, src);
} else {
xorps(dst, src);
}
}
~~~

Can anybody confirm this?

Thanks,
Pierre

>> email to v8-users+u...@googlegroups.com.

>> For more options, visit https://groups.google.com/d/optout.
>>
>

> --