(j3.2006) ieee_set_halting_mode

[John Reid]

Bill Long wrote:
> Malcolm Cohen wrote:
>> Bill Long wrote:
>>> But then I looked in 10-007 and it says that
>>> ieee_set_halting_mode is a PURE Subroutine.  Is this just a mistake in
>>> the standard?  Certainly this routine is not PURE in any operational 
>>> sense.
>>
>> It certainly is in every operational sense.
>>
>> I "sense" that this question arises because different people have 
>> different ideas of what PURE means.  It means different things in 
>> different C.S.-like contexts, in particular Fortran PURE procedures 
>> are not "pure functions" in at least one of the traditional CS senses 
>> as they are permitted to read global state.
> 
> 
> That's fine. But ieee_set_halting_mode performs a WRITE of global state. 

I don't see where the standard says this.

>  That directly contradicts the first sentence of Note 12.49.  Which is 
> what I take as the "sense" of PURE in Fortran.
>>
>> The Fortran PURE is quite simply, it follows the rules in the Fortran 
>> standard. 
> 
> Then, it would appear that it is not possible to write a PURE subroutine 
> in C, since none of the constraints in the PURE section would apply to C 
> syntax.  Yet, if not at the first level, at least at some level 
> ieee_set_halting_mode calls a non-PURE procedure to set the processor fp 
> mask register for traps.

With 10**6 images, would you really work with a single register?

>> That's it.  These rules are designed to prevent communication between 
>> simultaneously (or indeed sequentially) executing PURE procedures. 
>> IEEE_SET_HALTING_MODE cannot successfully communicate between such 
>> procedures - the only procedure that gets to see any change in the 
>> halting modes is a procedure that is called by the procedure that set it.
>>
> 
> Where does the standard say that?  The normal use (indeed, the only use 
> I've ever seen) of ieee_set_halting_mode is to set the modes at the 
> beginning of a program the way you want them, to overwrite the system 
> defaults.  The user assumes that this state remains in effect throughout 
> the program.  Otherwise the subroutine is useless.
> 
> 
>> Depending on how the hardware supports IEEE, this might indeed require 
>> some action on the part of the compiler in order to provide the 
>> semantics specified by c14.  That is not philosophically or materially 
>> different from the actions needed by the compiler to support the way 
>> the IEEE flags behave, that is, the effects of arithmetic when there 
>> is some possibility that IEEE_GET_FLAG might be called.
>>
> 
> Flags are different in that c14 has specific rules about restoring flag 
> values on exit from a procedure.  I don't see any analogous rules for 
> traps. Indeed, such a rule would defeat the value of the procedure.

See 14.6 for the rule on halting mode: "In a procedure other than 
IEEE_SET_HALTING_MODE or IEEE_SET_STATUS, the processor shall not change
the halting mode on entry, and on return shall ensure that the halting mode is 
the same as it was on entry." It is purposely vague on when halting actually 
occurs: "Halting is not precise and may occur any time after the exception has 
occurred."

Cheers,

John.