Mail Archives: djgpp-workers/2000/05/15/07:07:32
On 15 May 00, at 10:38, Eli Zaretskii wrote:
> On Sun, 14 May 2000, Dieter Buerssner wrote:
> 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.
This would only be a problem, when the FPU instruction would generate
different results, depending on the exception flags. Are there such
cases?
> > 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 actually believe, that anybody, who would unmask the exceptions,
will know what he does. If not, he probably will be lucky, because he
will probably find a bug in his code.
> > 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.
When you "silently" return a NaN, say by log(-1.0), the bit will not
be set 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.)
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;
> > 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.
I can't remember. Perhaps Cray, VMS, Convex or some IBM mainframe.
Matherr is not in Standard C, so it is unportable by definition. OTOH
C99 has means, to support IEEE floating point environments. Also, a
signal handler for SIGFPE is portable, when it just sets a flag
(which will be enough to detect error conditions).
> > 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.
I cannot find this in my draft to the C 99. To the contrary, I find,
again for my example of log:
F.9.3.7 The log functions
— log(±0) returns -Infinity and raises the divide-by-zero exception.
— log(1) returns +0.
— log(x) returns a NaN and raises the invalid exception if x <0.
— log(+Infinity) returns +Infinity.
"Swallowing" these exceptions, would mean, that there is no interest
in beeing IEEE compatible, as suggested by the C standard. I
personaly find this a pity. (Almost?) Every new machine supports
IEEE-754 floating point environments. This can be a great advantage
for numerical code. Why ignore it?
> > 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.
Then again, either the users don't know what they do, and get what
they deserved, or they should feel happy, that they found a bug. A
symify will point to the correct line.
I even think, that much software is not aware of NaNs and Infs, and
any code, that produces these special values is probably buggy.
> > 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,
You are correct. I only checked 2.03.
> > 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,
Then, one has no other choice as to leave them masked.
> semi-work on Windows 9X, they are a PITA under a debugger, etc.
(Don't now PITA). In my experience, the debugger will jump to the
correct code line.
> > > 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.
They all have a compile time symbol LDOUBLE. When LDOUBLE is defined
as 1, they will test the long double versions of the math functions.
As I said, they need some polishing. Adding long double support was
actually the main thing, I did with the test programs, I found on the
net (plus some "ANSIfying".) The math library that I contributed, had
already almost all math functions in long double.
I now have a better self written test program, that I can contribute.
> > 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. After that I lost interest,
but found it again ...
> > 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. (The code is essentially the same, as the
code I sent at the start of this thread.)
Regards,
Dieter Buerssner
- Raw text -