From owner-cvs-all@FreeBSD.ORG Tue Apr 1 22:21:50 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB3A837B401; Tue, 1 Apr 2003 22:21:50 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04B7043FA3; Tue, 1 Apr 2003 22:21:49 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id QAA19346; Wed, 2 Apr 2003 16:21:31 +1000 Date: Wed, 2 Apr 2003 16:21:30 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Peter Jeremy In-Reply-To: <20030401200457.GA30284@cirb503493.alcatel.com.au> Message-ID: <20030402154250.X25489@gamplex.bde.org> References: <200303272038.h2RKcM7L096560@repoman.freebsd.org> <20030330175646.281097ad.Alexander@Leidinger.net> <20030331082023.GE11307@cirb503493.alcatel.com.au> <20030401172440.701aaafd.Alexander@Leidinger.net> <20030401200457.GA30284@cirb503493.alcatel.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Alexander Leidinger cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org cc: cvs-src@FreeBSD.org Subject: Re: cvs commit: src/sys/ia64/include float.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2003 06:21:51 -0000 On Wed, 2 Apr 2003, Peter Jeremy wrote: > On Tue, Apr 01, 2003 at 05:24:40PM +0200, Alexander Leidinger wrote: > >On Mon, 31 Mar 2003 18:20:23 +1000 > >Peter Jeremy wrote: > > > >> It's not clear exactly what this program is intended to test. > > > >We noticed that icc does use other values for LDBL_MIN than we do, and > >instead of just thinking that Intel does it right I wanted to verify it. This might be caused by icc actually understanding the target's default precision for long doubles (FreeBSD changes the hardware default of 64-bit to 53-bit for technical reasons). > >So I started with tests for float and double. > > The actual digit string forming the constants is not especially > important - as long as the compiler interprets that string as the > correct FP value. There are a number of test programs intended to I think compilers are required to diagnose overflow. gcc -Wmumble reports the overflow for the current i386 LDBL_MAX if you increase the last digit in it by 1 (which corresponds to rounding the infinitely precise value up instead of down). However, since gcc doesn't understand the target's precision, its overflow threshold is wrong, so it permits a value of LDBL_MAX (the one in the i386 float.h) that causes overflow when used: %%% $ cat z.c #include #include long double x, y, zero; static void print_ld(long double *dp) { unsigned char *cp; int i; for (cp = (unsigned char *)(void *)dp, i = 0; i < sizeof(*dp); i++) printf("%02x", cp[i]); printf("\n"); } int main(void) { x = LDBL_MAX; y = LDBL_MAX + zero; /* This overflows. */ print_ld(&x); print_ld(&y); } $ cc -o z z.c $ ./z fffffffffffffffffe7f0000 0000000000000080ff7f0000 %%% The first value printed is the 64-bit-precision LDBL_MAX (with 2 bytes of padding). The second value is +Inf. Overflow can also be seen by checking the overflow bit using gdb or fpgetsticky(). Note that although LDBL_MAX is defined as the maximum representable long double value, and the 64-bit-precision LDBL_MAX is representable, it must be considered as an unsupported magic value since there is no way to produce it without invoking undefined behaviour. Undefined behaviour includes compiler/library bugs like generating the wrong bits for LBDL max and not trimming extra precision given by hardware math functions. Script to compute LDBL_MAX to 19 digits with 64 and 63-bit precisions: %%% #!/bin/sh bc < verify correct FP behaviour by the CPU and compiler floating around on > the net - look at NETLIB or Prof W. Kahan's web site. (I don't have > the URL's immediately to hand). ucbtest is good but is too old to cover much of C99. I haven't found anything anywhere near as good and up to date. Bruce