On 2005-05-29 18:19:19 +0300, Michael Veksler wrote:
> If more than 50 people report it, independently, as a bug then it
> sure is a bug. You might argue whether technically it is a bug, but
> from user's perspective it is a bug (and you have over 50 duplicates
> as an evidence). As such it has to be dealt with more positively.
Concerning the extended precision, there are two problems.

First there is a bug in GCC concerning casts and assignments
(see ISO/IEC 9899: 5.1.2.3#13, 6.3.1.5#2 and 6.3.1.8#2).

But even this were fixed, many users would still complain.
That's why I think that the Linux kernel should set the CPU
in double-precision mode, like some other OS's (MS Windows,
*BSD) -- but this is off-topic here. I've written a web page
about that:

  http://www.vinc17.org/research/extended.en.html

> I also think that it is also a bug from the technical angle. As far
> as I know, there is an IEEE standard that dictates things like
> rounding. I don't have it in front of me now, but as I remember it
> refers mostly to CPU's floating point unit. So if the CPU does not
> meet the standard, GCC can say that it is a bug in the CPU.

The IEEE-754 standard allows extended precision, even though the
C type is double precision. The term used by the IEEE-754 standard
is "destination", but doesn't specify what the "destination" is.
It may be a floating-point register.

> The standpoint that it's a bug in the CPU is unproductive. It would
> help the users if GCC were trying to hide IEEE nonconformance as
> much as possible. Things such as

I agree that GCC should try to hide IEEE non-conformance (but
x86 CPUs are conforming IEEE-754 implementations, modulo some
particular bugs).

>  assert( a / b == a / b);
> should not fail according to IEEE (as far as I remember).

According to IEEE, it may fail, for various reasons. In particular
because the IEEE-754 standard does not have language bindings.

Also note that a CPU may have two floating-point units, one
conventional in extended precision and one in double precision
(e.g. SSE2), and they could be used in parallel (this was an
example by Fred J. Tydeman on the stds-754 list).

But if you do,

  double x = a / b;
  double y = a / b;
  double z = a / b;

at least two of x, y, z should be equal if the processor supports
the IEEE-754 standard, even with any extended precision internally.

> An even more surprising example can be created:
>    #include <assert.h>
>    volatile float x=3;
>    int main()
>    {
>      float a = 1/x;
>      x = a;
>      assert(a == x); // -O2 will fail on gcc-3.4.3 and gcc-4.0.0
>    }

Yes, this is the bug in GCC I was talking about (the one concerning
the assignments).

> I think that you can't deny it is a bug. Copying a variable of the
> same type should not change its value (regardless of what ==
> generally means in FP context).

Yes.

-- 
Vincent Lef�vre <[EMAIL PROTECTED]> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Reply via email to