Regression (semi)fix for netbsd-mac68k

=?ISO-8859-1?Q?R=E9mi_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 :

=?ISO-8859-1?Q?R=E9mi_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/

=?ISO-8859-1?Q?R=E9mi_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 :

=?ISO-8859-1?Q?R=E9mi_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&amp;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&amp;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&amp;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/