Re: strange stable/9 buildworld failure

2013-07-11 Thread Dimitry Andric
On Jul 11, 2013, at 19:19, Andriy Gapon wrote: > on 11/07/2013 19:43 Andriy Gapon said the following: >> >> buildword was run as make -j8 buildworld and the it mysteriously failed like >> this: >> >> sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 liblwres.so.80 >> /usr/obj/usr/src/

Re: strange stable/9 buildworld failure

2013-07-11 Thread Andriy Gapon
on 11/07/2013 19:43 Andriy Gapon said the following: > > buildword was run as make -j8 buildworld and the it mysteriously failed like > this: > > sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 liblwres.so.80 > /usr/obj/usr/src/tmp/usr/lib > sh /usr/src/tools/install.sh -l s liblwres

Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity

2013-07-11 Thread Bruce Evans
On Thu, 11 Jul 2013, David Chisnall wrote: On 11 Jul 2013, at 13:11, Bruce Evans wrote: The error message for the __builtin_isnan() version is slightly better up to where it says more. The less-unportable macro can do more classification and detect problems at compile time using __typeof().

strange stable/9 buildworld failure

2013-07-11 Thread Andriy Gapon
buildword was run as make -j8 buildworld and the it mysteriously failed like this: sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 liblwres.so.80 /usr/obj/usr/src/tmp/usr/lib sh /usr/src/tools/install.sh -l s liblwres.so.80 /usr/obj/usr/src/tmp/usr/lib/liblwres.so 1 error *** [librar

Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity

2013-07-11 Thread Bruce Evans
On Thu, 11 Jul 2013, David Chisnall wrote: On 11 Jul 2013, at 13:11, Bruce Evans wrote: is also not required to be conforming C code, let alone C++ code, so there is only a practical requirement that it works when included in the C++ implementation. Working with the C++ implementation is t

Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity

2013-07-11 Thread David Chisnall
On 11 Jul 2013, at 13:11, Bruce Evans wrote: > The error message for the __builtin_isnan() version is slightly better up > to where it says more. > > The less-unportable macro can do more classification and detect problems > at compile time using __typeof(). The attached patch fixes the related

Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity

2013-07-11 Thread Bruce Evans
On Thu, 11 Jul 2013, Tijl Coosemans wrote: On 2013-07-11 06:21, Bruce Evans wrote: On Wed, 10 Jul 2013, Garrett Wollman wrote: < said: I think isnan(double) and isinf(double) in math.h should only be visible if (_BSD_VISIBLE || _XSI_VISIBLE) && __ISO_C_VISIBLE < 1999. For C99 and higher there

Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity

2013-07-11 Thread David Chisnall
On 11 Jul 2013, at 13:11, Bruce Evans wrote: > is also not required to be conforming C code, let alone C++ code, > so there is only a practical requirement that it works when included > in the C++ implementation. Working with the C++ implementation is the problem that we are trying to solve. >

Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity

2013-07-11 Thread Bruce Evans
On Thu, 11 Jul 2013, David Chisnall wrote: You're joining in this discussion starting in the middle, so you probably missed the earlier explanation. I was mainly addressing a C99 point. I know little about C++ or C11. On 11 Jul 2013, at 05:21, Bruce Evans wrote: I don't see how any conf

Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity

2013-07-11 Thread Tijl Coosemans
On 2013-07-11 06:21, Bruce Evans wrote: > On Wed, 10 Jul 2013, Garrett Wollman wrote: >> < said: >>> I think isnan(double) and isinf(double) in math.h should only be >>> visible if (_BSD_VISIBLE || _XSI_VISIBLE) && __ISO_C_VISIBLE < 1999. >>> For C99 and higher there should only be the isnan/isinf

Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity

2013-07-11 Thread David Chisnall
Hi Bruce, You're joining in this discussion starting in the middle, so you probably missed the earlier explanation. On 11 Jul 2013, at 05:21, Bruce Evans wrote: > I don't see how any conforming program can access the isnan() function > directly. It is just as protected as __isnan() would be.