From: user5857@newsgrouper.org.invalid   
      
   Thomas Koenig  posted:   
      
   > Fortran has an optional IEEE module.  One of its important features   
   > is that flags (IEEE exceptions) are set to quiet on entry of a procedure   
   > and restored to signalling if it was signalling on entry, or keep it   
   > signalling if it was raised on in the procedure.  Similarly, rounding   
   > modes are saved and restored for procedures.  This is automatically   
   > done if the right IEEE modules are used.  A user can set rounding   
   > modes or set and clear exceptions using the right modes.   
      
   How does a user set up his environment such that if TAN()* overflows   
   to infinity it returns with the OVERFLOW flag set ?!?   
      
   (*) EXP(), POW(,)   
      
   Conversely, how does one write a TAN()* subroutine with the above property ?   
      
   > Conceptually, this is the right thing to do.  A library routine should   
   > not produce different results depending on what a user did for his   
   > own calculations.   
      
   I would think that a user setting RM=ToZero would WANT a different   
   result from SIN() than the same call with RM=RNE ?!?   
      
   > Computationally, this can be quite expensive   
      
   And contrary to how IEEE 754 has been used for 40 years.   
      
   >                                               - having the meaning   
   > of a calculation changed by changing FP state should (I hope so,   
   > for corecntess's sake) flush any calculations done with the wrong   
   > FP mode.  Just calling a small library routine which does so could   
   > be enough.   
      
   Oh, and BTW, how does a user CALL a subroutine to set his RM when   
   the RETURN undoes the very nature of his request ?!?   
      
   > An example of the high cost is   
   > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121570 where, depending   
   > on the library implementation, gfortran may be over-cautious   
   > for the ieee_next_after function by saving and restoring fp state,   
   > but I'm not sure that the overhead is actually from the FP state or   
   > from calling extra functions.   
   >   
   > So... What is the best way to do allow this to be more efficient?   
      
   UN DO this change to IEEE 754.   
      
   > The CPU could speculate on the FP mode (not sure if that is actually   
   > done).  Other suggestions? How do current CPUs do so?   
      
   Multi-threaded cores already have to ship different RMs to FUs on   
   each FP instruction. The HW is all there--its the ISAs that are screwed   
   up.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)