[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#233673: gcc-3.3: Description of -ffloat-store in gcc man page is incorrect



On 2004-03-24 08:03:40 +0100, Matthias Klose wrote:
> Vincent Lefevre writes:
> > The second paragraph is incorrect. The IEEE754 standard has nothing
> > to do with that since it allows extended precision for intermediate
> > computations. This option just makes gcc more ISO C compliant, since
> > the ISO C forbids excess precision after an explicit conversion to
> > double (cast or affectation).
> 
> gcc-3.4 reads:
> 
>   -ffloat-store
>      Do not store floating point variables in registers, and inhibit
>      other options that might change whether a floating point value is
>      taken from a register or memory.
> 
>      This option prevents undesirable excess precision on machines such
>      as the 68000 where the floating registers (of the 68881) keep more
>      precision than a "double" is supposed to have.  Similarly for the
>      x86 architecture.  For most programs, the excess precision does
>      only good, but a few programs rely on the precise definition of
>      IEEE floating point.  Use -ffloat-store for such programs, after
>      modifying them to store all pertinent intermediate computations
>      into variables.

"This option prevents undesirable excess precision"

This isn't quite correct, since internal computations will still be
performed in extended precision if the processor is configured to do
so (unfortunately, this is the case by default under Linux, but not
under FreeBSD, NetBSD and AFAIK, MS Windows). Only the stored values
will be in double precision. But this is not equivalent to compute
in double precision directly due to the effect of "double rounding"
(a first rounding due to the computation in extended precision and a
second one due to the "extended -> double" conversion). See the test
at the end of this message.

"For most programs, the excess precision does only good"

This may be dangerous and not portable though. Users should not rely
on that when writing/testing programs. I think that it is better to
just say that it is harmless.

"but a few programs rely on the precise definition of IEEE floating
point"

As I said, this option has nothing to do with what IEEE requires.
Whether it is used or not, this will be conform to the IEEE-754
standard (which allows extended precision for intermediate
computations -- but doesn't say what intermediate computations are
exactly, this is left to the language specifications). This option
will just fix gcc's default behavior: without this option, gcc will
fail to convert extended precision values to double after a cast or
an assignment (unless this has been fixed in the latest versions).
The latest public draft of the C99 standard (WG14/N869) says:

In 5.1.2.3:

       [#13]  EXAMPLE 4 Implementations  employing  wide  registers
       have to take care to honor  appropriate  semantics.   Values
       are  independent  of  whether  they  are  represented  in  a
       register or in memory.  For example, an implicit spilling of
       a  register  is  not permitted to alter the value.  Also, an
       explicit  store  and  load  is  required  to  round  to  the
       precision  of  the  storage  type.  In particular, casts and
       assignments  are  required  to   perform   their   specified
       conversion.  For the fragment

               double d1, d2;
               float f;
               d1 = f = expression;
               d2 = (float) expressions;

       the  values  assigned to d1 and d2 are required to have been
       converted to float.

In 6.3.1.5:

       [#2]  When  a  double  is demoted to float, a long double is |
       demoted to double or float, or a value being represented  in |
       greater  precision  and  range than required by its semantic |
       type (see 6.3.1.8) is explicitly converted to  its  semantic |
       type,  if  the value being converted is outside the range of
       values that can be represented, the behavior  is  undefined.
       If  the value being converted is in the range of values that
       can be represented but cannot be  represented  exactly,  the |
       result  is  either  the  nearest  higher  or  nearest  lower |
       representable value,  chosen  in  an  implementation-defined
       manner.

In 6.3.1.8:

       [#2]  The  values of floating operands and of the results of
       floating expressions may be represented in greater precision
       and  range than that required by the type; the types are not
       changed thereby.45)

       45)The cast and assignment operators are still  required  to
          perform  their  specified  conversions  as  described  in
          6.3.1.4 and 6.3.1.5.

------------------------------------------------------------------

You can see all these differences with

  http://www.vinc17.org/software/tst-ieee754.c

(I've just updated it to add the assignment test, which is in fact
a test concerning the C language, not the IEEE-754 standard).

1) On Linux/x86 without -ffloat-store:

--------
__STDC_IEC_559__ defined:
The implementation shall conform to the IEEE-754 standard.
FLT_EVAL_METHOD is 2 (see ISO/IEC 9899, 5.2.4.2.2#7).
The IEEE-754 result is 9007199254740994 with double precision.
The IEEE-754 result is 9007199254740996 with extended precision.
The obtained result is 9007199254740996.

The implementation doesn't seem to convert values to the target type after
an assignment (see ISO/IEC 9899: 5.1.2.3#13, 6.3.1.5#2 and 6.3.1.8#2).
--------

2) On Linux/x86 with -ffloat-store:

--------
__STDC_IEC_559__ defined:
The implementation shall conform to the IEEE-754 standard.
FLT_EVAL_METHOD is 2 (see ISO/IEC 9899, 5.2.4.2.2#7).
The IEEE-754 result is 9007199254740994 with double precision.
The IEEE-754 result is 9007199254740996 with extended precision.
The obtained result is 9007199254740996.
--------

3) On Linux/ppc:

--------
__STDC_IEC_559__ defined:
The implementation shall conform to the IEEE-754 standard.
FLT_EVAL_METHOD is 0 (see ISO/IEC 9899, 5.2.4.2.2#7).
The IEEE-754 result is 9007199254740994 with double precision.
The IEEE-754 result is 9007199254740996 with extended precision.
The obtained result is 9007199254740994.
--------

(1) shows the gcc bug concerning assignments/casts and (2) shows
that using -ffloat-store fixes it. But in both cases, the result
in the first test is 9007199254740996, i.e. internal computations
are performed in extended precision whether -ffloat-store is used
or not. (3) shows what one gets with double-precision internal
computations.

Note: tst-ieee754.c contains other tests; I haven't written the
results here as they are off-topic.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA



Reply to: