"Giovanni Bajo wrote on 29/05/2005 13:54:39:
> Vincent Lefevre <[EMAIL PROTECTED]> wrote:
>
> > Perhaps because GCC developers think that GCC isn't buggy when the
> > processor doesn't do the job for them? (I'm thinking of bug 323.)
>
>
> You are mistaken, we think GCC isn't buggy about 323 because the C/C++
> standards do not tell us to do better than this. If you have higher
> expectations about floating point and C/C++, you should file a bugreport
> against the C/C++ standards.
>
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.
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 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
assert( a / b == a / b);
should not fail according to IEEE (as far as I remember). Even if
it were not stated by IEEE to be wrong, GCC should consider it wrong,
at least from the rule of least surprise.
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
}
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).
> Really, we can't make everybody happy. The best we can do is to adhere
the
> international well-known ISO/ANSI standards.
>
And what about the IEEE ? What about the above example, does it adhere
to ISO/ANSI ?
This FP issue is quite subjective and everyone seems to have a different
opinion. Some people even claim that -ffast-math should be default.
There is no "right" solution here, only *a set* of useful solutions.
As such (50 duplicates means it's useful!), bug 323 should have been
dealt with years ago.
I know that before bug 323 is handled, I will not file FP bug reports,
because I'll assume that it will be probably marked as a duplicate
of 323 anyway. Luckily, I am able to avoid FP most of the time
(at the cost of uglifying and slowing down parts of my code).
I don't know how many people are like me, but I guess that I am
not alone.
Michael
