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: M.Drochner@fz-juelich.de
Cc: gnats-bugs@NetBSD.org, 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: Thu, 16 Aug 2007 23:06:47 +0200

 This is a multipart MIME message.
 
 --==_Exmh_24243496863520
 Content-Type: text/plain; charset=us-ascii
 
 
 Some more findings:
 
 M.Drochner@fz-juelich.de said:
 > -Use of "long double" is just a waste of memory, and memory
 >  bandwidth. 
 
 Almost, but not quite: while the exponent is effectively
 limited to 53 bits, the mantissa has still 15 bits which
 is 4 more than double. So there is no gain in accuracy
 but a little more dynamic range.
 
 > +It is almost as easy to implement expl(), logl() and all the other
 >  "long double" variants
 
 So, in the light of this, it is not _that_ easy because the numeric
 ranges are different. The algorithms can still be reused I think.
 
 Another fact is that the LDBL_* macros of <float.h> don't
 reflect reality. Eg LDBL_MAX is already infinity. The long double
 support in gdtoa also suffers from this.
 See the appended program. On an i386/current box, it gives:
 1.189731495357231765021264e+4932
 inf
 1.189731495357231765021264e+4932
 inf
 1.189731495357231599977347e+4932
 1.189731495357231632999029e+4932
 1.189731495357231599977347e+4932
 1.189731495357231632999029e+4932
 
 which shows that both the compiler and gdtoa don't know about the
 53-bit mantissa -- LDBL_MAX gets converted to a number which will
 cause an overflow, and the other number has some excess bits in
 the mantissa which will get lost if touched by the FPU later.
 
 If I set the TARGET_96_ROUND_53_LONG_DOUBLE as said in my previous mail,
 it gives:
 inf
 inf
 1.189731495357231765021264e+4932
 inf
 1.189731495357231632999029e+4932
 1.189731495357231632999029e+4932
 1.189731495357231599977347e+4932
 1.189731495357231632999029e+4932
 
 which shows that the constants generated at compile time are
 consistent with reality now, but gdtoa still assumes mantissa
 bits not usable for further calculations.
 
 Adapting the LDBL_ constants to the 53-bit mantissa should fix
 this, but some review is needed because at some points just
 mantissa lengths are compared to decide whether a "long double"
 is different from a "double".
 
 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)
 -----------------------------------------------------------------------------------------
 -----------------------------------------------------------------------------------------
 
 --==_Exmh_24243496863520
 Content-Type: text/plain ; name="stest.c"; charset=us-ascii
 Content-Description: stest.c
 Content-Disposition: attachment; filename="stest.c"
 
 #include <float.h>
 #include <stdio.h>
 #include <stdlib.h>
 
 #define TRUE_LDBL_MAX 1.1897314953572316E+4932L
 long double null;
 
 void
 pr(long double d)
 {
 
 	printf("%.25Lg\n", d);
 	d += null;
 	printf("%.25Lg\n", d);
 }
 
 #define pr2(x) pr(x);pr(strtold(#x, 0))
 #define pr3(x) pr2(x)
 
 int
 main()
 {
 
 	pr3(LDBL_MAX);
 	pr3(TRUE_LDBL_MAX);
 
 	return 0;
 }
 
 --==_Exmh_24243496863520--