Mail Archives: djgpp-workers/2000/05/15/02:12:49
On Sun, 14 May 2000, Dieter Buerssner wrote:
> > We avoid exceptions to have control on what values are returned in
> > abnormal cases: the value we return is not always the FPU's masked
> > response to the appropriate exception. If you let the FPU to do its
> > thing, you cannot have that kind of control on the return value.
>
> I don't understand what you mean here by "FPU's masked response to
> the appropriate exception".
The masked response is what the FPU produces when the operands cause
an exception, but that exception is masked by the appropriate bit of
the control word.
The Intel manual defines what is produced in each such case for every
FP instruction. In some cases, our functions produce results for
abnormal operands which are different from what Intel defines.
> > > Could you please explain, why you dislike the exceptions.
> >
> > They are more trouble than they help, especially in the DJGPP
> > environment. See the thread about FP exceptions being delivered to
> > the parent program on Windows 9X, for example.
>
> I still cannot see the disadvantage. The exceptions are all masked by
> default. If you unmask them, you probably know what you do.
I don't think we should rely on exceptions being masked. Someone
could unmask them to debug their application code, without expecting
the library functions to trigger exceptions.
I agree that sometimes enabling exceptions in the library could be a
debugging aid. We could have some global variable that would let math
functions bypass the argument-checking code and go ahead and trigger
exceptions if they aren't masked. But I don't think this should be
done by default.
Personally, I prefer to use more portable techniques for debugging FP
code (`matherr', a good debugger, etc.), but YMMV.
> > > Besides the point, I made for debugging, they
> > > can also be useful in interactive numerical programs. Set a flag in
> > > a signal handler for SIGFPE, that can be checked at strategical
> > > places,
> >
> > You can test for NaN's and Inf's at the same places.
>
> Unfortunately, you can't. NaNs may dissapear by various means.
AFAIK, a NaN, once it appears, is dragged through all the FP
instructions. There's also the status word.
> > If you really
> > want fine control on what happens in abnormal cases, link with -lm and
> > write a custom `matherr' function; this is more portable than
> > exceptions, and also easier.
>
> Matherr is not not portable in my experience.
What system doesn't have it? I've seen it on every Unix box. Even
Turbo C 2.0 has it.
> When I coded the math functions in 1993, I did the non-exception-
> throwing return method. I came to the conclusion, that this is wrong.
> Now, you are telling me, that this was correct ;)
The main motivation for avoiding exceptions was the ANSI Standard, as
I already said. The other motivation was to let users have a
predictable environment where things didn't crash in mysterious ways.
> > Also, most people don't even know how to write a SIGFPE handler that
> > will avoid triggering another SIGFPE when it returns. And on NT you
> > cannot catch SIGFPE at all (I'm not sure what happens on Windows2000).
>
> Who cannot write the signal handler, propbably cannot unmask the
> exceptions.
The libc docs include an example of how to unmask them. They only
need to paste it into their code.
> Is there a misunderstanding? I never have seen floating
> point exceptions with DJGPP 2x when not especially asking for them.
Which 2.x versions? Before v2.02, when invalid operation exceptions
were not masked, I've seen quite a few of them, and c.o.m.d. had a
significant number of reports that involved a SIGFPE.
> (In 1x some were enabled, and IIRC, they couldn't be caught by a
> signal handler).
DJGPP v1.x didn't support signals at all. So you couldn't install a
signal handler for *any* signal.
> Is the default masking of the exceptions unreliable?
I think the entire handling of exceptions in general, and FP
exceptions in particular is too fragile in DJGPP to depend on it too
heavily. FP exceptions don't work on NT, semi-work on Windows 9X,
they are a PITA under a debugger, etc. Who knows what we will find in
Windows 2000 and in Millenium?
> I have seen the threat about make, and I wondered, how this can
> happen.
Looks like a plain Windows bug: Int 75h is delivered to the wrong
program.
> > If you could add at least some of the test programs to djtst, it would
> > be even better.
>
> There are already some of them in the tests directory.
I was talking about testing the long double versions. I don't think
we have test programs for that in djtst now.
> I fear, they were not of much help, because some bugs they found in
> 1994, were still left about a year ago.
It's a question of someone who has the time and motivation to fix the
problems. Lack of motivation doesn't mean we should default on having
test programs. In fact, if a new function is submitted for addition
to the library without a test program, I'd wonder how did the author
verify id works as advertised.
> But, more important, it uses 2 entries in the FPU stack, and even
> after carefully reading much documentation, I have not found a way to
> tell this to gcc.
You might try looking at the Linux version of math.h.
- Raw text -