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/examp
On 2012-10-23 11:05, Dimitry Andric wrote: On 2012-10-22 16:58, Jan Beich wrote: Dimitry Andric d...@freebsd.org writes: On 2012-10-22 09:00, Jan Beich wrote: ... undefined reference to `std::__1::basic_ioschar, std::__1::char_traitschar ::clear(unsigned int)' clang++: error: linker command failed with exit code 1 (use -v to see invocation) Strange, for me it compiles (with a bunch of warnings, which I have fixed locally), and links just fine. However, I always use -std=c++11, which -std= flag are you using, if any? Adding -std=c++11 doesn't help. Neither yours or Garrett's patches. Instead, removing local -finline-functions (implied by -O3) does. With clang, -O3 does not imply -finline-functions, but it may have some influence on the threshold for inlining. This error is still very strange though, and it might be a real bug in the optimizer at -O3; at this level, it really seems to generate a call to a function that is declared inline, with the __always_inline attribute. I have cherry-picked r165367 from the llvm trunk, which should fix this issue, and committed it into our head r242007. Can you please retry your buildworld with the -O3 flag after updating to at least that revision? I will also MFC the fix to stable/9 later on. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
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/examp
Dimitry Andric d...@freebsd.org writes: On 2012-10-23 11:05, Dimitry Andric wrote: On 2012-10-22 16:58, Jan Beich wrote: Dimitry Andric d...@freebsd.org writes: On 2012-10-22 09:00, Jan Beich wrote: ... undefined reference to `std::__1::basic_ioschar, std::__1::char_traitschar ::clear(unsigned int)' clang++: error: linker command failed with exit code 1 (use -v to see invocation) Strange, for me it compiles (with a bunch of warnings, which I have fixed locally), and links just fine. However, I always use -std=c++11, which -std= flag are you using, if any? Adding -std=c++11 doesn't help. Neither yours or Garrett's patches. Instead, removing local -finline-functions (implied by -O3) does. With clang, -O3 does not imply -finline-functions, but it may have some influence on the threshold for inlining. This error is still very strange though, and it might be a real bug in the optimizer at -O3; at this level, it really seems to generate a call to a function that is declared inline, with the __always_inline attribute. I have cherry-picked r165367 from the llvm trunk, which should fix this issue, and committed it into our head r242007. Can you please retry your buildworld with the -O3 flag after updating to at least that revision? As of r242014, atf-run builds fine with -O3 and libc++ for me. Thanks. I will also MFC the fix to stable/9 later on. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
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/examp
On 2012-10-22 16:58, Jan Beich wrote: Dimitry Andric d...@freebsd.org writes: On 2012-10-22 09:00, Jan Beich wrote: ... undefined reference to `std::__1::basic_ioschar, std::__1::char_traitschar ::clear(unsigned int)' clang++: error: linker command failed with exit code 1 (use -v to see invocation) Strange, for me it compiles (with a bunch of warnings, which I have fixed locally), and links just fine. However, I always use -std=c++11, which -std= flag are you using, if any? Adding -std=c++11 doesn't help. Neither yours or Garrett's patches. Instead, removing local -finline-functions (implied by -O3) does. With clang, -O3 does not imply -finline-functions, but it may have some influence on the threshold for inlining. This error is still very strange though, and it might be a real bug in the optimizer at -O3; at this level, it really seems to generate a call to a function that is declared inline, with the __always_inline attribute. For now, I would advise not to use higher levels than -O2. Meanwhile, I will take this problem to the llvm/clang guys. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
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/examp
On Mon, Oct 22, 2012 at 12:00 AM, Jan Beich jbe...@tormail.org wrote:
Marcel Moolenaar mar...@freebsd.org writes:
Author: marcel
Date: Mon Oct 22 01:18:41 2012
New Revision: 241823
URL: http://svn.freebsd.org/changeset/base/241823
Log:
Add ATF to the build. This is may be a bit rought around the egdes,
but committing it helps to get everyone on the same page and makes
sure we make progress.
[...]
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_ostreamchar,
std::__1::char_traitschar )':
/usr/src/usr.bin/atf/atf-run/../../../contrib/atf/atf-run/test-program.cpp:76:
undefined reference to `std::__1::basic_ioschar,
std::__1::char_traitschar ::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.0
+++ /scratch/p4/user/gcooper/atf-head/src/contrib/libc++/include/ios
2012-05-20 04:37:04.0
@@ -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.
Thanks!
-Garrett
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
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/examp
On 2012-10-22 09:24, Garrett Cooper wrote:
On Mon, Oct 22, 2012 at 12:00 AM, Jan Beich jbe...@tormail.org 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_ostreamchar, std::__1::char_traitschar
)':
/usr/src/usr.bin/atf/atf-run/../../../contrib/atf/atf-run/test-program.cpp:76: undefined
reference to `std::__1::basic_ioschar, std::__1::char_traitschar
::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.0
+++ /scratch/p4/user/gcooper/atf-head/src/contrib/libc++/include/ios
2012-05-20 04:37:04.0
@@ -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
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
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/examp
On Mon, Oct 22, 2012 at 4:09 AM, Dimitry Andric d...@freebsd.org wrote: On 2012-10-22 09:00, 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_ostreamchar, std::__1::char_traitschar )': /usr/src/usr.bin/atf/atf-run/../../../contrib/atf/atf-run/test-program.cpp:76: undefined reference to `std::__1::basic_ioschar, std::__1::char_traitschar ::clear(unsigned int)' clang++: error: linker command failed with exit code 1 (use -v to see invocation) Strange, for me it compiles (with a bunch of warnings, which I have fixed locally), and links just fine. However, I always use -std=c++11, which -std= flag are you using, if any? That said, I am planning on importing a new drop of libc++ soon, but I would rather see this fixed sooner than later. So I will cherry-pick a few fixes tonight. Meanwhile, here are the local diffs I have for making atf build. -Dimitry PS: As far as I can see, atf doesn't build at all with clang and libstdc++, because there are many warnings caused by -Wsystem-headers... Is there any incentive to fix these? I submitted the atf compile-time warnings patch on your behalf: http://code.google.com/p/kyua/issues/detail?id=42thanks=42ts=1350910277 . Thanks! -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
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/examp
On Mon, Oct 22, 2012 at 4:29 AM, Dimitry Andric d...@freebsd.org wrote: ... 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. Dmitry: Optimization level might be the salient point. Jan: What are your full CFLAGS/CXXFLAGS? Thanks! -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
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/examp
On Mon, Oct 22, 2012 at 01:18:41AM +, Marcel Moolenaar wrote: M Tinderbox breakages that are the result of this commit are entirely M the committer's fault -- in other words: buildworld testing on amd64 M only. Taking into account the fact that last couple of weeks head was usually not buildable rather than buildable, I strongly disappreciate this. It looks to me as we are again treating head/ as a pile of stuff, not as an operating system one can install and use. Now that we have a big choice of VCSes: svn user branches, git and perforce, why isn't it possible to settle things in private branch and only then commit them to the head/? -- Totus tuus, Glebius. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
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/examp
Dimitry Andric d...@freebsd.org writes: On 2012-10-22 09:00, 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_ostreamchar, std::__1::char_traitschar )': /usr/src/usr.bin/atf/atf-run/../../../contrib/atf/atf-run/test-program.cpp:76: undefined reference to `std::__1::basic_ioschar, std::__1::char_traitschar ::clear(unsigned int)' clang++: error: linker command failed with exit code 1 (use -v to see invocation) Strange, for me it compiles (with a bunch of warnings, which I have fixed locally), and links just fine. However, I always use -std=c++11, which -std= flag are you using, if any? Adding -std=c++11 doesn't help. Neither yours or Garrett's patches. Instead, removing local -finline-functions (implied by -O3) does. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
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/examp
On Mon, Oct 22, 2012 at 7:58 AM, Jan Beich jbe...@tormail.org wrote: Dimitry Andric d...@freebsd.org writes: On 2012-10-22 09:00, 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_ostreamchar, std::__1::char_traitschar )': /usr/src/usr.bin/atf/atf-run/../../../contrib/atf/atf-run/test-program.cpp:76: undefined reference to `std::__1::basic_ioschar, std::__1::char_traitschar ::clear(unsigned int)' clang++: error: linker command failed with exit code 1 (use -v to see invocation) Strange, for me it compiles (with a bunch of warnings, which I have fixed locally), and links just fine. However, I always use -std=c++11, which -std= flag are you using, if any? Adding -std=c++11 doesn't help. Neither yours or Garrett's patches. Instead, removing local -finline-functions (implied by -O3) does. Ok. I was on the right track, even though my solution wasn't correct... Now that we know how to repro it, we can come up with a legitimate fix, but just to be sure we have all the details could you please send us your full environment (CC/CXX/CFLAGS/CXXFLAGS)? Thanks! -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
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/examp
On Mon, Oct 22, 2012 at 09:42:42AM -0700, Garrett Cooper wrote: G On Mon, Oct 22, 2012 at 8:07 AM, Gleb Smirnoff gleb...@freebsd.org wrote: G On Mon, Oct 22, 2012 at 01:18:41AM +, Marcel Moolenaar wrote: G M Tinderbox breakages that are the result of this commit are entirely G M the committer's fault -- in other words: buildworld testing on amd64 G M only. G G Taking into account the fact that last couple of weeks head was usually G not buildable rather than buildable, I strongly disappreciate this. G G It looks to me as we are again treating head/ as a pile of stuff, G not as an operating system one can install and use. G G Now that we have a big choice of VCSes: svn user branches, git and G perforce, why isn't it possible to settle things in private branch G and only then commit them to the head/? G G I had been checking in changes to p4 over the last 4 months and then I G ditched it for a local svn checkout when preparing the final patch G that I sent to Marcel; I had run the patch in svn in two different G sets of VMs in a make tinderbox manner several times. All but a G handful of non-build critical items made it into this commit, and the G only breakage that was present was accidental and affected ATF G runtime. G G Maintaining all these moving pieces has proved challenging (esp. G because I lack the scripts to track all of the changes that I had at G IronPort with p4), and even then tracking new files in p4 is G entertaining compared to svn, git, etc. This unnecessary complexity G plus the fact that one needs p4 in order to collaborate with the G changes I'm working on is the primary reason why I'm ditching it for G git. G G The only breakage that's occurring now we've found is people using G clang/libc++ (and libc++ looks like it has bugs that would have been G caught with C++ applications written in a C++ standards-compliant G manner) and various optimization levels which would not have raised G red flags with make tinderbox in the first place. G G If there was a widespread (gcc and/or standard compiler/linker flags) G issue with the build a) we would have seen it be now in the tinderbox G emails and b) I would have CCed the current set of mailing lists so G the issue would have been resolved quickly. The fact that it wasn't G caught illustrates the fact that although we're trying to pilot clang G as the default compiler by next month, there's a huge gap in required G testing for commits. G G Looking forward, the major items for ATF have been committed. The rest G of the patches which will be committed will be considerably smaller, G targeted to specific components, and [for the most part, minus test G integration in the tinderbox builds which will only be done after G extensively testing is performed] will not affect the standard build G process. G G Thank you for the concern though and I understand where you're coming from. Okay, now I see that you had did a lot of testing and my blame was ungrounded. Sorry. But the commit message from Marcel was so provocating such blame :) And probably I was also driven by the fact that I closed a number of build breakages last week, which weren't mine. Sorry again. -- Totus tuus, Glebius. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
