Upstream Yocto Bringing in GCC 10

[Richard Hanley]

I found this thread on the gcc mailing list associated with the patches to
support coroutines
https://gcc.gnu.org/legacy-ml/gcc-patches/2020-01/msg01096.html

It sounds like the main parts that are experimental are:
1) There is some debate in the standards bodies about how to handle
allocation and how to disable exceptions.
2) There isn't an agreed upon way to handle ABI differences for calling
coroutines built by another compiler

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.

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.

- Richard

On Tue, Jun 2, 2020 at 1:11 PM Patrick Williams <patrick at stwcx.xyz> wrote:

> On Tue, Jun 02, 2020 at 06:32:34PM +0000, Khetan, Sharad wrote:
> > From: openbmc <openbmc-bounces+sharad.khetan=intel.com at lists.ozlabs.org>
> On Behalf Of Adrian Ambrozewicz
> > Sent: Tuesday, June 02, 2020 1:19 AM
> > W dniu 5/26/2020 o 17:57, Patrick Williams pisze:
>
> > >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:)
> >
> > 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.
>
> Just a few thoughts:
>
> 1. We've not historically had this distinction / restriction.  We've
>    tended to use the latest C++ standard soon after it is available in our
>    Yocto compiler toolchain and even used std::experimental pieces.
>     * Yocto supported GCC7 (C++17 support) in April 2018 and we enabled
>       it in October 2018.
>     * We used mapbox::variant with C++14, which was a C++14
>     * implementation of the proposed C++17 API, and then used std::variant
>       when it was available.
>     * We still have code referring to std::experimental::filesystem
>       which has almost identical API as std::filesystem.
>
> 2. "Vendors" don't really give us an indication of stability, so we'd
>    need to define one.  Today, GCC's C++20 status is a simple "no
>    support" (red), "partial support" (yellow), "done" (green).  Most of
>    the C++20 support is in GCC-10 which we are now using.
>     * https://gcc.gnu.org/projects/cxx-status.html
>
> 3. I suspect most of our locally written code is "less stable" than
>    anything coming out of GCC simply by nature of how many users and tests
>    they have.  Most of the C++ features accepted by the standard
>    committees have an implementation in at least 1 of the big 3
>    compilers (MS-VS, GCC, Clang) and so there is code around to use for
>    test suites.
>
> --
> Patrick Williams
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200602/02e52d12/attachment.htm>