Re: Test suite fails on alpha architecture

Steve Langasek <vorlon(at)debian(dot)org> 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:

int32 arg1 = PG_GETARG_INT32(0);
int32 arg2 = PG_GETARG_INT32(1);
int32 result;

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