GCC 7.1 Released | Hacker News Reader

GCC 7.1 Released

gcc.gnu.org

153 pointsedelsohn29 comments

"The C++ frontend now has experimental support for ALL (emphasis added) of the current C++17 draft, with the -std=c++1z and -std=gnu++1z options, and the libstdc++ library has most of the C++17 draft library features implemented too.

The Address Sanitizer can now report uses of variables after leaving their scope. GCC now can be configured for OpenMP 4.5 offloading to NVidia PTX GPGPUs."

The above are some really intriguing nuggets, I will have to check this out this weekend.

Did I overlook gcc 7.0??

New releases start with .1; .0 corresponds to the release candidate.

Thanks, David

It's an interesting convention but on the other hand makes quite explicit the common wisdom that "point-oh" releases are rarely production quality.

That's wonderful news. But here I am stuck on the latest centos running 4.8. They haven't even made the switch to abi breaking 5.0

You can install a devtoolset[1] to get a newer GCC which keeps ABI compatibility. I'm using gcc 6.2.1 on CentOS 7 that way.

[1]: https://www.softwarecollections.org/en/scls/rhscl/devtoolset...

And to be clear, devtoolset/softwarecollections.org is done by Red Hat - it's not some random third party repository providing some use-at-your-own-risk packages.

> But here I am stuck on the latest centos running 4.8

> They haven't even made the switch to abi breaking 5.0

That's kind of the point of RHEL/CentOS releases... stability above all else.

RHEL/CentOS 8.x will likely include a much newer, but still not bleeding-edge version of gcc and friends.

You can always download the source and compile a newer gcc if you have that requirement... or perhaps try EPEL repo's.

EPEL is extra packages, not usually newer packages. Software Collections is a variety of curated newer packages (including devtoolset, which includes GCC). https://www.softwarecollections.org

Then that's wonderful news to you: your long-release-cycle OS insulates you from every single worry about this update. This is why distributions like CentOS and Debian Stable exist.

(I just realized that might sound sarcastic to The Kids These Days, but it's 100% serious: that's the whole point of these long-term distributions, and those of us who have to manage large numbers of systems love it.)

And it's not like gcc 4.8 was a bad compiler anyway. It has decent C++14 support too.

... which in turn resulted in TensorFlow not being able to be used in clusters for a long, long time: https://github.com/tensorflow/tensorflow/issues/110

Which was the point. That was a long, long list of TensorFlow bugs that were avoided.

I just want to add to that, just to offer a perspective that people not concerned with the upkeep of software always realize: In the general case, when you keep software around for long some bugs will linger. But as long as the issues are well known that's not necessarily a bad thing.

Sometimes you have to work around some corner case or performance anomaly in another layer. You don't want to apply fixes to underlying software willy-nilly without first re-evaluating what you did.

So sometimes stable distributions will avoid fixing bugs for good reason. (That doesn't go for security issues, of course.) And if that's not what you want most distributions have a more suitable branch for you.

> most distributions have a more suitable branch for you

Exactly. CentOS has Fedora, Debian has sid/ubuntu/derivatives, Slackware has -current. If you don't require a stable platform (and most developers don't) then you're welcome to join people on the unstable side of things, making the next stable side of things.

The problem is most of the time developers working with clusters do not have control of which distribution to use. TensorFlow was considered stable (or at least stable enough for research) for a long time before it can be used with glibc 2.12.

That's odd, I was able to compile both bazel and tensorflow from source since early spring 2016 on RHEL 6.5 (not that it was straight forward ...), so it should work for centOS as well.

It certainly wasn't straightforward and took us two weeks to get right :(

This "long term" cycle is also why I get to "enjoy" C++98 and not C++11 for the next 20 years. But I'm happy it's more..."stable", I guess.

If you care about the difference between C++98 and C++11, CentOS is probably not the distribution for you. CentOS is for administrators who need to support a years-long lifecycle of an existing program.

The problem is that he still has to target that platform as a developer, meaning avoiding dependencies like new libstdc++ versions.

Although one can always link statically...

Why would someone target an old LTS distribution as a development target? That makes no sense.

Because your users are running it?

Ship them the dependencies too?

For Debian/Ubuntu there are always backports and PPAs.

And you can require RHEL7, or ship them Docker images, or a statically compiled blob.

My rolling release Gentoo I started building in 2012 is still on gcc 4.9.4. (Although I do see 5.4.0 installed in a slot).

It's been years since I did a gcc update. They're not for the weak of heart of spirit. I might decide to do a full backup soon and do it again soon.

5.4.0 was just stabilized on amd64 in the last few weeks, so you're not far behind. You do have to rebuild a lot of packages (anything C++), but it all went smoothly for me.

I find them quite simple, but then, I'm on NixOS. :-)

Which is not an operating system I'd normally recommend to... anyone. If you like Gentoo, though, then you might quite appreciate its build system. Worth a look?

He I'm on 6.3.0 :p (for Zen compile target.)

Reply on news.ycombinator.com