(j3.2006) IEEE and the GPU world

[Malcolm Cohen]

Bill Long wrote:
> It is uglier than that.  If a module has a USE of the IEEE_ARITHMETIC module, 
> and that module (possibly through several other modules) is used in a 
> subprogram, then the IEEE_ARITHMETIC module is accessible there.

Not necessarily.  A USE ONLY that lists only the stuff one wants would 
presumably not bring in anything from IEEE_ARITHMETIC et al unless it mentioned 
it.

> Even though the author of that procedure had no idea that is the case (since 
> there are no visible references to entities in the module).    I believe that 
> John's original points were that (1) the current wording in the standard is 
> not very consistent to start with,

If you say some of the wording is poor I'd have to agree, but I don't agree on 
consistency.  The latter seems to revolve around misreading "access" as 
"reference".

And although some of the wording is poor, mostly there is only one reasonable 
reading of it.

This applies especially to IEEE_FEATURES, where the effects are precisely 
specified in terms of the accessibility of its named constants.

As for IEEE_ARITHMETIC, this being accessible (and nothing else being 
accessible) implies very little - just support for IEEE_OVERFLOW and 
IEEE_DIVIDE_BY_ZERO.  That in turn only mandates detection of overflow or 
zero-divide, not whether you can do cute things with them.

> and (2) this side effect might not have been foreseen.

I would that thought it both obvious and desirable!  Highly undesirable would be 
if host association didn't work, so having to go through hundreds of module 
procedures putting USE IEEE_ARITHMETIC in them instead of one in the 
specification part.  If avoiding outer leakage was thought desirable, well 
Fortran 90 foresaw the need for that - a PRIVATE statement.

Also highly undesirable would be if use association didn't work - having to go 
through hundreds of source files to add e.g. subnormal number support instead of 
being able to do that at a higher level.

>  Some clean-up for (1) is desirable in any event.

There is certainly scope for editorial cleanup - I wanted to do some last time 
around but only had time to target the more obvious clangers.

I am much less convinced that there are sweeping technical changes to be made.

>   For (2), it might be desirable to limit the effects of the USE to 
> subprograms where it explicitly appears, and maybe module procedures where the 
> USE appears in the module. That would be a start.

That would be a very bad start indeed.

I don't believe we got much of this substantially wrong.  Without access to any 
of the named constants of IEEE_FEATURES, "the supported subset of features is 
processor dependent".  That is a pretty big hammer to have handed out, probably 
a big enough one for most people; as noted above, the minimum level of support 
is a pretty low bar to clear.

There is probably scope for useful extensions in a future revision to improve 
the handling of this kind of thing - better control over host association (e.g. 
IMPORT, ONLY: name-list) might be one of them.

Let not the GPU bacterium on the hair of the tail wag the dog.  At least wait 
until it grows into a flea.

Cheers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.