GCC 8.1 Released

Version 8.1 of the GCC compiler suite is out. "Are you tired of your existing compilers? Want fresh new language features and better optimizations? Make your day with the new GCC 8.1!" See this page for a complete list of changes in this release.

From:		Jakub Jelinek <jakub-AT-redhat.com>
To:		info-gnu-AT-gnu.org
Subject:		GCC 8.1 Released
Date:		Wed, 2 May 2018 14:16:05 +0200
Message-ID:		<20180502121605.GV8577@tucnak>

We are proud to announce the next, major release of the
GNU Compiler Collection.

Are you tired of your existing compilers?
Want fresh new language features and better optimizations?
Make your day with the new GCC 8.1!

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

The C++ front-end now has experimental support for some parts of the
upcoming C++2a draft, with the -std=c++2a and -std=gnu++2a options, and the
libstdc++ library has some further C++17 and C++2a draft library features
implemented too.

This releases features significant improvements in the emitted diagnostics,
including improved locations, location ranges and fix-it hints (especially
in the C++ front-end), and various new warnings have been added.

Profile driven optimizations have been significantly improved, on x86
functions are now split into hot and cold regions by default.  The link time
optimizations now have a new way of emitting the DWARF debug information,
which makes LTO optimized code more debuggable.  New loop optimizers have
added and existing improved and some, like -ftree-loop-distribution,
-floop-unroll-and-jam and -floop-interchange have been enabled by default at
-O3.

The AArch64 target now supports the Scalable Vector Extension, which
features vectors with runtime determined number of elements.

Some code that compiled successfully with older GCC versions might require
source changes, see http://gcc.gnu.org/gcc-8/porting_to.html for
details.

See

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

for more information about changes in GCC 8.1.

This release is available from the FTP servers listed here:

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

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

If you encounter difficulties using GCC 8.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!

Please consider a donation to the GNU Toolchain Fund to support the
continued development of GCC!

-- 
If you have a working or partly working program that you'd like
to offer to the GNU project as a GNU package,
see https://www.gnu.org/help/evaluation.html.

New optimizations and -O3

