From: already5chosen@yahoo.com   
      
   On Sat, 13 Sep 2025 22:00:28 GMT   
   MitchAlsup  wrote:   
      
   > 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 ?   
      
   I think that in above paragraph Thomas Koenig uses the word   
   'signalling' in a sense that differs from it's use in IEEE-754 standard.   
   He uses to mean, using 754 language, "Immediate alternative exception   
   handling block associated with a block". Ugh.   
      
   In more simple terms, Thomas probably meant to say that Fortran behaves   
   as if [under Windows] at the entry of the procedure we did   
    int old = _controlfp(_MCW_EM , _MCW_EM );   
      
   and at the exit from procedure we did   
    int old = _controlfp(_MCW_EM , old);   
      
   I'd guess that there exists POSIX equivalent for that, but I don't know   
   what it is.   
      
   > > 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 ?!?   
   >   
      
   I am not sure at all in specific case of sin() or in cases of other   
   standard functions from .   
   But for user's own or 3rd party procedures you are probably right.   
      
   > > Computationally, this can be quite expensive   
   >   
   > And contrary to how IEEE 754 has been used for 40 years.   
   >   
      
   I would not be so categorical.   
      
   Contrary to intentions of IEEE-754 committee?   
   Sure.   
      
   Contrary to real-world use of IEEE-754 compliant hardware?   
   That assumes that actual use (of non-default RMs) is somewhat   
   wide-spread, which I do not believe.   
      
   > >                                               - 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)