Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 581434

Summary: sys-devel/gcc-6.2.0 version bump
Product: Gentoo Linux Reporter: Yi Yang <ahyangyi>
Component: Current packagesAssignee: Gentoo Toolchain Maintainers <toolchain>
Status: RESOLVED FIXED    
Severity: normal CC: ab4bd, Adrian.Bassett, alex_y_xu, anthonyryan1, arthurzam, bertrand, carlphilippreh, dan, david, davidweb, dschridde+gentoobugs, eugene.shalygin, flow, fturco, gabemarcano, hendrik, holger, jaak, jens, jj, lenohou, marcus+bgo, mattst88, me, mitaspiotr, noein93, nrndda, octoploid, robink, siarhei.siamashka, steffen, todd, ua_gentoo_bugzilla, whissi, zeekec, zorry
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: All   
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 582084    

Description Yi Yang 2016-04-28 08:39:09 UTC
GCC 6.1 is out.
https://gcc.gnu.org/gcc-6/changes.html

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.
Comment 1 Jaak Ristioja 2016-04-28 21:53:46 UTC
Maybe it is possible to instrument GCC 6
Comment 2 Jaak Ristioja 2016-04-29 08:44:52 UTC
(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.
Comment 3 Jaak Ristioja 2016-04-29 08:53:57 UTC
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.
Comment 4 octoploid 2016-04-30 07:31:43 UTC
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)
Comment 5 octoploid 2016-04-30 07:37:49 UTC
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.
Comment 6 Marcus 2016-05-17 15:23:42 UTC
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.
Comment 7 fkater 2016-05-19 07:10:53 UTC
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.
Comment 8 Eugene Shalygin 2016-05-19 10:48:22 UTC
(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.
Comment 9 Magnus Granberg gentoo-dev 2016-05-19 15:45:37 UTC
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.
Comment 10 Ryan Hill (RETIRED) gentoo-dev 2016-05-28 17:28:33 UTC
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.
Comment 11 Tomek L 2016-06-02 15:23:57 UTC
>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.
Comment 12 Shane Peelar 2016-06-02 15:29:20 UTC
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.
Comment 13 Jaak Ristioja 2016-06-02 17:30:43 UTC
(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.
Comment 14 Yi Yang 2016-06-17 10:00:32 UTC
(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 ;)
Comment 15 Adam Feldman gentoo-dev 2016-07-03 07:48:46 UTC
*** Bug 587648 has been marked as a duplicate of this bug. ***
Comment 16 jospezial 2016-08-22 15:41:21 UTC
https://gcc.gnu.org/gcc-6/

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!
Comment 17 Ryan Hill (RETIRED) gentoo-dev 2016-08-24 01:58:23 UTC
Is anyone actually working on this?
Comment 18 Matt Turner gentoo-dev 2016-08-24 02:04:27 UTC
(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.
Comment 19 Anthony Basile gentoo-dev 2016-08-24 02:20:04 UTC
(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.
Comment 20 Joshua Kinard gentoo-dev 2016-08-24 10:43:07 UTC
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.
Comment 21 Magnus Granberg gentoo-dev 2016-09-12 23:11:12 UTC
Commited to git: id = 8161c1749c38be3161201c6e6a8027e3fe5cf848