i386/125011: precision of constants for long double

[Satoshi Kimura]

>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 at 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: