Date: Mon, 18 Nov 2013 23:54:00 +0100 From: Matthias Andree <mandree@FreeBSD.org> To: Dimitry Andric <dim@FreeBSD.org> Cc: freebsd-toolchain@freebsd.org Subject: Re: clang++ 3.3 issue (excessively slow compile vs. gcc 4.6 in just one file of a port) Message-ID: <528A9A88.80904@FreeBSD.org> In-Reply-To: <C350407E-E262-4E47-B1A5-09F5374C1AED@FreeBSD.org> References: <528A8481.9010200@FreeBSD.org> <62194A12-1B41-48F6-8434-BA2181411020@FreeBSD.org> <528A93BF.3020707@FreeBSD.org> <C350407E-E262-4E47-B1A5-09F5374C1AED@FreeBSD.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] Am 18.11.2013 23:30, schrieb Dimitry Andric: > On 18 Nov 2013, at 23:25, Matthias Andree <mandree@FreeBSD.org> wrote: >> Am 18.11.2013 23:04, schrieb Dimitry Andric: >> >>> I will have a look at the port meanwhile, I hope it does not pull in too >>> many dependencies? >> >> Thanks for the prompt response. Trying top-of-clang-tree will take me a >> few days until I get around to it (is clang-devel good enough for a >> first attempt?) > > Can you please run the ipsharpen.cc compilation command with -save-temps > added on your system, and then upload the resulting .ii file somewhere? > > That would save me the trouble of building most of GNOME, which it seems > to pull in... :) Uploaded. http://people.freebsd.org/~mandree/ has: <http://people.freebsd.org/~mandree/ipsharpen.ii.xz>: the xzipped .ii file (unpacked: 6.5 MB) <http://people.freebsd.org/~mandree/ipsharpen-compile%2bwarnings.txt>: compiler command line (make VERBOSE=1 MAKE_JOBS_UNSAFE=yes) and early warnings. It is still compiling, and these are the files in the working dir. work/rawtherapee-4.0.11/rtengine/ipsharpen.cc work/.build/rtengine/ipsharpen.ii work/.build/rtengine/ipsharpen.s-40cd6fd9 -O1, -Oz complete in c. 5 seconds, -Os require 5.6 s on my processor. -O2 has now spent more than 510 s I haven't dared -O3. I got: $ size work/.build/rtengine/CMakeFiles/rtengine.d text data bss dec hex filename 414247 16 168 414431 652df work/.build/rtengine/CMakeFiles/rtengine.dir/ipsharpen.cc.o and the .s file has also been xziped and uploaded to the URL above. (unpacked 3.5 MB). >> (Oh, and I wish we had more prominent error messages telling about an >> ABI mismatch between libc++ and libstdc++ than just the innocuous >> undefined references about - roughly - >> Glib::ustring::ustring(std::basic_string<> const &) - I needed to nm -sC >> the glibmm-2.0.so to figure out it provided the std::_1:: namespace >> stuff for c++ and finally figure out the libraries were alright but they >> were using the libc++ ABI rather than GCC's libstdc++.) > > Most of the time, you will only find out at link time if you have mixed > libstdc++ and libc++ STL containers... I'm not sure if there is a nicer > way to bring bad news. :-) Glib shares the fate, because it defers to std:: containers where possible. A nice way would require additional work and get the linkers to complain that symbols resolve with a different, incompatible ABI. That would, however, require second-guessing other ABIs and namespaces, and would hardly be portable -- or add ABI versions into the object files and .a and .so libraries, unless we already have ABI tags somewhere down deep in the ELF stuff. I never checked. [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKKmogACgkQvmGDOQUufZUXoACgsV6iN28PLYSZE395ejveqaQm 38gAn3KZgfHuOUNDOnnbxSVGTjKpFIbJ =x4Kn -----END PGP SIGNATURE-----home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?528A9A88.80904>