SEO

ARM platform fails the "point" test see below.


parallel group (13 tests): text name char boolean varchar oid int8 int2 float4 int4 float8 bit numeric
boolean ... ok
char ... ok
name ... ok
varchar ... ok
text ... ok
int2 ... ok
int4 ... ok
int8 ... ok
oid ... ok
float4 ... ok
float8 ... ok
bit ... ok
numeric ... ok
test strings ... ok
test numerology ... ok
parallel group (20 tests): lseg point box path circle polygon time timetz comments reltime interval tinterval abstime
inet date timestamp timestamptz type_sanity oidjoins opr_sanity
point ... FAILED
lseg ... ok
box ... ok
path ... ok
polygon ... ok
circle ... ok
date ... ok
time ... ok
timetz ... ok
timestamp ... ok
timestamptz ... ok
interval ... ok
abstime ... ok
reltime ... ok
tinterval ... ok
inet ... ok
comments ... ok
oidjoins ... ok
type_sanity ... ok
opr_sanity ... ok
test geometry ... ok
test horology ... ok
test insert ... ok
test create_function_1 ... ok
test create_type ... ok
test create_table ... ok
test create_function_2 ... ok
test copy ... ok
parallel group (7 tests): create_aggregate create_operator triggers vacuum constraints inherit create_misc
constraints ... ok
triggers ... ok
create_misc ... ok
create_aggregate ... ok
create_operator ... ok
inherit ... ok
vacuum ... ok
parallel group (2 tests): create_view create_index
create_index ... ok
create_view ... ok
test sanity_check ... ok
test errors ... ok
test select ... ok
parallel group (18 tests): select_distinct_on select_into select_having update select_distinct case select_implicit
union namespace random aggregates hash_index arrays transactions btree_index portals join subselect
select_into ... ok
select_distinct ... ok
select_distinct_on ... ok
select_implicit ... ok
select_having ... ok
subselect ... ok
union ... ok
case ... ok
join ... ok
aggregates ... ok
transactions ... ok
random ... ok
portals ... ok
arrays ... ok
btree_index ... ok
hash_index ... ok
update ... ok
namespace ... ok
test privileges ... ok
test misc ... ok
parallel group (5 tests): portals_p2 cluster rules foreign_key select_views
select_views ... ok
portals_p2 ... ok
rules ... ok
foreign_key ... ok
cluster ... ok
parallel group (14 tests): truncate sequence limit temp copy2 prepare polymorphism conversion domain rowtypes
rangefuncs without_oid plpgsql alter_table
limit ... ok
plpgsql ... ok
copy2 ... ok
temp ... ok
domain ... ok
rangefuncs ... ok
prepare ... ok
without_oid ... ok
conversion ... ok
truncate ... ok
alter_table ... ok
sequence ... ok
polymorphism ... ok
rowtypes ... ok
test stats ... ok
test tablespace ... ok
*** ./expected/point.out Tue Jan 4 10:55:16 2005
--- ./results/point.out Tue Jan 4 12:40:50 2005
***************
*** 101,107 ****
| (-3,4) | 5
| (-10,0) | 10
| (-5,-12) | 13
! | (10,10) | 14.142135623731
| (5.1,34.5) | 34.8749193547455
(6 rows)

--- 101,107 ----
| (-3,4) | 5
| (-10,0) | 10
| (-5,-12) | 13
! | (10,10) | 14.1421356237309
| (5.1,34.5) | 34.8749193547455
(6 rows)

***************
*** 127,134 ****
| (-5,-12) | (-10,0) | 13
| (-5,-12) | (0,0) | 13
| (0,0) | (-5,-12) | 13
! | (0,0) | (10,10) | 14.142135623731
! | (10,10) | (0,0) | 14.142135623731
| (-3,4) | (10,10) | 14.3178210632764
| (10,10) | (-3,4) | 14.3178210632764
| (-5,-12) | (-3,4) | 16.1245154965971
--- 127,134 ----
| (-5,-12) | (-10,0) | 13
| (-5,-12) | (0,0) | 13
| (0,0) | (-5,-12) | 13
! | (0,0) | (10,10) | 14.1421356237309
! | (10,10) | (0,0) | 14.1421356237309
| (-3,4) | (10,10) | 14.3178210632764
| (10,10) | (-3,4) | 14.3178210632764
| (-5,-12) | (-3,4) | 16.1245154965971
***************
*** 198,204 ****
| (-10,0) | (0,0) | 10
| (-10,0) | (-5,-12) | 13
| (-5,-12) | (0,0) | 13
! | (0,0) | (10,10) | 14.142135623731
| (-3,4) | (10,10) | 14.3178210632764
| (-5,-12) | (-3,4) | 16.1245154965971
| (-10,0) | (10,10) | 22.3606797749979
--- 198,204 ----
| (-10,0) | (0,0) | 10
| (-10,0) | (-5,-12) | 13
| (-5,-12) | (0,0) | 13
! | (0,0) | (10,10) | 14.1421356237309
| (-3,4) | (10,10) | 14.3178210632764
| (-5,-12) | (-3,4) | 16.1245154965971
| (-10,0) | (10,10) | 22.3606797749979

