Re: System libc++ isn't fully compatible with clang 3.4 from ports

2014-01-30 Thread Dimitry Andric
On 29 Jan 2014, at 15:45, Dmitry Marakasov amd...@amdmi3.ru wrote:
 * Dimitry Andric (d...@freebsd.org) wrote:
 
 JFYI, I've just ran into shortcoming of libc++ from 10-RELEASE when used
 with clang 3.4 from ports:
 ...
 The cause: http://llvm.org/bugs/show_bug.cgi?id=17798, was fixed in
 libc++ r194154. We probably need to update libc++ or at least backport
 this into stable branches if we want to support clang 3.4 in ports.
 
 Hm, which port is having problems with this?  I have built quite a large
 set, and never encountered this issue.
 
 In any case: yes, it is quite long overdue for a libc++ update. :-)  I
 will have a look tonight.
 
 New version of games/spring (not in ports yet).
 
 std::function and lambdas are not that widely used for this problem to
 be common, but some time we may run into it for some critical software.

Okay, I imported the 3.4 version of libc++, which includes the fix for
llvm PR17798, in r261283.  I also bumped __FreeBSD_version to 117
for it.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: System libc++ isn't fully compatible with clang 3.4 from ports

2014-01-29 Thread Dimitry Andric
On 29 Jan 2014, at 03:27, Dmitry Marakasov amd...@amdmi3.ru wrote:
 
 JFYI, I've just ran into shortcoming of libc++ from 10-RELEASE when used
 with clang 3.4 from ports:
...
 The cause: http://llvm.org/bugs/show_bug.cgi?id=17798, was fixed in
 libc++ r194154. We probably need to update libc++ or at least backport
 this into stable branches if we want to support clang 3.4 in ports.

Hm, which port is having problems with this?  I have built quite a large
set, and never encountered this issue.

In any case: yes, it is quite long overdue for a libc++ update. :-)  I
will have a look tonight.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: System libc++ isn't fully compatible with clang 3.4 from ports

2014-01-29 Thread Dmitry Marakasov
* Dimitry Andric (d...@freebsd.org) wrote:

  JFYI, I've just ran into shortcoming of libc++ from 10-RELEASE when used
  with clang 3.4 from ports:
 ...
  The cause: http://llvm.org/bugs/show_bug.cgi?id=17798, was fixed in
  libc++ r194154. We probably need to update libc++ or at least backport
  this into stable branches if we want to support clang 3.4 in ports.
 
 Hm, which port is having problems with this?  I have built quite a large
 set, and never encountered this issue.
 
 In any case: yes, it is quite long overdue for a libc++ update. :-)  I
 will have a look tonight.

New version of games/spring (not in ports yet).

std::function and lambdas are not that widely used for this problem to
be common, but some time we may run into it for some critical software.

-- 
Dmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru  ..:  jabber: amd...@jabber.ruhttp://www.amdmi3.ru
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


System libc++ isn't fully compatible with clang 3.4 from ports

2014-01-28 Thread Dmitry Marakasov
Hi!

JFYI, I've just ran into shortcoming of libc++ from 10-RELEASE when used
with clang 3.4 from ports:

---
% cat test.cc
#include iostream
#include functional

int main() {
std::functionvoid() f = []() { std::cerr  test\n; };
return 0;
}
% clang++ -std=c++11 test.cc ---
% clang++34 -std=c++11 test.cc ---
In file included from test.cc:1:
In file included from /usr/include/c++/v1/iostream:38:
In file included from /usr/include/c++/v1/ios:216:
In file included from /usr/include/c++/v1/__locale:15:
In file included from /usr/include/c++/v1/string:434:
In file included from /usr/include/c++/v1/algorithm:627:
In file included from /usr/include/c++/v1/memory:603:
/usr/include/c++/v1/tuple:320:11: error: rvalue reference to type 'lambda at 
test.cc:5:28' cannot bind to lvalue of type 'lambda at test.cc:5:28'
: value(__t.get())
  ^ ~
/usr/include/c++/v1/tuple:444:8: note: in instantiation of member function 
'std::__1::__tuple_leaf0, lambda at test.cc:5:28 , false::__tuple_leaf' 
requested here
struct __tuple_impl__tuple_indices_Indx..., _Tp...
   ^
/usr/include/c++/v1/functional:1286:26: note: in instantiation of member 
function 'std::__1::__function::__funclambda at test.cc:5:28, 
std::__1::allocatorlambda at test.cc:5:28 , void ()::__func' requested here
::new (__f_) _FF(_VSTD::move(__f));
 ^
test.cc:5:28: note: in instantiation of function template specialization 
'std::__1::functionvoid ()::functionlambda at test.cc:5:28 ' requested 
here
std::functionvoid() f = []() { std::cerr  test\n; };
  ^
In file included from test.cc:1:
In file included from /usr/include/c++/v1/iostream:38:
In file included from /usr/include/c++/v1/ios:216:
In file included from /usr/include/c++/v1/__locale:15:
In file included from /usr/include/c++/v1/string:434:
In file included from /usr/include/c++/v1/algorithm:627:
In file included from /usr/include/c++/v1/memory:603:
/usr/include/c++/v1/tuple:321:10: error: static_assert failed Can not copy a 
tuple with rvalue reference member
{static_assert(!is_rvalue_reference_Hp::value, Can not copy a tuple 
with rvalue reference member);}
 ^ 
/usr/include/c++/v1/tuple:320:11: error: rvalue reference to type 
'allocator[...]' cannot bind to lvalue of type 'allocator[...]'
: value(__t.get())
  ^ ~
/usr/include/c++/v1/tuple:444:8: note: in instantiation of member function 
'std::__1::__tuple_leaf0, std::__1::allocatorlambda at test.cc:5:28  , 
false::__tuple_leaf' requested here
struct __tuple_impl__tuple_indices_Indx..., _Tp...
   ^
/usr/include/c++/v1/functional:1294:34: note: in instantiation of member 
function 'std::__1::__function::__funclambda at test.cc:5:28, 
std::__1::allocatorlambda at test.cc:5:28 , void ()::__func' requested here
::new (__hold.get()) _FF(_VSTD::move(__f), allocator_Fp(__a));
 ^
test.cc:5:28: note: in instantiation of function template specialization 
'std::__1::functionvoid ()::functionlambda at test.cc:5:28 ' requested 
here
std::functionvoid() f = []() { std::cerr  test\n; };
  ^
In file included from test.cc:1:
In file included from /usr/include/c++/v1/iostream:38:
In file included from /usr/include/c++/v1/ios:216:
In file included from /usr/include/c++/v1/__locale:15:
In file included from /usr/include/c++/v1/string:434:
In file included from /usr/include/c++/v1/algorithm:627:
In file included from /usr/include/c++/v1/memory:603:
/usr/include/c++/v1/tuple:321:10: error: static_assert failed Can not copy a 
tuple with rvalue reference member
{static_assert(!is_rvalue_reference_Hp::value, Can not copy a tuple 
with rvalue reference member);}
 ^ 
4 errors generated.
---

The cause: http://llvm.org/bugs/show_bug.cgi?id=17798, was fixed in
libc++ r194154. We probably need to update libc++ or at least backport
this into stable branches if we want to support clang 3.4 in ports.

-- 
Dmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru  ..:  jabber: amd...@jabber.ruhttp://www.amdmi3.ru
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org