(j3.2006) IEEE and the GPU world

[John Reid]

Van Snyder wrote:
>>>> "scoping unit" should be "scope" throughout Clause 14 since we don't 
>>>> want to require IEEE compliance within an entire scoping unit if there 
>>>> is a USE statement for an IEEE module within a BLOCK construct.
>>> A BLOCK construct is a scoping unit, so that wouldn't do anything.
>> I think Van means "inclusive scope" and I have (tentatively) changed my draft 
>> interp to say that we goofed when we introduced "inclusive scope".
> 
> In retrospect, I think "scoping unit" was after all the correct term.
> 
> Consider two cases.
> 
> One is a subroutine with "use IEEE_ARITHMETIC" containing a block
> construct without it.  Does the mandate to support IEEE features extend
> into the block?  With "scoping unit" I think it does 

Well, 14.1:p3 says
"If a scoping unit does not access IEEE_FEATURES, IEEE_EXCEPTIONS, or 
IEEE_ARITHMETIC, the level of support is processor dependent, and need not 
include support for any exceptions."
so I disagree with you.

 > unless one has
 > something like "integer IEEE_ARITHMETIC" in the block.  The declaration
 > blocks the use: "any entity of the host that has this as its nongeneric
 > name is inaccessible by that name by host
 > association" [10-007:444:22-23].

The idea of "integer IEEE_ARITHMETIC" is interesting, if a very obscure way of 
saying "this block may be implemented on a GPU". Actually, I think we need
"integer IEEE_FEATURES, IEEE_EXCEPTIONS, IEEE_ARITHMETIC". Should the interp add 
a note explaining this?

> The other is a subroutine without "use IEEE_ARITHMETIC" containing a
> block construct with it.  Does the mandate for IEEE support extend
> throughout the subroutine?  With "scoping unit" it does not; with
> "inclusive scope" it does.

Do we want the possibility of a block and its host being implemented on 
different hardware? As we have it now, this is a possibility. I thought this was 
a mistake. What do others think?

Best wishes,

John.