Mail Archives: djgpp-workers/2000/05/16/07:11:55
On Mon, 15 May 2000, Dieter Buerssner wrote:
> > 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.
>
> This would only be a problem, when the FPU instruction would generate
> different results, depending on the exception flags.
No, that's not what I meant.
Suppose that a certain FP instruction, FBAR, produces a NaN when its
argument is zero and the invalid operation exception is masked.
Suppose that some library function, `fbar', uses FBAR internally. And
suppose that, for some good reason, we want `fbar' to return Inf for
a zero argument. In such a case, we cannot allow a free run of the
FPU in the hope that, since the exceptions are masked, it will produce
the correct result for us. We must manually examine the argument
*before* FBAR is issued, and if the argument is zero, manually to
assign Inf to the result.
> When you "silently" return a NaN, say by log(-1.0), the bit will not
> be set in the status word.
Are you sure? The Intel manual seems to say otherwise: it says that
any invalid operation sets the appropriate bit in the status word.
> A NaN can dissapear at least by the following functions: copysign,
> signbit, pow, fmax, fmin .... (This behaviour is demanded by C99.)
IMHO these are not important cases, and we don't comply to these
requirement yet anyway. I think for all practical purposes you can
assume that a NaN stays, and so the probability of catching it is very
close to 100%.
> Also, code that only compares a produced NaN, will loose it. Or
> something like:
>
> double x, y, z;
> /* assume x is NaN */
> z = (x < y) ? x : y;
How does this lose? z is not a NaN, but y (or x) still is, and you can
find it.
> Also, a signal handler for SIGFPE is portable
``Portable'' in what sense? The fact that a library recognizes SIGFPE
as a known symbol, and that you can call `signal' with SIGFPE as an
argument, does not yet tell anything about what will actually happen
when you call sqrt(-1).
> > The main motivation for avoiding exceptions was the ANSI Standard, as
> > I already said.
>
> I cannot find this in my draft to the C 99.
I meant C89. C99 was not yet finalized when Eric started his work.
> F.9.3.7 The log functions
> log(±0) returns -Infinity and raises the divide-by-zero exception.
I believe that you interpret the word ``exception'' too literally
here. The C99 standard does not specify what does ``exception''
mean. In particular, it doesn't say that it is related in any way to
the ``FP exceptions'' that Intel CPUs support. As far as I could see,
it doesn't even say that the result of these ``exceptions'' is a
SIGFPE that is delivered to the program.
So, for all practical purposes, we could maintain that setting an
appropriate flag in the FPU's status word is the ``exception'' that
C99 is talking about. In which case we comply with the standard even
if we don't actually trigger an FP exception in the Intel sense.
> "Swallowing" these exceptions, would mean, that there is no interest
> in beeing IEEE compatible, as suggested by the C standard.
Since the status word has an appropriate bit set, we don't swallow any
exceptions. We simply don't generate a signal out of them, but that's
another matter.
> > semi-work on Windows 9X, they are a PITA under a debugger, etc.
>
> (Don't now PITA).
PITA = Pain In The A**.
> In my experience, the debugger will jump to the correct code line.
Exceptions in the debuggee just barely work. They didn't work at all
before v2.03. Now they do, thanks to work by Pierre, Robert and
Andris, but I'm pretty sure that a sufficiently complicated FP program
that uses SIGFPE extensively will work funny under a debugger. I have
several such strange effects I've seen inside a debugger on my todo.
> I now have a better self written test program, that I can contribute.
Please do.
> > > 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.
>
> I think, I had the motivation to fix those bugs, and contibuted my
> code, but there was no feedback at all.
I didn't mean you, I meant those who worked on DJGPP development. I
think every release should include extensive testing of the library,
and our only tool for that--djtst--needs a lot of work to make it more
full and automatic.
> > > 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.
>
> I just looked. I.e. the inline log function IHMO has exactly the
> problem I described above.
What problem is that? If you mean how to tell GCC that inline
assembly uses several slots in the FP stack, perhaps there is no
problem if glibc doesn't care to do anything. If you think there
might be a problem, perhaps a message posted to glibc and/or gcc
forum(s) might be a good idea.
- Raw text -