clang++ 3.3 issue (excessively slow compile vs. gcc 4.6 in just one file of a port)

[Matthias Andree]

Am 18.11.2013 23:30, schrieb Dimitry Andric:
> On 18 Nov 2013, at 23:25, Matthias Andree <mandree at 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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-toolchain/attachments/20131118/c23f55e1/attachment.sig>