Nested upc_forall semantics

[Former user]

Originally reported on Google Code with ID 88

This is a successor of issue 47.

Nested upc_forall semantics. 
============================

The current specification calls for affinity statementes to be ignored, based on whether
the upc_forall loop currently being executed is "outermost" or not. Since upc_forall
loop nesting is completely dynamic, driven by control flow and function calls, there
is no real fool proof compiler analysis that can tell whether a forall loop's affinity
statement should be ignored or not.

Original proposal was to "outlaw" nested forall loops, changing UPC semantics to be
"undefined" when forall loops are nested.

a) Paul commented in issue 47 that the "undefined" option would break backward compatibility,
and would library writers hanging - they could *never* use forall loops since their
library might be called from within a forall loop.

b) Bill commented in the phone call on 9/21 that the original intent for the forall
design was to be used in the main() program only. As a point of morbid curiosity, I
would like to know whether upc_forall() was inspired by Fortran's DOALL?

c) Dan's proposal was to not "outlaw" nested forall loops straight away, but to slowly
phase them out by naming them "deprecated" in version 1.3, to be followed by more decisive
action in 1.4 or even 2.0.

Since no clear consensus has emerged, this issue is marked as Consensus-Low.

Reported by ga10502 on 2012-09-21 21:16:09

[Former user]

``` For completeness, note that I also suggested in issue 47 that we consider adding a dynamic query which would give a simple boolean indication if one is in a upc_forall context. This would allow library writers to use upc_forall when it is safe (independent of which semantic one choses for the nested case) and to fall-back to some other code when running in the context of a upc_forall.

I think this could be an entirely separate tracker issue if desired, but recommend deciding that on the next call rather than splitting it off preemptively ```

Reported by `[e-mail]` on 2012-09-21 22:07:56

[Former user]

Reported by `gary.funck` on 2012-09-22 17:08:42

[Former user]

``` Re comment 1: my oversight. I heard Paul mention the dynamic query, but it fled my consciousness by the time I was setting down things onto (virtual) paper.

```

Reported by `ga10502` on 2012-09-26 19:26:20

[Former user]

11/29 call we agreed this should be deprecated starting in 1.3.
I will draft some text

Reported by danbonachea on 2012-11-29 19:41:16 - Status changed: Accepted

[Former user]

Change proposal mailed 1/16/13:

--- upc-language.tex    (revision 199)
+++ upc-language.tex    (working copy)
@@ -999,6 +999,10 @@
     statements which are not controlling in a {\em nested
     upc\_forall} behave as if their {\em affinity} expressions were
     {\tt continue}.
+    \xadded[id=DB]{88}{
+    Nesting of {\tt upc\_forall} statements is considered an obsolescent
+    feature, and may be prohibited in a future revision of this specification.
+    }

 \np Every thread evaluates the first three clauses of a
     {\tt upc\_forall} statement in accordance with the semantics of

Reported by danbonachea on 2013-01-17 02:20:38 - Status changed: PendingApproval - Labels added: Consensus-High - Labels removed: Consensus-Low

[Former user]

Ratified at the 2/11/13 telecon and committed as SVN 202

Reported by danbonachea on 2013-02-11 22:54:12 - Status changed: Ratified