Posted May 2, 2018 14:56 UTC (Wed) by epa (subscriber, #39769) [Link] (2 responses)

It's always nice to see new optimizations, such as "-floop-interchange exchanges loops in a loop nest to improve data locality". These are enabled at -O3 and above. But I saw in the recent MySQL release that its build dropped an optimization level to -O2; apparently -O3 was "ricing" that doesn't help on modern systems. So what is "the best" default level, if you don't have specific information about the program being built?

I believe that -O3 turns on optimizations that can increase code size, and I can see that this could mean things no longer fit in cache and become slower. Yet the increase in size from -floop-interchange seems like it should be very modest compared to aggressively inlining things.

New optimizations and -O3

Posted May 5, 2018 1:05 UTC (Sat) by nairn62 (subscriber, #123752) [Link] (1 responses)

Nowadays, I use XY Kernel Compression Mode instead of Gzip for Linux, which cuts the kernel size down dramatically. I use -O3 frequently, which does increased the code side, but not by much. Time will tell in GCC 8.1.0 brings home the bacon for optimization improvements.

New optimizations and -O3

Posted May 5, 2018 21:30 UTC (Sat) by nix (subscriber, #2304) [Link]

Compressing things doesn't change the code size in memory, though, which is what matters for almost all metrics (the biggest one on non-embedded systems these days being icache usage).

Throwing exceptions in destructors has just become a bit harder

Posted May 2, 2018 16:33 UTC (Wed) by proski (subscriber, #104) [Link]

gcc 8 obsoletes std::uncaught_exception() in C++17 as required by the standard. Those who throw exceptions in destructors should rethink what they are doing or resort to using std::uncaught_exceptions(), which requires more code and more care, but checks what std::uncaught_exception() was meant to check.

GCC 8.1 Released

Posted May 2, 2018 23:35 UTC (Wed) by roc (subscriber, #30627) [Link] (8 responses)

Offering a non-secure download link in 2018 is not good.

GCC 8.1 Released

Posted May 3, 2018 15:07 UTC (Thu) by jthill (subscriber, #56558) [Link] (6 responses)

Secured connections only do what checking signatures does, and they're worse at it if you care about specific content. Then you need to check the signature on that. There's no privacy or authentication value to SSLing publicly-available-downloads-of-signed-content traffic at all -- anyone who cares can tell exactly what you fetch by just looking at how much and comparing sizes; the only thing SSL will get you in this scenario is quicker detection of vandalism. Not a big enough issue to get worked up about, I don't think, the choice is a judgement call down in bikeshedding territory.

GCC 8.1 Released

Posted May 3, 2018 17:55 UTC (Thu) by nybble41 (subscriber, #55106) [Link] (4 responses)

Secured connections permit a form of "herd immunity". If everyone checked the signatures for every file they download then you'd be correct—TLS wouldn't contribute very much. In practice, however, not everyone checks the signatures, and those who do check don't necessarily do so every time. If the connection is secured then you at least have a degree of confidence that you're getting the file from the same server as everyone else, so you're reasonably safe as long as *some* people check the signatures.

Also, if you're following the link in a web browser and not e.g. wget, a plain HTTP link gives an attacker the opportunity to inject malware or other undesirable content into the response instead of, or alongside, the intended download.

GCC 8.1 Released

Posted May 3, 2018 20:45 UTC (Thu) by flussence (guest, #85566) [Link] (3 responses)

How many people check that the signature on a TLS certificate matches what they expect? Would you feel safer downloading a GCC “verified” by Symantec, Comodo, StartCom or CNNIC? Would you even know if you mysteriously got a different but “valid” cert for the download, what with how modern browsers love to bury security-critical information as deep as possible?

We have that herd immunity - it's called distros. Besides protecting us from those braindead CA bundle policies that hand a backdoor to nation states on a silver platter, they also manage to do it without ruining caching for everybody.

GCC 8.1 Released

Posted May 4, 2018 11:57 UTC (Fri) by foom (subscriber, #14868) [Link] (2 responses)

> Would you feel safer downloading a GCC “verified” by Symantec, Comodo, StartCom or CNNIC?

Yes, certainly.

The large group of trusted CAs is far from perfectly trustworthy, but it does eliminate *some* risk. E.g. a random person at the coffee shop will not have the ability to spoof certificates, but could easily be mitm'ing unencrypted connections.

GCC 8.1 Released

Posted May 4, 2018 13:41 UTC (Fri) by bandrami (guest, #94229) [Link]

Except that those CA's have been caught, in the past, doing things like altering certificates' dates to meet hash requirements, and only get told to take some time off sitting in the corner. And bad Google certs have been spotted in the wild.

The problem has never been the tech, but the agents.

GCC 8.1 Released

Posted May 5, 2018 15:23 UTC (Sat) by flussence (guest, #85566) [Link]

The people who would be the most interested in distributing counterfeit GCC or kernel downloads would most certainly have the ability to twist the arm of a CA, or run one themselves.

GCC 8.1 Released

Posted May 8, 2018 0:18 UTC (Tue) by plugwash (subscriber, #29694) [Link]

The problem with signature checking for web downloads (downloads through a package manager are another matter) is that there is no automation. The user must first manually verify that the key actually belongs to the project and then manually verify the signature using the key. Many users will lack either the skills, the time or both to actually do that.

The CA cartel is far from perfect but nevertheless it is still a massive improvement on no verification at all.

GCC 8.1 Released

Posted May 3, 2018 18:58 UTC (Thu) by ErikF (subscriber, #118131) [Link]

It is a shame that no mirrors (https://www.gnu.org/prep/ftp.en.html) exist with HTTPS, in case that's important to you. Oh well.... :-)