From owner-freebsd-standards@FreeBSD.ORG Sat Jan 10 11:40:03 2009 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BA881065672 for ; Sat, 10 Jan 2009 11:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 39CA78FC14 for ; Sat, 10 Jan 2009 11:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n0ABe2Zp058114 for ; Sat, 10 Jan 2009 11:40:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n0ABe2oD058113; Sat, 10 Jan 2009 11:40:02 GMT (envelope-from gnats) Date: Sat, 10 Jan 2009 11:40:02 GMT Message-Id: <200901101140.n0ABe2oD058113@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org From: Bruce Evans Cc: Subject: Re: standards/130067: Wrong numeric limits in system headers? X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce Evans List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2009 11:40:03 -0000 The following reply was made to PR standards/130067; it has been noted by GNATS. From: Bruce Evans To: David Schultz Cc: John Hein , imp@freebsd.org, =?iso-8859-1?Q?V=E1clav?= Haisman , freebsd-standards@freebsd.org, freebsd-gnats-submit@freebsd.org Subject: Re: standards/130067: Wrong numeric limits in system headers? Date: Sat, 10 Jan 2009 22:35:59 +1100 (EST) On Fri, 9 Jan 2009, David Schultz wrote: > On Fri, Jan 09, 2009, John Hein wrote: >> FWIW, when you compile the OP's sample code on i386 with -pedantic >> (with 6.x's base gcc 3.4.6 or 7.x's base gcc 4.2.1), you get: >> >> x.cc:11: error: floating constant exceeds range of 'long double' >> >> (the LDBL_MAX line) >> >> That seems to tip the scale more to the 'float.h is wrong' side. No, it is strictly a bug in gcc (gcc is supposed to support FreeBSD's idea of a long double, since the special support is only used by FreeBSD, but it doesn't). The FreeBSD value of LDBL_MAX doesn't exceed the range of a long double with FreeBSD's idea of a long double. However, almost any operation on FreeBSD's LDBL_MAX would overflow. E.g., (LDBL_MAX + 0) and (LDBL_MAX * 1) both overflow to give a result of Inf. There may be optimization bugs related to this -- IIRC, evaluating x+0 as x at compile time is an invalid optimization, because x+0 should differ from x iff x is -0, but evaluating x*1 as x at compile time is a valid optimization because there should be no special cases; however LDBL_MAX*1 gives a special case. > gcc doesn't do quite the right thing with long double constants in > FreeBSD, and it causes no end of trouble when writing long double > routines that are intended to work when the FPU is switched to > extended precision mode. I think it does do the right thing from its viewpoint. In its viewpoint, long doubles have only 53 bits of precision. Since it refuses to construct long doubles with the full 64 bits of precision that are possible and expected by FreeBSD, this is a valid viewpoint -- there is no way to construct a long double with more than 53 bits of precision in C without invoking undefined behaviour, so the extra bits might as well not be there. This viewpoint also avoids surprises like LDBL_MAX*1 = Inf. > Older versions of gcc would evaluate long double constant > expressions at compile time using extended precision, which was > wrong because it didn't reflect what the FPU would have done at > runtime. More recent versions of gcc were "fixed" to evaluate all > long double constants using double precision, which matches what > the FPU does by default. However, now it's not even possible to > write a program that uses long double constants, even if the > program changes the FPU precision at runtime, because gcc > truncates all the constants at compile time (and generates > spurious complaints such as the one you mention). C99 defines some > pragmas that would improve the situation, but gcc doesn't > implement them. This is true. Bruce