[llvm] r286639 - [ORC] Re-apply 286620 with fixes for the ErrorSuccess class.

[Lang Hames via llvm-commits]

Hi Ulrich,

Thanks very much for tracking that down! I'll disable these tests
temporarily to get your bot building again, then write a less hacky version
of the QueueChannel to fix this.

Cheers,
Lang.


On Mon, Nov 14, 2016 at 10:24 AM, Ulrich Weigand <Ulrich.Weigand at de.ibm.com>
wrote:

> This causes several unit tests to simply hang on s390x, which breaks the
> build bot:
>
> OrcJITTests --gtest_filter=DummyRPC.TestAsyncIntInt
> OrcJITTests --gtest_filter=DummyRPC.TestAsyncVoidBool
> OrcJITTests --gtest_filter=DummyRPC.TestSerialization
>
> In all these cases, the symptom is the same: both threads spin endlessly
> in QueueChannel::readBytes. Looking at the code, the problem seems to be
> here:
>
> // If there's nothing to read then yield.
> while (InQueue.empty())
> std::this_thread::yield();
>
> At least when using a GCC 4.8.5 host compiler with its associated
> libcstdc++ headers to build this test, the "yield" function is a no-op and
> optimized out, so we end up with effectively:
>
> while (InQueue.empty())
> ;
>
> Since the "empty" function just tests some non-volatile member variables,
> this in turn gets optimized by the compiler to:
>
> if (InQueue.empty())
> for (;;);
>
> And here we indeed spin:
> => 0x00000000010d5058 <+64>: j 0x10d5058 <_ZN12QueueChannel9readBytesEPcj
> +64>
>
>
> Mit freundlichen Gruessen / Best Regards
>
> Ulrich Weigand
>
> --
> Dr. Ulrich Weigand | Phone: +49-7031/16-3727
> STSM, GNU/Linux compilers and toolchain
> IBM Deutschland Research & Development GmbH
> Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk
> Wittkopp
> Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart,
> HRB 243294
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161114/3515aa5c/attachment.html>