Subject: Re: port-i386/36770: "long double" arithmetics doesn't work on i386
To: None <port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,>
From: Matthias Drochner <M.Drochner@fz-juelich.de>
List: netbsd-bugs
Date: 08/13/2007 13:50:02
The following reply was made to PR port-i386/36770; it has been noted by GNATS.

From: Matthias Drochner <M.Drochner@fz-juelich.de>
To: gnats-bugs@NetBSD.org
Cc: port-i386-maintainer@NetBSD.org, gnats-admin@NetBSD.org,
	netbsd-bugs@NetBSD.org
Subject: Re: port-i386/36770: "long double" arithmetics doesn't work on i386
	 
Date: Mon, 13 Aug 2007 15:48:59 +0200

 M.Drochner@fz-juelich.de said:
 > gcc fails to emit instuctions which set the i387 floating point
 > control word to 64-bit rounding where "long double" data types are
 > used
 
 After some research I came to the conclusion that gcc doesn't
 intend to do so. (It might kill performance anyway.)
 It does instead live with the fact that the FPU does only
 provide IEEE "double" accuracy, even with "long double"
 variables. Since the standards (ISO C and IEEE754) do not
 require that "long double" is any better that "double", this
 is legal.
 
 > setting TARGET_96_ROUND_53_LONG_DOUBLE
 > in the gcc configuration doesn't help
 
 What this does is to dumb down compile time calculations
 on "long double" types to use 53-bit accuracy (while using
 the 80/96-bit format where data are put to .data).
 So this should be set for NetBSD/i386 (and amd64) for
 consistency between compile-time and runtime calculations,
 otherwise we might see different behaviour depending on
 eg optimization levels.
 
 > Try the program below (taken from an sqlite3 selftest).
 
 sqlite3's assumption that use of "long double" will fix
 the flaws of the conversion algorithm is not portable.
 I've filed a bug report there (#2570).
 
 This further means for NetBSD/i386:
 -Use of "long double" is just a waste of memory, and memory
  bandwidth.
 +It is almost as easy to implement expl(), logl() and all the other
  "long double" variants of math functions on i386 as it is for
  platforms where "long double" is identical to "double": just
  use wrappers which convert arguments, no need to implement
  algorithms which provide higher accuracies.
 
 best regards
 Matthias
 
 
 Forschungszentrum Juelich GmbH
 52425 Juelich
 
 Sitz der Gesellschaft: Juelich
 Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
 Vorsitzende des Aufsichtsrats: MinDirig'in Baerbel Brumme-Bothe
 Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. 
 Vorsitzender)