Date: Sat, 22 Mar 2014 15:37:25 +0100 From: Dimitry Andric <dim@FreeBSD.org> To: Jakub Lach <jakub_lach@mailplus.pl> Cc: freebsd-stable@freebsd.org Subject: Re: HEADS UP: merged llvm/clang 3.4 Message-ID: <DAFFF16E-367E-4B2F-9710-8C85487C2E19@FreeBSD.org> In-Reply-To: <1395489997493-5896543.post@n5.nabble.com> References: <0E7E81A1-54E9-4920-A360-005A1C0C4D47@FreeBSD.org> <1395476852973-5896505.post@n5.nabble.com> <76A1AA7F-E526-4481-B04D-0405D3090D93@FreeBSD.org> <1395489997493-5896543.post@n5.nabble.com>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On 22 Mar 2014, at 13:06, Jakub Lach <jakub_lach@mailplus.pl> wrote: > http://pastebin.com/LXT4PiVt > > (Tried commenting out all optimize options, > no difference, always boost-libs is build with -O3) > > FreeBSD 10.0-STABLE #0 r263539 amd64 > > I think libc++ is default now. Currently, it looks like your problem is caused by the "penryn" CPUTYPE. For some reason, this enables boost's 128 bit support, and it leads to problems later on. I'm still investigating what the exact cause is. For now, I would choose another CPUTYPE, or just not specify any CPUTYPE at all. The reason is that in the clang source code, there is the following comment about the Penryn model: /// This enumerator, like \see CK_Yonah, is a bit odd. It is another /// codename which GCC no longer accepts as an option to -march, but Clang /// has some logic for recognizing it. // FIXME: Warn, deprecate, and potentially remove this. CK_Penryn, //@} E.g. it looks like this particular type is an odd one. Apparently gcc already removed it, but I have no idea why. -Dimitry [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlMtoCsACgkQsF6jCi4glqNmjACg29Lu+3eV5viwDud1kzSryIv5 Y8MAniiz5annZajvaAGkv15fK/RZ9He3 =fviZ -----END PGP SIGNATURE-----help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DAFFF16E-367E-4B2F-9710-8C85487C2E19>