(j3.2006) 17-144r2

[Van Snyder]

In light of Dan's assertion that processors already have the machinery
for locality specs in the form of support for OpenMP locality specs, and
Daniel's assertion that the definitions in 17-144r1 did not sufficiently
sharply distinguish between shared and unspecified locality, I have
prepared and uploaded 17-144r2.

There were numerous problems noted in 17-144r1 that had nothing to do
with whether locality is explicitly specified or inferred, and there
were attempts to address those problems, which attempts had nothing to
do with whether locality is explicitly specified or inferred.  For
example, what happens if a pointer that has one locality becomes
associated with a variable that has different locality (just one of many
questions)?

Subgroup really ought to have studied 17-144r1 instead of reading the
subject line and rejecting it at that point.

17-144r2 proposes either to delete locality specs because they can be
provided by OpenMP directives (or Dan was mistaken and locality specs on
the DO CONCURRENT statement in fact do impose a burden on implementors),
or to replace them with only a SHARED locality spec to cover the cases
not covered by the definitions of shared locality in 17-144r1 (it would
be interesting to know what those cases are).

Even if neither of these approaches is adopted, the numerous problems
highlighted in 17-144r1 and 17-144r2 need to be addressed, or we might
well publish a corrigendum for the new standard before the new standard
is published.