GCC 4.8.1 released

[Posted June 3, 2013 by corbet]

From:		Jakub Jelinek <jakub-AT-redhat.com>
To:		gcc-announce-AT-gcc.gnu.org, gcc-AT-gcc.gnu.org, info-gnu-AT-gnu.org
Subject:		GCC 4.8.1 Released
Date:		Fri, 31 May 2013 13:16:13 +0200
Message-ID:		<20130531111613.GP1493__6187.47783960334$1369999067$gmane$org@tucnak.redhat.com>

The GNU Compiler Collection version 4.8.1 has been released.

GCC 4.8.1 is the first bug-fix release containing important fixes for
regressions and serious bugs in GCC 4.8.0 with over 91 bugs fixed since
the previous release.  Support for C++11 ref-qualifiers has been added
to GCC 4.8.1, making G++ the first C++ compiler to implement all the
major language features of the C++11 standard.

This release is available from the FTP servers listed at:

  http://www.gnu.org/order/ftp.html

Please do not contact me directly regarding questions or comments about
this release.  Instead, use the resources available from
http://gcc.gnu.org.

As always, a vast number of people contributed to this GCC release -- far
too many to thank them individually!

GCC 4.8.1 released

Posted Jun 3, 2013 16:18 UTC (Mon) by and (guest, #2883) [Link] (10 responses)

> Support for C++11 ref-qualifiers has been added to GCC 4.8.1, making G++ the first C++ compiler to implement all the major language features of the C++11 standard.

Probably they mean the first _released_ compiler. CLang already claimed this a few months ago, although for their SVN version. I think it is a bit strange that the GCC guys added new features in a point release. Maybe they should consider doing feature releases more frequently.

GCC 4.8.1 released

Posted Jun 3, 2013 18:04 UTC (Mon) by jmalcolm (subscriber, #8876) [Link] (9 responses)

Also, although GCC may be C++11 complete, libstdc++ (the standard library) is not. So, you cannot do full C++11 with the FSF stack.

Clang 3.3 (due out soon) and libc++ will be the first true C++11 compiler/library.

Apparently, you can use GCC with libc++ though. I have not tried it.

GCC 4.8.1 released

Posted Jun 3, 2013 19:28 UTC (Mon) by khim (subscriber, #9252) [Link] (8 responses)

Clang 3.3 (due out soon) and libc++ will be the first true C++11 compiler/library.

Only on MacOS, though. Lots of C++11 features only work with libstdc++ under Linux.

Apparently, you can use GCC with libc++ though. I have not tried it.

What will be the point? Apple dropped GCC support long ago and under Linux it makes no sense to use libc++ even with Clang, let alone GCC.

GCC 4.8.1 released

Posted Jun 3, 2013 20:17 UTC (Mon) by luto (guest, #39314) [Link] (6 responses)

What will be the point? Apple dropped GCC support long ago and under Linux it makes no sense to use libc++ even with Clang, let alone GCC.

Why not? libc++ is, it seems, a considerably better STL implementation. For example, it has allocator-aware containers and a non-refcounted string. The downside is that things like Boost are probably annoying to rebuild against libc++.

The libc++ website is rather unclear on how one is supposed to use it on Linux, though.

GCC 4.8.1 released

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

> For example, it has allocator-aware containers and a non-refcounted string.

Does anyone actually use allocator-aware containers though? In any case GCC 4.8 already has allocator-aware vector and forward_list, 4.9 already has allocator-aware unordered containers, and my local Git clone has allocator-aware associative containers, so we only need to do deque and list. We already have a non-refcounted string, we just need to enable it without affecting the C++03 ABI.

> The libc++ website is rather unclear on how one is supposed to use it on Linux, though.

There's a reason for that: You're *not* supposed to use it on Linux.

Linux support in libc++ is an afterthought with fewer resources than libstdc++ and no collaboration with the C library. I agree with khim, using libc++ on Linux makes no sense, except for messing about and experimenting for your own amusement.

GCC 4.8.1 released

Posted Jun 4, 2013 18:56 UTC (Tue) by luto (guest, #39314) [Link] (4 responses)

I've been wanting something like allocator-aware set and map for years so that I can use a trivial, fast non-thread-safe allocator for short-lived data structures.

Possibly no one uses them because almost nothing supports them yet.

GCC 4.8.1 released

Posted Jun 5, 2013 0:21 UTC (Wed) by jwakely (subscriber, #60262) [Link] (3 responses)

Which specific features do you need that are missing from GCC's set/map? Does Boost.Container provide those features?

GCC 4.8.1 released

Posted Jun 5, 2013 1:06 UTC (Wed) by jwakely (subscriber, #60262) [Link] (2 responses)

The reason I ask is that you can already use stateful allocators and scoped_allocator_adaptor with set/map, what's missing is using allocator_traits (which simplifies writing allocators but isn't essential for most purposes) and allocator propagation (which I wouldn't think is very relevant for short-lived objects) and the additional constructors needed for nested containers using the scoped allocator model. Many other uses work already - what are you missing so yours would work?

GCC 4.8.1 released

Posted Jun 5, 2013 1:38 UTC (Wed) by luto (guest, #39314) [Link] (1 responses)

Mainly paranoia. It's easy enough to do:

TrivialAllocator a;
std::map<T, U, TrivialAllocator> m(a);

and then accidentally copy or move m, causing memory corruption. (Also, I never really trusted non-allocator-aware containers to acutally copy a as opposed to doing a rebind and default-constructing a new one, since pre-C++11 allocators were pretty much intended to be stateless AFAICT.)

GCC 4.8.1 released

Posted Jun 5, 2013 10:07 UTC (Wed) by jwakely (subscriber, #60262) [Link]

> I never really trusted non-allocator-aware containers to acutally copy a as opposed to doing a rebind and default-constructing a new one,

But GCC's containers have *always* got that right, that can be verified easily if you cared to.

> since pre-C++11 allocators were pretty much intended to be stateless AFAICT.

No, containers were allowed to assume allocators were stateless, but the intention was to support stateful ones, the standard specifically said so: "Implementors are encouraged to supply libraries that can accept allocators that encapsulate more general memory models and that support non-equal instances." And indeed most implementations had some support for stateful allocators.

I suspect what you want doesn't depend on the allocator-aware requirements, so if you'd wanted it that badly for years you could have done it.

I also suspect the many hours I've spent implementing the allocator-aware requirements have been a massive waste of my time :-\

GCC 4.8.1 released

Posted Jun 5, 2013 6:11 UTC (Wed) by jmalcolm (subscriber, #8876) [Link]

>> Only on MacOS, though.

Work on libc++ may be lagging on Linux and Windows but libc++ is at least not Apple only.

FreeBSD lists the status of libc++ as "Works on -CURRENT, passing more tests than on Darwin". Darwin is Apple.

I think Clang/libc++ are scheduled to become the default tool-chain in FreeBSD 10.
https://wiki.freebsd.org/BSDToolchain

GCC 4.8.1 released

Posted Jun 3, 2013 16:58 UTC (Mon) by realnc (guest, #60393) [Link] (27 responses)

AFAIK Clang got there first with C++11 support. Perhaps the announcer wasn't aware of this.

GCC 4.8.1 released

Posted Jun 3, 2013 17:36 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link] (26 responses)

Pretty sure the announcement refers to the release. Not what was checked into a vcs.

GCC 4.8.1 released

Posted Jun 3, 2013 17:42 UTC (Mon) by jwakely (subscriber, #60262) [Link] (24 responses)

Indeed, Clang have not yet made a release that supports C++11 thread_local variables, and last I checked even their SVN version only supported dynamic destruction of thread_local variables when using GCC 4.8's C++ runtime.

GCC 4.8.1 released

Posted Jun 3, 2013 18:01 UTC (Mon) by rriggs (guest, #11598) [Link] (23 responses)

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).

GCC 4.8.1 released

Posted Jun 4, 2013 17:35 UTC (Tue) by jakub@redhat.com (guest, #31780) [Link]

The announcement meant core language C++11 feature completeness of a released compiler.
But even checking in VCS, clang was feature complete April 19th with
http://www.llvm.org/viewvc/llvm-project?view=revision&...
with various follow-ups needed for that,
g++ ref-specifiers were completed with:
http://gcc.gnu.org/r197437
http://gcc.gnu.org/r197387
http://gcc.gnu.org/r197318
(i.e. roughly April 1st-3rd), also some follow-up bugfixes.