X-Spam-Check-By: sourceware.org From: "Dave Korn" To: References: <17190 DOT 86623 DOT qm AT web59108 DOT mail DOT re1 DOT yahoo DOT com> <007501c7860c$fc385bf0$2e08a8c0 AT CAM DOT ARTIMI DOT COM> Subject: RE: newlib?: pow function can produce incorrect results. Date: Tue, 24 Apr 2007 03:23:43 +0100 Message-ID: <007f01c78617$94644ec0$2e08a8c0@CAM.ARTIMI.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On 24 April 2007 03:14, Lev Bishop wrote: > On 4/23/07, Dave Korn wrote: >> On 24 April 2007 00:53, Cary R. wrote: >> >>> I had some more time to look into this and when the >>> simple C program I mentioned earlier uses variables >>> like the other program, incorrect results are >>> produced. I have attached this C/C++ program. I >>> certainly don't understand what is going on. I would >>> have expected pow to be pass-by value which should >>> make the two calls identical from a system standpoint, >>> but the results imply something different. Any >>> suggestions would be greatly appreciated. >> >> >> The notorious PR323. > > Nah, in this case it's just that gcc's __builtin_pow() is more > standards-compliant than newlib's pow(). Yeh, after a second reading through the assembly I figure you're right. Maybe I should sleep every now and againzzzzzzzzzzzzzzzz...... cheers, DaveK -- Can't think of a witty .sigline today.... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/