================================================== ====================

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

Am Dienstag, 4. Januar 2005 19:03 schrieb Jim Buttafuoco:
> ARM platform fails the "point" test see below.

For the 7.4 release we got a report for the ARM platform where all tests
passed:

http://archives.postgresql.org/pgsql...0/msg01212.php

So either there are various degrees of ARM processors or something is broken.
Ideas?

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

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

http://archives.postgresql.org

On Thu, Jan 06, 2005 at 10:18:58AM +0100, Peter Eisentraut wrote:
> Am Dienstag, 4. Januar 2005 19:03 schrieb Jim Buttafuoco:
> > ARM platform fails the "point" test see below.
>
> For the 7.4 release we got a report for the ARM platform where all tests
> passed:
>
> http://archives.postgresql.org/pgsql...0/msg01212.php
>
> So either there are various degrees of ARM processors or something is broken.
> Ideas?

Yes, there are various degrees of those, but most of them should be
FPU-less. So FPU-emulation details would be interesting.

In case of Linux there are 3 variants:

NWFPE: default

FastFPE: only 32-bit mantissa, 4-8x faster than NWFPE

gcc -msoft-float: no FP instructions, direct calls. This
changes calling convention, so requires that all
code is compiled with this.

Jim, do you happen to use FastFPE?

--
marko


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

it looks like a sqrt problem that has been fixed with the linux 2.6 kernel series. I am going to look and see if I
can get a 2.6 kernel to check it out.

since all of the other tests pass, maybe just a note in the read me file.

Jim



---------- Original Message -----------
From: Peter Eisentraut <peter_e@gmx.net>
To: jim@contactbda.com
Cc: "pgsql-hackers" <pgsql-hackers@postgresql.org>
Sent: Thu, 6 Jan 2005 10:18:58 +0100
Subject: Re: [HACKERS] CSV arm check failure

> Am Dienstag, 4. Januar 2005 19:03 schrieb Jim Buttafuoco:
> > ARM platform fails the "point" test see below.
>
> For the 7.4 release we got a report for the ARM platform where all tests
> passed:
>
> http://archives.postgresql.org/pgsql...0/msg01212.php
>
> So either there are various degrees of ARM processors or something is broken.
> Ideas?
>
> --
> Peter Eisentraut
> http://developer.postgresql.org/~petere/
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
------- End of Original Message -------


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

http://archives.postgresql.org

Marko,

I am using the stock Debian 2.4.27 kernel. Don't know how to change the fp setup. Do you have any instructions for
me?

Thanks
Jim



---------- Original Message -----------
From: Marko Kreen <marko@l-t.ee>
To: Peter Eisentraut <peter_e@gmx.net>
Cc: jim@contactbda.com, pgsql-hackers <pgsql-hackers@postgresql.org>
Sent: Thu, 6 Jan 2005 15:26:05 +0200
Subject: Re: [HACKERS] CSV arm check failure

> On Thu, Jan 06, 2005 at 10:18:58AM +0100, Peter Eisentraut wrote:
> > Am Dienstag, 4. Januar 2005 19:03 schrieb Jim Buttafuoco:
> > > ARM platform fails the "point" test see below.
> >
> > For the 7.4 release we got a report for the ARM platform where all tests
> > passed:
> >
> > http://archives.postgresql.org/pgsql...0/msg01212.php
> >
> > So either there are various degrees of ARM processors or something is broken.
> > Ideas?
>
> Yes, there are various degrees of those, but most of them should be
> FPU-less. So FPU-emulation details would be interesting.
>
> In case of Linux there are 3 variants:
>
> NWFPE: default
>
> FastFPE: only 32-bit mantissa, 4-8x faster than NWFPE
>
> gcc -msoft-float: no FP instructions, direct calls. This
> changes calling convention, so requires that all
> code is compiled with this.
>
> Jim, do you happen to use FastFPE?
>
> --
> marko
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
------- End of Original Message -------


---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

On Thu, Jan 06, 2005 at 09:07:14AM -0500, Jim Buttafuoco wrote:
> I am using the stock Debian 2.4.27 kernel. Don't know how to
> change the fp setup. Do you have any instructions for me?

