Date: Sun, 13 Jun 1999 11:06:15 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Eric Rudd cc: djgpp-workers AT delorie DOT com Subject: Re: libm sources from cyberoptics In-Reply-To: <375EAF11.AC19F985@cyberoptics.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Wed, 9 Jun 1999, Eric Rudd wrote: > Eli Zaretskii wrote: > > > Perhaps you could send me your object files. I will then compare them > > with mine, and we will take it from there. > > > > I have documentation for sincos and powi at home, which I'll send to you > > > tomorrow. > > Attached is a ZIP file with acos.o, asin.o, and the docs for sincos > and powi. 1) About asin and acos returning NaN: This seems to be due to some subtle differences between Gas from Binutils 2.7 and from 2.8.1, perhaps a bug in the former. Here's a fragment from the diffs between your asin.o and mine, as disassembled by `objdump': *************** *** 16,22 **** 0000001e d9 e8 fld1 00000020 de c2 faddp %st,%st(2) 00000022 d9 e8 fld1 ! 00000024 de e9 fsubrp %st,%st(1) 00000026 de c9 fmulp %st,%st(1) 00000028 d9 fa fsqrt 0000002a d9 f3 fpatan --- 16,22 ---- 0000001e d9 e8 fld1 00000020 de c2 faddp %st,%st(2) 00000022 d9 e8 fld1 ! 00000024 de e1 fsubp %st,%st(1) 00000026 de c9 fmulp %st,%st(1) 00000028 d9 fa fsqrt 0000002a d9 f3 fpatan This difference is the reason for the NaN, because instead of 1-x on the stack top after FSUBRP, like what you wanted, I get x-1. I'm not sure whether this is a bug in Gas or something else. One thing that confuses me is that I don't understand how your code was supposed to work. As far as I know, "fsubrp %st(1), %st" means "compute st - st(1), store the result in st, then pop the stack". But if this is true, then the result is gone after the stack is popped, no? Am I missing something here? There are other places in your code that use FSUBRP, but they all seem to assemble and work correctly, and they all use the FP registers in a way that is consistent with my understanding. For example, here is a fragment from acosh.S: fld1 /* 1 x x ln2 */ fsubrp %st,%st(1) /* x-1 x ln2 */ If my interpretation is correct, perhaps Gas 2.7 cannot cope with this situation, while Gas 2.8.1 silently emits the correct instruction? Anyway, even if this is because of a bug in Gas 2.7, it would be nice if the code could assemble with both versions, if that is possible without paying too much. 2) exp2 and exp10: I checked again, and they indeed set errno for the last two Elefunt tests. The original test program didn't do that because I failed to see that your source defines __pow2, not pow2, and the one-pass operation of the linker got me by linking in the old version from stock libc.a. Provided we find a solution to asin and acos, this leaves the following issues: - should denormals raise ERANGE? - should sqrt(-0.0) and log(-0.0) return the same as for positive zero? - should ceil, fabs, floor, and frexp set errno for NaN arguments? - storing old control word on the stack as opposed to static data, in those functions that modify the control word; - docs. I did whatever is necessary for the docs part. I send it for your review in a separate message. As for the other items, given the different opinions heard during the discussion about them, how would you suggest to go about each one? I have a few more comments/questions, after reading the code some more: - hypot doesn't set errno if the result overflows a double (e.g., if both arguments are DBL_MAX). Is this intentional? If not, perhaps the final value should be checked for being an Inf, and errno set to ERANGE. The same applies to ldexp. - log2 doesn't set errno to ERANGE for zero arguments, although log, log10 and log1p all do. I think log2 should behave like the other log's. - shouldn't pow set errno to ERANGE when the second argument is Inf and the result is an Inf? If we come to an agreement quickly enough, we might be in time for v2.03 (which is all but ready, except for some last-minute administrative changes in the build process that DJ asked me to do).