On 13 Sep 2014, at 20:52, Andrey Chernov <a...@freebsd.org> wrote: > On 13.09.2014 22:30, Dimitry Andric wrote: >>> By first glance I see a lots of <optimized out> things. It is known that >>> in edge cases gcc preserves more "unused" values than clang. It can be >>> the possible case. I'll try to lower -O level preserving -march=core2 >>> and see. >> >> It seems to work for me with -O1 -march=core2, and while valgrind does >> complain a little, the warnings are all benign. >> >> I'll see if I can "mix and match" a few -O2 and -O1 compiled objects, to >> zero in on where the problematic area(s) are. > > I can confirm that it works with -march=core2 and without -O at all or > with -O1. So it looks very match like overoptimization in clang.
There is no such thing as "over-optimization"; there are only the following possibilities: 1) A bug in gcc's code, which manifests because of (correct) optimizations 2) A bug in one of clang's optimizer passes, which only manifests with -O2 and/or -march=core2 3) Random bit flips because of bad hardware I think we can rule out 3), since that would make it more likely to crash on different files as you retry the build. So that leaves either 1) or 2). In my experience, there definitely are bugs in optimizers, but bugs in the code to be optimized are *much* more common, especially when optimizers get more aggressive about exploiting the possibilities of the C or C++ abstract machine. Therefore, my guess would still be 1). :-) In any case, I have now narrowed it down to gcc/tree.c, which is not a very small file, and which is changed very often upstream, sometimes almost daily. So I will see if I can reproduce it with gcc trunk first, and if that turns out to be good, I will bisect to find the commit that fixes it. If trunk is also not good, the rabbit hole goes a bit deeper... -Dimitry
signature.asc
Description: Message signed with OpenPGP using GPGMail
