public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: Paolo Carlini <pcarlini@unitus.it> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, Subject: Re: c++/4762 Date: Tue, 13 Nov 2001 09:46:00 -0000 [thread overview] Message-ID: <20011119112603.22395.qmail@sourceware.cygnus.com> (raw) The following reply was made to PR c++/4762; it has been noted by GNATS. From: Paolo Carlini <pcarlini@unitus.it> 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
reply other threads:[~2001-11-19 11:26 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20011119112603.22395.qmail@sourceware.cygnus.com \ --to=pcarlini@unitus.it \ --cc=gcc-prs@gcc.gnu.org \ --cc=nobody@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).