Re: Infinite loop with GCC 4.3

[Joe Neeman]

On Mon, 2008-05-26 at 07:53 +0200, John Mandereau wrote:
> On 2008/05/26, Joe Neeman wrote:
> > Attached is the smallest example that I could find that reproduces the
> > problem. With g++ 4.3.0 on Fedora 9, I get an infinite loop with -O1 but
> > immediate termination with -O0. With g++ 4.2.3 on Debian, I get
> > termination regardless of the optimisation setting.
> > 
> > I think it is also easy to argue that the program should terminate,
> > regardless of rounding (the value of 'i' should be the same every time
> > the loop executes. So on the second time through, 'x' should be at least
> > as large as 'i').
> 
> I agree.

Well, it seems that I should have started by reading the gcc bug
tracker. This is a very popular bug:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

The summary is that you cannot expect sane behaviour with the double
data type using gcc (and apparently most other C compilers) on x86. In
particular, doubles may be truncated from 80 bits to 64 bits at any
time. Therefore, you can compare two (80-bit) doubles and find that they
are not equal only for them to become equal on the very next line.

The position of the gcc folks is that this is Intel's fault and so they
will not fix it. This leaves us with a few options:
1) Change Real to be a long double instead of a double (on x86 only?)
2) Compile with -msse on x86
3) Find some way of forcing a truncation (as suggested in comment #88 of
the above link)
4) Anything else?

Option 1 has the disadvantage that we have to change every instance of
max(0.0, some_real_number)
to
max((Real) 0.0, some_real_number)
and avoid similar situations in the future. This is especially true if
we only change the type on x86; then it's very easy for people on other
architectures (me on my x86_64 desktop, for example) to break the build.

Option 2 has the disadvantage that we exclude users with older
processors (possibly Via processors also?).

Option 3 has the disadvantage that it requires us to figure out where it
is needed. I am somewhat uncomfortable with the idea that any of our
floating point arithmetic could fail at any time and that we need to
rely on bug reports to find and fix breakages.

I'm inclined to go with option 1, at least on x86 and x86_64 where all
underlying operations are on 80-bit floats anyway. Other opinions?

Joe