|
|
Subscribe / Log in / New account

GCC 5.1 released

From:  Jakub Jelinek <jakub-AT-redhat.com>
To:  gcc-AT-gcc.gnu.org
Subject:  GCC 5.1 Released
Date:  Wed, 22 Apr 2015 16:38:15 +0200
Message-ID:  <20150422143815.GH1725@tucnak.redhat.com>
Archive‑link:  Article

One year passed from the time when the last major version
of the GNU Compiler Collection has been announced, so it is the time again
to announce a new major GCC release, 5.1.

GCC 5.1 is a major release containing substantial new
functionality not available in GCC 4.9.x or previous GCC releases.

The C++ front-end now has full C++14 language support and the Standard C++
Library has full C++11 support and experimental full C++14 support.
The full C++11 support has been made possible by adopting Dual ABI,
see https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dua...
for more details.

The C front-end now defaults to C11 mode with GNU extensions, which
affects semantics of the inline keyword and brings several other
user visible changes, see https://gcc.gnu.org/gcc-5/porting_to.html
for more details.

GCC 5.1 contains various interprocedural optimization improvements, e.g.
a new IPA Identical Code Folding pass and various LTO improvements, e.g.
ODR based merging of C++ types, see
http://hubicka.blogspot.cz/2015/04/GCC5-IPA-LTO-news.html for more details.

The GCC 5.1 Local Register Allocator now contains a rematerialization subpass,
on i?86/x86-64 is able to reuse the PIC hard register to improve performance
of position independent code, there is a simple interprocedural RA pass and
various other register allocation improvements were added.

GCC 5.1 adds partial support for the OpenACC standard, support for OpenMP 4.0
offloading to Intel's upcoming Xeon Phi accelerators and support for OpenACC
offloading to PTX.  The Undefined Behavior Sanitizer in GCC has been extended
by adding various new runtime checks.  An experimental GCC JIT library has
been added in GCC 5.1.

See

  https://gcc.gnu.org/gcc-5/changes.html

for more information about changes in GCC 5.1.

Note that the GCC versioning scheme changed recently, next major
release next year will be called GCC 6.1, next minor, bugfixing release
from the GCC 5 branch tentatively planned for end of June or July will be
GCC 5.2.  See https://gcc.gnu.org/develop.html#num_scheme for details.

This release is available from the FTP servers listed here:

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

The release is in gcc/gcc-5.1.0/ subdirectory.

If you encounter difficulties using GCC 5.1, please do not contact me
directly.  Instead, please visit http://gcc.gnu.org for information
about getting help.

Driving a leading free software project such as GNU Compiler Collection
would not be possible without support from its many contributors.
Not to only mention its developers but especially its regular testers
and users which contribute to its high quality.  The list of individuals
is too large to thank individually!




to post comments

GCC 5.1 released

Posted Apr 23, 2015 0:14 UTC (Thu) by ncm (guest, #165) [Link] (4 responses)

It probably should say it has full core-language support for C++14. I don't think the standard library is there yet.

GCC 5.1 released

Posted Apr 23, 2015 2:06 UTC (Thu) by mcatanzaro (subscriber, #93033) [Link]

Well he says "the Standard C++ Library has full C++11 support and experimental full C++14 support" so it seems clear enough to me :)

GCC 5.1 released

Posted Apr 23, 2015 10:35 UTC (Thu) by jwakely (subscriber, #60262) [Link] (2 responses)

I might have missed something, but I think it's complete :-)

GCC 5.1 released

Posted Apr 24, 2015 22:17 UTC (Fri) by ncm (guest, #165) [Link] (1 responses)

I noticed the hash containers seemed to be missing lots of constructors.

GCC 5.1 released

Posted May 19, 2015 10:54 UTC (Tue) by jwakely (subscriber, #60262) [Link]

Thanks, they should be fixed on trunk now and I'll do the backport for 5.2

GCC 5.1 released

Posted Apr 25, 2015 13:43 UTC (Sat) by lsl (subscriber, #86508) [Link] (5 responses)

Can someone tell what the hell the C++ standard committee members where thinking when prescribing new semantics for std::list and std::string, in full knowledge that this is going to break ABI for most implementations?

I mean, this is C++, not Ruby or Node.js. People expect compatibility concerns to be taken seriously here.

The things enabled by this change seem very minor, compared to the mess it has caused, despite the GCC developers' heroic efforts to ease the situation. Especially the list thing seems downright ridiculous. You could just track the length yourself, if you need constant time access to it, couldn't you? That's what people that actually needed it were doing all along, I guess. It doesn't enable anything that wasn't already trivially possible before.

Now, I assume the C++ committe members are smart guys, probably smarter than me. So why did they do it? I can't seem to find a convincing rationale for it.

GCC 5.1 released

Posted Apr 25, 2015 17:02 UTC (Sat) by magila (guest, #49627) [Link]

I'm not going to defend the decision to mandate O(1) size for std::list, but prohibiting COW for std::string seems pretty reasonable to me. In the years since C++98 was published a consensus has emerged that SSO is generally superior to COW, and AFAIK GCC is the only major C++ implementation still using COW. Being able to rely on all implementations using SSO makes it easier to write optimal code using std::string.

GCC 5.1 released

Posted Apr 25, 2015 20:40 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

The problem was already there. GCC used CoW for strings and MSVC used copying with small-buffer optimization. So something HAD to be broken anyway.

AFAIR, both MSVC and GCC had O(N) complexity for std::list::size but it definitely made sense to fix it.

GCC 5.1 released

Posted Apr 26, 2015 1:04 UTC (Sun) by Sesse (subscriber, #53779) [Link]

FWIW, there are tons of new semantics prescribed for everything, it's just that std::string and std::list are the two primary examples where you can't implement the new semantics without an ABI break. In particular, there are a lot of new demands around multithreading, since C++11 for the first time actually includes threads and all the associated machinery to make safe multithreading possible.

The standard does not say “copy-on-write is not allowed”, it just outlines a number of constraints (mostly related to threading) that are effectively incompatible with COW std::string. Of course this was done knowingly; see

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n...

GCC 5.1 released

Posted Apr 27, 2015 20:47 UTC (Mon) by ikm (guest, #493) [Link]

> Especially the list thing seems downright ridiculous. You could just track the length yourself, if you need constant time access to it, couldn't you?

Tracking the length yourself is error-prone, so you'd really have to implement your own list. Regarding the decision, the cost of splice() is now O(n) instead of O(1), and the cost of size() is O(1) instead of O(n). Since the latter is used much more, it seems like a fair trade.

GCC 5.1 released

Posted May 19, 2015 11:05 UTC (Tue) by jwakely (subscriber, #60262) [Link]

Sesse gave the proposal that explains the std::string changes.

Rationale for changing list::size() can be found in http://howardhinnant.github.io/On_list_size.html

The actual change was proposed by http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n...


Copyright © 2015, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds