------- Comment #117 from pepalogik at seznam dot cz 2008-06-24 20:12 -------
(In reply to comment #116)
> > Yes, but this requires quite a complicated workaround (solution (4) in my
> > comment #109).
>
> The problem is on the compiler side, which could store every result of a cast
> or an assignment to memory (this is inefficient, but that's what you get with
> the x87, and the ISO C language could be blamed too for *requiring* something
> like that instead of being more flexible).
>
> > So you could say that the IEEE754 double precision type is available even on
> > a processor without any FPU because this can be emulated using integers.
>
> Yes, but a conforming implementation would be the processor + a library, not
> just the processor with its instruction set.
>
> > Moreover, if we assess things pedantically, the workaround (4) still doesn't
> > fully obey the IEEE single/double precision type(s), because there remains the
> > problem of double rounding of denormals.
>
> As I said, in this particular case (underflow/overflow), double rounding is
> allowed by the IEEE standard. It may not be allowed by some languages (e.g.
> XPath, and Java in some mode) for good or bad reasons, but this is another
> problem.

OK, thanks for explanation. I think now it's clear.

> > I quote, too:
> > "Applies To
> > Microsoft® Visual C++®"
>
> Now I assume that it follows the MS-Windows API (though nothing is certain with
> Microsoft). And the other compilers under MS-Windows could (or should) do the
> same thing.

By a lucky hit, I have found this in the GCC documentation:
"
-mpc32
-mpc64
-mpc80
Set 80387 floating-point precision to 32, 64 or 80 bits. When '-mpc32' is
specified,
the significands of results of floating-point operations are rounded to 24
bits (single precision); '-mpc64' rounds the the significands of results of
floatingpoint
operations to 53 bits (double precision) and '-mpc80' rounds the significands
of results of floating-point operations to 64 bits (extended double precision),
which is the default. When this option is used, floating-point operations
in higher precisions are not available to the programmer without setting the
FPU control word explicitly.
[...]"

So GCC sets extended precision by default. And it's easy to change it.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

------- Comment #118 from vincent at vinc17 dot org 2008-06-24 20:45 -------
(In reply to comment #117)
> By a lucky hit, I have found this in the GCC documentation:
> "
> -mpc32
> -mpc64
> -mpc80

OK, this is new in gcc 4.3. I haven't tried, but if gcc just changes the
precision without changing the values of <float.h> macros to make them correct,
this is just a workaround (better than nothing, though). Also, this is a
problem for library code if it requires to have double precision instead of
extended precision, as these options won't probably be taken into account at
that point. (Unfortunately it's probably too late to have a clean ABI.)


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

------- Comment #119 from mbrudka at filbico dot pl 2008-07-17 10:45 -------
Another example related with fp on x87?

EXPECTED RESULT:
0 (with EPS accuracy)
0 (with EPS accuracy)
0 (with EPS accuracy)
0 (with EPS accuracy)

REAL RESULT:
5.313991e+33
5.313991e+33
0.000000e+00
0.000000e+00

CODE
#include <stdio.h>
int main( void )
{
/* register */ double d1 = 1e50;
/* register */ double d2 = -2.7438011834107752e+51;
/* register */ double s = 0.036445789368634796;
/* register */ double d3 = -d1/s;
/* register */ double d4 = s*d2;
/* register */ double d5 = s*d3;
printf( "%e
", d1 + s*d2);
printf( "%e
", d1 + s*d3);
printf( "%e
", d1 + d4);
printf( "%e
", d1 + d5);
return 0;
}


--

mbrudka at filbico dot pl changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |mbrudka at filbico dot pl


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

------- Comment #120 from vincent at vinc17 dot org 2008-07-17 12:41 -------
(In reply to comment #119)
> REAL RESULT:
> 5.313991e+33
> 5.313991e+33
> 0.000000e+00
> 0.000000e+00

Only without optimizations. But since the ISO C standard allows expressions to
be evaluated in a higher precision, there's no bug here (unless you show a
contradiction with the value of FLT_EVAL_METHOD, but the FP_CONTRACT pragma
should also be set to OFF -- though this currently has no effect on gcc).


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

------- Comment #121 from mbrudka at filbico dot pl 2008-07-17 12:51 -------
Thank you Vincent. I fact after commenting I realized that this is a plain
numerical error on the last digit of double in multiplication. I think that my
comment was rather irrelevant and I am the more ashamed the more I cannot
remove it from bugzilla


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org