<div dir="ltr">I found this thread on the gcc mailing list associated with the patches to support coroutines<div><a href="https://gcc.gnu.org/legacy-ml/gcc-patches/2020-01/msg01096.html">https://gcc.gnu.org/legacy-ml/gcc-patches/2020-01/msg01096.html</a><br></div><div><br></div><div>It sounds like the main parts that are experimental are:</div><div>1) There is some debate in the standards bodies about how to handle allocation and how to disable exceptions.</div><div>2) There isn't an agreed upon way to handle ABI differences for calling coroutines built by another compiler</div><div><br></div><div>I don't expect either of those issues to be particularly relevant to OpenBMC, which makes me more amenable to playing around with it at this stage.</div><div><br></div><div>Does anyone have an idea of what a good test project would be? Something of modest size that we can look for any hidden dragons that still need taming.</div><div><br></div><div>- Richard</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 2, 2020 at 1:11 PM Patrick Williams <<a href="mailto:patrick@stwcx.xyz">patrick@stwcx.xyz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Jun 02, 2020 at 06:32:34PM +0000, Khetan, Sharad wrote:<br>
> From: openbmc <openbmc-bounces+sharad.khetan=<a href="mailto:intel.com@lists.ozlabs.org" target="_blank">intel.com@lists.ozlabs.org</a>> On Behalf Of Adrian Ambrozewicz<br>
> Sent: Tuesday, June 02, 2020 1:19 AM<br>
> W dniu 5/26/2020 o 17:57, Patrick Williams pisze:<br>
<br>
> >I can imagine some companies or communities might choose to be careful in that matter. I was just wondering if there is some 'BKM' which states 'experimental (unstable?) implementations are prohibited from use until marked by software vendor as stable'. Maybe that's my problem - I could be confusing 'experimental' with 'unstable' after all:)<br>
> <br>
> If experimental means potentially unstable, I would say we avoid such implementation in the OpenBMC. We need to keep OpenBMC stable and such new language / compiler features may be pretty gnarly to debug by the users.<br>
<br>
Just a few thoughts:<br>
<br>
1. We've not historically had this distinction / restriction.  We've<br>
   tended to use the latest C++ standard soon after it is available in our<br>
   Yocto compiler toolchain and even used std::experimental pieces.<br>
    * Yocto supported GCC7 (C++17 support) in April 2018 and we enabled<br>
      it in October 2018.<br>
    * We used mapbox::variant with C++14, which was a C++14<br>
    * implementation of the proposed C++17 API, and then used std::variant<br>
      when it was available.<br>
    * We still have code referring to std::experimental::filesystem<br>
      which has almost identical API as std::filesystem.<br>
<br>
2. "Vendors" don't really give us an indication of stability, so we'd<br>
   need to define one.  Today, GCC's C++20 status is a simple "no<br>
   support" (red), "partial support" (yellow), "done" (green).  Most of<br>
   the C++20 support is in GCC-10 which we are now using.<br>
    * <a href="https://gcc.gnu.org/projects/cxx-status.html" rel="noreferrer" target="_blank">https://gcc.gnu.org/projects/cxx-status.html</a><br>
<br>
3. I suspect most of our locally written code is "less stable" than<br>
   anything coming out of GCC simply by nature of how many users and tests<br>
   they have.  Most of the C++ features accepted by the standard<br>
   committees have an implementation in at least 1 of the big 3<br>
   compilers (MS-VS, GCC, Clang) and so there is code around to use for<br>
   test suites.<br>
<br>
-- <br>
Patrick Williams<br>
</blockquote></div>