Re: manipulating FPU rounding modes on alpha
On Mon, Sep 10, 2007 at 12:44:56PM -0400, Lennart Sorensen wrote:
> I will give it a shot.
Build fails running 2.6.22, or rather the test fails.
zero : ERROR
+inf : ERROR
-inf : ERROR
near : ERROR
But if I then load the 'math_emu' module and repeat the command I get:
zero : ok
+inf : ok
-inf : ok
near : ok
So the math_emu feature in the kernel has something to do with it.
Looking at the kernel description for math_emu on the alpha, it looks
like a very serious error for debian to have made it modular instead of
built in, since the purpose of the module is not to emulate an FPU like
it is on x86 or arm, but instead to provide IEEE compliant floating
point on the alpha.
This is the description on 2.6.18:
tristate "Kernel FP software completion" if DEBUG_KERNEL && !SMP
default y if !DEBUG_KERNEL || SMP
This option is required for IEEE compliant floating point arithmetic
on the Alpha. The only time you would ever not say Y is to say M in
order to debug the code. Say Y unless you know what you are doing.
No wonder the floating point stuff goes broken when that isn't loaded.
Now this feature only applies to alphas below EV6 (So since mine as an
EV56 it needs the math_emu feature to generate IEEE compliant floating
I also see an indication that if you call gcc with the -mieee option, it
will generate code that runs on any alpha correctly, without relying on
the kernel to solve the problem for it.
I guess the real answer is that either debian should switch MATH_EMU
back to 'y' as highly recomended by the comment in the kernel, or we
need something to ensure that any alpha with a CPU less than an EV6
automatically loads the module at boot (especially the buildd's).
Perhaps calling it math_emu is a bad idea on the alpha, since it is more
of an "emulate proper ieee floating point", but certainly I think it is
wrong to make it a module in the debian kernels, since only 21264 and
higher alphas work correctly now, unless you know to load the math_emu
module. There isn't even a note in the linux-image changelog indicating
that this change was made. Amazingly this was filed in the past against
2.6.18 as bug 411813, and apparently lost again in later kernels. It
appears it is going to be fixed in the next 2.6.22 kernel release.