Re: Test suite fails on alpha architecture

On Wed, Nov 07, 2007 at 01:49:53PM -0500, Tom Lane wrote:
> 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.

> > 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)

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.
vorlon(at)debian(dot)org http://www.debian.org/