Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 18 Nov 2013 23:04:14 +0100
From:      Dimitry Andric <dim@FreeBSD.org>
To:        Matthias Andree <mandree@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:  <62194A12-1B41-48F6-8434-BA2181411020@FreeBSD.org>
In-Reply-To: <528A8481.9010200@FreeBSD.org>
References:  <528A8481.9010200@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--Apple-Mail=_54762E6D-157F-4FBA-98AF-AC72DCAADFDB
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

On 18 Nov 2013, at 22:20, Matthias Andree <mandree@FreeBSD.org> wrote:
> [Please keep me in Cc:, I am not subscribed.]
> 
> Greetings,
> 
> I have recently spent some efforts getting rawtherapee to compile on
> 10-stable.  I think I succeeded, and came across something I find worth
> investigating.
> 
> For just one of rawtherapee's files, clang++ 3.3's compile time is
> excessively long, compared both to the other files, as well as against
> gcc 4.6.
> 
> System: FreeBSD 10.0-BETA3 #1 r258178: Fri Nov 15 20:00:11 CET 2013
> toor@vmf10:/usr/obj/usr/src/sys/GENERIC
> 
> Compiler: FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
> Target: x86_64-unknown-freebsd10.0
> Thread model: posix
> 
> The port as it currently stands hacks the cmake-generated build.make to
> compile ipsharpen.cc with only -O1 option.  If I remove that patch, so
> that the port compiles with -O2 or -O3, compiling that single file takes
> too long for me to wait for it, in excess of 10 minutes, on my 2.5 GHz
> AMD Phenom II X4.  GCC 4.6 does not exhibit such behaviour.
> 
> I have not yet isolated what might cause this, how would I best go about
> that so we can pin this issue and possibly fix clang++?

In general, first try to reproduce it with top-of-tree clang.  If it
does not occur there, the problem was fixed in the mean time, so the
next question is which revision(s) fixed it, and if it is easy to import
the fix on top of 3.3 release.  This is usually done through bisection.

If it also occurs with top-of-tree clang, either post a preprocessed
file (.ii) to llvm.org's bugzilla, with the used optimization flags, or
attempt to minimize the testcase yourself.

I will have a look at the port meanwhile, I hope it does not pull in too
many dependencies?

-Dimitry


--Apple-Mail=_54762E6D-157F-4FBA-98AF-AC72DCAADFDB
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)

iEYEARECAAYFAlKKju8ACgkQsF6jCi4glqP1nACfegL0PnH8+fEIh8NrRA5KFDEN
P54An3KU+lne1PYh2ITT0fP9H+XbQLV+
=vrBm
-----END PGP SIGNATURE-----

--Apple-Mail=_54762E6D-157F-4FBA-98AF-AC72DCAADFDB--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?62194A12-1B41-48F6-8434-BA2181411020>