Date: Fri, 12 May 2000 16:27:38 -0400 (EDT) Message-Id: <200005122027.QAA14913@indy.delorie.com> From: Eli Zaretskii To: "Dieter Buerssner" CC: djgpp-workers AT delorie DOT com In-reply-to: <200005121101.HAA05022@delorie.com> (buers@gmx.de) Subject: Re: Math functions References: <200005121101 DOT HAA05022 AT delorie DOT com> Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > From: "Dieter Buerssner" > 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.