To: J3                                                     J3/20-160r3
From: Gary Klimowicz&Rich Bleikamp
Subject: Technical issue UTI-007 in DO CONCURRENT REDUCE
Date: 2020-October-14

Reference: 19-252r2, 20-007

Background
==========

In F202x, we added a new locality clause, REDUCE.

In UTI-007, the editor commented that we describe an initialization at
the start of each iteration (which would be inefficient if actually
implemented for each iteration). We propose an edit to correct this
while retaining the initialization corresponding to the REDUCE operator.

Since the notion of thread-local storage is implied for REDUCE
variables, we can reword this to say that the construct entity is only
initialized once before the iterations begin.

A note was also requested to elaborate on the processor's freedom to
assign intermediate values to the construct entity.



Edits to 20-007r1
=================

{ 11.1.7.5 Additional semantics for DO CONCURRENT constructs }

{ UTI-007 Initialize the construct entity once for all iterations }

[190:31-32 p3]
  Replace
    "At the beginning of execution of each iteration,"
  with
    "Before execution of the iterations begin"

  So the last sentence of paragraph 3 reads

    "Before execution of the iterations begin, the construct entity is
     assigned an initial value corresponding to its reduce-operation as
     specified in Table 11.1."

{ the construct entity gets its value once for all iterations }


[190:32++] (after table 11.1)
Add this note: (note by Rich B, don't blame Gary)

" Note:
  A processor can implement a DO CONCURRENT construct in a manner such that
  a variable with REDUCE locality might not have the initial value from
  Table 11.1 at the start of every iteration."

{ Add a note }


[191:before line 1]

Delete UTI-007.



{ end }