Thread: CSV arm check failure
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
======================================================================
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-hackers/2003-10/msg01212.php So either there are various degrees of ARM processors or something is broken. Ideas? -- Peter Eisentraut http://developer.postgresql.org/~petere/
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-hackers/2003-10/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. Thischanges calling convention, so requires that allcode is compiledwith this. Jim, do you happen to use FastFPE? -- marko
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-hackers/2003-10/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 -------
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-hackers/2003-10/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 -------
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
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-hackers/2003-10/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 -------
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-hackers/2003-10/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
Marko, See my email with test program. I will recompile the kernel and get back to the list 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 16:58:03 +0200 Subject: Re: [HACKERS] CSV arm check failure > 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 Original Message -------
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
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 -------
On Thu, Jan 06, 2005 at 11:39:14AM -0500, Jim Buttafuoco wrote: > 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. I do not think its bug in Debian or kernel - it is expected and documented behaviour of FastFPE to have less precision. Also if you think of ARM usage scenarious it seems fine to use lighter emulation. The question is rather how to handle it in PostgreSQL regression testing: 1) Document the need for NWFPE - which gives standard results. 2) Use FastFPE results on Linux/ARM. 3) Autodetect - ok, that was a joke. I guess 1) is fine now. 2) should be done when FastFPE is standard on Linux/ARM. -- marko
Marko Kreen wrote:
>On Thu, Jan 06, 2005 at 11:39:14AM -0500, Jim Buttafuoco wrote:
>
>
>>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.
>>
>>
>
>I do not think its bug in Debian or kernel - it is expected and
>documented behaviour of FastFPE to have less precision. Also if
>you think of ARM usage scenarious it seems fine to use lighter
>emulation.
>
>The question is rather how to handle it in PostgreSQL
>regression testing:
>1) Document the need for NWFPE - which gives standard results.
>2) Use FastFPE results on Linux/ARM.
>3) Autodetect - ok, that was a joke.
>
>I guess 1) is fine now. 2) should be done when FastFPE is
>standard on Linux/ARM.
>
>
Why not just add an alternative regression output? pg_regress is
designed to handle it, and we have quite a few of those already to deal
with minor FP differences.
Reminder: here is the complete set of diffs:
*** ./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
cheers
andrew
On Thu, Jan 06, 2005 at 12:32:12PM -0500, Andrew Dunstan wrote: > Marko Kreen wrote: > >The question is rather how to handle it in PostgreSQL > >regression testing: > >1) Document the need for NWFPE - which gives standard results. > >2) Use FastFPE results on Linux/ARM. > >3) Autodetect - ok, that was a joke. > > > >I guess 1) is fine now. 2) should be done when FastFPE is > >standard on Linux/ARM. > > Why not just add an alternative regression output? pg_regress is > designed to handle it, and we have quite a few of those already to deal > with minor FP differences. I have not looked at pg_regress much and had not noticed the 'unconditional alternative' feature. I only thought of the resultmap alternative. Unconditionally adding FastFPE results may even be good, so that FastFPE can pass on any platform. Here are Jim's FastFPE 'point' results in separate file. Unfortunately I have not an ARM machine to test it on. Jim, could you apply this patch and run 'make check' on the FastFPE kernel. If you encounter more small FP errors, then simply copy results/<test>.out to expected/<test>_X.out where X is a next free number. Then send resulting files to this list. -- marko
Attachment
Marko Kreen <marko@l-t.ee> writes:
> I have not looked at pg_regress much and had not noticed the
> 'unconditional alternative' feature. I only thought of the
> resultmap alternative. Unconditionally adding FastFPE results
> may even be good, so that FastFPE can pass on any platform.
No, it would be bad, because on most other platforms this behavior
is probably a bug, and altering the tests like that would mask the bug.
The unconditional-acceptance thing has to be used with great caution;
preferably only for issues that we expect on many platforms (such as
locale dependencies).
I have noticed an increasing tendency among the buildfarm crew to think
that the regression tests should show zero diffs on all platforms no
matter what. That is not the design goal. The intent is to tell you
about possible problems. If you decide that a particular diff isn't
really a problem, fine, but that doesn't mean we should mask the same
symptom everywhere.
regards, tom lane
Tom Lane wrote: >I have noticed an increasing tendency among the buildfarm crew to think >that the regression tests should show zero diffs on all platforms no >matter what. That is not the design goal. The intent is to tell you >about possible problems. If you decide that a particular diff isn't >really a problem, fine, but that doesn't mean we should mask the same >symptom everywhere. > > > > I don't want to mask anything that shouldn't be. I made the suggestion in this particular case because we already have a number of alternative result files caused by FP differences. The buildfarm is a dashboard application - when everything is OK you want it to show all green. If that's not a goal, then some redesign is appropriate. Perhaps buildfarm needs its own test suite, rather than leveraging those in the distribution, although that would be a pity, to say the least. cheers andrew
On Thu, Jan 06, 2005 at 02:05:17PM -0500, Tom Lane wrote: > Marko Kreen <marko@l-t.ee> writes: > > I have not looked at pg_regress much and had not noticed the > > 'unconditional alternative' feature. I only thought of the > > resultmap alternative. Unconditionally adding FastFPE results > > may even be good, so that FastFPE can pass on any platform. > > No, it would be bad, because on most other platforms this behavior > is probably a bug, and altering the tests like that would mask the bug. > > The unconditional-acceptance thing has to be used with great caution; > preferably only for issues that we expect on many platforms (such as > locale dependencies). How about the following then: let pg_regress.sh accept multiple choices from resultmap. -- marko
Attachment
Marko Kreen wrote: >>The unconditional-acceptance thing has to be used with great caution; >>preferably only for issues that we expect on many platforms (such as >>locale dependencies). >> >> > >How about the following then: let pg_regress.sh accept multiple >choices from resultmap. > > Good idea. I was thinking along the same lines. cheers andrew
On Jan 7, 2005, at 4:35, Andrew Dunstan wrote: > The buildfarm is a dashboard application - when everything is OK you > want it to show all green. If that's not a goal, then some redesign is > appropriate. Perhaps buildfarm needs its own test suite, rather than > leveraging those in the distribution, although that would be a pity, > to say the least. What would you think about setting up a few columns to show the results of the various stages, rather than just the single result? Each row might get a little long, but then you can easily see if the other stages (beyond the first problem) work as well. I've been trying to think of a way to shorten the system information, but haven't thought of anything wonderful yet. Best, Michael Glaesemann grzm myrealbox com
Am Donnerstag, 6. Januar 2005 17:39 schrieb Jim Buttafuoco: > 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. OK, that's good enough. At least we found the cause of the problem. Future generations can look in the archives if they are interested in that kind of detail. -- Peter Eisentraut http://developer.postgresql.org/~petere/