It can be changed by configuring and recompiling kernel.

I checked the kernel-image-2.4.27-arm package from
Debian/testing and indeed it uses FastFPE emulation.

To be specific, the 'bast' and 'netwinder' targets do.
The 'lart', 'riscpc' and 'riscstation' targets use NWFPE.
I guess 'lart' and 'bast' are some devel boards and 'netwinder'
is the main target.

Looking at handhelds.org kernels they mostly use NWFPE
although there are couple of configs with FastFPE.

I have no clue on other Linux distros or *BSD's on ARM.

It seems PostgreSQL may encounter both NWFPE and FastFPE
on Linux/ARM. How to handle this I do not know.

--
marko


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Marko,

I couldn't get 2.4.27 to patch with the arm patches, so I downloaded 2.4.25 (with has CONFIG_FPE_NWFPE=y) and ALL
tests passed. So I will file a bug report with Debian. We should also put something in the Postgresql readme about
this issue.

Jim


---------- Original Message -----------
From: Marko Kreen <marko@l-t.ee>
To: Jim Buttafuoco <jim@contactbda.com>
Cc: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers <pgsql-hackers@postgresql.org>
Sent: Thu, 6 Jan 2005 17:25:20 +0200
Subject: Re: [HACKERS] CSV arm check failure

> On Thu, Jan 06, 2005 at 10:21:43AM -0500, Jim Buttafuoco wrote:
> > I will recompile the kernel and get back to the list
>
> Thanks. This way we can be sure it is FP-emulation effect.
>
> --
> marko
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
------- End of Original Message -------


---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Marko/All,

I wrote the following test program

#include <stdio.h>
#include <math.h>

#define HYPOT(A, B) sqrt((A) * (A) + (B) * (B))
int main()
{
printf("SQRT Test\n");
long double a;

a = HYPOT(0-10,0-10);
printf("double a = %20.12Lf\n",a);
exit(0);
}

and compiled it as follows
gcc -lm -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g -o sqrttest sqrt.c

with the following results:
SQRT Test
double a = 14.142135623731

which is the exact answer in the "results" file for point.

Now if I use perl instead of "C" I get the wrong answer 14.1421356237309 which is what postgres is also reporting. So
this looks like a compile time problem which is alittle over my head.

Any idea's
Jim




Jim


---------- Original Message -----------
From: Marko Kreen <marko@l-t.ee>
To: Peter Eisentraut <peter_e@gmx.net>
Cc: jim@contactbda.com, pgsql-hackers <pgsql-hackers@postgresql.org>
Sent: Thu, 6 Jan 2005 15:26:05 +0200
Subject: Re: [HACKERS] CSV arm check failure

> On Thu, Jan 06, 2005 at 10:18:58AM +0100, Peter Eisentraut wrote:
> > Am Dienstag, 4. Januar 2005 19:03 schrieb Jim Buttafuoco:
> > > ARM platform fails the "point" test see below.
> >
> > For the 7.4 release we got a report for the ARM platform where all tests
> > passed:
> >
> > http://archives.postgresql.org/pgsql...0/msg01212.php
> >
> > So either there are various degrees of ARM processors or something is broken.
> > Ideas?
>
> Yes, there are various degrees of those, but most of them should be
> FPU-less. So FPU-emulation details would be interesting.
>
> In case of Linux there are 3 variants:
>
> NWFPE: default
>
> FastFPE: only 32-bit mantissa, 4-8x faster than NWFPE
>
> gcc -msoft-float: no FP instructions, direct calls. This
> changes calling convention, so requires that all
> code is compiled with this.
>
> Jim, do you happen to use FastFPE?
>
> --
> marko
------- End of Original Message -------


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

On Thu, Jan 06, 2005 at 10:18:58AM +0100, Peter Eisentraut wrote:
> For the 7.4 release we got a report for the ARM platform where all tests
> passed:
>
> http://archives.postgresql.org/pgsql...0/msg01212.php

Additional info point:

> (sid)noel ( at ) debussy:~/postgresql-cvs/pgsql$ uname -a
> Linux debussy 2.4.19-netwinder #1 Thu Mar 20 03:14:34 CET 2003 armv4l GNU/Linux

I am guessing: the distro was Debian.

I cant find 2.4.19-netwinder kernel but 2.4.16-netwinder from
Debian/stable uses NWFPE. Ѕo Debian has changed from NWFPE to
FastFPE at some point in time.

--
marko


---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

On Thu, Jan 06, 2005 at 10:21:43AM -0500, Jim Buttafuoco wrote:
> I will recompile the kernel and get back to the list

Thanks. This way we can be sure it is FP-emulation effect.

--
marko


---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend