Will GCC-6.1 be available anytime soon?

[asturm]

[janos666]

I recently had some trouble with GCC after changing some hardware in my home server, including a switch from AMD 5600K to Pentium G4400.

I usually had march=native in my make.conf and compiled the kernel the same way (gentoo-sources with the experimental flag to make this convenient). Obviously, I had to recompile everything for basic x86-64 before switching the hardware but the migration went fine up to that point. However, I had serious issues with switching back to march=native.

GCC 5.4 (~amd64) identified this CPU as "silvermont" which is quite similar (if not exactly the same?) in terms of instruction set support but it's not exactly the same architecture (this is a 14nm skylake desktop CPU, not a low-power SoC from the 22nm haswell era). Although, it seemed to get all the instruction sets right (the flags reported by /proc/cpuinfo and the debug output of gcc seemed to be in line, however, I didn't check all of them one-by-one, just looked for some obvious mistakes), thus using march=native resulted in incompatible code (I didn't expect a problem, so I completely messed up the whole system with emerge, I had to roll back to a snapshot).

So, I tried to run ahead of the problem and use 6.2-r1 (**) but it seemed to have even more problems. It correctly identified the CPU as "skylake" and it disabled most of the instruction sets which are not available at the entry level of this CPU lineup (the easiest example is probably the AVX family which is available only for Core i* and Xeon E* V5 but not for Pentium and Celeron variants), however it leaved some clearly incompatible sets enables (namely BMI1 and BMI2 - I have no idea why...?).

But strangely enough, after upgrading from gentoo-sources 4.7.6 to 4.8.0 (~amd64), GCC 6.2 started working fine. I wonder if this was:
1: a random bug (possibly related to the status of the GCC 6.2 ebuild)
2: the new kernel might produces a slightly different output on /proc/cpuinfo which might be easier for GCC 6.2 to understand...? (I never logged that output and didn't examine it closely before both GCC versions failed.)
3: while upgrading the kernel, I figured out how to use the early microcode update driver (I previously thought I get the microcode updated by the motherboard firmware but later realized that only updates CPU0 and leaves CPU1 at it's initial revision and there are 10+ skylake microcode updates since the platform's release, so rev0 probably has numerous issues which might weren't considered by the kernel since CPU0 was updated...).

Did anybody have similar experience?


There seems to remain a tiny issue still: both GCC versions detect the L1 cache size as 32KiB (l1-cache-size=32), even though it's 64KiB (according to both Intel's specs and dmidecode or lshw).
I am not sure if that's a bug but I can't create a GCC bug tracker account anyways.

[trippels]

[Nsane457]

So, I'm happy to announce that after having started this thread and actively working to fix the bugs, all GCC-6 related bugs are pretty much fixed. The few that remain either have a pull-request/patch pending or a reason as to why the package can't/shouldn't be fixed (most require version bumps). On to GCC-7...

[NeddySeagoon]

Nsane457,

gcc-7 has been mostly working for me since just before it was unmasked. I was tempted for arm64 support.
My guess is that it won't be far behind gcc-6 and the /17.0/ profiles going stable.

gcc-7 probably deserves its own thread.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.