clang makes segfaulting code with -march=core2 on i386

[Dimitry Andric]

On 13 Sep 2014, at 20:52, Andrey Chernov <ache at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-toolchain/attachments/20140914/992c5163/attachment.sig>