GCC 6.1 is out.
I'd like to try it out. The improvements to LTO seem significant.
A noticable change in changelog says
> 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.
Which means we can expect major breakage if we blindly upgrade to GCC 6. Therefore, we probably want to mask GCC 6.1 for quite some time, at least until application developers catch on.
Maybe it is possible to instrument GCC 6
(In reply to Jaak Ristioja from comment #1)
> Maybe it is possible to instrument GCC 6
Sry, I just wanted to CC myself, but unfortunately left some text in this box.
I was just thinking whether it were possible to instrument GCC 6 to warn when the code contains questionable expressions using the this pointer, e.g.
if (this == 0)
or similar. I don't know whether GCC 6 warns on such cases, but patching sys-devel/gcc to warn when it encounters affected code might help finding such issues earlier.
According to the official "Porting to GCC 6" guide @ https://gcc.gnu.org/gcc-6/porting_to.html there is now a -Wnonnull-compare option which should warn in such cases. And it is also enabled by -Wall.
Just add "-fno-delete-null-pointer-checks -flifetime-dse=1" to CXXFLAGS
and everything should be fine.
Without these two flags you'll get tons of seemingly random segfaults.
(My whole Gentoo system is build with gcc-6 and it works fine)
All -fdelete-null-pointer-checks issues can be found by -fsanitize=undefined.
-flifetime-dse=2 (the new default in gcc-6) issues are much harder
to debug. -fsanitize=undefined doesn't work in this case. And there
also is no warning available.
I can confirm comment #4 by octoploid.
I first built my system without -flifetime-dse=1 and had segfaults all over the place. In particular many Qt5 QML applications failed because of lifetime-dse optimizations before. As long as upstream bug https://bugreports.qt.io/browse/QTBUG-52057 is not fixed -flifetime-dse is required to get a working system.
Why the hell should we wait for other packages to be fixed and block GCC ?
I see no point at all in waiting. There are certainly a lot of people around
not even using QT and stuff at all. Other's might want to try it out, cross-compile with it whatever.
So, IMHO, enable GCC and (hard) mask it. Give people the freedom to decide.
(In reply to F. Kater from comment #7)
> So, IMHO, enable GCC and (hard) mask it. Give people the freedom to decide.
+1, expecting porting to GCC 6 from developers and not providing the GCC 6 (to them too) is illogical at least.
With use ssp enable glibc fail to build that we want to have default on.
On hardened gcc with pie enable grub and the kernel fail to build so far.
No one is waiting for other packages to be fixed before adding 6.1. We'll add it hardmasked just like we've done for every release.
>We'll add it hardmasked just like we've done for every release.
GCC 6.1 was released on April. Why it hasn't been added to portage? This is ridiculous, Gentoo have a problem with some key packages maintainers.
If you want a workaround, consider adding the hardened-development overlay and installing gcc 6.1.0 from there. You'll have to disable pie for it to build kernels, however, and if you want to build things like Qt and Chromium with it, you'll need to add -flifetime-dse=1 to your CXXFLAGS.
I know this is not ideal, but it's working for me in the meantime while this is being sorted out.
(In reply to Ryan Hill from comment #10)
> No one is waiting for other packages to be fixed before adding 6.1. We'll
> add it hardmasked just like we've done for every release.
So, is the current long delay part of Gentoo's regular process for packaging GCC or is there some extraordinary reason for this? Given the upvotes on this report, I suggest this release to be prioritized.
(In reply to Jaak Ristioja from comment #13)
> (In reply to Ryan Hill from comment #10)
> > No one is waiting for other packages to be fixed before adding 6.1. We'll
> > add it hardmasked just like we've done for every release.
> So, is the current long delay part of Gentoo's regular process for packaging
> GCC or is there some extraordinary reason for this? Given the upvotes on
> this report, I suggest this release to be prioritized.
I don't remember a comparable delay for GCC 5, even if it actually caused more breakage than GCC 6 can cause. (changing visibility and incompatible std::string namespace were major breakers)
In the meantime the GCC 6 from hardened is probably the best thing we now have. My own overlay (ahyangyi-overlay) also has a simplistic and almost vanilla ebuild, but I don't recommend that ;)
*** Bug 587648 has been marked as a duplicate of this bug. ***
The GNU project and the GCC developers are pleased to announce the release of GCC 6.2.
This release is a bug-fix release, containing fixes for regressions in GCC 6.1 relative to previous releases of GCC.
Please let it into the tree!
Is anyone actually working on this?
(In reply to Ryan Hill from comment #17)
> Is anyone actually working on this?
I haven't seen any evidence. I did ask vapier on #gentoo-dev if there was anything I could do to help, but I didn't see a reply.
(In reply to Matt Turner from comment #18)
> (In reply to Ryan Hill from comment #17)
> > Is anyone actually working on this?
> I haven't seen any evidence. I did ask vapier on #gentoo-dev if there was
> anything I could do to help, but I didn't see a reply.
Zorry is working on it with an emphasis on hardening. The ebuild/eclass is in the hardened-development overlay. I'm also interested because gcc-6 has a lot of fixes for musl. Usually the hardened team follows vapier's lead when it comes to pushing out cutting edge versions of gcc, but if he's busy we could put it on the tree. Let me ask Zorry if its good to go.
I've been itching to test it out on mips. Got torched for a while on R10K-class systems during 4.9, and someone on gcc's upstream fixed it by accident. 5.x has been very good for o32 and n32, both glibc and uclibc. Want to see if there are any surprises lurking in 6.x or not. I am just beginning to begin another catalyst run, soon, which will be based on binutils-2.26.1 and gcc-5.4.0. But after that, wide open to start testing a few different things w/ 6.x.
Commited to git: id = 8161c1749c38be3161201c6e6a8027e3fe5cf848