Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 5 Oct 1997 03:09:38 +1000
From:      Bruce Evans <bde@zeta.org.au>
To:        bde@zeta.org.au, cracauer@cons.org
Cc:        freebsd-current@FreeBSD.ORG, jkh@time.cdrom.com, Matthew.Thyer@dsto.defence.gov.au, ports@FreeBSD.ORG
Subject:   Re: xlock: caught signal 8 while running galaxy mode.
Message-ID:  <199710041709.DAA00343@godzilla.zeta.org.au>

next in thread | raw e-mail | index | archive | help
>> Dying screensavers are a good example of why trapping on FP exceptions
>> is good: FP exceptions are often due to bugs, and trapping helps find
>> the bugs.
>
>Sure. But most free (and commercial) software has been developed and
>tested on machines that don't trap.

Most commercial (and free?) software has been developed for DOS and
Windows :-).  I'm not sure what Microsoft C libraries do, but Borland
C libraries trap by default.

>> >> There are bugs in our gcc that make relying on FP exceptions handled
>> >> right dangerous and Bruce Evans felt it is better to through the
>> >> signal, so that people get aware of the problem.
>> 
>> I don't know of any bugs in gcc related to FP exceptions.
>> ...
>> How is our gcc worse than NetBSD's or Linux's?
>
>s/gcc/FreeBSD/
>
>If I remeber correctly (and the one who told me was probably you), one
>can't disable FP exceptions easily without hiding stack exceptions as
       mask
>well.

Also, one can't mask FP exceptions without masking FP -> int conversion
exceptions (like the one in xlock) as well.

>Behaviour for compile-time and runtime evaluation is different
>in quite a few places.

This is unrelated to FP exceptions.

>There was something that we can't set errno (as
>we should accourding to POSIX) if we use IEEE non-trapping.

No, the library problem is that we don't set errno (as we should
according to ANSI) if we use "IEEE_MODE" in lib/msun (as we do now),
and we wouldn't return IEEE-ish exception values (except for most cases
involving HUGE_VAL = +Inf) if we used "POSIX_MODE" in lib/msun.

>Correct me if I'm wrong, but if we don't trap, these's little point in
>setting errno, isn't it? As I understand, we don't have working errno
>support anyway. So there's nothing to loose.

If we trap (as we do now), then the correct value for errno after a
call to a math functions is unimportant since code that checks it is
unreachable, but if we didn't trap then the code would be reachable,
so it is important for errno to be correct.

>[...]
>> I decided not to commit the change to the control word until someone
>> fixes the error handling in lib/msun.
>
>Well, is there any agreement which standard to follow? Is plain IEEE
>reasonable?

No, not yet (perhaps after C9X?).  It is also not fully implemented
by gcc.

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710041709.DAA00343>