On Sun, Jan 18, 2004 at 07:24:01PM +0100, GSR - FR <famrom@xxxxxxxxxxxxxxxxxxxx> wrote:
> -O2
> -O2 -ffloat-store
> -O2 -fno-strict-aliasing
> -O2 -ffloat-store -fno-strict-aliasing
Just to clarify, -fno-strict-aliasing works around bugs in existing code,
while -ffloat-store ensures that rounding is done at every step necessary
to get exact ieee 754 semantics.
> declared const, and still the only way is -O0.
There are not too many options here:
- this is a bug in the code
- this is the bug in gcc
- this is a bug in the algorithm
If it's not a gcc bug (which is possible but not necessarily probable),
thens ee below for some ideas on what this might have caused.
> Getting different values cos the compiler decides you can go with
> different data size depending if it keeps all or not in CPU is not
It's still legal, if you define "legal" as following the standards.
It's also not much of a problem usually since you just get extra
precision and less rounding, which only a few algorithms have a problem
with, and these usually fit into the "designed for specific fp
implementations" class.
It's also, fortunately, an x86-only-problem, as it's only a big speed
hit on x86.
As for workarounds for this, you can either use -ffloat-store or setfpucw,
in which case you lose the ability to do double precision.
However, since -ffloat-store doesn't fix the problems, it could be that
the compiler does some unexpected (but legal) transformations.
For example, in C, the compiler is legally allowed to transform:
r = (1 - a) * b;
into:
r = a - a * b;
Which might not be the same value. If that is a problem, you either have
to use more sequence points (i.e. multiple statements), or you need to use
fortran, where these kinds of transformations are not allowed :)
Unless you are certain that this isn't caused by a real gcc bug (usually,
compiling with different major versions of the compiler is a good
indication in favour or against it, depending on the outcome, as the same
bug in gcc-2.95 and gcc-3.x is a rare thing), you might want to chekc your
code for constructs where the limited precision of floating point values
makes a difference.
This is just a hint, this does not mean that there is a bug there, but
floating point values, as you of course know, have their problems that
real numbers don't have.
(BTW, gdoubles and doubles etc. are not different, so there is no need to
bother with testing one set against the other).
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@xxxxxxxx |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
