Date: Mon, 15 May 2000 10:38:32 +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: <200005141214.PAA00835@is.elta.co.il> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Sun, 14 May 2000, Dieter Buerssner wrote: > > We avoid exceptions to have control on what values are returned in > > abnormal cases: the value we return is not always the FPU's masked > > response to the appropriate exception. If you let the FPU to do its > > thing, you cannot have that kind of control on the return value. > > I don't understand what you mean here by "FPU's masked response to > the appropriate exception". 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. > > > Could you please explain, why you dislike the exceptions. > > > > They are more trouble than they help, especially in the DJGPP > > environment. See the thread about FP exceptions being delivered to > > the parent program on Windows 9X, for example. > > 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 agree that sometimes enabling exceptions in the library could be a debugging aid. We could have some global variable that would let math functions bypass the argument-checking code and go ahead and trigger exceptions if they aren't masked. But I don't think this should be done by default. Personally, I prefer to use more portable techniques for debugging FP code (`matherr', a good debugger, etc.), but YMMV. > > > Besides the point, I made for debugging, they > > > can also be useful in interactive numerical programs. Set a flag in > > > a signal handler for SIGFPE, that can be checked at strategical > > > places, > > > > You can test for NaN's and Inf's at the same places. > > 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. > > If you really > > want fine control on what happens in abnormal cases, link with -lm and > > write a custom `matherr' function; this is more portable than > > exceptions, and also easier. > > 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. > 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. The other motivation was to let users have a predictable environment where things didn't crash in mysterious ways. > > Also, most people don't even know how to write a SIGFPE handler that > > will avoid triggering another SIGFPE when it returns. And on NT you > > cannot catch SIGFPE at all (I'm not sure what happens on Windows2000). > > 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. > 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, I've seen quite a few of them, and c.o.m.d. had a significant number of reports that involved a SIGFPE. > (In 1x some were enabled, and IIRC, they couldn't be caught by a > signal handler). DJGPP v1.x didn't support signals at all. So you couldn't install a signal handler for *any* signal. > 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, semi-work on Windows 9X, they are a PITA under a debugger, etc. Who knows what we will find in Windows 2000 and in Millenium? > I have seen the threat about make, and I wondered, how this can > happen. Looks like a plain Windows bug: Int 75h is delivered to the wrong program. > > 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. > 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. Lack of motivation doesn't mean we should default on having test programs. In fact, if a new function is submitted for addition to the library without a test program, I'd wonder how did the author verify id works as advertised. > 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.