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!
Posted Apr 23, 2015 0:14 UTC (Thu)
by ncm (guest, #165)
[Link] (4 responses)
Posted Apr 23, 2015 2:06 UTC (Thu)
by mcatanzaro (subscriber, #93033)
[Link]
Posted Apr 23, 2015 10:35 UTC (Thu)
by jwakely (subscriber, #60262)
[Link] (2 responses)
Posted Apr 24, 2015 22:17 UTC (Fri)
by ncm (guest, #165)
[Link] (1 responses)
Posted May 19, 2015 10:54 UTC (Tue)
by jwakely (subscriber, #60262)
[Link]
Posted Apr 25, 2015 13:43 UTC (Sat)
by lsl (subscriber, #86508)
[Link] (5 responses)
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.
Posted Apr 25, 2015 17:02 UTC (Sat)
by magila (guest, #49627)
[Link]
Posted Apr 25, 2015 20:40 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link]
AFAIR, both MSVC and GCC had O(N) complexity for std::list::size but it definitely made sense to fix it.
Posted Apr 26, 2015 1:04 UTC (Sun)
by Sesse (subscriber, #53779)
[Link]
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...
Posted Apr 27, 2015 20:47 UTC (Mon)
by ikm (guest, #493)
[Link]
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.
Posted May 19, 2015 11:05 UTC (Tue)
by jwakely (subscriber, #60262)
[Link]
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...
GCC 5.1 released
GCC 5.1 released
GCC 5.1 released
GCC 5.1 released
GCC 5.1 released
GCC 5.1 released
GCC 5.1 released
GCC 5.1 released
GCC 5.1 released
GCC 5.1 released
GCC 5.1 released