Not a bug, but a big trouble indeed

[Jeffrey A Law]

  In message < 34D3390A.721E992D@di.unipi.it >you write:
  > So far, so good.
  > Here gcc enters the picture.
  > The CSE phase ignores (understandably) the changes in the rounding mode,
  > and this causes incorrect results.
  > For instance, if we have the declaration
  > 
  >    float /* or double */ a, b, lower, upper;
  > 
  > it seems that, after CSE, the fragment
  > 
  >   round_save();
  >   round_down();
  >   lower = a + b;
  >   round_up();
  >   upper = a + b;
  >   round_restore();
  > 
  > becomes indistinguishable from
  > 
  >   round_save();
  >   round_down();
  >   lower = a + b;
  >   round_up();
  >   upper = lower;  // HERE!
  >   round_restore();
[ ... ]

  > Is there a way around this problem (besides the obvious one
  > of compiling without optimizations)?
Not that I'm aware of -- it looked like you already had the volatiles
in the asm which would have been your only hope.

  > Is it possible to tell gcc: "look, when I call round_xxx() there is no
  > guarantee whatsoever that the floating point quantities computed
  > _before_ the call are equal to the quantities having an equivalent
  > expression but computed _after_ the call"?
  > 
  > Perhaps some (yet to be implemented) attribute?
Hmmm.  Basically you're changing things in the fpu that the compiler
can't know about which cause normally valid optimizations to become
invalid.

Maybe the way to go would be some kind of way to specify in the asm
that it alters *state of the entire machine* in an unknown way.  Which
would be implemented by having cse forget everything when it encountered
such instructions.

jeff