Mail Archives: djgpp-workers/2000/05/12/15:53:26
> From: "Dieter Buerssner" <buers AT gmx DOT de>
> Date: Fri, 12 May 2000 14:09:52 +0200
>
> The setting of errno seems not to be required by the latest C Standard.
C89 clearly requires it. I don't think it's wise to drop support for
C89 while adding support for C99. The code is already written, and
IMHO setting errno is a good feature: it makes error checking easy and
predictable (as opposed to using `isnan' and similar functions).
Anyway, the only saving would be a single integer instruction that
stores a value in errno.
> To me, it seems redundant, because the error can already be detected
> by the return value.
I think our discussions "Re: Unnormals?" show how very much
NON-trivial are these tests, what with all the different NaN types
that Intel dumps on us.
> The checking code for the mathfunctions silently loads a NaN into the
> top of the FPU-stack, when a domain error occures. This has IHMO a
> significant disadvantage. When setting up the FPU control word, to
> get exceptions for (say) overflow, div by zero and invalid (which I
> find useful while debugging), the functions won't raise that
> exception.
AFAIK, the latest version of GCC emit inline code for many standard
math functions. I'm positive about `sqrt' and `exp', but I'd expect
some others, like `sin', `cos', and `atan', to be handled in a similar
way. The inline code issues the FP instruction, and if it produces
abnormal results (as indicated by the status word), the library
function is called to handle this.
If I'm right, then if you unmask the exception, you will get a SIGFPE,
like you want, from the the inline code.
But in general, yes, the math functions (and the DJGPP runtime in
general) are not meant to be used with exceptions unmasked. If you
want that, you'll probably need to write custom debugging
replacements for library functions.
Note that if you link against libm.a, the exceptions won't be
triggered as well.
> So, I think, the easier implementation of my_log is preferrable. It
> will always return the same values, but won't set errno.
This is a step backwards, IMHO. The original math functions written
by DJ which where in use up to and including v2.02 were implemented
like you suggest. We replaced them with Eric's versions because they
complied with ANSI C while still being very fast and accurate; before
that, the only way to get ANSI behavior was to link against libm.a and
pay the price in performance.
> Anyway, is there interest in long double versions of the math
> functions?
Yes, since C99 requires them.
> Do you prefer, to not raise exceptions?
Yes, absolutely. At least for production code, which is what libc.a
is for.
> Some functions are a compromise between correctness up to the last
> bit and speed. I.e. the argument reduction code for the trig
> functions is not as sophisticated as the argument reduction code in
> libm, but uses additional precision for intermediate results (from
> Stephen Moshiers cephes), and can be much faster than the
> corresponding code in libm. Similar for powl. I also have functions,
> that are missing right now, like expm1[l] or log1p[l], rint[l] ...
Please post the list of the functions, and let's talk about them.
- Raw text -