Re: [HACKERS] NaN/Inf fix for ECPG
Le 26 févr. 2010 à 17:11, Tom Lane a écrit : =?iso-8859-1?Q?R=E9mi_Zara?= remi_z...@mac.com writes: I've tried patch 1 and 2, but they do not work. The fact is that the code is not used in the backend, because strtod(NaN, endptr) works. (isnan(strtod(NaN, endptr)) is true). Hmm. So what do you get from SELECT 'nan'::numeric::float8; on that machine? That should exercise the backend's version of get_float8_nan(). regression=# select 'nan'::numeric::float8; float8 -- Infinity (1 row) So it is indeed the same behavior. Maybe that should be added to the regression tests. So what's the best way to workaround the bug in NetBSD/mips ? (nan(), (0.0/0.0), strtod(nan, null) ?) Regards, Rémi Zara -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] NaN/Inf fix for ECPG
=?iso-8859-1?Q?R=E9mi_Zara?= remi_z...@mac.com writes: Le 26 févr. 2010 à 17:11, Tom Lane a écrit : Hmm. So what do you get from SELECT 'nan'::numeric::float8; regression=# select 'nan'::numeric::float8; float8 -- Infinity (1 row) So it is indeed the same behavior. Yeah. So what it boils down to is that the platform has a NAN constant but casting it to double produces the wrong thing. There's no doubt that that's a bug in the floating-point support. You did say you'd submitted it to the NetBSD folk right? BTW, what about the float4 case, 'nan'::numeric::float4 ? Maybe that should be added to the regression tests. Perhaps. A lot of this stuff was never stress-tested in the past because when it was put in, it was a crap shoot whether NaN (or Inf) really worked on most platforms. Our attitude was if it works for you, great, but we're not going to sweat about it if it doesn't. I'm not sure whether full IEEE float support has gotten sufficiently universal to justify expecting more. I guess we could try it and see how many other buildfarm members fail. So what's the best way to workaround the bug in NetBSD/mips ? I don't think it's our bug to fix. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] NaN/Inf fix for ECPG
Le 27 févr. 2010 à 17:57, Tom Lane a écrit : =?iso-8859-1?Q?R=E9mi_Zara?= remi_z...@mac.com writes: Le 26 févr. 2010 à 17:11, Tom Lane a écrit : Hmm. So what do you get from SELECT 'nan'::numeric::float8; regression=# select 'nan'::numeric::float8; float8 -- Infinity (1 row) So it is indeed the same behavior. Yeah. So what it boils down to is that the platform has a NAN constant but casting it to double produces the wrong thing. There's no doubt that that's a bug in the floating-point support. You did say you'd submitted it to the NetBSD folk right? I submitted it. BTW, what about the float4 case, 'nan'::numeric::float4 ? That works OK. Maybe that should be added to the regression tests. Perhaps. A lot of this stuff was never stress-tested in the past because when it was put in, it was a crap shoot whether NaN (or Inf) really worked on most platforms. Our attitude was if it works for you, great, but we're not going to sweat about it if it doesn't. I'm not sure whether full IEEE float support has gotten sufficiently universal to justify expecting more. I guess we could try it and see how many other buildfarm members fail. So what's the best way to workaround the bug in NetBSD/mips ? I don't think it's our bug to fix. It would mean retiring pika until/if the bug is fixed... :-( Regards, Rémi Zara -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] NaN/Inf fix for ECPG
=?iso-8859-1?Q?R=E9mi_Zara?= remi_z...@mac.com writes: Le 27 févr. 2010 à 17:57, Tom Lane a écrit : I don't think it's our bug to fix. It would mean retiring pika until/if the bug is fixed... :-( Grumble ... well, I suppose we've put in worse platform-specific hacks elsewhere. At least this is pretty localized. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] NaN/Inf fix for ECPG
On Fri, Feb 26, 2010 at 11:14:01AM -0500, Tom Lane wrote: I think it would be a good idea, just to have all that code using identical #includes. R�mi's problem may be a platform bug rather Sounds reasonable, done. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] NaN/Inf fix for ECPG
Tom Lane írta: Boszormenyi Zoltan z...@cybertec.at writes: Can you try whether the first patch (missing float.h from data.c) solves the problem? And together with the 2nd one? In that patch I fixed the order of float.h and math.h in nan_test.pgc, which is the opposite of the order found in e.g. backend/utils/adt/float.c. The 3rd patch is explicit about NetBSD/mips but it doesn't feel right. The third patch is surely wrong. We don't need to do that in the backend's instance of get_float8_nan, so ecpglib shouldn't need it either. I suspect that the ultimate cause of this is either one of the header inclusion inconsistencies you found, or something associated with not pulling in all the stuff that postgres.h does. port/netbsd.h is empty though, so it's not immediately clear what might be missing. ecpglib/data.c includes postgres_fe.h, so it should be pulling everything that's relevant from port/*, right? Michael, can we try to install the first two patches? They wouldn't hurt. Thanks in advance, Zoltán Böszörményi -- Bible has answers for everything. Proof: But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil. (Matthew 5:37) - basics of digital technology. May your kingdom come - superficial description of plate tectonics -- Zoltán Böszörményi Cybertec Schönig Schönig GmbH http://www.postgresql.at/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] NaN/Inf fix for ECPG
Le 26 févr. 2010 à 12:12, Boszormenyi Zoltan a écrit : ecpglib/data.c includes postgres_fe.h, so it should be pulling everything that's relevant from port/*, right? Michael, can we try to install the first two patches? They wouldn't hurt. I've tried patch 1 and 2, but they do not work. The fact is that the code is not used in the backend, because strtod(NaN, endptr) works. (isnan(strtod(NaN, endptr)) is true). I should also note that isnan((double)nan()) is true (works). I will also report to NetBSD that isnan((double)NAN) does not work on mips. Regards, Rémi Zara -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] NaN/Inf fix for ECPG
On Fri, Feb 26, 2010 at 12:12:10PM +0100, Boszormenyi Zoltan wrote: Michael, can we try to install the first two patches? If I understood the rest of the thread correctly this is not needed anymore, right? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] NaN/Inf fix for ECPG
=?iso-8859-1?Q?R=E9mi_Zara?= remi_z...@mac.com writes: I've tried patch 1 and 2, but they do not work. The fact is that the code is not used in the backend, because strtod(NaN, endptr) works. (isnan(strtod(NaN, endptr)) is true). Hmm. So what do you get from SELECT 'nan'::numeric::float8; on that machine? That should exercise the backend's version of get_float8_nan(). regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] NaN/Inf fix for ECPG
Michael Meskes mes...@postgresql.org writes: On Fri, Feb 26, 2010 at 12:12:10PM +0100, Boszormenyi Zoltan wrote: Michael, can we try to install the first two patches? If I understood the rest of the thread correctly this is not needed anymore, right? I think it would be a good idea, just to have all that code using identical #includes. Rémi's problem may be a platform bug rather than something we can fix ourselves, but I think that making sure that ecpg uses the exact same coding that's been proven in the backend will forestall problems on other platforms. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] NaN/Inf fix for ECPG
Rémi Zara írta:
Le 24 févr. 2010 à 18:58, Boszormenyi Zoltan a écrit :
Here's the attached test code. Compile it with
gcc -Wall -o nantest nantest.c -lm
and run it. It tests NAN anf INFINITY values with isinf() and isnan().
The expected output is:
==
$ ./nantest
computed NAN
1 0
computed INFINITY
0 1
==
Instead of computed, NetBSD/x86-64 prints defined
but the test results are the same as under Linux/x86-64.
Here it is :
First, thanks for running it.
-bash-4.1$ gcc -Wall -o nantest nantest.c -lm
-bash-4.1$ ./nantest
defined NAN
0 1
So: isnan((double)NAN) == false, isinf((double)NAN) == true?
No wonder this causes a little problem.
defined INFINITY
0 1
Ok. So, on NetBSD/mips (#ifdef __NetBSD__ __mips__), isnan(NAN) is true,
isnan((double)NAN) is false, and isnan((double)(0.0 / 0.0)) is true.
Regards,
Rémi Zara
NAN on NetBSD/x86-64 is defined as:
extern const union __float_u __nanf;
#define NAN __nanf.__val
I would guess that it's similar on mips. Is is possible that
NetBSD/mips has a conversion bug?
What I don't get is that the code I used in ECPG and in this
test code is the same as in src/backend/utils/adt/float.c. E.g.:
float8in sees NaN - value will be (double)NAN
float8out sees isnan(value) - outputs NaN string
Can someone shed some light on why the backend
doesn't get the problem as above? :-(
As Rémi says, isnan((double)(0.0 / 0.0)) == true for him.
Michael: IIRC, IEEE754 explicit about that the (0.0/0.0) division
produces NaN. How about doing it explicitely in ECPG?
Rémi: please, run this code to confirm the above?
Best regards,
Zoltán Böszörményi
--
Bible has answers for everything. Proof:
But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
than these cometh of evil. (Matthew 5:37) - basics of digital technology.
May your kingdom come - superficial description of plate tectonics
--
Zoltán Böszörményi
Cybertec Schönig Schönig GmbH
http://www.postgresql.at/
#include math.h
#include float.h
#include stdio.h
static double
get_float8_nan(void)
{
printf(computed NAN\n);
return (double) (0.0 / 0.0);
}
static double
get_float8_infinity(void)
{
#ifdef INFINITY
printf(defined INFINITY\n);
return (double) INFINITY;
#else
printf(computed INFINITY\n);
return (double) (HUGE_VAL * HUGE_VAL);
#endif
}
int main(void) {
double d;
d = get_float8_nan();
printf(%d %d\n, isnan(d), isinf(d));
d = get_float8_infinity();
printf(%d %d\n, isnan(d), isinf(d));
return 0;
}
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] NaN/Inf fix for ECPG
Le 25 févr. 2010 à 11:26, Boszormenyi Zoltan a écrit : NAN on NetBSD/x86-64 is defined as: extern const union __float_u __nanf; #define NAN __nanf.__val Same here: math.h:extern const union __float_u __nanf; math.h:#define NAN __nanf.__val I would guess that it's similar on mips. Is is possible that NetBSD/mips has a conversion bug? What I don't get is that the code I used in ECPG and in this test code is the same as in src/backend/utils/adt/float.c. E.g.: float8in sees NaN - value will be (double)NAN float8out sees isnan(value) - outputs NaN string Can someone shed some light on why the backend doesn't get the problem as above? :-( As Rémi says, isnan((double)(0.0 / 0.0)) == true for him. Michael: IIRC, IEEE754 explicit about that the (0.0/0.0) division produces NaN. How about doing it explicitely in ECPG? Rémi: please, run this code to confirm the above? bash-4.1$ gcc -Wall -o nantest1 nantest1.c -lm bash-4.1$ ./nantest1 computed NAN 1 0 defined INFINITY 0 1 Regards, Rémi Zara -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] NaN/Inf fix for ECPG
I wrote:
As Rémi says, isnan((double)(0.0 / 0.0)) == true for him.
Michael: IIRC, IEEE754 explicit about that the (0.0/0.0) division
produces NaN. How about doing it explicitely in ECPG?
I came up with three patches, they are attached.
Can you try whether the first patch (missing float.h from data.c)
solves the problem? And together with the 2nd one? In that
patch I fixed the order of float.h and math.h in nan_test.pgc,
which is the opposite of the order found in e.g. backend/utils/adt/float.c.
The 3rd patch is explicit about NetBSD/mips but it doesn't feel right.
They are working on Linux/x86-64 and NetBSD/x86-64. Can you try
the combinations below on pika outside the buildfarm whether they
still fail the ECPG make check?
- patch 1 by itself (12a)
- patch 1+2 (12a + 12-regr)
- patch 3 with/without 1+2
Sorry to give you work, but we don't have a mips machine.
Thanks in advance,
Zoltán Böszörményi
--
Bible has answers for everything. Proof:
But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
than these cometh of evil. (Matthew 5:37) - basics of digital technology.
May your kingdom come - superficial description of plate tectonics
--
Zoltán Böszörményi
Cybertec Schönig Schönig GmbH
http://www.postgresql.at/
*** pgsql/src/interfaces/ecpg/ecpglib/data.c~ 2010-02-25 13:11:56.0 +0100
--- pgsql/src/interfaces/ecpg/ecpglib/data.c 2010-02-25 13:11:56.0 +0100
***
*** 5,10
--- 5,11
#include stdlib.h
#include string.h
+ #include float.h
#include math.h
#include ecpgtype.h
diff -dcrpN pgsql.orig/src/interfaces/ecpg/test/expected/pgtypeslib-nan_test.c pgsql/src/interfaces/ecpg/test/expected/pgtypeslib-nan_test.c
*** pgsql.orig/src/interfaces/ecpg/test/expected/pgtypeslib-nan_test.c 2010-02-16 19:56:08.0 +0100
--- pgsql/src/interfaces/ecpg/test/expected/pgtypeslib-nan_test.c 2010-02-25 13:16:17.0 +0100
***
*** 9,16
#line 1 nan_test.pgc
#include stdio.h
#include stdlib.h
- #include math.h
#include float.h
#include pgtypes_numeric.h
#include decimal.h
--- 9,16
#line 1 nan_test.pgc
#include stdio.h
#include stdlib.h
#include float.h
+ #include math.h
#include pgtypes_numeric.h
#include decimal.h
diff -dcrpN pgsql.orig/src/interfaces/ecpg/test/pgtypeslib/nan_test.pgc pgsql/src/interfaces/ecpg/test/pgtypeslib/nan_test.pgc
*** pgsql.orig/src/interfaces/ecpg/test/pgtypeslib/nan_test.pgc 2010-02-16 19:56:09.0 +0100
--- pgsql/src/interfaces/ecpg/test/pgtypeslib/nan_test.pgc 2010-02-25 13:15:07.0 +0100
***
*** 1,7
#include stdio.h
#include stdlib.h
- #include math.h
#include float.h
#include pgtypes_numeric.h
#include decimal.h
--- 1,7
#include stdio.h
#include stdlib.h
#include float.h
+ #include math.h
#include pgtypes_numeric.h
#include decimal.h
*** pgsql.orig/src/interfaces/ecpg/ecpglib/data.c 2010-02-04 11:10:03.0 +0100
--- pgsql/src/interfaces/ecpg/ecpglib/data.c 2010-02-25 12:57:49.0 +0100
***
*** 85,94
static double
get_float8_nan(void)
{
! #ifdef NAN
! return (double) NAN;
! #else
return (double) (0.0 / 0.0);
#endif
}
--- 85,94
static double
get_float8_nan(void)
{
! #if !defined(NAN) || (defined(__NetBSD__) defined(__mips__))
return (double) (0.0 / 0.0);
+ #else
+ return (double) NAN;
#endif
}
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] NaN/Inf fix for ECPG
Le 17 févr. 2010 à 12:18, Boszormenyi Zoltan a écrit : Is this buildfarm member for detecting bugs in the already obsolete NetBSD 5.0 BETA, or what? The final 5.0 and two bugfix releases are already out for a while. The owner of that particular machine should upgrade. I upgraded pika to NetBSD 5.0.2, and the problem is still there. There are some tests (in core) which tests for NaN and Infinity, which pass. So either those tests are insufficient, or the code does something different there. Anything you want me to try ? Regards, Rémi Zara -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] NaN/Inf fix for ECPG
Boszormenyi Zoltan z...@cybertec.at writes: Can you try whether the first patch (missing float.h from data.c) solves the problem? And together with the 2nd one? In that patch I fixed the order of float.h and math.h in nan_test.pgc, which is the opposite of the order found in e.g. backend/utils/adt/float.c. The 3rd patch is explicit about NetBSD/mips but it doesn't feel right. The third patch is surely wrong. We don't need to do that in the backend's instance of get_float8_nan, so ecpglib shouldn't need it either. I suspect that the ultimate cause of this is either one of the header inclusion inconsistencies you found, or something associated with not pulling in all the stuff that postgres.h does. port/netbsd.h is empty though, so it's not immediately clear what might be missing. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] NaN/Inf fix for ECPG
Le 17 févr. 2010 à 12:18, Boszormenyi Zoltan a écrit : Is this buildfarm member for detecting bugs in the already obsolete NetBSD 5.0 BETA, or what? The final 5.0 and two bugfix releases are already out for a while. The owner of that particular machine should upgrade. I upgraded pika to NetBSD 5.0.2, and the problem is still there. There are some tests (in core) which tests for NaN and Infinity, which pass. So either those tests are insufficient, or the code does something different there. Anything you want me to try ? Regards, Rémi Zara -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] NaN/Inf fix for ECPG
Rémi Zara írta:
Le 17 févr. 2010 à 12:18, Boszormenyi Zoltan a écrit :
Is this buildfarm member for detecting bugs in the already
obsolete NetBSD 5.0 BETA, or what? The final 5.0 and
two bugfix releases are already out for a while. The owner
of that particular machine should upgrade.
I upgraded pika to NetBSD 5.0.2,
Thanks very much for that.
and the problem is still there.
:-(
There are some tests (in core) which tests for NaN and Infinity, which
pass. So either those tests are insufficient, or the code does something
different there.
Anything you want me to try ?
Here's the attached test code. Compile it with
gcc -Wall -o nantest nantest.c -lm
and run it. It tests NAN anf INFINITY values with isinf() and isnan().
The expected output is:
==
$ ./nantest
computed NAN
1 0
computed INFINITY
0 1
==
Instead of computed, NetBSD/x86-64 prints defined
but the test results are the same as under Linux/x86-64.
Best regards,
Zoltán Böszörményi
--
Bible has answers for everything. Proof:
But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
than these cometh of evil. (Matthew 5:37) - basics of digital technology.
May your kingdom come - superficial description of plate tectonics
--
Zoltán Böszörményi
Cybertec Schönig Schönig GmbH
http://www.postgresql.at/
#include math.h
#include float.h
#include stdio.h
static double
get_float8_nan(void)
{
#ifdef NAN
printf(defined NAN\n);
return (double) NAN;
#else
printf(computed NAN\n);
return (double) (0.0 / 0.0);
#endif
}
static double
get_float8_infinity(void)
{
#ifdef INFINITY
printf(defined INFINITY\n);
return (double) INFINITY;
#else
printf(computed INFINITY\n);
return (double) (HUGE_VAL * HUGE_VAL);
#endif
}
int main(void) {
double d;
d = get_float8_nan();
printf(%d %d\n, isnan(d), isinf(d));
d = get_float8_infinity();
printf(%d %d\n, isnan(d), isinf(d));
return 0;
}
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] NaN/Inf fix for ECPG
Le 24 févr. 2010 à 18:58, Boszormenyi Zoltan a écrit : Here's the attached test code. Compile it with gcc -Wall -o nantest nantest.c -lm and run it. It tests NAN anf INFINITY values with isinf() and isnan(). The expected output is: == $ ./nantest computed NAN 1 0 computed INFINITY 0 1 == Instead of computed, NetBSD/x86-64 prints defined but the test results are the same as under Linux/x86-64. Here it is : -bash-4.1$ gcc -Wall -o nantest nantest.c -lm -bash-4.1$ ./nantest defined NAN 0 1 defined INFINITY 0 1 Ok. So, on NetBSD/mips (#ifdef __NetBSD__ __mips__), isnan(NAN) is true, isnan((double)NAN) is false, and isnan((double)(0.0 / 0.0)) is true. Regards, Rémi Zara -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] NaN/Inf fix for ECPG
Michael Meskes írta: On Tue, Feb 16, 2010 at 10:28:00PM +0100, Michael Meskes wrote: I was trying to stress the *beta* status. Maybe someone into NetBSD might be interested in reporting this as a bug. At least it behaves different to all other archs we have. Hmm, it seems the patch didn't work. Back to the drawing board. I hope the amd64 version of NetBSD 5.0.2 behaves similarly, I can only try it as a VM guest... -- Bible has answers for everything. Proof: But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil. (Matthew 5:37) - basics of digital technology. May your kingdom come - superficial description of plate tectonics -- Zoltán Böszörményi Cybertec Schönig Schönig GmbH http://www.postgresql.at/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] NaN/Inf fix for ECPG
Boszormenyi Zoltan írta: Michael Meskes írta: On Tue, Feb 16, 2010 at 10:28:00PM +0100, Michael Meskes wrote: I was trying to stress the *beta* status. Maybe someone into NetBSD might be interested in reporting this as a bug. At least it behaves different to all other archs we have. Hmm, it seems the patch didn't work. Back to the drawing board. I hope the amd64 version of NetBSD 5.0.2 behaves similarly, I can only try it as a VM guest... NetBSD 5.0.2/x86_64 passed all both the main and the ECPG make check tests. The BETA might have had a bug or NetBSD/MIPS has some quirks I can't solve. Now what? On a sidenote, this machine fails for the 8.4 STABLE tree, too, in the main make check... Is this buildfarm member for detecting bugs in the already obsolete NetBSD 5.0 BETA, or what? The final 5.0 and two bugfix releases are already out for a while. The owner of that particular machine should upgrade. Best regards, Zoltán Böszörményi -- Bible has answers for everything. Proof: But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil. (Matthew 5:37) - basics of digital technology. May your kingdom come - superficial description of plate tectonics -- Zoltán Böszörményi Cybertec Schönig Schönig GmbH http://www.postgresql.at/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] NaN/Inf fix for ECPG
Hi,
buildfarm member pika fails the NaN test.
Does FreeBSD/MIPS really return true for isinf(NaN)?
Anyway, the attached patch tries to fix the test case
by testing isnan() first and doesn't check isinf()
if isnan() returned true.
Best regards,
Zoltán Böszörményi
--
Bible has answers for everything. Proof:
But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
than these cometh of evil. (Matthew 5:37) - basics of digital technology.
May your kingdom come - superficial description of plate tectonics
--
Zoltán Böszörményi
Cybertec Schönig Schönig GmbH
http://www.postgresql.at/
diff -durpN pgsql.orig/src/interfaces/ecpg/test/expected/pgtypeslib-nan_test.c pgsql/src/interfaces/ecpg/test/expected/pgtypeslib-nan_test.c
--- pgsql.orig/src/interfaces/ecpg/test/expected/pgtypeslib-nan_test.c 2010-02-09 11:43:57.0 +0100
+++ pgsql/src/interfaces/ecpg/test/expected/pgtypeslib-nan_test.c 2010-02-16 12:10:55.0 +0100
@@ -104,10 +104,10 @@ if (sqlca.sqlcode 0) sqlprint ( );}
if (sqlca.sqlcode)
break;
- if (isinf(d))
- printf(%d %sInf '%s'\n, id, (d 0 ? - : +), val);
if (isnan(d))
printf(%d NaN '%s'\n, id, val);
+ else if (isinf(d))
+ printf(%d %sInf '%s'\n, id, (d 0 ? - : +), val);
{ ECPGdo(__LINE__, 0, 1, NULL, 0, ECPGst_normal, insert into nantest1 ( id , d ) values ( $1 + 3 , $2 ),
ECPGt_int,(id),(long)1,(long)1,sizeof(int),
diff -durpN pgsql.orig/src/interfaces/ecpg/test/pgtypeslib/nan_test.pgc pgsql/src/interfaces/ecpg/test/pgtypeslib/nan_test.pgc
--- pgsql.orig/src/interfaces/ecpg/test/pgtypeslib/nan_test.pgc 2010-02-09 11:43:57.0 +0100
+++ pgsql/src/interfaces/ecpg/test/pgtypeslib/nan_test.pgc 2010-02-16 12:04:59.0 +0100
@@ -37,10 +37,10 @@ main(void)
exec sql fetch from cur into :id, :d, :val;
if (sqlca.sqlcode)
break;
- if (isinf(d))
- printf(%d %sInf '%s'\n, id, (d 0 ? - : +), val);
if (isnan(d))
printf(%d NaN '%s'\n, id, val);
+ else if (isinf(d))
+ printf(%d %sInf '%s'\n, id, (d 0 ? - : +), val);
exec sql insert into nantest1 (id, d) values (:id + 3, :d);
exec sql insert into nantest1 (id, d) values (:id + 6, :val);
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] NaN/Inf fix for ECPG
Boszormenyi Zoltan írta:
Hi,
buildfarm member pika fails the NaN test.
Does FreeBSD/MIPS really return true for isinf(NaN)?
Anyway, the attached patch tries to fix the test case
by testing isnan() first and doesn't check isinf()
if isnan() returned true.
I lied in the patch name, it wasn't a context diff.
Also, the same remedy seems to be needed in ecpglib/execute.c, too.
Best regards,
Zoltán Böszörményi
--
Bible has answers for everything. Proof:
But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
than these cometh of evil. (Matthew 5:37) - basics of digital technology.
May your kingdom come - superficial description of plate tectonics
--
Zoltán Böszörményi
Cybertec Schönig Schönig GmbH
http://www.postgresql.at/
diff -dcrpN pgsql.orig/src/interfaces/ecpg/ecpglib/execute.c pgsql/src/interfaces/ecpg/ecpglib/execute.c
*** pgsql.orig/src/interfaces/ecpg/ecpglib/execute.c 2010-02-04 11:10:03.0 +0100
--- pgsql/src/interfaces/ecpg/ecpglib/execute.c 2010-02-16 12:19:38.0 +0100
*** ecpg_store_result(const PGresult *result
*** 468,482
static void
sprintf_double_value(char *ptr, double value, const char *delim)
{
! if (isinf(value))
{
if (value 0)
sprintf(ptr, %s%s, -Infinity, delim);
else
sprintf(ptr, %s%s, Infinity, delim);
}
- else if (isnan(value))
- sprintf(ptr, %s%s, NaN, delim);
else
sprintf(ptr, %.14g%s, value, delim);
}
--- 468,482
static void
sprintf_double_value(char *ptr, double value, const char *delim)
{
! if (isnan(value))
! sprintf(ptr, %s%s, NaN, delim);
! else if (isinf(value))
{
if (value 0)
sprintf(ptr, %s%s, -Infinity, delim);
else
sprintf(ptr, %s%s, Infinity, delim);
}
else
sprintf(ptr, %.14g%s, value, delim);
}
*** sprintf_double_value(char *ptr, double v
*** 484,498
static void
sprintf_float_value(char *ptr, float value, const char *delim)
{
! if (isinf(value))
{
if (value 0)
sprintf(ptr, %s%s, -Infinity, delim);
else
sprintf(ptr, %s%s, Infinity, delim);
}
- else if (isnan(value))
- sprintf(ptr, %s%s, NaN, delim);
else
sprintf(ptr, %.14g%s, value, delim);
}
--- 484,498
static void
sprintf_float_value(char *ptr, float value, const char *delim)
{
! if (isnan(value))
! sprintf(ptr, %s%s, NaN, delim);
! else if (isinf(value))
{
if (value 0)
sprintf(ptr, %s%s, -Infinity, delim);
else
sprintf(ptr, %s%s, Infinity, delim);
}
else
sprintf(ptr, %.14g%s, value, delim);
}
diff -dcrpN pgsql.orig/src/interfaces/ecpg/test/expected/pgtypeslib-nan_test.c pgsql/src/interfaces/ecpg/test/expected/pgtypeslib-nan_test.c
*** pgsql.orig/src/interfaces/ecpg/test/expected/pgtypeslib-nan_test.c 2010-02-09 11:43:57.0 +0100
--- pgsql/src/interfaces/ecpg/test/expected/pgtypeslib-nan_test.c 2010-02-16 12:10:55.0 +0100
*** if (sqlca.sqlcode 0) sqlprint ( );}
*** 104,113
if (sqlca.sqlcode)
break;
- if (isinf(d))
- printf(%d %sInf '%s'\n, id, (d 0 ? - : +), val);
if (isnan(d))
printf(%d NaN '%s'\n, id, val);
{ ECPGdo(__LINE__, 0, 1, NULL, 0, ECPGst_normal, insert into nantest1 ( id , d ) values ( $1 + 3 , $2 ),
ECPGt_int,(id),(long)1,(long)1,sizeof(int),
--- 104,113
if (sqlca.sqlcode)
break;
if (isnan(d))
printf(%d NaN '%s'\n, id, val);
+ else if (isinf(d))
+ printf(%d %sInf '%s'\n, id, (d 0 ? - : +), val);
{ ECPGdo(__LINE__, 0, 1, NULL, 0, ECPGst_normal, insert into nantest1 ( id , d ) values ( $1 + 3 , $2 ),
ECPGt_int,(id),(long)1,(long)1,sizeof(int),
diff -dcrpN pgsql.orig/src/interfaces/ecpg/test/pgtypeslib/nan_test.pgc pgsql/src/interfaces/ecpg/test/pgtypeslib/nan_test.pgc
*** pgsql.orig/src/interfaces/ecpg/test/pgtypeslib/nan_test.pgc 2010-02-09 11:43:57.0 +0100
--- pgsql/src/interfaces/ecpg/test/pgtypeslib/nan_test.pgc 2010-02-16 12:04:59.0 +0100
*** main(void)
*** 37,46
exec sql fetch from cur into :id, :d, :val;
if (sqlca.sqlcode)
break;
- if (isinf(d))
- printf(%d %sInf '%s'\n, id, (d 0 ? - : +), val);
if (isnan(d))
printf(%d NaN '%s'\n, id, val);
exec sql insert into nantest1 (id, d) values (:id + 3, :d);
exec sql insert into nantest1 (id, d) values (:id + 6, :val);
--- 37,46
exec sql fetch from cur into :id, :d, :val;
if (sqlca.sqlcode)
break;
if (isnan(d))
printf(%d NaN '%s'\n, id, val);
+ else if (isinf(d))
+ printf(%d %sInf '%s'\n, id, (d 0 ? - : +), val);
exec sql insert into nantest1 (id, d) values (:id + 3, :d);
exec sql insert into nantest1 (id, d) values (:id + 6, :val);
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] NaN/Inf fix for ECPG
On Tue, Feb 16, 2010 at 12:21:34PM +0100, Boszormenyi Zoltan wrote: Does FreeBSD/MIPS really return true for isinf(NaN)? Actually it's a netbsd beta version, so maybe there's a bug in their libc. But anyway, the patch doesn't seem to hurt, so I committed it. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] NaN/Inf fix for ECPG
Michael Meskes írta: On Tue, Feb 16, 2010 at 12:21:34PM +0100, Boszormenyi Zoltan wrote: Does FreeBSD/MIPS really return true for isinf(NaN)? Actually it's a netbsd beta version, so maybe there's a bug in their libc. I realized my typo after sending my mail. Sorry if I offended anyone calling NetBSD FreeBSD. :-) But anyway, the patch doesn't seem to hurt, so I committed it. Thanks. Best regards, Zoltán Böszörményi -- Bible has answers for everything. Proof: But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil. (Matthew 5:37) - basics of digital technology. May your kingdom come - superficial description of plate tectonics -- Zoltán Böszörményi Cybertec Schönig Schönig GmbH http://www.postgresql.at/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] NaN/Inf fix for ECPG
I realized my typo after sending my mail. Sorry if I offended anyone calling NetBSD FreeBSD. :-) I was trying to stress the *beta* status. Maybe someone into NetBSD might be interested in reporting this as a bug. At least it behaves different to all other archs we have. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] NaN/Inf fix for ECPG
On Tue, Feb 16, 2010 at 10:28:00PM +0100, Michael Meskes wrote: I was trying to stress the *beta* status. Maybe someone into NetBSD might be interested in reporting this as a bug. At least it behaves different to all other archs we have. Hmm, it seems the patch didn't work. Back to the drawing board. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
