[Bug 205453] 11.0-CURRENT libcxxrt/guard.cc uses C11's _Static_assert in conditionally-compiled C++ code and when it is used buildworld fails for syntax errors in g++ compilers

2016-03-27 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205453

Dimitry Andric  changed:

   What|Removed |Added

 Status|New |Closed
 Resolution|--- |FIXED

--- Comment #5 from Dimitry Andric  ---
Fixed in r297299.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: CXXSTD=c++11

2016-03-27 Thread Dimitry Andric 
On 25 Mar 2016, at 00:18, Bryan Drewery  wrote:
> 
> On 3/24/2016 4:16 PM, Dimitry Andric wrote:
>> On 24 Mar 2016, at 23:54, Dimitry Andric  wrote:
>>> 
>>> On 24 Mar 2016, at 23:51, Bryan Drewery  wrote:
>> ...
 It fails without -std=c++11 (there's more discussion in that link and in
 PR 205453).
>>> 
>>> Yeah, I also commented on PR 205453 in the past, but I still don't
>>> understand where the external gcc gets its _Static_assert macro from.
>>> Or whether it gets it at all.  Maybe we should place a hack for this in
>>> sys/cdefs.h?  We shouldn't litter contrib code with #ifdef GCC_VERSION
>>> blocks.
>> 
>> Hm, hacking around in cdefs.h also doesn't really help, because gcc
>> refuses to recognize either _Static_assert or static_assert when it's
>> not in C++11 mode.  Reading back https://reviews.freebsd.org/D1390, I
>> see that I originally wanted to avoid building libcxxrt with -std=c++11.
>> This was so you could even build it with gcc 4.2.1 from base.
>> 
>> However, it really doesn't make much sense to do so, and upstream
>> libcxxrt simply uses static_assert directly, and requires -std=c++11.  I
>> will update the libcxxrt build to do so, probably tomorrow.
>> 
> 
> Sounds good.

Done in r297299 [1].  I also imported libc++ r255683 [2], which should
fix llvm-cov compilation with g++, in r297322 [3].

-Dimitry

[1] https://svnweb.freebsd.org/changeset/base/297299
[2] http://reviews.llvm.org/rL255683
[3] https://svnweb.freebsd.org/changeset/base/297322



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: boost/asio/ip/resolver_query_base.hpp:96:3: warning: all paths through this function will call itself

2016-03-27 Thread Dimitry Andric 
On 25 Mar 2016, at 20:15, Willem Jan Withagen  wrote:
> Any suggestions why I'm getting this warning/error in the ceph code:
> 
> In file included from log/Log.cc:12:
> In file included from /usr/local/include/boost/asio.hpp:63:
> In file included from /usr/local/include/boost/asio/ip/basic_resolver.hpp:24:
> In file included from 
> /usr/local/include/boost/asio/ip/basic_resolver_query.hpp:21:
> /usr/local/include/boost/asio/ip/resolver_query_base.hpp:96:3: warning: all 
> paths through this function will call
>  itself [-Winfinite-recursion]
> 
> Could be a boost error, but I have not seen any upgrades to a newer version.

It's a boost bug.  You can apply this trivial upstream fix:

https://github.com/boostorg/asio/commit/9e757605709cace0fc048ad284b2d6aa3ae784ac

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail