Xref: news2.mv.net comp.os.msdos.djgpp:3395 From: Thomas Demmer Newsgroups: comp.os.msdos.djgpp Subject: Re: libm.a/linker *BUG* with test program Date: Fri, 03 May 1996 11:41:49 +0100 Organization: Lehrstuhl fuer Stroemungsmechanik Lines: 39 Message-ID: <3189E2ED.167E@LSTM.Ruhr-UNI-Bochum.De> References: <4mb7ob$3lf AT crc-news DOT doc DOT ca> <3189D117 DOT 41C6 AT LSTM DOT Ruhr-UNI-Bochum DOT De> NNTP-Posting-Host: bvb.lstm.ruhr-uni-bochum.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Thomas Demmer wrote: > > Richard Young wrote: > > > > I've discovered the following incorrect behavior with DJGPP version 2. > > The included test program illustrates the symptom of the behavior which > > seems to be as a result of including the math library. When I don't > > include libm.a the program does not crash. When I include libm.a the > > program crashes on the 3rd pow() call. It seems that it also is related > > to calling ldexp() too since just calling pow() many times works fine. > > > I tried your test program and found the same error. It looks as > if ldexp() doesn't clean up the co-proc stack. It leaves the "6" > on the stack and after some calls the stack is full. > -- After debugging a bit, I think the function scalbn() in src/libm/src/s_scalbn.s is the culprit. It is used in some other functions, too, so one might try to provoke crashes. But for that I'll have to learn a few things about the binary representation of floats first ;-)) Ciao Tom ************************************************************* * Thomas Demmer * * Lehrstuhl fuer Stroemungsmechanik * * Ruhr-Uni-Bochum * * Universitaetsstr. 150 * * D-44780 Bochum * * Tel: +49 234 700 6434 * * Fax: +49 234 709 4162 * * http://www.lstm.ruhr-uni-bochum.de/~demmer * *************************************************************