Thread: Regression (semi)fix for netbsd-mac68k
Hi, One of the regression failure on NetBSD mac68k is float8 (see http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=osprey&br=HEAD). The failure is due to the fact the strtod does not underflow for +-10e-400. I see in src/test/regress/resultmap that NetBSD ix86 does not overflow either, and that that seems to be OK since there is a special result file for this platform so that the test passes. So a "fix" for NetBSD mac68k would be to special case it too... Patch: It should be possible to have one regexp for netbsd, but I did not figure how to write it.... --- src/test/regress/resultmap.orig 2004-10-04 16:42:47.000000000 +0200 +++ src/test/regress/resultmap 2004-12-22 23:27:51.000000000 +0100 @@ -3,6 +3,7 @@ float8/i.86-.*-freebsd[234]=float8-small-is-zero float8/i.86-.*-openbsd=float8-small-is-zero float8/i.86-.*-netbsd=float8-small-is-zero +float8/m68k-.*-netbsd=float8-small-is-zero float8/.*-qnx=float8-exp-three-digits float8/i.86-pc-mingw32=float8-exp-three-digits-win32float8/i.86-pc-cygwin=float8-small-is-zero Regards, Rémi Zara -- Rémi Zara http://www.remi-zara.net/
Rémi Zara <remi_zara@mac.com> writes:
> --- src/test/regress/resultmap.orig 2004-10-04 16:42:47.000000000=20
> +0200
> +++ src/test/regress/resultmap 2004-12-22 23:27:51.000000000 +0100
> @@ -3,6 +3,7 @@
> float8/i.86-.*-freebsd[234]=float8-small-is-zero
> float8/i.86-.*-openbsd=float8-small-is-zero
> float8/i.86-.*-netbsd=float8-small-is-zero
> +float8/m68k-.*-netbsd=float8-small-is-zero
> float8/.*-qnx=float8-exp-three-digits
> float8/i.86-pc-mingw32=float8-exp-three-digits-win32
> float8/i.86-pc-cygwin=float8-small-is-zero
Looks reasonable to me --- why do you call it only a "semi" fix?
I wonder whether we oughtn't remove the i.86- part from the patterns
for the BSDen, ie, assume they will have this behavior on all hardware
not just Intel.
regards, tom lane
Le 23 déc. 04, à 00:26, Tom Lane a écrit : > Rémi Zara <remi_zara@mac.com> writes: >> --- src/test/regress/resultmap.orig 2004-10-04 >> 16:42:47.000000000=20 >> +0200 >> +++ src/test/regress/resultmap 2004-12-22 23:27:51.000000000 +0100 >> @@ -3,6 +3,7 @@ >> float8/i.86-.*-freebsd[234]=float8-small-is-zero >> float8/i.86-.*-openbsd=float8-small-is-zero >> float8/i.86-.*-netbsd=float8-small-is-zero >> +float8/m68k-.*-netbsd=float8-small-is-zero >> float8/.*-qnx=float8-exp-three-digits >> float8/i.86-pc-mingw32=float8-exp-three-digits-win32 >> float8/i.86-pc-cygwin=float8-small-is-zero > > Looks reasonable to me --- why do you call it only a "semi" fix Because strtod really should underflow, so there seems to be a bug in NetBSD's strtod. So this is just accepting the bug, not correcting it :) > I wonder whether we oughtn't remove the i.86- part from the patterns > for the BSDen, ie, assume they will have this behavior on all hardware > not just Intel. From pgbuildfarm, it seems that openBSD sparc64 does not exhibit the problem (it's not part of resultmap, and passes the float8 test). Regards, Rémi Zara -- Rémi Zara http://www.remi-zara.net/
Rémi Zara <remi_zara@mac.com> writes:
> Le 23 d=E9c. 04, =E0 00:26, Tom Lane a =E9crit :
>> Looks reasonable to me --- why do you call it only a "semi" fix
> Because strtod really should underflow, so there seems to be a bug in
> NetBSD's strtod.
> So this is just accepting the bug, not correcting it :)
Sure, but it's not our job to fix strtod(). Feel free to file a bug
report with the NetBSD guys.
>> I wonder whether we oughtn't remove the i.86- part from the patterns
>> for the BSDen, ie, assume they will have this behavior on all hardware
>> not just Intel.
> From pgbuildfarm, it seems that openBSD sparc64 does not exhibit the
> problem (it's not part of resultmap, and passes the float8 test).
OK, never mind that then. Patch applied as-is.
regards, tom lane
Le 23 déc. 04, à 04:52, Tom Lane a écrit : > Rémi Zara <remi_zara@mac.com> writes: >> Le 23 d=E9c. 04, =E0 00:26, Tom Lane a =E9crit : >>> Looks reasonable to me --- why do you call it only a "semi" fix > >> Because strtod really should underflow, so there seems to be a bug in >> NetBSD's strtod. >> So this is just accepting the bug, not correcting it :) > > Sure, but it's not our job to fix strtod(). Feel free to file a bug > report with the NetBSD guys. Of course. Will do. >>> I wonder whether we oughtn't remove the i.86- part from the patterns >>> for the BSDen, ie, assume they will have this behavior on all >>> hardware >>> not just Intel. > >> From pgbuildfarm, it seems that openBSD sparc64 does not exhibit the >> problem (it's not part of resultmap, and passes the float8 test). > > OK, never mind that then. Patch applied as-is. Cool, thanks ! Regards, Rémi Zara -- Rémi Zara http://www.remi-zara.net/
Rémi Zara said: >> >>> From pgbuildfarm, it seems that openBSD sparc64 does not exhibit the >>> problem (it's not part of resultmap, and passes the float8 test). >> >> OK, never mind that then. Patch applied as-is. > > Cool, thanks ! > Now we just need to work out why the box is failing the oldstyle_length test - see http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=osprey&dt=2004-12-23%2005:00:22 cheers andrew
"Andrew Dunstan" <andrew@dunslane.net> writes: > Now we just need to work out why the box is failing the oldstyle_length test > - see > http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=osprey&dt=2004-12-23%2005:00:22 Either the passing of arguments or the passing of the return value isn't working the way we think. Put a printf into oldstyle_length to see what value it thinks it's returning. I suspect it is receiving the right arguments and computing the right value, but the return convention is messed up. Some fooling around with the func_ptr definition near the top of fmgr.c might fix it. regards, tom lane
Le 23 déc. 04, à 16:09, Tom Lane a écrit : > "Andrew Dunstan" <andrew@dunslane.net> writes: >> Now we just need to work out why the box is failing the >> oldstyle_length test >> - see >> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=osprey&dt=2004-12 >> -23%2005:00:22 > > Either the passing of arguments or the passing of the return value > isn't > working the way we think. Put a printf into oldstyle_length to see > what > value it thinks it's returning. I suspect it is receiving the right > arguments and computing the right value, but the return convention is > messed up. Some fooling around with the func_ptr definition near the > top of fmgr.c might fix it. Indeed. NetBSD mac68k's gcc does not define __mc68000__, but __m68k__ The following patch makes the oldstyle_length test pass ! The change in miscinit is not necessary but for consistency sake (the return value of the func is not read). Index: src/backend/utils/fmgr/fmgr.c =================================================================== RCS file: /projects/cvsroot/pgsql/src/backend/utils/fmgr/fmgr.c,v retrieving revision 1.86 diff -u -r1.86 fmgr.c --- src/backend/utils/fmgr/fmgr.c 25 Oct 2004 00:46:42 -0000 1.86 +++ src/backend/utils/fmgr/fmgr.c 25 Dec 2004 21:10:53 -0000 @@ -40,7 +40,7 @@ * *additionally* into %d0 for compatibility.) The price is that there are * some warnings about int->pointer conversions... */ -#if defined(__mc68000__) && defined(__ELF__) +#if (defined(__mc68000__) || (defined(__m68k__))) && defined(__ELF__) typedef int32 ((*func_ptr) ()); #else Index: src/backend/utils/init/miscinit.c =================================================================== RCS file: /projects/cvsroot/pgsql/src/backend/utils/init/miscinit.c,v retrieving revision 1.135 diff -u -r1.135 miscinit.c --- src/backend/utils/init/miscinit.c 9 Oct 2004 23:13:06 -0000 1.135 +++ src/backend/utils/init/miscinit.c 25 Dec 2004 21:10:54 -0000 @@ -915,7 +915,7 @@ *----------------------------------------------------------------------- -- */ -#if defined(__mc68000__) && defined(__ELF__) +#if (defined(__mc68000__) || (defined(__m68k__))) && defined(__ELF__) typedef int32 ((*func_ptr) ()); #else Regards, Rémi Zara -- Rémi Zara http://www.remi-zara.net/