[lfs-dev] gcc test failures with current svn
zarniwhoop at ntlworld.com
Sun Aug 7 12:50:50 PDT 2016
On Sun, Aug 07, 2016 at 08:47:32PM +0200, Romain Geissler wrote:
> On Sun, 7 Aug 2016, Ken Moffat wrote:
> > On Sun, Aug 07, 2016 at 12:20:23PM -0500, Bruce Dubbs wrote:
> > > Ken Moffat wrote:
> > >
> > > Isn't -flto the gold linker? I'm not sure.
> > >
> > > Didn't someone once say that if you don't follow the book and something
> > > breaks, that you get to keep the pieces?
> > >
> > > [snip]
> > Probably (-flto), certainly the book doesn't enable the plugins.
> > And yes, I'm keeping all the pieces.
> The book neither explicitly disable the linker plugin. So as we are
> using up to date binutils which supports the linker plugin, on a non
> exotic plateform like using ELF, then by default both binutils and gcc
> will be built with LTO and linker plugin support, whether you use gold
> or not.
Thanks for that comment - I had not considered that.
> About the build failures you are reporting, you only show the ones in
> the "guality" test folders. For me, whatever the gcc/binutils/gdb
> versions, these tests are always very flacky and I could never got them
> to work at 100% whatever the configuration I use.
> What are the "guality" tests ? Simply tests that checks that the
> generated debug symbols are fine. In other words, in these tests, gcc
> compiles some dummy programs with different options, then start them
> with gdb, and tries to put breakpoint and print values. In all the case
> I investigated on my side, the issue were that when printing values of
> variables in gdb, it often ended up printing "optimized out" rather than
> the real value. These tests are highly dependent on the gdb version you
> use. So in the end, gcc may be wrong, or maybe it is gcc that cannot
> properly read the gcc DWARF data, but the resulting code is fine, just
> the debugging may not be.
> Apparently I am not the only one where these tests are very flacky. I
> discovered that in Google branch of gcc they ended up completely
> disabling all these tests because they were always broken at different
> places. See https://gcc.gnu.org/ml/gcc-patches/2011-03/msg02120.html
> Even today, these tests seems to pass for some gcc developers, but not
> for others. Just check the gcc "testresults" mailing list:
> For example a run executed on gcc 6 x86_64 by H.J. Lu:
> https://gcc.gnu.org/ml/gcc-testresults/2016-08/msg00767.html you can see
> that a lot of guality tests are failing as well.
> So I wouldn't care that much about "guality" tests (on my side, I have
> disabled them since they never worked, even when using the very latest
> git revision of all involved components).
Thanks - I had not spotted they were all in '/quality/', I focussed
more on the several pr numbers. I don't recall failures here
before, but I take your point - with the recervation that HJL's
versions of binutils have often turned out to be "bleeding edge" -
at one time (probably in CLFS, but perhaps when the lfs-hackers (?)
list was active) I was using his binutils about half the time - but
in the end I gave that up as too much pain.
It would be interesting to see if my haswell shows the same
problems, but for the moment I'm not going to try more than one
(different) build at a time.
I'm also *worried* by the many i686 failures - it seems entirely
plausible that I might have not noticed them.
At that point I went back and *looked* at my gcc-6.1.0 test results
from 20160527 on the haswell, and got very embarassed - no i386
failures, but 52 failures in plain gcc - and that system works well.
Maybe I'll just give up!
`I shall take my mountains', said Lu-Tze. `The climate will be good
for them.' -- Small Gods
More information about the lfs-dev