From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22431 invoked by alias); 19 Nov 2001 11:26:05 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 22396 invoked by uid 71); 19 Nov 2001 11:26:03 -0000 Date: Tue, 13 Nov 2001 09:46:00 -0000 Message-ID: <20011119112603.22395.qmail@sourceware.cygnus.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Paolo Carlini Subject: Re: c++/4762 Reply-To: Paolo Carlini X-SW-Source: 2001-11/txt/msg00290.txt.bz2 List-Id: The following reply was made to PR c++/4762; it has been noted by GNATS. From: Paolo Carlini To: gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, pmu@sun3.oulu.fi, nobody@gcc.gnu.org Cc: Subject: Re: c++/4762 Date: Mon, 19 Nov 2001 12:12:33 +0100 Hi, it looks like the bug cannot be reproduced. I received these exaplanations from Petri. Cheers, Paolo. ///////////////////// Hello, Thank you for your email. The current history of the bug is following; while coding a numerical program doing lengthy calculations (more than 50 hours), I came around some weird behaviour. The program has a linked list driving a numerical module with different parameters. For some unknown reason, every 18th or 42th (depending on the platform) came out as NaN (it took about 5 hours to reach that point). After three weeks of intense debugging I was able to track down the bug into two subroutines (the program has more than 10000 lines of code in it). That's when the weirdness started. When examining the calculations producing NaN in debugger, none of the variables where it came from by adding, subtracting, multiplying or dividing were NaN. Some times sin() gave NaN. Few times even a variable defined as constant was mysteriously changed to a NaN. I checked the code for memory leaks, and found none. The size of the program was not increasing during execution. I tried memory guardian libraries (as Electric fence), which found nothing. I went through the code many times and did'nt found any leaks or wild pointers; all the reserved memory areas were released consistently. The NaN seemed just to pop up as it pleased. Then I started to search web for similiar bug reports, and found some. Few reports were written about NaN:s and unconsistent behaviour of the floating point libraries. That's when I wrote the program in the bug report and noticed it producing NaN:s. I ran it over one weekend, and it gave out one NaN for about 1e9 calculations of sin() or cos(). That's when I wrote the report. Afterwards, I gave the code in the report to some friends of mine, and they were NOT able to reproduce the bug (with Redhat 7.2). My mentioning about stack overflow was only a wild guess and propably a wrong one. However, I was able to get rid of the problem by nuking the RedHat installation in my workstation and reinstalling newest version of it (7.2). At solaris platform the problem was delt with by using a Sun complier. So the final reason of the bug is still open. But the original program is working just fine! I noticed that the my report was hmmm... less than graciously done, but that is result from local paranoia; I have the sendmail disabled in my workstation, and I use other computer for emails and such. So, I'm sorry for the mess. I hope that these emails are going where they should go... Best wishes, Petri Mutka http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&pr=4762&database=gcc