From: David Huggins-Daines <dhd@linuxcare.com>
To: parisc-linux@thepuffingroup.com
Subject: Re: [parisc-linux] floating point exception error
Date: 28 Sep 2000 11:41:51 -0400 [thread overview]
Message-ID: <87snqk1q2o.fsf@linuxcare.com> (raw)
In-Reply-To: David Huggins-Daines's message of "27 Sep 2000 16:41:38 -0400"
David Huggins-Daines <dhd@linuxcare.com> writes:
> We probably need more complicated FPU trap logic in the kernel in
> order to deliver exceptions in the proper POSIX and IEEE manner.
Yes, I'm handwaving. Of course POSIX says nothing about this, and I
don't exactly know what IEEE says about delivery of exceptions (just
that certain exception flags need to exist).
The FPU support that I've put in glibc is specified by ANSI C99 (not
C89 as far as I can tell), and is found in <fenv.h>
A cursory comparison of this header file on GNU libc 2.1.92 vs. HP/UX
11 reveals that HP/UX implements the same functions, except for
feenableexcept() which does not exist on HP/UX. The definition of
fenv_t is different from what I expected in that it does not include
the exception status registers (LSW of %fr0, %fr1-%fr3), only the
status word (MSW of %fr0). Also, I notice that the FE_* macros refer
to the flag bits rather than the enable bits in the floating point
status word, and are different in wide mode (!).
> I would appreciate it if someone from HP could comment on this -
> how does HP/UX handle this?
Just for the record, this is what the mawk configure test reports on
HP/UX 11:
checking handling of floating point exceptions
division by zero does not generate an exception
overflow does not generate an exception
math library supports ieee754
Which is the same as reported by Linux/i386.
Linux/alpha without -mieee reports:
checking handling of floating point exceptions
division by zero generates an exception
overflow does not generate an exception
(and then some warnings at the end)
Whereas with -mieee we get the same results as HP/UX 11 and
Linux/i386.
So it looks like we are either not managing to set up %fr0 properly on
process startup or we are mangling it in the kernel or libc somewhere
along the way. I'll investigate further today.
--
dhd@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.
next prev parent reply other threads:[~2000-09-28 15:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-09-27 19:55 [parisc-linux] floating point exception error Matt Taggart
2000-09-27 20:41 ` David Huggins-Daines
2000-09-28 15:41 ` David Huggins-Daines [this message]
2000-09-29 18:28 ` David Huggins-Daines
2000-09-29 18:56 ` John David Anglin
2000-09-29 19:07 ` David Huggins-Daines
2000-09-29 19:41 ` David Huggins-Daines
2000-10-02 0:33 ` John David Anglin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87snqk1q2o.fsf@linuxcare.com \
--to=dhd@linuxcare.com \
--cc=parisc-linux@thepuffingroup.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.