i386/85080: output of long double subnormals (with printf) is wrong by a factor 2

[Vincent Lefevre]

>Number:         85080
>Category:       i386
>Synopsis:       output of long double subnormals (with printf) is wrong by a factor 2
>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 Aug 18 10:10:24 GMT 2005
>Closed-Date:
>Last-Modified:
>Originator:     Vincent Lefevre
>Release:        FreeBSD 5.4-RELEASE i386
>Organization:
LORIA / INRIA Lorraine
>Environment:
System: FreeBSD spe152.testdrive.hp.com 5.4-RELEASE FreeBSD 5.4-RELEASE #0: Sun May 8 10:21:06 UTC 2005 root at harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386


	
>Description:
When I print the value of a long double with printf ("%Le", x)
and the value is a subnormal, I get the value divided by 2.
>How-To-Repeat:
Consider the following code:

#include <stdio.h>
#include <float.h>

int main (void)
{
  long double x, y;
  int i;

  for (x = LDBL_MIN; x != 0; x /= 2.0)
    {
      y = x;
      for (i = 0; i < 10; i++)
        printf ("%c%02X", i ? ' ' : '[', ((unsigned char *) &y)[i]);
      printf ("]  %.30Le\n", x);
    }

  return 0;
}

I get:
[00 00 00 00 00 00 00 80 01 00]  3.362103143112093506262677817322e-4932
[00 00 00 00 00 00 00 40 00 00]  8.405257857780233765656694543304e-4933
[00 00 00 00 00 00 00 20 00 00]  4.202628928890116882828347271652e-4933
[00 00 00 00 00 00 00 10 00 00]  2.101314464445058441414173635826e-4933

The first value is the smallest normalized long double (LDBL_MIN).
The decimal output is correct. The decimal output of the following
ones is twice lower the correct value.

>Fix:

I haven't looked at the source, but it seems that the programmer
forgot that there is not implicit bit for the extended precision,
so that the exponent field is decreased by 1 *and* the mantissa is
divided by 2 when going from LDBL_MIN to LDBL_MIN/2 (see above),
hence the factor 2. The fix should be simple: add (or subtract) 1
to the bias.
	


>Release-Note:
>Audit-Trail:
>Unformatted: