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=