Andreas Lange wrote:

Huh, long shot: maybe cbrt is a macro on that platform?

Can you find where and how is cbrt declared and defined on your system
headers?

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Andreas Lange <anlan (AT) ida (DOT) liu.se> writes:
Presumably the problem is that the cc call lacks "-lm".

Checking back against 8.1, I see that 8.1's configure has

AC_CHECK_LIB(m, main)

where 8.2 tries to do

AC_SEARCH_LIBS(pow, m)

I suppose there is something funny about pow() on your platform
causing that probe to fail. What does config.log have at the
"checking for library containing pow" step?

My inclination is to undo this particular change, and thus to
unconditionally include libm whenever it can be found. I can't imagine
there are any platforms where we don't need libm, given the fairly
extensive demands of utils/adt/float.c; furthermore, given the frequency
with with some of these functions are macro-ized or otherwise diddled
with, relying on an AC_SEARCH_LIBS test seems risky.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Andreas Lange <anlan (AT) ida (DOT) liu.se> writes:
Interesting. Could pow() actually be in libc on your machine?
The other possible explanation is that it's a macro, but the
AC_SEARCH_LIBS code seems to go out of its way to fail if that's
the case.

Anyway this illustrates the dilemma we face in trying to do a real probe
for libm: the common functions (pow) are likely to be macro-ized, while
uncommon ones might not be there at all (cbrt). Anyone have a better
idea than reverting to the unconditional AC_CHECK_LIB(m, main) call?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Tom Lane 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

Zdenek

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Zdenek Kotala wrote:

I noticed that the Sun FAQ now has changed from hinting that -fast might
be very beneficial to recomend staying away from it.

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.

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

I do understand the recomendation to avoid -fast, the tweaking is both
compiler version and hardware architecture dependant. Doing a make check
is always advisable.

regards,
Andreas

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Andreas Lange wrote:
Yes, because there was some problem with regression test.

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.


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

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq