(j3.2006) (SC22WG5.4802) [ukfortran] Fourth WG5 ballot on interpretations

[N.M. Maclaren]

On Sep 26 2012, Malcolm Cohen wrote:
>Nick Maclaren writes:
>>
>>Upon checking on what this meant, I believe that the lists in tables
>>14.1 and 14.2 contain some errors.  Specifically, I can see no reason
>>for IEEE_GET_ROUNDING MODE and IEEE_GET_UNDERFLOW MODE not to be pure
>>(but they aren't),
>
> It's possible that these were made non-pure to make them, or elemental 
> procedures, easier to implement. That's not a very compelling reason,
> but  it is not quite no reason.

I still can't see it, given the other PURE procedures, but I take your
point that someone else might be able to.

>> but I can see good reasons for IEEE_SET_FLAG and
>>IEEE_SET_HALTING_MODE not to be (and they are).
>
> All of the functionality of IEEE_SET_FLAG that is visible outside the 
> calling routine (the set flags in the called routine are merged into the 
> flags of the calling routine) is already present in ordinary 
> floating-point arithmetic. Therefore unless you wish to forbid X+Y inside 
> an elemental procedure, there is absolutely no point in forbidding 
> IEEE_SET_FLAG.

That wasn't my point, and the last statement doesn't follow.  I was
thinking of the implementation.  You can't clear a flag that way and,
at least on some systems, clearing one bit of such state without
causing other problems can be non-trivial.  Indeed, on some pre-IEEE
systems, it used to need privilege, but I can't remember how the
various IEEE 754 architectures do it.

While Fortran does not support threading, it does not forbid it and
several language extensions use it, and doing that might well need
taking out a lock (probably uniquely in Fortran PURE intrinsics).
Let's not get onto the spectacular mess that almost every threading
specification makes of such state, and merely note the importance of
virtual threads, where this can become decidedly tricky.  When setting
flags in simple arithmetic, the hardware gets the thread affinity
correct automatically (or is broken).

> Similarly, the effects of IEEE_SET_HALTING_MODE are not visible to the 
> caller. Reasonable minds may differ on this one, since it runs counter to 
> the possible rationale mentioned above for IEEE_GET_ROUNDING_MODE et al.
>
> But anyway, according to the Fortran standard, IEEE_SET_HALTING_MODE has 
> no side-effect, because the model is that the halting mode is restored on 
> return from the procedure.

I was thinking of the implementation.  In particular, the remarks about
potentially needing locking are redoubled in spades for this one.

>>  However, even if true,
>>that is a matter for a separate interpretation.
>
> Please no. If you think it is a wart, it is a matter for a future 
> revision. These are not a recent addition - far from it, they are a 
> widely implemented part of F2003 and the original TR describing them was 
> last century! I certainly see no actual error.

Correction accepted.  That was a simple mistake.


Regards,
Nick Maclaren.