From owner-svn-src-all@FreeBSD.ORG Mon Oct 22 11:29:56 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9F3ED79B; Mon, 22 Oct 2012 11:29:56 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2B93B8FC0C; Mon, 22 Oct 2012 11:29:56 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:c885:d4a7:e016:ae9d] (unknown [IPv6:2001:7b8:3a7:0:c885:d4a7:e016:ae9d]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id AAD505C59; Mon, 22 Oct 2012 13:29:47 +0200 (CEST) Message-ID: <50852E29.1050905@FreeBSD.org> Date: Mon, 22 Oct 2012 13:29:45 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Garrett Cooper Subject: Re: svn commit: r241823 - in head: . etc etc/atf etc/mtree lib lib/atf lib/atf/libatf-c lib/atf/libatf-c++ libexec libexec/atf libexec/atf/atf-check share share/atf share/doc share/doc/atf share/exampl... References: <201210220118.q9M1Ifh5098857__14926.3614825488$1350868751$gmane$org@svn.freebsd.org> <1TQC0L-000AZG-Q5@internal.tormail.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcel Moolenaar , Howard Hinnant , svn-src-all@freebsd.org, src-committers@freebsd.org, svn-src-head@freebsd.org, Jan Beich X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 11:29:56 -0000 On 2012-10-22 09:24, Garrett Cooper wrote: > On Mon, Oct 22, 2012 at 12:00 AM, Jan Beich wrote: ... >> atf-run fails to link when using -stdlib=libc++. It works if I remove >> `throw' from check_stream(). Any clue? >> >> test-program.o: In function `(anonymous namespace)::check_stream(std::__1::basic_ostream >&)': >> /usr/src/usr.bin/atf/atf-run/../../../contrib/atf/atf-run/test-program.cpp:76: undefined reference to `std::__1::basic_ios >::clear(unsigned int)' >> clang++: error: linker command failed with exit code 1 (use -v to see invocation) > > Is it a bug in libc++ where it's doing the wrong thing inlining some > values for basic_ios (my guess is based on the snippet example at: > http://www.cplusplus.com/reference/iostream/ios/clear/ ): > > $ p4 diff -du ios > --- //depot/user/gcooper/atf-head/src/contrib/libc++/include/ios > 2012-05-20 04:37:04.000000000 0000 > +++ /scratch/p4/user/gcooper/atf-head/src/contrib/libc++/include/ios > 2012-05-20 04:37:04.000000000 0000 > @@ -575,10 +575,10 @@ > _LIBCPP_ALWAYS_INLINE > _LIBCPP_EXPLICIT > operator bool() const {return !fail();} > - _LIBCPP_ALWAYS_INLINE bool operator!() const {return fail();} > - _LIBCPP_ALWAYS_INLINE iostate rdstate() const {return ios_base::rdstate();} > - _LIBCPP_ALWAYS_INLINE void clear(iostate __state = goodbit) {ios_base::clear(__state);} > - _LIBCPP_ALWAYS_INLINE void setstate(iostate __state) {ios_base::setstate(__state);} > + _LIBCPP_INLINE_VISIBILITY bool operator!() const {return fail();} > + _LIBCPP_INLINE_VISIBILITY iostate rdstate() const {return ios_base::rdstate();} > + void clear(iostate __state = goodbit) {ios_base::clear(__state);} > + _LIBCPP_INLINE_VISIBILITY void setstate(iostate __state) {ios_base::setstate(__state);} > _LIBCPP_ALWAYS_INLINE bool good() const {return ios_base::good();} > _LIBCPP_ALWAYS_INLINE bool eof() const {return ios_base::eof();} > _LIBCPP_ALWAYS_INLINE bool fail() const {return ios_base::fail();} > > I'm building clang and libc++ in my VM to confirm. I don't think so, as these member functions are supposed to be always inlined. E.g. basic_ios::clear() should always be expanded inline to ios_base::clear(), which is a normal (out of line) function. However, the visibility stuff is always terribly confusing, so you might have a found a real issue. Note that in libc++ trunk, the attributes of these member functions have not changed. In any case, I cannot reproduce the link error on my system. -Dimitry