[erlang-questions] Testing reliable floating points exeption fails on x86?

[Mikael Pettersson]

On Wed, 19 Sep 2007 15:29:28 +0400, Sergei Golovan wrote:
> Could someone explain me what 'reliable floating points exceptions'
> are and how their reliability is checked?

The ability to program the FPU so that e.g. overflows are reported
as signals instead of as +inf.

> I'm packaging erlang/OTP for Debian GNU/Linux using two erlang
> flavours: with and without HiPE (HiPE enabled architectures are i386
> (x86), amd64 (x86_64), powerpc and sparc). If I understand correctly,
> HiPE refuses to build if floating points exceptions are unreliable.

Correct for x86-32, x86-64, ppc32, and sparc32.
HiPE doesn't require FP exceptions on ARMv5b.

> I built erlang on x86 architecture many times and test for reliable fp
> exceptions never failed. But recently I've got a bugreport
> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=442965) where the
> test fails.
> 
> 1) Could it be that the test fails due to false negative (probably
> because it was run on x86_64 hardware, though I never managed to get
> it failed using both 32-bit and 64-bit kernel with 32-bit userland)?

There's no information in that Debian bug report apart from "it failed".
Most likely a compile-time error is causing fpe-test.c to fail.

FWIW, the HiPE group regularly does builds on Fedora-based x86-{32,64}
boxes without problems.

> 2) I'm tempted to disable this test in a Debian source package and
> undefine NO_FPE_SIGNALS only for 4 architectures mentioned above. Will
> this cause any harm if erlang is built without HiPE support (for those
> 4 arches there are two erts - with and without HiPE and users select
> which to use)? Or fp exceptions play certain role even in this case?

Floating-point arithmetic in the base BEAM system will be slower
if FP exceptions don't work.

The real solution is to debug the fpe-test.c failure on the
bug reporter's machine.

/Mikael