Re: [BUGS] Test suite fails on alpha architecture
Martin Pitt [2007-12-04 23:43 +0100]: So I tried to approach it from the other side: Building postgresql with CFLAGS=-O0 -g or -O1 -g works correctly, but with -O2 -g I get above bug. Just FAOD, building with gcc 4.1 and -O2 works fine. I guess this sufficiently proves that this is a gcc 4.2 bug. Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org signature.asc Description: Digital signature
Re: [BUGS] Test suite fails on alpha architecture
Hi,
Tom Lane [2007-11-07 13:49 -0500]:
All the other diffs that Martin showed are divide-by-zero failures,
and I do not see any of them on Gentoo's machine. I think that this
must be a compiler bug. The first example in his diffs is just
select 1/0, which executes this code:
int32arg1 = PG_GETARG_INT32(0);
int32arg2 = PG_GETARG_INT32(1);
int32result;
if (arg2 == 0)
ereport(ERROR,
(errcode(ERRCODE_DIVISION_BY_ZERO),
errmsg(division by zero)));
result = arg1 / arg2;
It looks to me like Debian's compiler must be allowing the division
instruction to be speculatively executed before the if-test branch
is taken. Perhaps it is supposing that this is OK because control
will return from ereport(), when in fact it will not (the routine
throws a longjmp). Since we've not seen such behavior on any other
platform, however, I suspect this is just a bug and not intentional.
I tried this on a Debian Alpha porter box (thanks, Steve, for pointing
me at it) with Debian's gcc 4.2.2. Latest sid indeed still has this
bug (the floor() one is confirmed fixed), not only on Alpha, but also
on sparc.
Since the simple test case did not reproduce the error, I tried to
make a more sophisticated one which resembles more closely what
PostgreSQL does (sigsetjmp/siglongjmp instead of exit(), some macros,
etc.). Unfortunately in vain, since the test case still works
perfectly with both no compiler options and also the ones used for
PostgreSQL. I attach it here nevertheless just in case someone has
more luck than me.
So I tried to approach it from the other side: Building postgresql
with CFLAGS=-O0 -g or -O1 -g works correctly, but with -O2 -g I
get above bug.
So I guess I'll build with -O1 for the time being on sparc and alpha
to get correct binaries until this is sorted out. Any idea what else I
could try?
Thanks,
Martin
--
Martin Pitthttp://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org
#include stdio.h
#include stdlib.h
#include setjmp.h
#define ERROR 20
#define ereport(elevel, rest) \
(errstart(elevel, __FILE__, __LINE__, __func__) ? \
(errfinish rest) : (void) 0)
#define PG_RE_THROW() \
siglongjmp(PG_exception_stack, 1)
sigjmp_buf PG_exception_stack;
int errstart(int elevel, const char *filename, int lineno,
const char *funcname)
{
printf(error: level %i %s:%i function %s\n, elevel, filename, lineno, funcname);
return 1;
}
void errfinish(int dummy, const char* msg)
{
puts(msg);
PG_RE_THROW();
}
int
do_div(char** argv)
{
int arg1 = atoi(argv[1]);
int arg2 = atoi(argv[2]);
int result;
if (arg2 == 0)
ereport(ERROR, (1, division by zero));
result = arg1 / arg2;
return result;
}
int
main(int argc, char **argv)
{
if (sigsetjmp(PG_exception_stack, 0) == 0) {
int result = do_div(argv);
printf(%d\n, result);
} else {
printf(caught error, aborting\n);
return 1;
}
return 0;
}
signature.asc
Description: Digital signature
Re: [BUGS] Test suite fails on alpha architecture
On Wed, Nov 07, 2007 at 02:44:23PM -0500, Tom Lane wrote:
I don't have access to a machine on which the failure occurs, but
perhaps Martin can try it. I'd think it'd be pretty easy, say
#include stdio.h
#include stdlib.h
void
ereport(const char *msg)
{
fprintf(stderr, %s\n, msg);
exit(0);
}
int
main(int argc, char **argv)
{
int arg1 = atoi(argv[1]);
int arg2 = atoi(argv[2]);
int result;
if (arg2 == 0)
ereport(division by zero);
result = arg1 / arg2;
printf(%d\n, result);
return 0;
}
cc -g -O2 -fPIC -fno-strict-aliasing -mieee -D_GNU_SOURCE bug.c
./a.out 1 0
I would not be surprised at all if it's compile-switch dependent; these
look to be the switches Martin tested with.
So strangely, when I first ran this test case I recall being able to
reproduce the SIGFPE; but now going back to it I'm getting the correct
division by zero output.
But postgresql still fails to build with the same errors as before.
FWIW, the first test suite failure involving floor() has been resolved now
in the glibc package in unstable.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [BUGS] Test suite fails on alpha architecture
Heya, I know I'm quite late with my answer, sorry. Frank Lichtenheld [EMAIL PROTECTED] writes: On Sat, Nov 03, 2007 at 06:32:34PM -0400, Martin Pitt wrote: Can you grant one of us access to the machine to work on it? I don't own any alpha machine, but maybe Frank, Steven, or anyone from the Debian alpha porter list can create a temporary account for you? I'm not sure how we handle that for our experimental buildds. Admins? One of the alphas used in the experimental buildd network is actually in bdale's basement, so I'm not really happy to hand out access to it. The other one (digitalis), which is hosted at the university of Darmstadt and is our under full control, should actually be used as a porting machine if needed. Debian Developers [1] can get access to them by pinging either Andreas Barth, Martin Zobel-Helas or me. We have our own userdir-ldap setup, so please include a mail address and a verifiable GPG key in your ping, together with a short description what you want to do. Marc Footnotes: [1] And Debian contributors, as long as there is some sort of trust relationship -- BOFH #357: I'd love to help you -- it's just that the Boss won't let me near the computer. pgpWucrzB1mpa.pgp Description: PGP signature
Re: [BUGS] Test suite fails on alpha architecture
Steve Langasek [EMAIL PROTECTED] writes: It may be specific to particular versions of glibc and the kernel. At least one of the test regressions is actually due to the bug described in http://lists.debian.org/debian-alpha/2007/10/msg00014.html; I haven't dug into the rest of the failures further at this point. Thanks for the tip about that bug. Using the gentoo project's kindly-lent Alpha, I see that the failure in our float8 regression test is indeed explained by floor() doing the wrong thing. The case that fails is regression=# select (-34.84)::float8 ^ '1e200'; ERROR: 2201F: invalid argument for power function LOCATION: dpow, float.c:1337 where we are expecting to get value out of range: overflow. Instead this test is failing: /* * The SQL spec requires that we emit a particular SQLSTATE error code for * certain error conditions. */ if ((arg1 == 0 arg2 0) || (arg1 0 floor(arg2) != arg2)) ereport(ERROR, (errcode(ERRCODE_INVALID_ARGUMENT_FOR_POWER_FUNCTION), errmsg(invalid argument for power function))); and indeed regression=# select floor(1e200::float8) - 1e200::float8; ?column? -1.69964157701365e+184 (1 row) so it seems floor(3m) is off by one in the last place. But if it can be reproduced on other distros as well, all the better. All the other diffs that Martin showed are divide-by-zero failures, and I do not see any of them on Gentoo's machine. I think that this must be a compiler bug. The first example in his diffs is just select 1/0, which executes this code: int32arg1 = PG_GETARG_INT32(0); int32arg2 = PG_GETARG_INT32(1); int32result; if (arg2 == 0) ereport(ERROR, (errcode(ERRCODE_DIVISION_BY_ZERO), errmsg(division by zero))); result = arg1 / arg2; It looks to me like Debian's compiler must be allowing the division instruction to be speculatively executed before the if-test branch is taken. Perhaps it is supposing that this is OK because control will return from ereport(), when in fact it will not (the routine throws a longjmp). Since we've not seen such behavior on any other platform, however, I suspect this is just a bug and not intentional. FWIW the Gentoo machine is running $ gcc -v Using built-in specs. Target: alpha-unknown-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.1.2/work/gcc-4.1.2/configure --prefix=/usr --bindir=/usr/alpha-unknown-linux-gnu/gcc-bin/4.1.2 --includedir=/usr/lib/gcc/alpha-unknown-linux-gnu/4.1.2/include --datadir=/usr/share/gcc-data/alpha-unknown-linux-gnu/4.1.2 --mandir=/usr/share/gcc-data/alpha-unknown-linux-gnu/4.1.2/man --infodir=/usr/share/gcc-data/alpha-unknown-linux-gnu/4.1.2/info --with-gxx-include-dir=/usr/lib/gcc/alpha-unknown-linux-gnu/4.1.2/include/g++-v4 --host=alpha-unknown-linux-gnu --build=alpha-unknown-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-libunwind-exceptions --disable-multilib --disable-libmudflap --disable-libssp --disable-libgcj --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 4.1.2 (Gentoo 4.1.2) Bottom line is that I see nothing here that the Postgres project can fix --- these are library and compiler bugs. regards, tom lane -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [BUGS] Test suite fails on alpha architecture
Hi Tom, Tom Lane [2007-11-07 13:49 -0500]: Bottom line is that I see nothing here that the Postgres project can fix --- these are library and compiler bugs. Thank you for your detailled analysis! I'll file bugs to the appropriate places then. Thanks, Martin -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org signature.asc Description: Digital signature
Re: [BUGS] Test suite fails on alpha architecture
Tom Lane [EMAIL PROTECTED] writes: All the other diffs that Martin showed are divide-by-zero failures, and I do not see any of them on Gentoo's machine. I think that this must be a compiler bug. The first example in his diffs is just select 1/0, which executes this code: int32arg1 = PG_GETARG_INT32(0); int32arg2 = PG_GETARG_INT32(1); int32result; if (arg2 == 0) ereport(ERROR, (errcode(ERRCODE_DIVISION_BY_ZERO), errmsg(division by zero))); result = arg1 / arg2; It looks to me like Debian's compiler must be allowing the division instruction to be speculatively executed before the if-test branch is taken. Perhaps it is supposing that this is OK because control will return from ereport(), when in fact it will not (the routine throws a longjmp). Since we've not seen such behavior on any other platform, however, I suspect this is just a bug and not intentional. Can you create a stand-alone testcase for this? -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [BUGS] Test suite fails on alpha architecture
On Wed, Nov 07, 2007 at 01:49:53PM -0500, Tom Lane wrote: Steve Langasek [EMAIL PROTECTED] writes: It may be specific to particular versions of glibc and the kernel. At least one of the test regressions is actually due to the bug described in http://lists.debian.org/debian-alpha/2007/10/msg00014.html; I haven't dug into the rest of the failures further at this point. But if it can be reproduced on other distros as well, all the better. All the other diffs that Martin showed are divide-by-zero failures, and I do not see any of them on Gentoo's machine. I think that this must be a compiler bug. The first example in his diffs is just select 1/0, which executes this code: int32arg1 = PG_GETARG_INT32(0); int32arg2 = PG_GETARG_INT32(1); int32result; if (arg2 == 0) ereport(ERROR, (errcode(ERRCODE_DIVISION_BY_ZERO), errmsg(division by zero))); result = arg1 / arg2; It looks to me like Debian's compiler must be allowing the division instruction to be speculatively executed before the if-test branch is taken. Perhaps it is supposing that this is OK because control will return from ereport(), when in fact it will not (the routine throws a longjmp). Since we've not seen such behavior on any other platform, however, I suspect this is just a bug and not intentional. FWIW the Gentoo machine is running $ gcc -v Using built-in specs. Target: alpha-unknown-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.1.2/work/gcc-4.1.2/configure --prefix=/usr --bindir=/usr/alpha-unknown-linux-gnu/gcc-bin/4.1.2 --includedir=/usr/lib/gcc/alpha-unknown-linux-gnu/4.1.2/include --datadir=/usr/share/gcc-data/alpha-unknown-linux-gnu/4.1.2 --mandir=/usr/share/gcc-data/alpha-unknown-linux-gnu/4.1.2/man --infodir=/usr/share/gcc-data/alpha-unknown-linux-gnu/4.1.2/info --with-gxx-include-dir=/usr/lib/gcc/alpha-unknown-linux-gnu/4.1.2/include/g++-v4 --host=alpha-unknown-linux-gnu --build=alpha-unknown-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-libunwind-exceptions --disable-multilib --disable-libmudflap --disable-libssp --disable-libgcj --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 4.1.2 (Gentoo 4.1.2) Ok, and Debian is building with gcc 4.2: $ gcc -v Using built-in specs. Target: alpha-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --disable-libssp --with-long-double-128 --enable-checking=release --build=alpha-linux-gnu --host=alpha-linux-gnu --target=alpha-linux-gnu Thread model: posix gcc version 4.2.3 20071014 (prerelease) (Debian 4.2.2-3) $ Any chance of testing with a newer version of gcc on Gentoo as well to help confirm that the compiler is to blame? Bottom line is that I see nothing here that the Postgres project can fix --- these are library and compiler bugs. Right; though whereas the floor() bug could simply be ignored since it will be fixed in glibc (or the kernel) when the time comes, if the other regressions are the result of a compiler problem then ignoring those failures would indeed mean distributing broken binaries. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [BUGS] Test suite fails on alpha architecture
Falk Hueffner [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
It looks to me like Debian's compiler must be allowing the division
instruction to be speculatively executed before the if-test branch
is taken.
Can you create a stand-alone testcase for this?
I don't have access to a machine on which the failure occurs, but
perhaps Martin can try it. I'd think it'd be pretty easy, say
#include stdio.h
#include stdlib.h
void
ereport(const char *msg)
{
fprintf(stderr, %s\n, msg);
exit(0);
}
int
main(int argc, char **argv)
{
int arg1 = atoi(argv[1]);
int arg2 = atoi(argv[2]);
int result;
if (arg2 == 0)
ereport(division by zero);
result = arg1 / arg2;
printf(%d\n, result);
return 0;
}
cc -g -O2 -fPIC -fno-strict-aliasing -mieee -D_GNU_SOURCE bug.c
./a.out 1 0
I would not be surprised at all if it's compile-switch dependent; these
look to be the switches Martin tested with.
regards, tom lane
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [BUGS] Test suite fails on alpha architecture
On Wed, Nov 07, 2007 at 02:41:51PM -0500, Steve Langasek wrote: On Wed, Nov 07, 2007 at 01:49:53PM -0500, Tom Lane wrote: All the other diffs that Martin showed are divide-by-zero failures, and I do not see any of them on Gentoo's machine. I think that this must be a compiler bug. The first example in his diffs is just select 1/0, which executes this code: int32arg1 = PG_GETARG_INT32(0); int32arg2 = PG_GETARG_INT32(1); int32result; if (arg2 == 0) ereport(ERROR, (errcode(ERRCODE_DIVISION_BY_ZERO), errmsg(division by zero))); result = arg1 / arg2; It looks to me like Debian's compiler must be allowing the division instruction to be speculatively executed before the if-test branch is taken. Perhaps it is supposing that this is OK because control will return from ereport(), when in fact it will not (the routine throws a longjmp). Since we've not seen such behavior on any other platform, however, I suspect this is just a bug and not intentional. FWIW the Gentoo machine is running $ gcc -v Using built-in specs. Target: alpha-unknown-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.1.2/work/gcc-4.1.2/configure --prefix=/usr --bindir=/usr/alpha-unknown-linux-gnu/gcc-bin/4.1.2 --includedir=/usr/lib/gcc/alpha-unknown-linux-gnu/4.1.2/include --datadir=/usr/share/gcc-data/alpha-unknown-linux-gnu/4.1.2 --mandir=/usr/share/gcc-data/alpha-unknown-linux-gnu/4.1.2/man --infodir=/usr/share/gcc-data/alpha-unknown-linux-gnu/4.1.2/info --with-gxx-include-dir=/usr/lib/gcc/alpha-unknown-linux-gnu/4.1.2/include/g++-v4 --host=alpha-unknown-linux-gnu --build=alpha-unknown-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-libunwind-exceptions --disable-multilib --disable-libmudflap --disable-libssp --disable-libgcj --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 4.1.2 (Gentoo 4.1.2) Ok, and Debian is building with gcc 4.2: $ gcc -v Using built-in specs. Target: alpha-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --disable-libssp --with-long-double-128 --enable-checking=release --build=alpha-linux-gnu --host=alpha-linux-gnu --target=alpha-linux-gnu Thread model: posix gcc version 4.2.3 20071014 (prerelease) (Debian 4.2.2-3) $ Any chance of testing with a newer version of gcc on Gentoo as well to help confirm that the compiler is to blame? In Gentoo the testcase gives the same division by zero under these gcc versions: Current Stable: gcc version 4.1.2 (Gentoo 4.1.2 p1.0.2) Current Testing: gcc version 4.2.2 (Gentoo 4.2.2 p1.0) Feel free to add me if you have an open bug for this, in order to test anything you need or provide some more information about our platform. Thanks. Bottom line is that I see nothing here that the Postgres project can fix --- these are library and compiler bugs. Right; though whereas the floor() bug could simply be ignored since it will be fixed in glibc (or the kernel) when the time comes, if the other regressions are the result of a compiler problem then ignoring those failures would indeed mean distributing broken binaries. -- Jose Luis Rivero [EMAIL PROTECTED] Gentoo/Doc Gentoo/Alpha -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [BUGS] Test suite fails on alpha architecture
Hi *: Martin Pitt escribió: Hi, Tom Lane [2007-11-03 14:27 -0400]: Martin Pitt [EMAIL PROTECTED] writes: The testsuite of 8.3 beta 2 fails on the Alpha architecture (versions up to 8.2 worked fine). We redid some of the float error handling for 8.3, in hopes of getting closer to the IEEE standard behavior for NaNs and infinities and so on. I guess that isn't working on your Alpha. I have a vague recollection that Alphas use non-IEEE floats so maybe this is not too surprising. Can you grant one of us access to the machine to work on it? I don't own any alpha machine, but maybe Frank, Steven, or anyone from the Debian alpha porter list can create a temporary account for you? Or poke into it yourself? There is no developer accessible alpha porter box for Debian unfortunately. :( Since Debian is having some problems with its alpha development machine, the Gentoo/Alpha port is happy to offer some help with this problem. We can provide with shell account access (or even a chroot) in our development machine (AlphaServer ES40) for debugging this PostgreSQL bug. If it only happens on Debian, I could create a debian chroot for testing. Gentoo/Alpha Team can be reached by mail: [EMAIL PROTECTED] or by IRC in Freenode #gentoo-alpha. Thanks and feel free to ask if you need something more. -- Jose Luis Rivero [EMAIL PROTECTED] Gentoo/Doc Gentoo/Alpha -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [BUGS] Test suite fails on alpha architecture
=?ISO-8859-1?Q?=22Jos=E9_Luis_Rivero_=28yoswink=29=22?= [EMAIL PROTECTED] writes: Since Debian is having some problems with its alpha development machine, the Gentoo/Alpha port is happy to offer some help with this problem. We can provide with shell account access (or even a chroot) in our development machine (AlphaServer ES40) for debugging this PostgreSQL bug. If it only happens on Debian, I could create a debian chroot for testing. I'm guessing that it's specific to Alpha (and maybe glibc) but not any particular Linux distro. So let's try Gentoo first, and then Martin can check if the fix works for Debian. If you could set me up a shell account accessible by ssh, I should have time to poke at this tomorrow. I don't need root access but will need all the usual C development tools (gcc, gdb, etc). Thanks for helping! regards, tom lane -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [BUGS] Test suite fails on alpha architecture
Hi! On Tue, 06 Nov 2007, Tom Lane wrote: If you could set me up a shell account accessible by ssh, I should have time to poke at this tomorrow. I don't need root access but will need all the usual C development tools (gcc, gdb, etc). Just send me a (preferably signed) mail with desired username and SSH-PubKey. Regards, Tobias -- In the future, everyone will be anonymous for 15 minutes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [BUGS] Test suite fails on alpha architecture
On Tue, Nov 06, 2007 at 12:52:34PM -0500, Tom Lane wrote: =?ISO-8859-1?Q?=22Jos=E9_Luis_Rivero_=28yoswink=29=22?= [EMAIL PROTECTED] writes: Since Debian is having some problems with its alpha development machine, the Gentoo/Alpha port is happy to offer some help with this problem. We can provide with shell account access (or even a chroot) in our development machine (AlphaServer ES40) for debugging this PostgreSQL bug. If it only happens on Debian, I could create a debian chroot for testing. I'm guessing that it's specific to Alpha (and maybe glibc) but not any particular Linux distro. It may be specific to particular versions of glibc and the kernel. At least one of the test regressions is actually due to the bug described in http://lists.debian.org/debian-alpha/2007/10/msg00014.html; I haven't dug into the rest of the failures further at this point. But if it can be reproduced on other distros as well, all the better. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [BUGS] Test suite fails on alpha architecture
Hi, Tom Lane [2007-11-03 14:27 -0400]: Martin Pitt [EMAIL PROTECTED] writes: The testsuite of 8.3 beta 2 fails on the Alpha architecture (versions up to 8.2 worked fine). We redid some of the float error handling for 8.3, in hopes of getting closer to the IEEE standard behavior for NaNs and infinities and so on. I guess that isn't working on your Alpha. I have a vague recollection that Alphas use non-IEEE floats so maybe this is not too surprising. Can you grant one of us access to the machine to work on it? I don't own any alpha machine, but maybe Frank, Steven, or anyone from the Debian alpha porter list can create a temporary account for you? Or poke into it yourself? There is no developer accessible alpha porter box for Debian unfortunately. :( Thank you, Martin -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [BUGS] Test suite fails on alpha architecture
On Sat, Nov 03, 2007 at 06:32:34PM -0400, Martin Pitt wrote: Tom Lane [2007-11-03 14:27 -0400]: Martin Pitt [EMAIL PROTECTED] writes: The testsuite of 8.3 beta 2 fails on the Alpha architecture (versions up to 8.2 worked fine). We redid some of the float error handling for 8.3, in hopes of getting closer to the IEEE standard behavior for NaNs and infinities and so on. I guess that isn't working on your Alpha. I have a vague recollection that Alphas use non-IEEE floats so maybe this is not too surprising. Can you grant one of us access to the machine to work on it? I don't own any alpha machine, but maybe Frank, Steven, or anyone from the Debian alpha porter list can create a temporary account for you? I'm not sure how we handle that for our experimental buildds. Admins? Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [BUGS] Test suite fails on alpha architecture
On 3 Nov 2007, at 10:32 pm, Martin Pitt wrote: Hi, Tom Lane [2007-11-03 14:27 -0400]: Martin Pitt [EMAIL PROTECTED] writes: The testsuite of 8.3 beta 2 fails on the Alpha architecture (versions up to 8.2 worked fine). We redid some of the float error handling for 8.3, in hopes of getting closer to the IEEE standard behavior for NaNs and infinities and so on. I guess that isn't working on your Alpha. I have a vague recollection that Alphas use non-IEEE floats so maybe this is not too surprising. Can you grant one of us access to the machine to work on it? I don't own any alpha machine, but maybe Frank, Steven, or anyone from the Debian alpha porter list can create a temporary account for you? Or poke into it yourself? There is no developer accessible alpha porter box for Debian unfortunately. :( There's one at Sanger. Sadly, it's been waiting for almost a year for the DSA's to actually set it up so people can use it. Tim -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
