GCC 5 Is Coming This Month With OpenMP 4.0, Offloading, Cilk Plus & More

[phoronix]

Phoronix: GCC 5 Is Coming This Month With OpenMP 4.0, Offloading, Cilk Plus & More

GCC 5 is expected to be formally released later this month and it by far is looking to be the most exciting GNU Compiler Collection update yet! GCC 5 has amassed a ton of exciting open-source compiler features over the past year...

http://www.phoronix.com/scan.php?page=news_item&px=GCC-5-Coming-This-Month

[caligula]

So, Clang still for development and GCC for optimized release builds (if the critical bugs don't crash it / resulting binary) ?

[davidlt]

You missed Exynos M1 (ARMv8 64-bit) recently added to GCC/binutils.

[discordian]

So, Clang still for development and GCC for optimized release builds (if the critical bugs don't crash it / resulting binary) ?

Well depends, libstdc++ is going through some breaking changes with some classes like string being replaced with C++11 conform implementations. Admittedly I havent fully researched the details how and what kind of binary compatibility will be maintained, but I suppose you run into deep trouble if need to compile programs to run on older systems with older versions of libstdc++ (or more so than usual).
Given that gcc and libstdc++ are rather deeply tied, it might be easier to use clang which supports a range of C++ library (-versions) per switch until all the platforms you want to support provide a recent libstdc++.

[Haegar15]

Well depends, libstdc++ is going through some breaking changes with some classes like string being replaced with C++11 conform implementations. Admittedly I havent fully researched the details how and what kind of binary compatibility will be maintained, but I suppose you run into deep trouble if need to compile programs to run on older systems with older versions of libstdc++ (or more so than usual).

The new string-implementation is the most important feature for me in GCC 5.0. I wonder why not more information is spread on that topic (not mentioned in Michael's article, either). The Cow-implementation in old libstdc++ had many downsides.

I hope to get more information about that ABI change. But as most of the implementation in Header-Only it shouldn't be too hard to keep it compatible.

[JeffLaw]

More information on GCC 5, Fedora 22 and the like

Haegar:

You indicated you were looking for additional information on the C++ ABI changes and such.. You might consider looking at these two blog posts...

http://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/

http://developerblog.redhat.com/2015/02/10/gcc-5-in-fedora/

[Haegar15]

You might consider looking at these two blog posts...

http://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/

http://developerblog.redhat.com/2015...c-5-in-fedora/

Thank you very much. These Blogposts very indeed helpful.

But what is not covered there is the case when I want to ship a binary package compiled with GCC 5 and the new ABI.
Of course it will run on the same distribution I was building it on, but can it run on a distribution which is 2 or 3 years old (e.g. RHEL6). Do I have to use -D_GLIBCXX_USE_CXX11_ABI=0 to ensure that my binary will run on older distributions? Is there a way to somehow link everything statically?

[discordian]

The new string-implementation is the most important feature for me in GCC 5.0. I wonder why not more information is spread on that topic (not mentioned in Michael's article, either). The Cow-implementation in old libstdc++ had many downsides.

I hope to get more information about that ABI change. But as most of the implementation in Header-Only it shouldn't be too hard to keep it compatible.

The header-only stuff is exactly the big problem. If you have a old library using your strings (or vice-versa) you will have 2 differemt interpretations of the data. There are several ways to offer a fundamental different implementation, an neither is without troubles.

Libstd++ had a c++11 compatible string implementation for several years (vstring since 4.1). It wasn't swapped until now exactly because of the breakage it will cause.

Yes, this new implementation is welcome, just to avoid misunderstandings, but if you want to target current popular distros you have to use an older libstdc++ (or link it statically and not pass strings across shared libs).

[mlau]

You missed Exynos M1 (ARMv8 64-bit) recently added to GCC/binutils.

...which is just an alias for generic cortex-a57 optimizations.

[JeffLaw]

Thank you very much. These Blogposts very indeed helpful.

But what is not covered there is the case when I want to ship a binary package compiled with GCC 5 and the new ABI.
Of course it will run on the same distribution I was building it on, but can it run on a distribution which is 2 or 3 years old (e.g. RHEL6). Do I have to use -D_GLIBCXX_USE_CXX11_ABI=0 to ensure that my binary will run on older distributions? Is there a way to somehow link everything statically?

It's not covered because it's not an issue for Red Hat's customers. We have a hybrid linking model that we use when we provide newer compilers on existing versions of RHEL (via our Developer Tool Set product). In that hybrid linking model, as many symbols as possible are satisfied by the system libstdc++ dynamically, but anything not supplied by the system library is statically bound into the executable. Thus executables which use facilities not found in the system libstdc++ (C++03, old ABI) have copies of whatever functionality they need and can run on RHEL systems without the DTS product.

You can get a bit of background on the hybrid linking model and DTS as a whole via this Red Hat blog entry, in particular the "Under the Hood" section.

http://developerblog.redhat.com/2013/01/23/is-your-c-development-team-missing-out-developer-toolset-newer-tools-on-and-for-multiple-rhel-releases/#more-598

You could mimick that model, build with -D_GLIBCXX_USE_CXX_ABI=0 or ship libstdc++ with your executables and arrange to find your libstdc++ before any system version of libstdc++.


jeff