CY2021 - Possible compiler change to gcc 8.3

[Nick Cannon]

The Working Group is seriously considering a move to gcc 8.3 for CY2021 which would allow us to also move C++ standard compliance for SDKs and APIs to C++17.

While there are many advantages to upgrading, there are also some serious caveats as certain old features have been removed after being deprecated long ago. Full information can be found here but the removals are:

• Support for the obsolete SDB/coff debug info format has been removed. The option -gcoff no longer does anything.
• The Cilk+ extensions to the C and C++ languages have been removed.
• The non-standard C++0x std::copy_exception function was removed. std::make_exception_ptr should be used instead.

Please let us know if this will cause major issues for you, or if there are any other reasons why you prefer we not move to gcc 8.3 next year.

Thanks,

Nick

[Larry Gritz]

What's the rationale for choosing 8.3 specifically? It is already a full year old now. If we're jumping a couple versions anyway, why not all the way to 9? 

I don't have a strong preference in gcc version, as long as it fully supports C++17. (TBH, even at work I tend to use clang for the projects I directly author and maintain.)

This may be helpful: https://en.cppreference.com/w/cpp/compiler_support

It looks like C++17 syntax is complete as of gcc 7, but the very last bits of C++17 library don't come until gcc libstdc++ 9.

--

Larry Gritz

l...@larrygritz.com

[Nick Cannon]

On Sun, Mar 1, 2020 at 9:55 PM Larry Gritz <l...@larrygritz.com> wrote:

What's the rationale for choosing 8.3 specifically? It is already a full year old now. If we're jumping a couple versions anyway, why not all the way to 9? 

The proposal came from a combination of stability and convenience after a discussion with software vendors:

• gcc 9 is less mature, still has rough edges
• RHEL/CentOS 8.1 ships with gcc 8.3.1, as does Redhat Developer Toolset 8.1.

If there are more requests for us to consider gcc 9 then we will look into it further.

Nick

[Larry Gritz]

I don't have an actual preference between 8 and 9, just a general view that for a component we hold steady for several years at a time, when we do move we should always try catch up to the current version. But strong vendor preference and syncing with CentOS is a reasonable rationale to override this.

I believe that if we set the standard to C++17 / gcc8, individual studios are free to use gcc9 or any modern clang if they find it has better performance and works for them; they should all be link compatible.

Do you know if CentOS 8.1 / the vendors are also talking about moving to the new ABI, or is the plan to still stick with the gcc4 ABI?

-- lg

--

Larry Gritz

l...@larrygritz.com

[Nick Cannon]

On Mon, Mar 2, 2020 at 10:05 AM Larry Gritz <l...@larrygritz.com> wrote:

Do you know if CentOS 8.1 / the vendors are also talking about moving to the new ABI, or is the plan to still stick with the gcc4 ABI?

Not much yet but we'll be spinning up a small group to get into more detailed discussions about compilers and binary compatibility soon so watch this space...

There is no plan to uprev glibc for CY2021 at this time, I don't think we'll be in a position to require an upgrade to RHEL/CentOS 8 until at least 2022 unless there is broad community support for accelerating it to 2021.

Nick

[daniele...@gmail.com]

I've just been reading gcc 8.3 notes and it says that the c++17 standard library is experimental whereas gcc9 is not experimental. https://en.cppreference.com/w/cpp/compiler_support states most features supporter, I'm just not sure if there are any bugs or issues. Just thought it might be worth pointing out.

[Daniel Heckenberg]

It may be worth noting that the RHEL Developer toolset has narrower (but more clearly stated) interop claims than GCC when it comes to mixing C++ standards and compiler versions.

e.g. for RHEL DTS 9:

https://access.redhat.com/documentation/en-us/red_hat_developer_toolset/9/html/user_guide/chap-GCC#sect-GCC-CPP-Compatibility

As far as I understand for GCC, the intended interoperation compatibility range is that as soon as any particular C++ standard support graduates from experimental, then it will be ABI compatible for all future versions of GCC, and you must runtime link to the most recent libstdc++ used during any module's compile/link. 

I'm curious how the RHEL DTS approach of static linking newer symbols (libstdc++_nonshared.a) to augment the original OS libstdc++ plays here, especially when using a non-GCC compiler (like clang).  Does anyone have a good understanding of this... or war stories?

Nick -- has this discussion developed further within the Working Group?

Thanks,

Daniel

[David Aguilar]

Hi Daniel,

Here's what I understand about this topic.

devtoolset-6 defaults to the old c++ ABI.  Normally, users on gcc6 would be required to opt-in to the older ABI when using c++14, but devtoolset-6 was compiled like this:

    $ g++ -v

    ...

    Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,lto --prefix=/opt/rh/devtoolset-6/root/usr --mandir=/opt/rh/devtoolset-6/root/usr/share/man --infodir=/opt/rh/devtoolset-6/root/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --enable-plugin --with-linker-hash-style=gnu --enable-initfini-array --disable-libgcj --with-default-libstdcxx-abi=gcc4-compatible --with-isl=/builddir/build/BUILD/gcc-6.3.1-20170216/obj-x86_64-redhat-linux/isl-install --enable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
    ...

    gcc version 6.3.1 20170216 (Red Hat 6.3.1-3) (GCC)

This is the key part: --with-default-libstdcxx-abi=gcc4-compatible

This doc is relevant:

https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html

Particularly, this section:

"""

    The _GLIBCXX_USE_CXX11_ABI macro (see Macros) controls whether the declarations in the library headers use the old or new ABI. So the decision of which ABI to use can be made separately for each source file being compiled. Using the default configuration options for GCC the default value of the macro is 1 which causes the new ABI to be active, so to use the old ABI you must explicitly define the macro to 0 before including any library headers. (Be aware that some GNU/Linux distributions configure GCC 5 differently so that the default value of the macro is 0 and users must define it to 1 to enable the new ABI.)

"""

Note that it says, "Be aware that some GNU/Linux distributions configure GCC 5 differently so that the default value of the macro is 0."

That note is referring to the --with-default-libstdcxx-abi=gcc4-compatible flag above.

The end result is that DTS gcc6 defaults to the old ABI to allow c++11 interop with the older system compiler (gcc4).

My reading of the DTS docs suggests that this DTS flag is no longer relevant in the newer devtoolset versions -- the compiler is now being built in its default new ABI mode.  That's why their docs mention: "objects compiled with the system GCC in C++11 or C++14 mode are not compatible."

This effectively means that projects that explicitly #define _GLIBCXX_USE_CXX11_ABI in their implementations will need to allow for this flag to be controlled externally if they want to keep source compatibility with the old world.  Because DTS/gcc6 used the old ABI as the default, it's not surprising to find projects that do not account for this difference and use whatever is the compiler's default.  Those are straightforward to deal with -- they will have to be recompiled.

IIUC this means that we can't use any c++11/14 objects compiled with DTS/gcc6 (using the old ABI) with the newer DTS compilers in their default modes without explicitly #defining the old ABI.  Stuff will need to be recompiled.

--

David

[Daniel Heckenberg]

Hi David, all,

Thanks for that thorough explanation!

The ASWF CI working group discussed this topic recently. We agreed to
extend our docker images to include the proposed CY2021 spec which
should provide an easy way to validate / experiment on the compiler
choice and implications.

Cheers,
Daniel