Re: glibc conditioning

[Geoff Keating <geoffk at geoffk dot org>]

> Date: Mon, 27 Aug 2001 14:28:30 -0700 (PDT)
> From: Jinsong Zhao <zhaojs@cadence.com>

> Andreas Jaeger <aj@suse.de> directed me to report the problem to this
> mailing list. I work at Cadence Design Systems. For those people who
> don't know us, Cadence is the largest Electronic Design Automation
> software vendor, and our tools are used by almost every IC designers.
> 
> Lately I ported some codes to Linux (redhat 7.0), hoping to run codes
> faster on a cheaper platform. Formal releases of our tools run on
> Sun/HP/IBM workstations. Though the code runs much faster on Linux,
> the problem is that ... results are entirely different from those we
> have on workstations. I found the problem reported in
> 
> http://www.srware.com/linux_numerics.txt
> 
> is the most relevant. In my case, in gdb I can see that two variables
> a and b, both double, are the same up to 16 digits, yet if(a==b) fails
> on Linux while on Solaris (compiled under gcc) it succeeds. Then I
> would have different sorted order of some data structure. Then it's no
> surprise the results are different. The problem is that we use a lot
> of legacy codes and debugging those codes is extremely difficult.

Are you sure that what you see is the specific difference reported at
that URL?

There are many things that can cause different results, including:

1. excess precision of the x86 FPU
2. bugs in the program (for instance, endianness issues)
3. more accurate elementary functions
4. more accurate text<->FP conversion

Of these, the first two are hardware issues, the last two are library
issues.  The first can be dealt with by setting the FPU into a
different mode---others on the list can tell you better how to do this.

The URL refers to (4) of these.  The author appears to be
arguing that atoi("0.3") should not be equivalent to 3.0/10.0,
but I can't see precisely what he claims it _should_ be.

-- 
- Geoffrey Keating <geoffk@geoffk.org>