On 13 Sep 2014, at 20:00, Andrey Chernov <a...@freebsd.org> wrote: > On 13.09.2014 20:45, Dimitry Andric wrote: >> After some massaging of gcc's source to disable its built-in segfault >> handlers, I get this backtrace: > > Do you get this with my core or finally able to reproduce it by yourself?
I was able to reproduce it, on stable/10. I could not reproduce it on head, but that is how it sometimes goes with this kind of issue. :) >> I think it's most likely this is some type of undefined behavior in gcc, >> which leads to randomly corrupted tree values. Of course, it could also >> be a clang bug, but I don't see any "64-bit" instructions in there at >> all. >> >> This needs to be investigated further, but it's very hard to understand >> what is going on the guts of gcc's parser. Let alone to reduce this to >> some sort of reproducible test case. > > 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. -Dimitry
signature.asc
Description: Message signed with OpenPGP using GPGMail
