Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm 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 From: "Ralf B. Schulz" Organization: DKFZ To: Subject: Re: 1.5.12: FPU affected by gethostname call Date: Wed, 23 Feb 2005 17:41:48 +0100 User-Agent: KMail/1.5 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502231741.48661.r.schulz@dkfz.de> Long doubles are 12 byte = 96 bit = sizeof(long double). No matter whether stored in memory or in registers, they should have that length, no? The -ffloat-store option does not make a difference (at least not in the first 7 digits). However, there is a significant difference between the version calling gethostname() --> p1 results in 1.11022e-16 (or, if "tolerance" is set to 1e-19, it stops at p1 = -5.5e-17) and the version without that function call --> p1 results in 8e-17 (or, if "tolerance" is set to 1e-19, it goes right down to 0). The program I mailed is an excerpt from a large project (the deal.II library, www.dealii.org) which runs fine on a lot of Linux and other Unix systems, on all kinds of processors and multiprocessor environments, but the part I sent you does not terminate if run under cygwin, in case gethostname() is called from _anywhere_ in the program. It doesn't even matter when gethostname() is called, its effect is visible after the call throughout the program (!). In the case of the original program, gethostname() is called in some startup code, the loop causing the problems is called at some completely different point in the program. It seems unlikely that this should have an effect on whether or not variables are stored in registers. In the original code, tolerance is set to 1e-19 instead of 5e-16 if long doubles are available. In this case, the code calling gethostname() goes into an infinite loop. -Ralf On Wednesday 23 February 2005 16:15, Dave Korn wrote: > -----Original Message----- > From: cygwin-owner On Behalf Of R.Schulz > > >Sent: 23 February 2005 14:28 > > > >the following c++ program (see below) is affected by a strange bug: > > floating > > >point precision is decreased by uncommenting the call to gethostname(). > > > >* if you change the long doubles to normal doubles, values seem to be not > >affected by the gethostname call > >* the resulting values for double precision are equal to the values > > obtained > > >with long doubles in case the gethostname() function is invoked > > I'd bet the -ffloat-store flag makes a difference too. This is a > well-known issue with x86 floating point implementations: > > http://gcc.gnu.org/ml/gcc-help/2005-01/msg00173.html > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 > http://gcc.gnu.org/ml/gcc-help/2005-02/msg00081.html > http://www.vinc17.org/research/extended.en.html > http://www.srware.com/linux_numerics.txt > > http://www.google.co.uk/search?q=+site:gcc.gnu.org+x86+extended+precision+c >o > mpiler+problem&hl=en&lr=&client=firefox-a&rls=org.mozilla:en-US:official&st >a rt=20&sa=N > > To summarize: inside the FP registers of the cpu, long doubles are > stored in extended (80-bit) precision format. When these values have to be > stored to memory locations, however, they are truncated to 64 bits. So you > get different results from a calculation depending if it's entirely done in > registers or if some of the intermediate results need to be spilled to the > stack, or otherwise stored in memory. > > In this case, the FP registers are presumably being saved and restored > owing to the call to gethostname, so that's why removing the call fixes it. > > If you use normal doubles, you're only ever working with 64-bit values, > so that's why changing to doubles gets the same result as long doubles with > the function call uncommented, even if the registers are not in this case > spilled to memory. > > > cheers, > DaveK -- ----------------------------------------------------- Ralf B. Schulz, Dipl.-Inform. Med Functional and Molecular Emission Computed Tomography Dept. E020 Medical Physics in Radiology DKFZ -- German Cancer Research Center Im Neuenheimer Feld 280 D-69120 Heidelberg, Germany phone: ++49 (0) 6221 42-2606 fax: ++49 (0) 6221 42-2572 web: http://www.dkfz.de/en/medphysrad/ect/team/rschulz.html -- 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/