From owner-freebsd-current@FreeBSD.ORG  Mon May 28 08:42:10 2012
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 7CC44106566C
	for <freebsd-current@FreeBSD.org>; Mon, 28 May 2012 08:42:10 +0000 (UTC)
	(envelope-from theraven@FreeBSD.org)
Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27])
	by mx1.freebsd.org (Postfix) with ESMTP id 4A6788FC0C
	for <freebsd-current@FreeBSD.org>; Mon, 28 May 2012 08:42:10 +0000 (UTC)
Received: from [192.168.0.2] (cpc2-cmbg15-2-0-cust790.5-4.cable.virginmedia.com
	[86.26.15.23]) (authenticated bits=0)
	by theravensnest.org (8.14.5/8.14.5) with ESMTP id q4S8fxAG098028
	(version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO);
	Mon, 28 May 2012 08:42:04 GMT (envelope-from theraven@FreeBSD.org)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: David Chisnall <theraven@FreeBSD.org>
In-Reply-To: <4FC30090.4070003@gwdg.de>
Date: Mon, 28 May 2012 09:41:56 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <4D8CF7D2-CBEE-438E-A9E7-9C47A8892622@FreeBSD.org>
References: <4FC30090.4070003@gwdg.de>
To: Rainer Hurling <rhurlin@gwdg.de>
X-Mailer: Apple Mail (2.1257)
Cc: freebsd-current@FreeBSD.org
Subject: Re: Use of C99 extra long double math functions after r236148
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, 
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 28 May 2012 08:42:10 -0000

On 28 May 2012, at 05:35, Rainer Hurling wrote:

> Yesterday r236148 (Allow inclusion of libc++ <cmath> to work after =
including math.h) was comitted to head, many thanks.
>=20
> Does this mean, that extra long double functions like acoshl, expm1l =
or log1pl are now "really implemented"? As far as I understand, they had =
only been declared before?

They are still not implemented.  The <cmath> header in libc++ provides =
wrappers around these functions for C++, but if they are not declared =
then the compiler throws an error.  Now there is a linker error if they =
are used, but if they are not used then it works irrespective of whether =
you just include <cmath> or do undefined things like include <math.h> =
first.

> If this is right, are they usable on a recent CURRENT, built with =
gcc42 (system compiler), by ports which use gcc46 (not clang)? If not, =
are there any plans to implement these functions in the near future?

I think they're one of the last bits of C99 / C11 that anyone actually =
cares about (C11 unicode support being another), so they'll probably get =
done at some point, but doing them correctly is nontrivial, except on =
platforms where double and long double are the same. =20

> The use of C99 extra long double functions would be of interest for =
example for programs like math/R, especially its upcoming releases.

I would be very wary of anything that depends on long double.  The C =
spec makes no constraints on the range of float, double, or long double, =
but by convention on most platforms float is an IEEE 754 32-bit floating =
point value and double is 64-bit.  No such conventions apply to long =
doubles and I know of (widely deployed) platforms where they are 64 =
bits, 80 bits and 128 bits, respectively.  I believe on PowerPC FreeBSD =
actually gets it wrong and uses 64 bits even though the platform ABI =
spec recommends using 128 bits.  x86 uses 80-bit x87 values (although =
sizeof(long double) may be 16 because they have some padding bytes in =
memory).  If your program is tolerant of a potential variation in =
precision between 64 bits and 128 bits, then it is probably tolerant of =
just using doubles.

David=