GCC 6.1 Compiler Officially Released With OpenMP 4.5, C++14 Default & Much More

[phoronix]

Phoronix: GCC 6.1 Compiler Officially Released With OpenMP 4.5, C++14 Default & Much More

Jakub Jelinek of Red Hat today announced the official release of the big GCC 6.1 compiler update!..

http://www.phoronix.com/scan.php?page=news_item&px=GCC-6.1-Released

[hubick]

It's exciting to think about 16 years of C++ development finally hitting mainstream developer use.

[gufide]

I wonder what's keeping clang developper to make c++14 the default standard too.

[thelongdivider]

Can you compare this to llvm/clang from git?

[Fuchs]

Quite important part of the release notes:

Value range propagation now assumes that the this pointer of C++ member functions is non-null. This eliminates common null pointer checks but also breaks some non-conforming code-bases (such as Qt-5, Chromium, KDevelop).


Yeah, let's release something that breaks Qt5, great idea. Have fun with KDE, VLC, Mumnlr and various others breaking. And Chromium. I'm sure nobody will notice.

[kalrish]

Quite important part of the release notes:

Value range propagation now assumes that the this pointer of C++ member functions is non-null. This eliminates common null pointer checks but also breaks some non-conforming code-bases (such as Qt-5, Chromium, KDevelop). As a temporary work-around -fno-delete-null-pointer-checks can be used. Wrong code can be identified by using -fsanitize=undefined.

Yeah, let's release something that breaks Qt5, great idea. Have fun with KDE, VLC, Mumnlr and various others breaking. And Chromium. I'm sure nobody will notice.

They are non-conforming. It's their fault to rely on undefined behavior. But, anyway, it's not like it won't be possible to build them with the new GCC version, as your partial quote implies: the old behavior is just a flag away. And there are ways to detect such non-standard code.

[kruger]

Quite important part of the release notes:

Value range propagation now assumes that the this pointer of C++ member functions is non-null. This eliminates common null pointer checks but also breaks some non-conforming code-bases (such as Qt-5, Chromium, KDevelop).


Yeah, let's release something that breaks Qt5, great idea. Have fun with KDE, VLC, Mumnlr and various others breaking. And Chromium. I'm sure nobody will notice.

The full point states that

• Value range propagation now assumes that the this pointer of C++ member functions is non-null. This eliminates common null pointer checks but also breaks some non-conforming code-bases (such as Qt-5, Chromium, KDevelop). As a temporary work-around -fno-delete-null-pointer-checks can be used. Wrong code can be identified by using -fsanitize=undefined.

So you can still compile these projects. And it is these projects developers fault that they rely on undefined behavior. And GCC even gives you the tools to quickly find the undefined spots to fix them. And not doing the null check when it's unnecessary gives you some performance. And… stop whining

[caligula]

Yeah, let's release something that breaks Qt5, great idea. Have fun with KDE, VLC, Mumnlr and various others breaking. And Chromium. I'm sure nobody will notice.

Why would you want worse perfomance and to support non-standard behavior? Seems irrational.

[carewolf]

Quite important part of the release notes:

Value range propagation now assumes that the this pointer of C++ member functions is non-null. This eliminates common null pointer checks but also breaks some non-conforming code-bases (such as Qt-5, Chromium, KDevelop).


Yeah, let's release something that breaks Qt5, great idea. Have fun with KDE, VLC, Mumnlr and various others breaking. And Chromium. I'm sure nobody will notice.

It doesn't really break them. At least in Qt the null-checks of this are just assertions, extra protection in debug builds.

[Brane215]

I've just managed to compile it under Gentoo. I've filtered Gentoo specific patches for gcc-5.3.0 and tweaked them for 6.1.0 but there is something wrong with poisoning system directories. During compiling, it tries to used poisoned getenv from its own libraries and croaks. I tried leaving 67_all_gcc-poison-system-directories.patch, but thing still poisons itself.

After that, I've cut out all extra patches and now it works, but it would be nice if someone could take a look at this and make gcc-6.1.0.ebuild soon...