Re: 1.5.12: FPU affected by gethostname call

["Ralf B. Schulz" <r dot schulz at dkfz-heidelberg dot 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/