GCC 4.8.1 released

Posted Jun 3, 2013 18:01 UTC (Mon) by rriggs (guest, #11598)
In reply to: GCC 4.8.1 released by jwakely
Parent article: GCC 4.8.1 released

Any idea when the "experimental" label be dropped and the ABI declared stable? It's difficult to justify using C++11 for production code when ABI changes are made in a point release. Many developers will not consider Clang or GCC usable for C++11 until that happens.

GCC 4.8.1 released

Posted Jun 3, 2013 18:23 UTC (Mon) by jwakely (subscriber, #60262) [Link] (22 responses)

I hope we can do it for GCC 4.9

AFAIK for the default configuration the only ABI changes in a point release have been to revert ABI breakage, i.e. bugfixes to make the ABI *more* stable. The change in GCC 4.8.1 is backwards compatible for the default configuration.

I have some more C++11 ABI changes I need to make, but they'll only be for GCC 4.9.0, not a point release.

GCC 4.8.1 released

Posted Jun 3, 2013 19:24 UTC (Mon) by rriggs (guest, #11598) [Link] (9 responses)

There will be much rejoicing when that comes to pass.

Does that imply that we are likely to see a feature-complete libstdc++ in that time frame? I'm less concerned about that since Boost provides the one major feature that is currently lacking -- <regex>.

GCC 4.8.1 released

Posted Jun 3, 2013 19:57 UTC (Mon) by jwakely (subscriber, #60262) [Link] (8 responses)

I wouldn't like to speculate about feature-completeness, because it depends on volunteers with no fixed schedule.

GCC 4.8.1 released

Posted Jun 3, 2013 23:17 UTC (Mon) by jengelh (guest, #33263) [Link] (7 responses)

And whenever the committee comes up with a new version of the standard, it suddenly becomes non-feature-complete again :)

GCC 4.8.1 released

Posted Jun 4, 2013 6:18 UTC (Tue) by khim (subscriber, #9252) [Link]

True, but there are different levels of non-feature-completeness. <regex>, in particular, was standartized six years ago. It's one thing to not support something brand-spanking-new, it's another thing not to support something many years old.

GCC 4.8.1 released

Posted Jun 4, 2013 11:04 UTC (Tue) by jwakely (subscriber, #60262) [Link] (5 responses)

I wouldn't be surprised if we implement all the new C++14 features before the missing C++11 ones, there's nothing as complicated as <regex> or UTF8 code conversion facets in C++14.

GCC 4.8.1 released

Posted Jun 7, 2013 3:23 UTC (Fri) by jzbiciak (guest, #5246) [Link] (4 responses)

there's nothing as complicated as <regex> or UTF8 code conversion facets in C++14.

...yet.

GCC 4.8.1 released

Posted Jun 7, 2013 13:31 UTC (Fri) by jwakely (subscriber, #60262) [Link] (3 responses)

No, I meant what I said.

The Bristol meeting in April was the deadline for new features to be added to C++14.

GCC 4.8.1 released

Posted Jun 7, 2013 13:47 UTC (Fri) by jzbiciak (guest, #5246) [Link] (2 responses)

That good, then.

Please ignore my failed attempt at tongue in cheek humor.

GCC 4.8.1 released

Posted Jun 7, 2013 14:52 UTC (Fri) by jwakely (subscriber, #60262) [Link] (1 responses)

I thought it was meant in jest, but the committee is *really* keen that C++14 doesn't become C++19, because that would cause all sorts of scheduling problems for C++17 ;-)

The larger changes (e.g. filesystem library, networking library, a trivial little thing called concepts) are being done as separate "Technical Specification" documents so they can happen on separate schedules that are independent of approving a new standard.

GCC 4.8.1 released

Posted Jun 7, 2013 16:54 UTC (Fri) by jzbiciak (guest, #5246) [Link]

That sounds like a good strategy. C++11 is a huge leap over C++98. I have to agree with Stroustrup's statement that it feels like a new language. It's sufficiently disruptive that I personally mentally treat C++11 code as a different language than C++98, and am holding off on writing C++11 until more compilers support it.

These finer grain updates sound much less disruptive.

And reading up on that "trivial little thing called concepts": That looks very useful, but feels like the kind of feature that would ripple to all corners of the language, or at least all the corners of the standard library. Probably a good thing it is on a parallel track that won't hold up a specific refresh of the C++ standard.

ABI stability

Posted Jun 4, 2013 7:36 UTC (Tue) by tbleher (guest, #48307) [Link] (11 responses)

AFAIK for the default configuration the only ABI changes in a point release have been to revert ABI breakage, i.e. bugfixes to make the ABI *more* stable. The change in GCC 4.8.1 is backwards compatible for the default configuration.

So how stable is the C++ ABI in general? There was recently a thread on the openal list where several participants claimed that compiling a C++ program and then replacing libstdc++ with a newer version was not guaranteed to work (see e.g. this message, start of thread). This would make distributing pre-compiled C++ programs very hard.

What does GCC guarantee in this regard?

ABI stability

Posted Jun 4, 2013 10:51 UTC (Tue) by jwakely (subscriber, #60262) [Link] (4 responses)

> I don't think that is true in the general case, but correct me if I'm wrong.

Someone should correct him for being wrong. Almost entirely wrong.

> I think they like to preserve ABI compatibility between all same point versions (e.g. 4.2.x),

GCC 4.8's libstdc++ is backward-compatible all the way back to GCC 3.4 nine years ago, but why let a few facts get in the way when you can pontificate about a subject you once read something a long time ago and forgot the details.

> ABI compatibility between minor versions is desired but not required.

100% wrong.

> I think Sun Sparc broke in one of the minor 4.x bumps (4.0 or 4.1),

[Citation needed] (It might be true, but I'm not aware of it.)

> And I don't think they like to make any guarantees about the STL compatibility.

100% wrong.

> No, that is dependent on packaging managers/distros.

Wrong, symbol versioning is used in the default configuration on GNU/Linux and Solaris (at least.)

ABI stability

Posted Jun 5, 2013 19:51 UTC (Wed) by nix (subscriber, #2304) [Link]

ISTR a C ABI change in some non-x86 arch's representation of bitfields (was it SPARC though? Don't think so). However... as widely-used parts of the ABI go, that's not one.

ABI stability

Posted Jun 6, 2013 19:27 UTC (Thu) by zlynx (guest, #2285) [Link] (2 responses)

If GCC didn't break ABI compatibility there wouldn't be the need to fix it in GCC point releases.

I don't have an example to point to right this instant but I have definitely hit serious C++ ABI bugs in the past while running Gentoo. I updated to GCC 4.something and older C++ programs started segfaulting.

Not to mention that on IA64 important things like exception handlers would just fail to catch exceptions every other GCC version.

This past experience is why the C++ library that I'm responsible for at work is built for each customer's particular Linux distribution rather than trying to build one binary that works for everybody. It's also why everything is hidden behind a private implementation pointer and there is NO USAGE of anything inline in the includes.

ABI stability

Posted Jun 7, 2013 17:46 UTC (Fri) by khim (subscriber, #9252) [Link]

If GCC didn't break ABI compatibility there wouldn't be the need to fix it in GCC point releases.

True, but what does it change? You can say the same about Android, GLibC, Linux, Windows or any other project which is serious about ABI compatibility.

This past experience is why the C++ library that I'm responsible for at work is built for each customer's particular Linux distribution rather than trying to build one binary that works for everybody.

It's your choice but it does not prove anything. Somehow others can build one binary and it works just fine. I've seen problems with many libraries but libstdc++ was never a problem. It's certainly possible to build libstdc++ in a fashion which will make it incompatible, but most major distributions carry LSB-compatible libstdc++ and work just fine with a single binary.

ABI stability

Posted Jun 7, 2013 19:45 UTC (Fri) by jwakely (subscriber, #60262) [Link]

Well duh. If [programmers didn't introduce bugs] there wouldn't be the need to fix [them]. Thanks for the newsflash.

And I cannot parse a sentence containing both "on IA64" and "important things" ;)

ABI stability

Posted Jun 4, 2013 11:20 UTC (Tue) by jwakely (subscriber, #60262) [Link] (5 responses)

To answer your question directly: the ABI is entirely stable for C++03 code. Any ABI breakage for C++03 code is a serious bug. If the ABI wasn't required to be stable we'd have switched to a non-ref-counted std::string years ago and fixed numerous other known issues (and hacking on libstdc++ would be a lot more fun!)

If you use C++11 then in general you can combine C++11 code built with GCC 4.X and C++03 code built with any GCC, but there is not the same guarantee that you can combine with C++11 code built with GCC 4.Y or GCC 4.Z, because the C++11 features are not all stable yet (e.g. for GCC 4.9 I'm about to add a new virtual function to a base class in <future>.) This is why C++11 support is still labelled "experimental", because it would be worse to claim it's stable and then have to break the ABI.

ABI stability

Posted Jun 7, 2013 18:19 UTC (Fri) by luto (guest, #39314) [Link] (4 responses)

Is there a path forward to make this kind of change (e.g. getting rid of ref-counted strings) either by breaking things one day or by some highly magical use of versioning?

Also, what happens if/when C++ gets real empty member support (e.g. "T [[allow_empty]] allocator" or whatever other ideas might be floating around)? Can libstdc++ start using these in a way that won't change the ABI?

ABI stability

Posted Jun 7, 2013 19:36 UTC (Fri) by jwakely (subscriber, #60262) [Link] (3 responses)

Yes, there's a new attribute to allow magical versioning, so that std::string in C++11 mode will mangle differently (and so will any type or function using it, which makes it solve the problem properly, unlike inline namespaces.)

I don't think libstdc++ has any need for empty member support, I'm not sure the language needs it either.

ABI stability

Posted Jun 7, 2013 21:24 UTC (Fri) by luto (guest, #39314) [Link] (2 responses)

I don't think libstdc++ has any need for empty member support, I'm not sure the language needs it either.

As far as I know, it's always possible to replace member variables with inheritance, but IMO it's somewhere between ugly and insanely ugly.

Writing "Allocator [[allow_empty]] a;" would be prettier and a lot less verbose than using fancy empty-base-optimized tuples, not to mention easier to deal with in gdb.

ABI stability

Posted Jun 7, 2013 23:44 UTC (Fri) by jwakely (subscriber, #60262) [Link] (1 responses)

But I can't see any reason to replace working code that uses empty bases with code using such an attribute, because that attribute might not work in C++98 mode anyway and the existing code has to keep working. The simplest way to not break the ABI is not change working code!

ABI stability

Posted Jun 8, 2013 0:46 UTC (Sat) by luto (guest, #39314) [Link]

I can't argue with that. Perhaps I'll even submit such a proposal to add such an attribute (and libstdc++ can ignore it unless it comes in handy for new C++17 classes).