I am involved in a project called raspbian to produce a hard-float derivative of debian for the raspberry pi. Within this port we had problems with floating point exceptions while running the compiler. These problems were tracked down by masta (a freepascal upstream developer) to reversed logic in a routine for controlling floating point exception settings (attempting to disable an exception enabled it and vice-versa)

Howevr this then left the question of "why didn't I see this problem when preparing the freepascal packages for debian armhf?". The conclusion i've come to is that on the armv7 systems i've tested (a beagleboard XM running 2.6.39.2-x2 and an IMX53 quickstart board running ) the method freepascal uses for enabling vfp exceptions simply doesn't work.

I've written a small test program in C and inline assembler to demonstrate this. It tries to enable a number of floating point exceptions using a price of inline assembly I copied from the freepascal run time library and then does a division of the command line arguments. When I test this on a Pi running raspbian I get a floating point exception as expected.

./a.out 1 0
Floating point exception

but when I try it on my beagleboard XM or IMX53 board I don't get any exception.

./a.out 1 0
inf

Any vfp experts able to help get to the bottom of what is going on here?

peter green wrote

an IMX53 quickstart board running

That should have said running 3.2.0-2-mx5

According to
http://www.riscosopen.org/forum/forums/5/topics/850#posts-11105 the cpu on the BeagleBoard does not support trapping FPU exceptions.

http://sourceware.org/ml/libc-ports/2012-06/msg00021.html

I quote: "ARM VFPv3 and VFPv4 do not support trapping floating-point exceptions;
VFPv2, VFPv3U and VFPv4U do. The lack of support causes the glibc math/test-fenv test to fail on VFPv3 and VFPv4 systems.

The natural fix for that would be for fesetenv (FE_NOMASK_ENV) to fail on
hardware not supporting trapping exceptions. There is, however, no HWCAP
bit to indicate whether trapping floating-point exceptions is supported.
Could one be added to the kernel, or is there a good way fesetenv could detect this from userspace without a new HWCAP bit?"

Am I correctly intepreting this as "most current armv7 implementations don't support trapping exceptions but some of them do or may do in the future"?

If there is then IMO we do need to get the fix for the inverted exception masking
in freepascal into wheezy.

What it means it that, if the diagnosis of the problem is correct, then the package is broken on some supported armhf/armv7 hardware, just not the hardware you were testing on. (hardware with VFPv3U and VFPv4U) With the same bug.