[ Marquette | MSCS | Corliss | Vladik's Intervals ]
Interval FAQ: [ Entry page | Contents | Search ]
About Sun's f95 with Interval Support

Interval FAQ
Jack Chang -- How does compiler optimizatiom mode affect rounding?

From Jack Chang (chang@u.washington.edu), University of Washington:

How does compiler optimizatiom mode affect rounding?

I am wondering if compiler optimizatiom mode would affect rounding. It looks like that the egcs(gnu) compiler would overwrites rounding control if optimization is turn on. However, if I specify that no floating point variables should store in registers, the rounding control would be working at least for -O1 and -O2 for the egcs compiler. Nonetheless, the performace would suffer a great deal. For instance,

if no optimization, (g++ -O0 ...) or with -ffloat-store flag turned on 

[RNEAR(3.0/7.0),RNEAR(3.0/7.0)] =
[0.42857142857142854764, 0.42857142857142854764]

[RDOWN(3.0/7.0),RUP(3.0/7.0)] =
[0.42857142857142854764, 0.42857142857142860315]
with optimization (g++ -O1 or above) 
[RNEAR(3.0/7.0),RNEAR(3.0/7.0)] =
[0.42857142857142854764, 0.42857142857142854764]

[RDOWN(3.0/7.0),RUP(3.0/7.0)] =
[0.42857142857142854764, 0.42857142857142854764]
Is there any way to fix the problem? Please advise,

Jack Chang

Response by Juergen Wolff v. Gudenberg:

(wolff@informatik.uni-wuerzburg.de), Lehrstuhl fuer Informatik II, Universitaet Wuerzburg

The advice to take some regions out of the optimization is ok for the moment, but I like to stimulate a slightly more general discussion of the topic.

We found similar problems with optimizing compilers and floating-point arithmetic.:

  1. Switching of the rounding mode is not considered to have any influence on arithmetic operations, so it is moved out of loops etc.
    possible solution:
    ==> compiler writers should learn the dependence between rounding and arithmetic.
    even better solution:
    ==> computer architects should learn that rounding belongs to an arithmetic operation and provide us with such combined operations instead of manipulating a control register.
  2. Different word-length in register and memory causes problems when comparing to numbers.
    possible solution
    ==> I think that compiler writers do their job correctly here, they could issue an explicit warning. Computer architects should not be blamed for providing more precision. So we have to avoid those comparisons or use it consciously.
  3. If x == NaN, then x > y and x <= y both deliver false according to IEEE 754.
    possible solution:
    ==> compiler writers may not change a floating-point comparison in order to save branch instructions.

Juergen WvG

Response by Nelson H. F. Beebeg:

(beebe@math.utah.edu), Center for Scientific Computing, University of Utah:

Jack Chang (chang@u.washington.eduk) writes on Fri, 18 Feb 2000 11:34:16 -0800 (PST) about a problem with rounding control in gcc with the -ffloat-store flag.

This is a bug; I reported it several weeks ago, and received patches for gcc-2.95.2 that will make it into the next release (date unknown).

Jack, if you are interested, mail me privately, and I'll dig them out of my mail archives. Otherwise, you could revert to the gcc 2.7x releases, were -ffloat-store works as expected.

Nelson H. F. Beebe

[ Marquette | MSCS | Corliss | Vladik's Intervals ]
Interval FAQ: [ Entry page | Contents | Search ]
About Sun's f95 with Interval Support

If you have a question related to validated computing, interval analysis, or related matters, I recommend

This page URL: http://www.mscs.mu.edu/~georgec/IFAQ/chang1.html
Last modified February 27, 19100. Send comments to (georgec@mscs.mu.edu)
Access count since 20 Apr 1999 : Graphical counter