Andreas Lange wrote:
> Zdenek Kotala wrote:
>
>> Main problem is -fast switch. It modifies behavior of floating point
>> operation (it is reason why It is not good option for postgres) and
>> use another floating point libraries and some function are inlined. It
>> is reason why pow test passed with -fast switch without -lm switch.
>>
>> Detail description of -fast you can found on
>> http://docs.sun.com/source/819-3688/cc_ops.app.html
>>
>
> I noticed that the Sun FAQ now has changed from hinting that -fast might
> be very beneficial to recomend staying away from it.
Yes, because there was some problem with regression test.
> Using -fast is an old habit, has been building with it for years. I've
> seen that the testsuite breaks (in date/time) with only -fast, but it
> seems the only option one has to disable to normalize floating point
> enough is -fns. I hope passing the testsuite really means that fp math
> behaves correctly. If I'm wrong about that, I'll have to change our
> build routine.
I little bit played with compiler switches and only -xO5 had significant
deal for postgres. But I only tested it with pgbench.
Very important thing is that backend sends floating point number in
binary form. It means that you must compile also client library and
client application with -fast switch. If you don't do this, the result
should be nonsense.
> Beeing lazy, it is a good bit easier to go with -fast and turn of the
> problematic optimization with:
> -fast -fns=no
> than expanding the -fast macro and having to add all parameters:
> -dalign -nofstore -fsimple=2 -fsingle -xalias_level=basic -native
> -xdepend -xlibmil -xlibmopt -xO5 -xregs=frameptr
Parameters -fsimple=2 -xlibmopt -xlibmil also break IEEE floating point
arithmetic and also break errno behavior (does not report errno). If you
look in adt/float.c source code, you can see comment from Tom about
problems with errno on Linux many years ago. This should happen also
with -xlibmil and -xlibmopt switch.
My suggestion is do not use -fast anyway. Let me know if I'm not correct.
Zdenek
