Date: Tue, 16 May 2000 14:28:55 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Dieter Buerssner cc: djgpp-workers AT delorie DOT com Subject: Re: Math functions In-Reply-To: <200005151237.PAA11341@is.elta.co.il> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by delorie.com id GAA04646 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 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.