Date: Sun, 14 Sep 2014 19:27:33 +0200 From: Dimitry Andric <dim@FreeBSD.org> To: Andrey Chernov <ache@freebsd.org> Cc: toolchain@freebsd.org Subject: Re: clang makes segfaulting code with -march=core2 on i386 Message-ID: <E5DBCCF7-87C3-4CC4-9790-88D1C44698FF@FreeBSD.org> In-Reply-To: <54149286.80608@freebsd.org> References: <54130AD0.8090103@freebsd.org> <A212D7AF-4DA7-4043-BB73-1746A5C2F42F@FreeBSD.org> <54133E1E.9030105@freebsd.org> <54135B24.5040905@freebsd.org> <54135D0B.7060701@freebsd.org> <6FDF432B-8245-4BC7-952B-DFFEEA106D6F@FreeBSD.org> <5414865A.6030101@freebsd.org> <CC121A4D-A6D0-430B-B15F-BFB48C5FB6E6@FreeBSD.org> <54149286.80608@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_1F537256-260A-4987-9296-E2E8D2986F41 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=koi8-r On 13 Sep 2014, at 20:52, Andrey Chernov <ache@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 --Apple-Mail=_1F537256-260A-4987-9296-E2E8D2986F41 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlQV0AwACgkQsF6jCi4glqOFbgCfWGJhF83P/JwJHevYh14ATRF9 WokAnA+QMHcBx+f2MIQ9EIq5pRw01RW2 =lem7 -----END PGP SIGNATURE----- --Apple-Mail=_1F537256-260A-4987-9296-E2E8D2986F41--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E5DBCCF7-87C3-4CC4-9790-88D1C44698FF>