Tom Lane writes:
> Sean Chittenden <[EMAIL PROTECTED]> writes:
> > Is there a place where -fno-fast-math
> > could be used as a CC option if the CC is gcc?
>
> configure is what I had in mind ;-). I can't think of any part of the
> code where we'd really want this sort of optimization enabled.
> > After looking through gcc, using -O and -ffast-math will create broken
> > code, but -O2 -ffast-math _should_ be okay.
>
> At least in the gcc shipped with Red Hat 7.2, it doesn't seem to matter:
> you get the wrong answer regardless of -O level. Here's the test case
> I used:
>
> [tgl@rh1
Sean Chittenden <[EMAIL PROTECTED]> writes:
> Is there a place where -fno-fast-math
> could be used as a CC option if the CC is gcc?
configure is what I had in mind ;-). I can't think of any part of the
code where we'd really want this sort of optimization enabled.
> After looking through gcc,
> > Out of curiosity: why does -ffast-math break the datetime rounding code?
What code bits is this for? Is there a place where -fno-fast-math
could be used as a CC option if the CC is gcc? After looking through
gcc, using -O and -ffast-math will create broken code, but -O2
-ffast-math _should_
Thomas Lockhart wrote:
> ...
> > > > Hard to imagine why anyone would want such an optimization. How much
> > > > faster could it possibly be?
> > > Back in ye bad olde days, there was probably an order-of-magnitude
> > > difference between the speed of a float multiply and that of a float
> > >
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> with -ffast-math gcc will "improve" it to
> >>
> >> int hour = time * 0.000278;
>
> > Hard to imagine why anyone would want such an optimization. How much
> > faster could it possibly be?
>
> Back
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> with -ffast-math gcc will "improve" it to
>>
>> int hour = time * 0.000278;
> Hard to imagine why anyone would want such an optimization. How much
> faster could it possibly be?
Back in ye bad olde days, there was proba
Tom Lane wrote:
> Ron Johnson <[EMAIL PROTECTED]> writes:
> > Out of curiosity: why does -ffast-math break the datetime rounding code?
>
> We dug into this last night, and it turns out that the culprit is code
> like
>
> int hour = time / 3600;
>
> where time is a double. This yields an
Ron Johnson <[EMAIL PROTECTED]> writes:
> Out of curiosity: why does -ffast-math break the datetime rounding code?
We dug into this last night, and it turns out that the culprit is code
like
int hour = time / 3600;
where time is a double. This yields an exact result when done
correctly
I said:
> I had success with this test:
BTW, some digging in the assembly code shows that the actual problem is
this: instead of emitting "x / 3600.0", with -ffast-math the compiler
emits the equivalent of "x * (double) (1.0 / 3600.0)". It's the
last-bit inaccuracy of the latter constant that's
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> If the test doesn't use any library function's run-time behavior, you can
> usually do something like
> main() {
> int a[(2.0+2.0==4.0)?1:-1]
> }
> This will fail to compile if the floating-point arithmetic is broken.
However, unless gcc itself is
11 matches
Mail list logo
