From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 651 invoked by alias); 7 Apr 2004 17:06:48 -0000 Mailing-List: contact libc-hacker-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sources.redhat.com Received: (qmail 606 invoked from network); 7 Apr 2004 17:06:45 -0000 Received: from unknown (HELO e4.ny.us.ibm.com) (32.97.182.104) by sources.redhat.com with SMTP; 7 Apr 2004 17:06:45 -0000 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i37H6cAL829100; Wed, 7 Apr 2004 13:06:38 -0400 Received: from d27mc103.rchland.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i37H6v9D086308; Wed, 7 Apr 2004 13:06:57 -0400 In-Reply-To: <20040324160427.GM15946@sunsite.ms.mff.cuni.cz> To: Jakub Jelinek Cc: Ulrich Drepper , Glibc hackers , libc-hacker-owner@sources.redhat.com, Richard Henderson MIME-Version: 1.0 Subject: Re: [PATCH] long double IEEE double -> quad switch From: Steve Munroe Message-ID: Date: Wed, 07 Apr 2004 17:06:00 -0000 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2004-04/txt/msg00012.txt.bz2 Jakub Jelinek wrote on 03/24/2004 10:04:27 AM: > Hi! > > The following patch allows sparc32 (and easily also alpha, s390{,x}) to > switch from double == long double to IEEE quad long double without > upgrading libc.so/libm.so SONAME. > All functions which deal with long double (*printf*, *scanf*, *told*, > q[efg]cvt*, strfmon{,_l}, *l in libm (and a few math routines in libc) > had to be versioned and the installed headers > allow both -mlong-double-128 (which can now be made the default > GCC option for sparc-*-linux and other arches) and through __REDIRECTs > (or #defines for lame compilers) -mlong-double-64. > Tested on sparc32 (only 2x6 make check failures (6 failures in > test-ldouble and 6 in test-ildoubl; 4 of them is a GCC bug which optimizes > out division by floating zero from const long double array (seems to be > fixed in gcc 3.4), so division by zero exception is not raised, > one is imprecise test in libm-test.inc (recently added atan2 has > just enough digits for ldbl-96, not ldbl-128) and one is a 10 ulps failure > which can be probably added to ulps)) and x86-64. Have you made any more progress on this? We are all waiting for this to be resolved. > > Alpha long double support should be doable on top of this patch quite > easily, just a few linux/alpha/{Makefile,Implies,Versions,bits/wordsize.h} > tweaks. > > PowerPC{,64} will be far more difficult if ppc is going to use > IBM long double format as opposed to IEEE quad long double > (basically sysdeps/ieee754/ldbl-128ibm/ and sysdeps/ieee754/ldbl-64-128ibm/ > would need to be implemented, whereas the latter is trivial, the former > is a lot of work). > I have most of this code written but we are still debugging (a number of surprises in nextafter and fpclassify but we are making progress). So we are ready to start submitting code but would like to see more about your work first. You mention ldbl-128ibm/ and ldbl-64-128ibm/ what do you see as the difference? I also see an opportunity to improve the double implementations for 64-bit. Should we add dbl-64-64(sp?) where the code assumes 64-bit registers for the (long) integer bit manipulation. This should be generally useful beyond powerpc64. Steven J. Munroe Linux on Power Toolchain Architect IBM Corporation, Linux Technology Center