From owner-freebsd-i386@FreeBSD.ORG Thu Jun 26 15:50:01 2008 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C6EF106567B for ; Thu, 26 Jun 2008 15:50:01 +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 71B178FC24 for ; Thu, 26 Jun 2008 15:50:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m5QFo17s057545 for ; Thu, 26 Jun 2008 15:50:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m5QFo1EQ057544; Thu, 26 Jun 2008 15:50:01 GMT (envelope-from gnats) Resent-Date: Thu, 26 Jun 2008 15:50:01 GMT Resent-Message-Id: <200806261550.m5QFo1EQ057544@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-i386@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Satoshi Kimura , com@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 490601065673 for ; Thu, 26 Jun 2008 15:49:18 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 305888FC16 for ; Thu, 26 Jun 2008 15:49:18 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.2/8.14.2) with ESMTP id m5QFnIMC058518 for ; Thu, 26 Jun 2008 15:49:18 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.2/8.14.1/Submit) id m5QFnIcM058517; Thu, 26 Jun 2008 15:49:18 GMT (envelope-from nobody) Message-Id: <200806261549.m5QFnIcM058517@www.freebsd.org> Date: Thu, 26 Jun 2008 15:49:18 GMT From: Satoshi Kimura , com@FreeBSD.org To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: i386/125011: precision of constants for long double X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2008 15:50:01 -0000 >Number: 125011 >Category: i386 >Synopsis: precision of constants for long double >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-i386 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Jun 26 15:50:01 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Satoshi Kimura >Release: 6.2 >Organization: private use >Environment: FreeBSD 6.2-RELEASE #0: Fri Jan 12 11:05:30 UTC 2007 root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP >Description: 1. problem On rather new environment of FreeBSD (ex. 6.2, 7.0), standard gcc (i.e /usr/bin/gcc) makes strange code concerning "long double". The precision of all constants of "long double" are rounded to that of "double". In addition, if we add -m128bit-long-double option to gcc, this behavior did not appear. Historically, precision of constants of "long double" were as follows: FreeBSD gcc 96bit 128bit 2.2.6 2.2.2.1 NR - 3.4 2.7.2.3 NR - 4.9 2.95.4 NR - 3.0.4 NR NR 5.3 3.2.3 NR NR 3.3.5 R R <- (1) 3.4.2 NR NR <- (2) 6.2 3.4.6 R NR <- (3) 6.3 3.4.6 R NR 4.2.4 R NR 7.0 4.2.1 R NR Meanings of this table are as follows: FreeBSD : version of FreeBSD (RELEASE) gcc : version of gcc 96bit : 96bit long double 128bit : 128bit long double (compiled with -m128bit-long-double option) NR : not rounded, i.e keep precision of long double. R : rounded to precision of double. 2. question On above table, modification from (2) to (3) was made by discussions at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17778 The reason of this midification was as follows: > On FreeBSD/i386, FPU precision is set to 53 bits to avoid problems with extra > precision and double rounding for doubles. gcc understands this and evaluates > FP constants in 53-bit precision, even for long doubles. He compared (1) and (2) on above table, and concluded to resume the condition of (1). But, I cannot find the reason that 128bit "long double" did not modified. ((3) on above table.) The most impotant question is that his understanding above is correct or not ? If false, this modification is to be avoided. Or, if true, 128bit "long double" is also to be modified. >How-To-Repeat: 1. run sample code on http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17778 or 2. compile this source s.c int main(void) { double c; long double lc; c = 3.14159265358979323846; lc = 3.14159265358979323846L; } % gcc -m96bit-long-double -S s.c -o s1.s % gcc -m128bit-long-double -S s.c -o s2.s and compare two assembler source, so wo can see the difference as follows: 24c24 < movl $560513024, %eax --- > movl $560513589, %eax >Fix: >Release-Note: >Audit-Trail: >Unformatted: