On 6/19/06, Seongbae Park <[EMAIL PROTECTED]> wrote:
On 6/19/06, Dave Korn <[EMAIL PROTECTED]> wrote:
> On 19 June 2006 00:04, Paolo Carlini wrote:
>
> > Zdenek Dvorak wrote:
> >
> >> ... I suspect there is something wrong with your
> >> code (possibly invoking some undefined behavior, using uninitialized
> >> variable, sensitivity to rounding errors, or something like that).
> >>
> >>
> > A data point apparently in favor of this suspect is that the "problem"
> > goes away if double is replaced everywhere with long double...
> >
> > Paolo.
>
> Is this another case of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
> then?
>
> cheers,
> DaveK
It is the same case. Fundamentally, this is not fixable by the compiler alone
without significant performance penalty.
There are very few implementations [1] that are completely IEEE754 conformant
and making them to be so is often prohibitively expensive,
hence it's not done or at least not by default.
So whenever you're programming a floating-point code,
you need to be aware of the caveats of a particular implementation.
Beside x86's well-known extended precision issue,
other processors have things like flush-denormal-inputs-to-zero,
or multiply-add instruction that is not equivalent to separate muitply and add.
I think it's not fair to expect gcc to somehow "fix" this whole mess alone.
Of course, whenever there's a reasonable workaround for a particular issue,
I'm sure gcc developers will try to accomodate it,
but IMHO this one (bug 323) isn't such.
[1] by implementation, I mean the combination of:
microprocessor, OS, compiler and runtime libraries..
Using -mfpmath=sse -msse2 is a workaround if you have a processor that supports
SSE2 instructions. As opposed to -ffloat-store, it works reliably and
with no performance
impact.
Richard.
