clang makes segfaulting code with -march=core2 on i386

Dimitry Andric dim at FreeBSD.org
Sat Sep 13 18:30:46 UTC 2014


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

-------------- 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/20140913/34f6eb09/attachment.sig>


More information about the freebsd-toolchain mailing list