Re: good news and bad news on floating-point problems
On Wed, 8 Jul 1998, James D. Freels wrote:
> The good news first:
> When patched with the DEC-supplied patches, kernel 2.0.34 and when the
> CONFIG_MATHEMU=y switch is set in linux/.config, the kernel 2.1.208
> both produce the desired result for a floating divide by zero.
> Namely, with the -mieee switch set, a floating divide by zero will
> show as "Inf." when printed. Further, the same test code when
> compiled with the -fpe1 switch on DEC-Unix f77, will also produce the
> correct result. Even further, with the correct dynamic libraries
> installed, the -non_shared switch is not necessary.
> The bad news:
> My large, production, legacy code when compiled with the same switches
> on either side (Linux or DEC-Unix) core-dumps on floating-point
> exceptions. The same code runs correctly on DEC-Unix with -fpe1
> switch enabled. What is really odd is that at one time, with "some"
> kernels, this did not occur and the code ran correctly (both "g77
> -mieee" compiled or "f77 -fpe1" compiled).
> I guess there are listed 5 floating exceptions that can occur with
> divide by zero being one of them. Apparently the -mieee and/or the
> MATHEMU does not catch all of the possibilities.
Actually there are six fp exceptions, three which can be disabled and
three which cannot.
>From the Alpha Architecture Handbook, section 4.7.6:
There are six exceptions that can be generated by floating-point operate
instructions, all signalled by an arithmetic exception trap. These
Division by zero
Underflow, may be disabled
Inexact result, may be disabled
Integer overflow (conversion to integer only), may be disabled
The invalid exception occurs when trying to compute with a NaN or Inf value.
Alpha has *no* hardware support for any of these floating exceptions and
requires software traps for strict IEEE compliance.
I've done some testing on IEEE modes under Linux/Alpha but haven't yet
tried all cases. I'm using gcc 2.8.1 and Linux 2.1.105 for now and it
looks pretty good though.
If you could somehow compile a test case that throws SIGFPE with -mieee
I'd like to look at it.
Can you open the core file in gdb and identify the insn that causes SIGFPE?
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com